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

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:

...


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"

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.

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.debianfan@gmx.de) kirjoitti:

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

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

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:

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.debianfan@gmx.de) kirjoitti:

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

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?

Since this is merely a question of preferred behavior that can be
easily configured by changing the value for TitlePref, I'm closing
this bug.

Martin-Éric

Hi Martin-Éric,

I've seen your decision about becoming a DM in the recent changelog
update.  Congratulations and thanks for taking over the responsibility!


However, I'd like to challenge your decision of closing this bug:

since I'm quite confident that there *is* a bug if one wants to use
TitlePref=0.  Which I happen to do.


As I mentioned already in my update #40 [1] (with different email
address back then), the following 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 ------------------------------

is buggy since sscanf does not zero-terminate the string.

I can provide a patch for that if you see any chances to get this
incorporated.

Thanks again

Jens

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912993#40

ke 12.3.2025 klo 22.52 Farblos (farblos@vodafonemail.de) kirjoitti:

Patches are always welcome.

Martin-Éric

Sounds good, thanks for the offer.

Two follow-up questions:

- The upstream of cups-pdf seems to be inactive for quite some
  time already, correct?  So fixing this issue directly in
  Debian is the best we could hope for, correct?

- I haven't yet provided patches to a Debian project.  Would
  the description found, for example, here:

https://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-for-debian-packages/

  be OK for you and cups-pdf?  If you have a more recent or
  more appropriate description, please let me know.

Thanks

Jens

ti 18.3.2025 klo 0.24 Farblos (farblos@vodafonemail.de) kirjoitti:

Upstream became a father a couple of years ago, and he has a busy job
in a medical research lab. His time outside of that has become
extremely limited.

Yes or just follow what dpkg-source says when it notifies you that you
have modified the source and generates the patch template for you.

Martin-Éric

Here is my patch, then.  Plus a small postscript test document with
an extra short title to demonstrate the difference in file name without
my patch (generating job 29):

  [~]$ aptitude show printer-driver-cups-pdf
  Package: printer-driver-cups-pdf
  Version: 3.0.1-20
  State: installed
  Automatically installed: no
  Priority: optional
  Section: graphics
  Maintainer: Debian CUPS Maintainers <debian-printing@lists.debian.org>
  Architecture: amd64
  [...]


  [~]$ ls -al ~/tmp/transfer/print/
  total 8
  drwxr-xr-x 2 farblos farblos 4096 Mar 21 21:45 .
  drwxr-xr-x 5 farblos farblos 4096 Mar 19 17:56 ..

  [~]$ lpr -o Title=0 ~/tmp/test.ps

  [~]$ ls -al ~/tmp/transfer/print/
  total 12
  drwxr-xr-x 2 farblos farblos 4096 Mar 21 21:45 .
  drwxr-xr-x 5 farblos farblos 4096 Mar 19 17:56 ..
  -rw------- 1 farblos farblos 1608 Mar 21 21:45 Y_ome_farblos_tmp_transfer_print-job_29.pdf

And with my patch (generating job 30):

  [~]$ aptitude show printer-driver-cups-pdf
  Package: printer-driver-cups-pdf
  Version: 3.0.1-20.1
  State: installed
  Automatically installed: no
  Priority: optional
  Section: graphics
  Maintainer: Debian CUPS Maintainers <debian-printing@lists.debian.org>
  Architecture: amd64
  [...]


  [~]$ ls -al ~/tmp/transfer/print/
  total 12
  drwxr-xr-x 2 farblos farblos 4096 Mar 21 21:45 .
  drwxr-xr-x 5 farblos farblos 4096 Mar 19 17:56 ..
  -rw------- 1 farblos farblos 1608 Mar 21 21:45 Y_ome_farblos_tmp_transfer_print-job_29.pdf

  [~]$ lpr -o Title=0 ~/tmp/test.ps

  [~]$ ls -al ~/tmp/transfer/print/
  total 16
  drwxr-xr-x 2 farblos farblos 4096 Mar 21 21:48 .
  drwxr-xr-x 5 farblos farblos 4096 Mar 19 17:56 ..
  -rw------- 1 farblos farblos 1608 Mar 21 21:48 Y-job_30.pdf
  -rw------- 1 farblos farblos 1608 Mar 21 21:45 Y_ome_farblos_tmp_transfer_print-job_29.pdf

Please let me know if that is OK for you.

Thanks

Jens

pe 21.3.2025 klo 23.14 Farblos (farblos@vodafonemail.de) kirjoitti:

Thanks. I'm curious to see what upstream thinks of this first. I just
pinged him.

Martin-Éric

Any reaction on that ping of yours?  It has been a while now.
But OTOH there has has been even an upstream release just after
your last reply to this bug, so there might still be hope!

Thanks

Jens

la 17.5.2025 klo 17.57 Farblos (farblos@vodafonemail.de) kirjoitti:

None, other than a short e-mail informing me of that small release
incorporating only the Ghostscript patch and telling me that he might
find the time to address other pending issues later this year.

Martin-Éric

Thanks.  Will wait patiently, then.

Jens