State of the PpdPrintingSpecification?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

State of the PpdPrintingSpecification?

Matthias Klose-6
Many packages still have the /usr/share/cups/model directory hardcoded,
in most cases it's derived from cups-config --datadir.  I'm proposing to
add an option --modeldir to cups-config, that points to /usr/share/ppd
on Debian based systems. A fallback safe call to get the model dir would be

  d=$(cups-config --modeldir) || d=$(cups-config --datadir)/model; echo $d

which would work for backports as well.

Is anybody working on gutenprint to comply with the spec?

  Matthias


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: State of the PpdPrintingSpecification?

Roger Leigh
Matthias Klose <[hidden email]> writes:

> Many packages still have the /usr/share/cups/model directory hardcoded,
> in most cases it's derived from cups-config --datadir.  I'm proposing to
> add an option --modeldir to cups-config, that points to /usr/share/ppd
> on Debian based systems. A fallback safe call to get the model dir would be
>
>   d=$(cups-config --modeldir) || d=$(cups-config --datadir)/model; echo $d
>
> which would work for backports as well.
>
> Is anybody working on gutenprint to comply with the spec?
I can switch to using /usr/share/ppd/gutenprint at any time.  I would
rather have the CUPS ppd symlink in place before making the change
(/usr/share/cups/model/ppd -> /usr/share/ppd).

I'm still not sure that the Gutenprint PPDs are "generic" PPDs:

- They only work with the CUPS spooler, because they contain special
  magic:

    *cupsVersion:   1.1
    *cupsModelNumber: "0"
    *cupsManualCopies: True
    *cupsFilter:    "application/vnd.cups-raster 100 rastertogutenprint.5.0"
    *cupsFilter:    "application/vnd.cups-command 33 commandtoepson"

  A PPD is, by definition, a definition for a PostScript printer, but
  these PPDs are merely a "bridge" between CUPS and the libgutenprint
  filter, rastertogutenprint.  Without the magic, they are useless.
  Are they really suitable for inclusion?

  Note that with CUPS 1.2, we will not provide any PPDs at all.  We
  provide a small generator program, and the CUPS daemon can generate
  them on the fly.  Admin tools will then have to do this all through
  CUPS, which AFAICT they can do now if they wish.

- While admin tools legitimately need to access them, they will always
  be CUPS-specific.  Should CUPS-specific admin tools use only the
  generic location, or would looking under /usr/share/cups/model
  (which will also include the generic PPDs) be better?


Regards,
Roger

--
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of the PpdPrintingSpecification?

Matthias Klose-6
Roger Leigh schrieb:

> Matthias Klose <[hidden email]> writes:
>
>> Many packages still have the /usr/share/cups/model directory hardcoded,
>> in most cases it's derived from cups-config --datadir.  I'm proposing to
>> add an option --modeldir to cups-config, that points to /usr/share/ppd
>> on Debian based systems. A fallback safe call to get the model dir would be
>>
>>   d=$(cups-config --modeldir) || d=$(cups-config --datadir)/model; echo $d
>>
>> which would work for backports as well.
>>
>> Is anybody working on gutenprint to comply with the spec?
>
> I can switch to using /usr/share/ppd/gutenprint at any time.  I would
> rather have the CUPS ppd symlink in place before making the change
> (/usr/share/cups/model/ppd -> /usr/share/ppd).

So cups shouldn't use /usr/share/ppd directly, but continue to use
/usr/share/cups/model as location for the ppd's? I'm confused, because
foomatic-filters-ppds doesn't ship that link anymore, but hpijs-ppds does.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: State of the PpdPrintingSpecification?

Roger Leigh
Matthias Klose <[hidden email]> writes:

> Roger Leigh schrieb:
>> Matthias Klose <[hidden email]> writes:
>>
>>> Many packages still have the /usr/share/cups/model directory hardcoded,
>>> in most cases it's derived from cups-config --datadir.  I'm proposing to
>>> add an option --modeldir to cups-config, that points to /usr/share/ppd
>>> on Debian based systems. A fallback safe call to get the model dir would be
>>>
>>>   d=$(cups-config --modeldir) || d=$(cups-config --datadir)/model; echo $d
>>>
>>> which would work for backports as well.
>>>
>>> Is anybody working on gutenprint to comply with the spec?
>>
>> I can switch to using /usr/share/ppd/gutenprint at any time.  I would
>> rather have the CUPS ppd symlink in place before making the change
>> (/usr/share/cups/model/ppd -> /usr/share/ppd).
>
> So cups shouldn't use /usr/share/ppd directly, but continue to use
> /usr/share/cups/model as location for the ppd's? I'm confused, because
> foomatic-filters-ppds doesn't ship that link anymore, but hpijs-ppds does.
CUPS should include a symlink from /usr/share/cups/model to
/usr/share/ppd, then it will pick up all the PPDs.  At this point I
can switch to the new location and it will all continue working, with
no missing or duplicated PPDs.  CUPS should continue to use
/usr/share/cups/model for backward compatibility (user-installed PPDs,
third-party PPDs etc.).

