Re: [Gnome-print] Printer & model description files

[Chema Celorio <chema ximian com>]

I like this XML definition. Some comments :

On 11 Jun 2001 04:12:52 +0200, Lauris Kaplinski wrote:
>   Resolution - list of resolution names (should be included)

There are some backends that are resolution agnostic, like the PDF
driver. The applications and systems should be able to print when the
resolution is either unknown or there isn't a real resolution.

> Transport
>   Backend (basically spooling system to use, like file, lpr...)
>     - various backend-specific keys

But transports are not going to be handled by gnome-print anymore,
right ?

> 
> Output.Media.MediaType - paper type (glossy, ...)
> Output.Imaging.Mode - color, bw...
> Output.Imaging.Density - well, that may have children...
> Output.Imaging.ColorSpace - colorspace if Mode == color, color
>   correction should be in subtree for given colorspace
> Engine.Backend.PSLevel - PS level, if Backend == PostScript? or backend
>   is GhostScript? I am not sure, b-e should be PS, gs some subtype
> Device.InstalledMemory - printer memory
> Device.MediaSource - trays, ...

sounds good.

> 
> I have thought, whether to add "LogicalSize" to Media. I.e. application
>   can set different logical page size, and there will be option, whether
>   you want to scale, tile or crop result

> 
> I'd like to use '.' as separator, mainly because it makes the access
> similar to ECMAScript/JavaScript. Mybe one day the configuration data
> is stored in DOM and we can use JavaScript to create dialogs ;-)

hmm. I'll pass ;-).


> Well, constraints.
> I have not touched these, but I think gpa structure does make sense.
> One super-cool but probably too complex to implement, would be to
> specify constraints as ECMAScript/JavaScript expressions (to be verified
> whenever system tries to set some setting value). Not that it
> is absolutely needed, but it would remove the necessity to implement
> Yet Another Control Language - as I understood that PPD contraints
> could be quite complex.

But why ECMAScript/Javascript ? the users usualy don't have this
interpreters installed. The idea is great, because we don't have to
write complex code or anything, but i would prefere using python or
scheme/guile.


> 
> Printer:
> 
> Header:
> 
> <?xml version="1.0"?>
> <Printer Id="STYLUS-COLOR-740-000989526338006212000000">
>   <Name>Stylus Color 740</Name>
>   <Model>STYLUS-COLOR-740</Model>
> 
> That's all. Again we can add additional information.
> Ah, forgot. For gp, I modified naming schemas, so model files are not
> fixed length, and printer names are composed, as:
> MODELNAME-XYZSOMEIDVALUE.printer
> So they are easily locatable by hand.
> 
> Settings:
> 
>   <Settings Id="SETTINGS-000989526338006212000001">
>     <Name>Default</Name>
>     <Key Id="Engine">
>       <Key Id="Backend" Value="omni"/>
>     </Key>
>     <Key Id="Output">
>       <Key Id="Media">
>         <Key Id="PhysicalSize" Value="A4"/>
>         </Key>
>       <Key Id="Resolution" Value="360x360"/>
>     </Key>
>     <Key Id="Transport">
>       <Key Id="Backend" Value="file">
>         <Key Id="FileName" Value="output.omni"/>
>       </Key>
>     </Key>
>   </Settings>
> 
> Here are only part of option trees, that may change. Everything else is
> read from options anyways.
> Well, specifying keys as xml nodes is not necessary. Instead we could
> use approcah similar to original gpa. I do not know, which would make
> more sense. As I implemented settings as tree of nodes too, writing
> xml was more straightforward.

Yes, i think the "Key" is just saying that it is a node. I would prefer
if we removed it :

<Settings>
  <Id>0009090900900</Id>
  <Name>Default</Name>
  <Engine>
     <Backend>omni</Backend>
  </Engine>
  <Output>
     <Media>
        <PhysicalSize>A4</PhysicalSize>
     </Media>
     <Resolution>
        <ResolutionX>360</ResolutionX>
        <ResolutionY>360</ResolutionY>
... etc
   
> Namespacing.
> I do not think adding namespace to each node does make sense. AFAIK xml
> spec allows you to add single namespace indicator to header, and all
> node inherit it, unless specified otherwise.

XML will write the root node namespace to all the nodes by default.

> 
> Translation:
> Probably will be something like:
> <Name>
>   <Value Language="ee">Hää ja kiire printer</Value>
>   Default Name Here
> </Name>
> Or we can put default value into its own node (I have to check, what
> XML says about such constructs).

I think we should use the xml-i18n-tools for this, the format for
translatable nodes is :

<_Name>HP Printer</_Name>

And then the xml-i18n-tools go and put Name in the .po files. 

> 
> About PPD imports:
> We have to fix quite big set of configuration keys. If there are
> unknown ones, these may go into certain spot, like
> Device.Other
> Together with GUI info etc. So one will be able to construct
> advanced printer setup dialog, which allows changing these values -
> but most certainly these would only clutter basic dialogs.
> 
> Well, again my idea:
> There canbe enormous number of configuration keys. Certain set of
> these are known by gnome-print dialogs. If there is more (and these
> are important), printer should specify its own configuration
> widgetry, possibly by providing known key, like:
> GUI.Module
> 
> So, comments?

In general i like it. I don't Love


<Options>
  <Option Id="Engine">
    <Option Id="Backend" Type="List" Default="omni">
      <Item Id="omni">
        <Name>OMNi</Name>

I rather have the old format :

<Options>
  <Option>Engine</Option>
    <Option Type="List">Backend</Option>
      <Item>omni</Item>
        <Name>OMNi</Name>

...

About the Default settings, it is better to have them outside on a node
because when we include nodes, we might want to specify a different set
of defaults. If they are inside the options, whenever we share nodes we
will have to share the default settings. 

> 
> Best wishes,
> Lauris Kaplinski
> 
> 
> 
> 
> _______________________________________________
> Gnome-print maillist  -  Gnome-print@helixcode.com
> http://lists.helixcode.com/mailman/listinfo/gnome-print
> 



_______________________________________________
Gnome-print maillist  -  Gnome-print@helixcode.com
http://lists.helixcode.com/mailman/listinfo/gnome-print