FW: pdfdistiller - CUPS PDF

[Kurt Pfeifle]

On Monday 10 July 2006 15:17, Goffioul Michael wrote:

> Thanks. Forwarding to kde-print mailing list for further processing
> (I retired as kdeprint developer).

Thanks, Michael.

> Cristian, Kurt, could you take care 
> of it?

I finally was able to take a little bit of time to *look* at Axel's
modified pdf-writer script, but was not yet able to *test* it. I am
pretty sure the scripts works fine on standard SUSE systems; I have
my doubts if it works on non-standard ones, or on most other distros.
See for details rest of this mail.

So here are some more detailed remarks and requests for improvements:

 + In general, the code looks very nice and cleanly written

 + It uses "logger"; does that utility exist for most Linux distros in
   their default installations? (I know it is on SUSE...; what about
   Debian, RedHat, Ubuntu, Mandrake, Gentoo,... ?)

 + If USERMODE is enabled, it attempts to create the $HOME/$PRTUSER/PDF
   target directory; however, if USERMODE is disabled, it does *not* 
   attempt to analoguously create PDFPATH=${DEVICE_URI#pdf-writer:}. I
   think it should...

 + USERMODE="off" is currently hardcoded as the default into the 
   the backend script. I'd like to see a possibility to override it 
   from an external environment variable (CUPS 1.2 now supports new
   "SetEnv" and "GetEnv" cupsd.conf directives), like this:

      [ x"${USERMODE}" != x"on" ] && USERMODE="off"

 + I'd rename JOB=$1 into JOB_ID=$1 for better clarity

 + The scripts sets DEFGROUP="users" and then (in case the "chown" (*)
   command fails {as it will if "RunAsUser Yes" is used in CUPS 1.1.x},
   it tries "chgrp $DEFGROUP /home/$PRTUSER/PDF" to make the result
   readable for the user. However, the group "users" does not exist
   on all systems; some systems even default to "$USER:$USER" ownership
   of all $HOME/* and not "$USER:users"....

     (*) if the chown command fails, very likely the mkdir command on
         the previous line will also have failed, and then all the 
         lines 140 - 143 will be in vain...

 + Why does it *only* use the ${DATE}.pdf as a $FILENAME (line 142)
   in case it succeeded to chown the $PDFPATH to the user (i.e. is 
   able to write to the user's directory)? This is very unpractical
   (even if it is clear that the result will belong to the user),
   because in all practical environments, PDFs tend to get exchanged,
   and by naming them only by date, we would impose a need for renaming
   of the file upon the user...

 + Therefore I would like to see as part of the resulting PDF file not 
   just the username and date ('FILENAME="$PDFPATH/$PRTUSER-$DATE.pdf"'), 
   but also the job title ("$3" in the commandline parameters of each 
   CUPS filter and backend). However, some programs like browsers do
   send job titles which contain illegal characters for a file name;
   hence we would need an additional function that translates f.e.
   "http://" into "http:__"

 + The script makes the hard assumption that the user's $HOME is in
   home/${PRTUSER}. Shouldn't we better get the user's home directory 
   via a more generic, portable way? S.th. like:

     getent passwd "${PRTUSER}"|cut -d ':' -f6

> Note: I stripped the PDF file and RPM package due to size limitation

Where is the RPM to download for a second look? Does it include a
sensible PPD?

  [ The PPD used for a PDF printer is crucial. Most PPDs currently 
    used for this purpose are very sub-optimal. I've used worktime
    in recent weeks to write 4 different PPDs from scratch who are
    specialized in taking advantage of PDF features by embedding
    "pdfmark" operators into the PostScript code. One is a very 
    simple PPD with hardly any user interface options; it tries to
    use sensible default settings for non-expert users. The 2nd one
    is a PPD that lets you simply select between "eBook", "Screen",
    "Printer" and "PrePress" settings. The 3rd is one that opens you
    all kinds of options, similar to Adobe Distiller. The 4th is one
    that allows you to set special settings for PDFs that are meant
    for presentations (page transistion effects, fullscreen file 
    open by default...). They are meant to drive a new Danka PDF 
    Server product. Unfortunately I have not yet gotten permission 
    by my boss to publish them. But I may... ]

> Michael.

Cheers,
Kurt