FW: pdfdistiller - CUPS PDF

[Kurt Pfeifle]

On Monday 17 July 2006 19:33, Axel Schmidt wrote:

> >  + 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,... ?)
> >   
> To make the code more common I can add a check of /etc/SuSE-release to 
> know if I am on a SUSE system. Otherwise I can produce log message e.g. 
> /var/log/pdfwriter
> Logger was just nice for testing.

Yes, logger *is* nice. Maybe it can even be kept, if most other systems
do have it by default. Then I'd not test for SuSE-release, but for `which 
logger`...

> >  + 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...
> >   
> As default it writes to PDFPATH, e.g. /export/share/pdf

Yes, but my point is: $PDFPATH may not exist (whereever it is).

Only in case USERMODE is "on", the script does create the PDF 
subdir in /home/$PRNUSER.

But if a device URI of "pdf-writer:/tmp/PDFs/pdf-writer" is used,
that "/tmp/PDFs/pdf-writer" may not have been created by the user
and should be created by the script itself.

Also, "/export/share/pdf" may not exist either....

> >  + 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"
> >   
> If this works now - of course I should add it.

See http://www.cups.org/documentation.php/ref-cupsd-conf.html for
some details.

> >  + I'd rename JOB=$1 into JOB_ID=$1 for better clarity
> >
> >   
> OK
> 
> >  + 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...
> >   
> Yes I know it looks strange - anyway the change owner, etc. will only 
> work if cups runs as root. These part is obsolate if USERMODE="off"

But this part is called "if USERMODE = on"? So if we run cupsd as user 
"lp", we expect that user being able to create a "PDF" subdir in *my* 
$HOME? I don't think that works...
 
> >  + 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...
> >   
> When USERMODE="off" all files printed by the user will cary the user name:
> 
> f.e.
> 
> axels-2006-07-10-15:13.14.pdf
> 
> USERMODE="on" make sense when desktop clients are used by differents users.
> Then all PDF move to /home/<user name>/PDF and only carry the date.
> 
> 2006-07-10-15:14.10.pdf

I understand. My argument is to add another parameter instead of the 
date only, like the (santitized) job title provided by CUPS. 

Imagine you are using that nice PDF printer frequently, and looking 
for a specific PDF you create today 4 weeks from now...

> >  + 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:__"
> >
> I tested printing from brower and several application. The information 
> about the job title if any exist at all, was obsolate like "(stdin)".

Hmmm? My experience is different. I'll look into it a bit more closely
next weekend, I hope.

> >  + 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
> >   
> Of course I can add it - but I think basicly the users are always 
> located below "/home".

No. Think about Win32-client/Samba users, and this PDF printer being 
used used via Samba as a shared Windows printer.

Very frequently, Samba users will be authenticated with the help of 
Winbind via the domain controller as domain users.

Those users on the Samba server typically have a home directory of

  /home/DOMAINNAME/windowsusername

and my line of "getent passwd ${PRTUSER}|cut -d ':' -f6" would 
work perfectly in this case. (However, I am not sure if the complete
pdf-writer backend would work -- need to look at it more closely...)

> >> 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... ]
> >   
> I used to achieve the best result the Adobe PPD file for Windows.

You mean the Adobe PPD used for Acrobat Distiller? A legally clean 
re-distribution of this PPD is questionable (my guess), but I haven't 
looked at its license yet....

> It  
> seems that one may use it for free. I have to check with lawyer if I may 
> add it in  my pdf-writer rpm.

Ghostscript has one now as well; when I discovered it 2 years ago, it
just had appeared in their CVS, and was buggy as hell ("cupstestppd" 
wouldn't let it pass f.e.). I sent them in a detailled bug report at 
the time, but never heard of it again. I believe it is now released 
and is called "ghostpdf.ppd"

In any case, this PPD could serve as a basis for modifications and 
improvements.

Cheers,
Kurt