Bug#912993: printer-driver-cups-pdf: creates wrong filename using short title

[Martin Lange]

Package: printer-driver-cups-pdf
Version: 3.0.1-5
Severity: normal

Dear Maintainer,

using the cups-pdf printer with a short document title (< 32 chars) results in faulty generated filename. This don't affect titles >= 32 chars.

example:
lp -d PDF -t short INPUT.pdf

result:
a generated PDF file named "short__rtin_PDF.pdf"
(in this case, file name seems to be the target path (/home/martin/PDF) with first characters replaced by the title in some magically appeared brackets)

expected:
a generated PDF file named "short.pdf" in /home/martin/PDF/

some logging:
[DEBUG] now extracting postscript code
[DEBUG] found title in ps code: (short)
rtin/PDF
Mon Nov 5 16:49:30 2018 [DEBUG] found end of postscript code: %%EOF

[DEBUG] all data written to spoolfile: /var/spool/cups-pdf/SPOOL/cups2pdf-10959
[DEBUG] trying to use PS title: (short)
rtin/PDF
[STATUS] ***Experimental Option: DecodeHexStrings
[DEBUG] checking for hex strings: (short)
rtin/PDF
[DEBUG] not a hex string, has no start marker: (short)
rtin/PDF
[DEBUG] calling alternate_replace_string
[DEBUG] removing alternate special characters from title: (short)
rtin/PDF
[DEBUG] removing leading _ from title: _short__rtin_PDF
[DEBUG] title successfully retrieved: short__rtin_PDF
[DEBUG] input data read from stdin
[DEBUG] output filename created: /home/martin/PDF/short__rtin_PDF.pdf
[DEBUG] ghostscript commandline built: /usr/bin/gs -q -dCompatibilityLevel=1.2 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/home/martin/PDF/short__rtin_PDF.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-10959



-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages printer-driver-cups-pdf depends on:
ii cups 2.2.8-5
ii cups-client 2.2.8-5
ii ghostscript 9.25~dfsg-4
ii libc6 2.27-6
ii libcups2 2.2.8-5
ii libpaper-utils 1.1.24+nmu5

printer-driver-cups-pdf recommends no packages.

Versions of packages printer-driver-cups-pdf suggests:
ii system-config-printer 1.5.11-3

-- no debconf information

[Martin-Éric Racine]

Volker,

Unless I'm mistaken, this is an upstream issue that affects filenames
of less than 32 characters. Can you check?

Martin-Éric

ke 16. lokak. 2019 klo 17.21 Alf (alf.de...@gmx.de) kirjoitti:
>
> I was hit by the same issue as well, getting cryptic suffixes appended
> the the filename.
>
> I carefully went through the configuration file and found:
>
> > ###########################################################################
> > # #
> > # Filename Settings #
> > # #
> > ###########################################################################
>
> ...
> > ### Key: TitlePref (config, ppd, lpoptions) ## where to look first
> > for a title when creating the output filename ## (title in PS file
> > or title on commandline): ## 0: prefer title from %Title statement
> > in the PS file ## 1: prefer title passed via commandline ###
> > Default: 0
> >
> > TitlePref 0
>
>
> which means that the filename is derived preferable from the title
> statement in the PS file. However the old beheaviour was to derive the
> output filename from commandline = input filename, strip the suffix and
> append "pdf" instead.
>
> So, I set that Option to "1"
> > TitlePref 1
>
> And now my PDF-printer works as it used to since years.
>
> I double checked with the configuration file in Stretch, ist is
> precisely the same as it shipped with Buster with regard to this option
> (default = 0), so actually in Stretch it was not performinmg as
> documentatoin says - thus buggy.
>

[Alf]

[Martin-Éric Racine]

Greetings,

Does the issue you reported against printer-driver-cups-pdf still
apply to the 3.0.1-9 version currently shipping with Debian 11
(Bullseye)?

Martin-Éric

[Martin-Éric Racine]

If setting "TitlePref 1" accomplishes what you need, then I don't see
how this constitutes a bug. It merely means that the package ships
with settings that don't fit your particular case.

Martin-Éric

ti 28. syysk. 2021 klo 14.10 Alf (alf.de...@gmx.de) kirjoitti:
>
> I did check in Buster and it beheaves as described in /etc/cups/cups-pdf.conf.
>
> Default setting for "TitlePref" ist "0" which generates the output file name from %Title statement in the PS file.
>
> This was different in older Debian versions up to including Stretch, where it derived output file name from input file name.
> This is what I have to correct in Buster as well as in Bullseye where I have to set it to
> TitlePref 1
> to get the old used format under XFCE4 desktop. Would be great if Debian would set this in the *.deb-package.
>
>
> Am 27.09.21 um 13:37 schrieb Martin-Éric Racine:

[in.cog...@arcor.de]

I'm on Debian testing with package printer-driver-cups-pdf version 3.0.1-14.

I get broken output file names as well, and I think it is an upstream bug.

Here is my configuration as dumped by cups-pdf:

------------------------------ snip ------------------------------
Thu Mar 9 14:50:11 2023 [DEBUG] *** Final Configuration ***
Thu Mar 9 14:50:11 2023 [DEBUG] AnonDirName = "/var/spool/cups-pdf/ANONYMOUS"
Thu Mar 9 14:50:11 2023 [DEBUG] AnonUser = "nobody"
Thu Mar 9 14:50:11 2023 [DEBUG] GhostScript = "/usr/bin/gs"
Thu Mar 9 14:50:11 2023 [DEBUG] GSCall = "%s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s"
Thu Mar 9 14:50:11 2023 [DEBUG] Grp = "lpadmin"
Thu Mar 9 14:50:11 2023 [DEBUG] GSTmp = "TMPDIR=/var/tmp"
Thu Mar 9 14:50:11 2023 [DEBUG] Log = "/var/log/cups"
Thu Mar 9 14:50:11 2023 [DEBUG] PDFVer = "1.2"
Thu Mar 9 14:50:11 2023 [DEBUG] PostProcessing = ""
Thu Mar 9 14:50:11 2023 [DEBUG] Out = "${HOME}/tmp/transfer/print"
Thu Mar 9 14:50:11 2023 [DEBUG] Spool = "/var/spool/cups-pdf/SPOOL"
Thu Mar 9 14:50:11 2023 [DEBUG] UserPrefix = ""
Thu Mar 9 14:50:11 2023 [DEBUG] RemovePrefix = ""
Thu Mar 9 14:50:11 2023 [DEBUG] OutExtension = "pdf"
Thu Mar 9 14:50:11 2023 [DEBUG] Cut = 3
Thu Mar 9 14:50:11 2023 [DEBUG] Truncate = 64
Thu Mar 9 14:50:11 2023 [DEBUG] DirPrefix = 0
Thu Mar 9 14:50:11 2023 [DEBUG] Label = 2
Thu Mar 9 14:50:11 2023 [DEBUG] LogType = 7
Thu Mar 9 14:50:11 2023 [DEBUG] LowerCase = 1
Thu Mar 9 14:50:11 2023 [DEBUG] TitlePref = 0
Thu Mar 9 14:50:11 2023 [DEBUG] DecodeHexStrings = 1
Thu Mar 9 14:50:11 2023 [DEBUG] FixNewlines = 0
Thu Mar 9 14:50:11 2023 [DEBUG] AllowUnsafeOptions = 0
Thu Mar 9 14:50:11 2023 [DEBUG] AnonUMask = 0000
Thu Mar 9 14:50:11 2023 [DEBUG] UserUMask = 0077
Thu Mar 9 14:50:11 2023 [DEBUG] *** End of Configuration ***
------------------------------ snip ------------------------------

A few lines later in the log file I get these really suspicious entries:

------------------------------ snip ------------------------------
Thu Mar 9 14:50:11 2023 [DEBUG] found title in ps code: cups-pdf.c
idt/tmp/transfer/print
Thu Mar 9 14:50:11 2023 [DEBUG] found end of postscript code: %%EOF

------------------------------ snip ------------------------------

Note that newline ("cups-pdf.c***\n***idt/tmp/transfer/print") is part of
the first log line!

So IMHO there is something wrong with this block from cups-pdf.c:

------------------------------ snip ------------------------------
if (sscanf(buffer, "%%%%Title: %"TBUFSIZE"c", title)==1) {
log_event(CPDEBUG, "found title in ps code: %s", title);
is_title=1;
}
------------------------------ snip ------------------------------

Can it be that the result in variable title needs to be zero-terminated?