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

[Chema Celorio <chema ximian com>]

On 14 Jun 2001 01:43:53 +0200, Lauris Kaplinski wrote:
> 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.
>  

agree.

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

Ok. What about my proposal to call gnome-spooler with the flags so that
we can later take care of that ?

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

agree. Also adding a random code is a big security risk so we need to
be carefull about it. Lets not bother with constraints at this point
we can later look into fixing that problem.

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

The key= value= thing makes me think of shell config files. I don't
think that the dificulty of writing the DTD should be an issue of 
deciding how to define our data.

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

yes, this is a problem. Lets fix it later ;-).
All the problems we can fix later lets leave them for later.
The task is already very big and we can't solve everything on
the first implementation. We will need to revisit this issues, but
i am tryting to make the smaller task we can. 

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

I think it is importatn if we write a couple of sample xml files while
we discuss the format. The sample files are very helpfull. Lauris :
can you modify the old format to the new format at least for one printer
so that we can start writing down the desitions. Based on this format we
can then propose chagnes to it.

regards,
Chema

> 
> Best wishes,
> Lauris Kaplinski
> 
> 
>