Sorry - fixed now Re: [Fwd: Summary of the LSM Free Software Printing Summit]

[Zenaan Harkness]

Terribly sorry about redundant posts - my Enter key was being CTRL +
Enter, and my input subsystem couldn't be reset (at least, not that I
knew how), so I rebooted. (Yes, I tried hitting my keyboard control keys
in case they were stuck, but that didn't fix anything either - they
could possibly have been the problem, but it's a new keyboard and I
haven't had that problem on this keyboard before.)

I shall finish and correct my comment(s). I've snipped parts unrelated
to my comments, in the interests of everyone's sanity :/

Thanks for bearing with me,
Zenaan


On Fri, 2004-07-16 at 06:19, Roger Leigh wrote: 
...
> Proposed PPD extensions
> - -----------------------
> 
> Patrick Powell then started an unplanned (but very interesting)
> discussion about the shortcomings of current PPD files and user
> interfaces.  Currently, PPDs may only contain a single language, which
> makes internationalisation difficult (translated PPDs are not
> typically distributed with Debian due to the sheer size).

If this is implemented, this will make printer PPD "driver"
integration pretty straightforward - we simply automate the
extraction of the relevant information from the PPD file, eg:
 - which 'low level' drivers supported (and which kernels)
 - which translations are included
 - printer features

I imagine the truly canonical location for all this information
to stay as inside the PDD file. And, for a nice searchable DB
(hfdb) to be a really useful thing for people looking to purchase
a printer and/ or looking for driver/ os options. The hfdb will be
able to cross reference the PPD printer info with low-level driver
info, to provide something quite useful.

HAL wll be able to make use of "maximal feature support" metric
to auto-choose 'best' low level driver for the printer the user
just plugged in, as well as take advantage of auto-generated hal
xml printer descriptor files (these can come straight from PPD,
or if it is useful to include cross reference info with other
drivers, hardware interfaces (eg. usb, firewire), then from
hfdb (which is what I'll personally be focusing on)).

So the way I'm imagining the data transformation flow at this point
is:

  PPD -> hfdb -> xml -> hal

Now printer data submissions may well come from multiple points:
 - obviously at the moment, still from linuxprinting.org
 - hfdb, once we start accepting submissions
 - hal - perhaps some automated "new data submission" thing (?)
 - wherever

Our intention is to at a minimum have hfdb become a single distro-,
device- and kernel- email submission point, and ideally unify the
disparate hardware info databases community-wide.

Given that PPD files are text, we can simply diff any changes between
versions, in order to add updates to hfdb. Or remunge them into hfdb or
whatever works. It's possible there might be reasons to maintain the
canonical data in hfdb's DB (SQL db at the moment, perhaps XML later),
and generate the PPD files from that - but I don't think this is a
necessity.

...
> How Not to Build a Printer Database /or/
> Printer Configuration is not as Simple as I Thought
> - ---------------------------------------------------
> 
> On Friday, Patrick Powell talked about "How Not to Build a Printer
> Database".  Patrick has been working on the next generation of
> Foomatic (version 4) and intends to replace the current database used
> to generate PPDs with plain PPDs (which can have the necessary
> information extracted from them on demand).  This aims to simplify the
> information by having a single PPD for each printer model, which would
> support all of the drivers that work with that model.  In addition,
> his new scheme to allow translation and help comments in PPDs would
> allow translation of non-modifiable, copyrighted PPDs without
> violating any copyright, since they can simply be tacked onto the end
> of the file, without touching the original content.  The differing
> requirements and management of small home/office users and users of
> large corporate networks were also discussed.

My comments above should perhaps have gone here. Anyway, hopefully
it's clear enough.

...
> Colour management
> - -----------------
> ...
> There is no doubt that colour management is the future, but since this
> will require significant cooperation between projects to work upon a
> unified method of managing colour throughout the whole printing
> "workflow", in addition to significant reworking of individual
> projects, this is certainly possible, but will take some time to
> realise our goal.  For Gimp-Print at least, this will not be possible
> until after our 5.0 release (hopefully in November).

I suspect that hfdb (and possibly hal) are right on target to be
useful supporters of such this color management effort.

We should perhaps find out what freedesktop.org and/ or other lists
are or will be related, to keep with the pulse of things. If anyone
has list subscription suggestions, I would appreciate it.

...
> Ghostscript
> - -----------
> ...
> Additionally, he would like to be able to simplify Foomatic by
> allowing the gs device and other command-line-only options to be
> specified in the Postscript directly so that all of the required
> options can be specified directly in the PPD.

This sounds like similar goals as above. Looks like there is
common ground with these different projects moving forward.
Great to hear.

...
> Gimp-Print
> - ----------
> ...
> Integration colour profile support is only half of the colour problem.
> The other is actually creating the profiles, which requires special
> equipment and lots of time.  Ideally some means by which users could
> tune their own printers would be a partial solution, but the hard part
> is having a known standard with which to compare the printed output

For anyone who knows - surely this is something that the
manufacturer's themselves already do?

...
> Paper handling
> - --------------
> 
> OpenPrinting defines a set of paper sizes and standardised names based
> upon the ISO and US paper sizes, amongst others.  libpaper could be
> enhanced to support the additional metadata and paper sizes.
> 
>   ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf and
>   ftp://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn10-20020226-5101.1.pdf
>   (available in a few weeks)
> 
> In particular, the support for standardised names, aliases and storing
> the paper sizes in any common unit of measure (while allowing for
> conversion into the type required by the user) are desirable.  For
> each paper, a "legacy name", multiple aliases, and a "self-describing
> name" (including dimensions and units) are defined.  We should
> probably also provide a human-readable name for aesthetic and
> internationalisation purposes.

I hadn't thought about this previously, and I guess "hardware"
doesn't really cover paper (it's more a "consumable"), but it would be
possible to include such data in hfdb. At this point I think it would
be:
 - unnecessary scope expansion (we've a job enough already)
 - it is more an R&D effort, not simply classification/ data storage
 - once completed, I don't imagine new paper sizes to be submitted :)

> PPDs
> - ----
> 
> PPD i18n issues were discussed with Patrick Powell.  Once a clear
> specification is available, this should be relatively easy to
> implement in Gimp-Print, since translated PPDs are already available.

This is good news - at least for bi-lingual and non-english speakers
(readers?).

Again, sorry for the redundant posts, I hope some find this useful,
Zenaan
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal