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

[Lauris Kaplinski <lauris ximian com>]

Hello!

On 13 Jun 2001 12:52:14 -0500, Chema Celorio wrote:
> 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.

Well, resolution is useful anyways. Like the question - if certain
paint method (ex fractal fill) cannot be used directly, which resolution
bitmap to use. That affects pdfs too.
Also - for calculating font metrics, resolution HAS to be known. For
PDFs etc. I think there should be implicit system default 600dpi.
But - of course - you CAN omit almost every setting, in which case
whatever driver chooses the one, most appropriate for it.
Ah, yes - seems that PDF needs a bit tailored print dialog anyways
- if it uses resolution, it has to be numeric, not list.
 
> > 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 ?

No, they are. Even, if there will be universal CORBA (Bonobo?) based
gnome-printserver, I think we'll use at least 2 transport classes:
FILE
PRINTSERVER
Unitl then, there will be:
FILE
LPR
COMMAND? for things like invoking gfax
Of course, we do not need modules for those, they can very well be
compiled in, but having tansport objects does make sense.

> > 
> > 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.

Well, margins
Output.Media.PhysicalPage.Margins.[X0,Y0,X1,Y1]

> > 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.

Whatever.
Javascript has wonderful syntax, so I like it ;-)
But the main idea is, that we either will implement simple constraining
solution - or, if complex one is needed, borrow complex one from some
existing interpreted language.

> > <?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

Well, we can add aliasing for well-known options. But if everything
would be written that way, AFAIK writing DTD will become major pain.

> > 
> > 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. 

Agree, that existing technology should be used.
Still, there is specific problem - quite possibly gnome-print definition
files are more dynamic, than (maybe) gnome-print intself, and certainly
more dynamic than bonobo ui definition files of well-known projects.
Which creates po-updating problem. I.e. there is no other way to add
printer definition with translation, that to update some big existing
po file.


> > 
> > 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>
> 

Wait ... name has to be a child of Item:omni
The markup will become ugly, if content and subnodes are mixed - that
was the reason, I used attributes at first.
Also I have obtained a view, that character data should be used in XML
mainly for things, that are semantically texts - i.e. for names &
descriptions, but not for id-s etc. Actually this is hair-cutting, as
in DOM-level attributes are specific nodes anyways - but well - your
design seems to forget the existence of attributes at all ;-)
Also using "id" as attribute is more close to DOM-based xml-tree
representatioon systems known to me - but that may well be
SVG-ism...

Best wishes,
Lauris Kaplinski



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