FW: pdfdistiller - CUPS PDF

[Axel Schmidt]

Hallo Kurt,

I added my comments below ...

Kurt Pfeifle wrote:
> 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,... ?)
>   
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.


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

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

>  + 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"

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


>  + 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)".

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


>   
>> Michael.
>>     
>
> Cheers,
> Kurt
>
>   

Axel


-- 
Axel Schmidt
Technical Specialist
Plattform Linux
Axel.Schmidt at novell.com
+49 179 127 6617

Novell, Inc.
Software for the Open Enterprise
www.novell.com/open