(This is as I understand it, at least.)


Regards,
Roger

--
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of the PpdPrintingSpecification?

Matthias Klose-6
Roger Leigh schrieb:

> Matthias Klose <[hidden email]> writes:
>
>> Roger Leigh schrieb:
>>> Matthias Klose <[hidden email]> writes:
>>>
>>>> Many packages still have the /usr/share/cups/model directory hardcoded,
>>>> in most cases it's derived from cups-config --datadir.  I'm proposing to
>>>> add an option --modeldir to cups-config, that points to /usr/share/ppd
>>>> on Debian based systems. A fallback safe call to get the model dir would be
>>>>
>>>>   d=$(cups-config --modeldir) || d=$(cups-config --datadir)/model; echo $d
>>>>
>>>> which would work for backports as well.
>>>>
>>>> Is anybody working on gutenprint to comply with the spec?
>>> I can switch to using /usr/share/ppd/gutenprint at any time.  I would
>>> rather have the CUPS ppd symlink in place before making the change
>>> (/usr/share/cups/model/ppd -> /usr/share/ppd).
>> So cups shouldn't use /usr/share/ppd directly, but continue to use
>> /usr/share/cups/model as location for the ppd's? I'm confused, because
>> foomatic-filters-ppds doesn't ship that link anymore, but hpijs-ppds does.
>
> CUPS should include a symlink from /usr/share/cups/model to
> /usr/share/ppd, then it will pick up all the PPDs.  At this point I
> can switch to the new location and it will all continue working, with
> no missing or duplicated PPDs.  CUPS should continue to use
> /usr/share/cups/model for backward compatibility (user-installed PPDs,
> third-party PPDs etc.).

replacing the /usr/share/cups/model directory by a symlink is
"interesting", known from our /usr/doc -> /usr/share/doc change.

I currently cannot see the rational about the single symlink vs. the
symlinks in the model subdirectory.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: State of the PpdPrintingSpecification?

Henrique de Moraes Holschuh
In reply to this post by Matthias Klose-6
On Fri, 07 Apr 2006, Matthias Klose wrote:
> > I can switch to using /usr/share/ppd/gutenprint at any time.  I would
> > rather have the CUPS ppd symlink in place before making the change
> > (/usr/share/cups/model/ppd -> /usr/share/ppd).
>
> So cups shouldn't use /usr/share/ppd directly, but continue to use
> /usr/share/cups/model as location for the ppd's? I'm confused, because
> foomatic-filters-ppds doesn't ship that link anymore, but hpijs-ppds does.

I will remove the hpijs/hplip symlinks *after* CUPS starts using
/usr/share/ppds automatically...

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Head's up: Printing Summit talk at 01:00PM EDT about PPD and i18n

Henrique de Moraes Holschuh
In reply to this post by Matthias Klose-6
We have scheduled a breakout session in the printing summit about PPD files
and their i18n, and that session will *also* include the PPD filesystem
placement specification.

So you people may want to be online on the summit backchannel at 01:00 PM
EDT (GMT -04:00), freenode (former opn) network, #printing-summit.  I will
relay your comments to the people in the summit.

Debian and Mandrake are the only distributions here, but CUPS upstream, KDE
upstream, HPLIP upstream, GhostScript upstream, GutenPrint upstream...
they're all here and listening.  LSB was here yesterday, and they're also
interested.

One ****very**** important note:  CUPS 1.2 supports dynamic generation of
PPDs through helpers, *and* it tries to find changes in the PPD filesystem
tree every time it needs to look after a PPD.  That means it detects changes
instantly, AND that it wastes a great deal of resources if the PPD tree is
big (and it is also probably quite slow if the helpers are slow to provide a
list of the PPDs they can generate).

So, unless CUPS 1.2.x starts using in-kernel file/tree-alteration-monitors,
we do *not* want to symlink the entire /usr/share/ppd inside CUPS anymore,
it would be better to use the dynamic PPD generation stuff to speed things
up.   Gutenprint, foomatic and hplip are probably going to want to move to
dynamic generation.

That also means we need a place in /etc and a place in /usr for the PPD
generator helpers (CUPS specific), and a place in /etc for the users to drop
their custom PPDs easily.

A short talk to CUPS upstream suggests we might want to:
  1. Not symlink our /usr/share/ppd stuff
  2. Symlink /usr/local/share/ppd
  3. Symlink /etc/ppd (or wherever)
  4. Use a *fast* helper that tells cups of the PPDs installed by the
     distribution (i.e. stuff in /usr/share/ppd), and fetches them from
     there when needed.

I have also requested a way to keep track of PPD changes (so that we can
have an easier time doing conffile-like PPD updates on upgrade), and it will
probably be available in CUPS 1.3, which should be out in about 6 months.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]