Bug 32198 - Blank pdf output from cups-pdf 3.0.1-3.mga9
Summary: Blank pdf output from cups-pdf 3.0.1-3.mga9
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 9
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA9-64-OK
Keywords: IN_ERRATA9, advisory, validated_update
Depends on:
Blocks:
 
Reported: 2023-08-28 16:27 CEST by Dusan Pavlik
Modified: 2025-04-14 19:48 CEST (History)
9 users (show)

See Also:
Source RPM: cups-pdf-3.0.1-3.mga9.src.rpm
CVE:
Status comment:


Attachments
Diff from https://raw.githubusercontent.com/archlinux/svntogit-packages/packages/cups-pdf/trunk/remove-deprecated-ghostscript-setpdfwrite-operator.diff (2.36 KB, patch)
2023-08-29 18:33 CEST, Dave Hodgins
Details | Diff
wrong output from patched cups-pdf (41.26 KB, application/pdf)
2023-08-31 18:02 CEST, Dusan Pavlik
Details
Pdf generated with BRF (130.69 KB, application/pdf)
2023-11-08 23:57 CET, katnatek
Details

Description Dusan Pavlik 2023-08-28 16:27:13 CEST
Description of problem:
If I printing to cups-pdf printer. Output is one blank pdf page.

Version-Release number of selected component (if applicable):
cup-pdf 3.0.1-3.mga9

How reproducible:


Steps to Reproduce:
1. Select printer cup-pdf
2. Printing
Dusan Pavlik 2023-08-28 16:27:28 CEST

Version: Cauldron => 9

Comment 1 Lewis Smith 2023-08-28 21:15:06 CEST
Please say what desktop you are using. Does this happen when printing from any application?

I need to try this.

Source RPM: (none) => cups-pdf-3.0.1-3.mga9.src.rpm
Summary: Blank pdf output from cup-pdf 3.0.1-3.mga9 => Blank pdf output from cups-pdf 3.0.1-3.mga9
CC: (none) => lewyssmith

Comment 2 Lewis Smith 2023-08-28 21:38:19 CEST
Confirmed.
Cauldron/Mageia 9, LxQt, cups-pdf-3.0.1-3.mga9
I installed the package, and used MCC to 'add' the cups-pdf 'printer'. It then appeared as an option in print dialogues. (Also an entry for 'cups-pdf-linux', which if selected did not activate the print button).
Tried printing to it from two different applications, single pages; in both cases the result was a blank page.

No visible maintainer for this; and cups itself has various committers; so assigning this bug globally.

Assignee: bugsquad => pkg-bugs
CC: lewyssmith => (none)
Severity: normal => major

Comment 3 Dave Hodgins 2023-08-29 02:03:31 CEST
# cat /var/log/cups/cups-pdf-Generic-CUPS-PDF-Printer_log
Mon Aug 28 19:17:00 2023  [ERROR] Can't read
Mon Aug 28 19:17:01 2023  [ERROR] ghostscript reported an error
Mon Aug 28 19:17:01 2023  [STATUS] PDF creation successfully finished

Might be an error in parameters specified in /etc/cups/cups-pdf.conf to
properly pass the pdf to ghostscript. Not sure though.

CC: (none) => davidwhodgins

Comment 4 Dusan Pavlik 2023-08-29 06:56:54 CEST
I mean there is solution

https://www.linuxquestions.org/questions/slackware-14/cups-pdf-printer-prints-a-blank-pdf-after-ghostscript-9-54-0-update-4175694164/

ps. I using wine programs and I need output to pdf
Comment 6 David GEIGER 2023-08-30 06:09:41 CEST
Please the upcoming cups-pdf-3.0.1-3.1.mga9 update.


Assigning to QA,

Packages in 9/Core/Updates_testing:
======================
cups-pdf-3.0.1-3.1.mga9

From SRPMS:
cups-pdf-3.0.1-3.1.mga9.src.rpm

Assignee: pkg-bugs => qa-bugs
CC: (none) => geiger.david68210

Comment 7 Dusan Pavlik 2023-08-31 18:00:40 CEST
I install cups-pdf-3.0.1-3.1.mga9.x86_64.rpm    

But output is wrong.  See attachment.
Comment 8 Dusan Pavlik 2023-08-31 18:02:48 CEST
Created attachment 13961 [details]
wrong output from  patched cups-pdf
Comment 9 Dave Hodgins 2023-08-31 19:48:44 CEST
Confirmed it still doesn't work properly. Trying to print a text file
with some characters set to bold/italic, to pdf from oowriter, the pdf has ...
ERROR:
rangecheck
OFFENDING COMMAND:
defineresource
STACK:
--nostringval--
/R13
/CMap
--nostringval--
/R13
--nostringval--
13


So there's something wrong with generating of the pdf document.
Comment 10 Morgan Leijström 2023-09-03 22:59:53 CEST
Just noting cups-pdf is not in a a released media, so this issue is not for errata  (even though this problematic cups-pdf-3.0.1-3 is in release *repository*)

CC: (none) => fri

Comment 11 Dave Hodgins 2023-09-03 23:36:00 CEST
The errata isn't just for things on the iso images. It's also for anything that
breaks or requires manual changes after upgrading from m8 to m9.
Comment 12 Morgan Leijström 2023-09-03 23:43:06 CEST
Upgrading breaks pdf printing.

https://wiki.mageia.org/en/Mageia_9_Errata#Printing

Keywords: (none) => IN_ERRATA9
Priority: Normal => High

Comment 13 Morgan Leijström 2023-09-04 10:52:59 CEST
Updated errata with tips on workarounds: many programs can export pdf by other means.

---

Related:

Users need to go hunting for where the output file gets stuffed away.
Here using cuips.pdf the file gets "hidden" in ~/Desktop - not localised.

(Desktop have different names in different languages, plus some desktop systems do not always show its content as desktop.)
 
And nowhere in the setup procedure nor settings nor print dialogue (what I can find) or when it prints, user is told where the output will go or how to set it.
Did I miss something, is this a bug or should I post an enhancement request?
Comment 14 Marja Van Waes 2023-10-13 17:31:39 CEST
(In reply to Dusan Pavlik from comment #7)
> I install cups-pdf-3.0.1-3.1.mga9.x86_64.rpm    
> 
> But output is wrong.  See attachment.

(In reply to Dusan Pavlik from comment #8)
> Created attachment 13961 [details]
> wrong output from  patched cups-pdf

(In reply to Dave Hodgins from comment #9)
> Confirmed it still doesn't work properly. Trying to print a text file
> with some characters set to bold/italic, to pdf from oowriter, the pdf has
> ...
> ERROR:
> rangecheck
> OFFENDING COMMAND:
> defineresource
> STACK:
> --nostringval--
> /R13
> /CMap
> --nostringval--
> /R13
> --nostringval--
> 13
> 
> 
> So there's something wrong with generating of the pdf document.

Setting the "feedback keyword"

CC: (none) => marja11
Keywords: (none) => feedback

Comment 15 katnatek 2023-10-13 19:39:16 CEST
Not works, try to print this bug report from firefox, and produce a blank pdf
Comment 16 Dusan Pavlik 2023-11-01 19:12:52 CET
I thought about this problem and used another printer offered in drakconf. It is specifically a BRF printer.


-workarounds with printing to pdf (not export), 

Step by step:
1. open drakonf / drakprinter
2. add new printer
3. choose "Generic CUPS-BRF"  - printer (forward)
4. select "generic" (manufacturer) - (forward)
5. select driver "PDF" (forward)
6. change name if you want    (apply)

Now printer BRF is printing to  "/home/user/BRF" or "/root/BRF"

Output is looking good. Output have .brf sufix but is regular pdf file.

I  will examining it in different situations.
Comment 17 katnatek 2023-11-08 23:56:36 CET
(In reply to Dusan Pavlik from comment #16)
> I thought about this problem and used another printer offered in drakconf.
> It is specifically a BRF printer.
> 
> 
> -workarounds with printing to pdf (not export), 
> 
> Step by step:
> 1. open drakonf / drakprinter
> 2. add new printer
> 3. choose "Generic CUPS-BRF"  - printer (forward)
> 4. select "generic" (manufacturer) - (forward)
> 5. select driver "PDF" (forward)
> 6. change name if you want    (apply)
> 
> Now printer BRF is printing to  "/home/user/BRF" or "/root/BRF"
> 
> Output is looking good. Output have .brf sufix but is regular pdf file.
> 
> I  will examining it in different situations.

This recommendation works for me
Comment 18 katnatek 2023-11-08 23:57:39 CET
Created attachment 14143 [details]
Pdf generated with BRF
PC LX 2024-01-06 15:57:22 CET

CC: (none) => mageia

Comment 19 Thomas Andrews 2024-02-04 21:52:06 CET
The workaround may get the job done after a fashion, but cups-pdf should still be fixed. Sending it to David Geiger, who attempted the fix in comment 6.

Assignee: qa-bugs => geiger.david68210
Keywords: feedback => (none)
CC: (none) => andrewsfarm

Comment 20 Thomas Andrews 2024-02-04 21:56:00 CET
(In reply to Morgan Leijström from comment #13)
> Related:
> 
> Users need to go hunting for where the output file gets stuffed away.
> Here using cuips.pdf the file gets "hidden" in ~/Desktop - not localised.
> 
> (Desktop have different names in different languages, plus some desktop
> systems do not always show its content as desktop.)
>  
> And nowhere in the setup procedure nor settings nor print dialogue (what I
> can find) or when it prints, user is told where the output will go or how to
> set it.
> Did I miss something, is this a bug or should I post an enhancement request?

I'd say let's get this fixed as it is first, then you can file an enhancement request about your concerns.
Comment 21 katnatek 2024-02-05 00:23:40 CET
(In reply to Thomas Andrews from comment #19)
> The workaround may get the job done after a fashion, but cups-pdf should
> still be fixed. Sending it to David Geiger, who attempted the fix in comment
> 6.

The current version is from 2017 https://www.cups-pdf.de/changelog.shtml, and the possible fix not works.

I say we must recommend use CUPS-BRF instead
Comment 22 Morgan Leijström 2024-02-05 00:30:25 CET
So to drop in mga10?
Comment 23 katnatek 2025-04-10 20:41:26 CEST
Some news https://www.cups-pdf.de/changelog.shtml
2025-03-23 : 3.0.2
  - updated GhostScript command line arguments
  - added full code documentation by Lew Pitcher
katnatek 2025-04-11 20:20:06 CEST

Assignee: geiger.david68210 => j.alberto.vc

katnatek 2025-04-12 06:58:11 CEST

Assignee: j.alberto.vc => qa-bugs

Comment 24 katnatek 2025-04-12 07:05:49 CEST
SRPMS:
cups-pdf-3.0.2-1.mga9

RPM:
cups-pdf-3.0.2-1.mga9
Comment 25 Herman Viaene 2025-04-12 10:30:59 CEST
Hmmm, I cann't replicate the problem with the current version. But I notice the text of normal font is very light in contrast. I guess depending on the screen it might be overlooked.
No time now to test the new version, coming back later.

CC: (none) => herman.viaene

Comment 26 Morgan Leijström 2025-04-12 11:01:30 CEST
Hooray - it creates a pdf with content :-)
pdf is output in the user desktop folder, and with job number appended to file name in the form "-job_1964" before ".pdf".

Tested printing a text only mail from thunderbird, and part of a pdf manual with images.

Problem: all visible content is raster image = ugly looking and file is ten times bigger than what is created by printing dialogue option "Save to pdf".

Is that some default setting that can be adjusted?
- I think most want compact and good looking outputs.
Then comes the complexity of embedding fonts or not for compactness versus compatibility; IMO it should by default embed used fonts.

That said, I do not rember what type of output our earlier cups-pdf did create when it worked.
Comment 27 Dusan Pavlik 2025-04-12 11:07:32 CEST
I tested this version and it works.
I just removed the old cups-pdf printer and added the new one.

Hm. I will look to problem, which describe  Morgan Leijström
Comment 28 Herman Viaene 2025-04-12 14:53:31 CEST
MGA9-64 Plasma Wayland on Compaq H000SB
No installation issues.
Cann't see any difference with previous version, so it works.
Comment 29 Thomas Andrews 2025-04-12 16:33:20 CEST
Cups-pdf was already installed on my production system, but the virtual printer had been removed, months ago. This was probably the version from comment 6, but I didn't think to check. I installed the printer again, and the fault was still there. No installation issues with installing the update. I used the already-installed printer for this test.

Using the default resolution of 300 DPI (Looks to be adjustable in printer "properties"), I printed a two-page spreadsheet from Libreoffice Calc. The resulting file appeared on my desktop, had a size of 75.6 KiB, and looks perfect in Okular.

Then I used the other two options for producing a pdf from Calc, Print to File and Export to PDF, sending each to the desktop, as well.

When using Print to File, I was surprised to see the properties button bring up the properties of my default Color Laserjet printer. I left them alone, and printed a file that was 75.1 KiB in size, and looked identical to the cups-pdf file in Okular.

Export to PDF brought up an entirely different settings dialog, with many more options. Again I used the defaults, this time producing a file 77.0 KiB in size, that again looked identical in Okular.

Looks good here so far.
Comment 30 Thomas Andrews 2025-04-12 17:05:10 CEST
Changing the resolution in the properties dialog doesn't seem to affect the output. I tried with the spreadsheet, and again with a Writer document page with two jpeg images. No difference if set at 300 DPI or 1200 DPI.

There should have been. It might be that user setting changes are ignored, and cups-pdf just uses the settings as set by root in MCC. 

A minor niggle, from my perspective. At least there is usable output now.
Comment 31 katnatek 2025-04-12 19:25:07 CEST
(In reply to Morgan Leijström from comment #26)
> Hooray - it creates a pdf with content :-)
> pdf is output in the user desktop folder, and with job number appended to
> file name in the form "-job_1964" before ".pdf".
> 
> Tested printing a text only mail from thunderbird, and part of a pdf manual
> with images.
> 
> Problem: all visible content is raster image = ugly looking and file is ten
> times bigger than what is created by printing dialogue option "Save to pdf".
> 
> Is that some default setting that can be adjusted?
> - I think most want compact and good looking outputs.
> Then comes the complexity of embedding fonts or not for compactness versus
> compatibility; IMO it should by default embed used fonts.
> 
> That said, I do not rember what type of output our earlier cups-pdf did
> create when it worked.

/etc/cups/cups-pdf.conf but is like Chinese for me how to adjust the ghostcript command

You can test if the BRF printer in comment#16 have better results
katnatek 2025-04-12 20:05:12 CEST

Keywords: (none) => advisory

Comment 32 Len Lawrence 2025-04-12 20:17:57 CEST
mga9, x64
Using LibreOffice writer to load a simple text file and choosing Generic-CUPS-PDF-Printer in the Print dialogue generated a PDF in ~/Desktop.

Using the command-line was successful but generated a larger PDF in Desktop with pages too big to be read.  I guess some options concerning resolution need to be passed to ghostscript, but in principle it works.
$ lpr -PGeneric-CUPS-PDF-Printer fugit.manual

$ ll Desktop
-rw------- 1 lcl lcl 36072 Apr 12 18:51 fugit.manual-job_48.pdf
-rw------- 1 lcl lcl 64181 Apr 12 19:09 fugit.manual-job_50.pdf

CC: (none) => tarazed25

Comment 33 Thomas Andrews 2025-04-12 21:32:52 CEST
From /usr/share/doc/cups-pdf/README:

CUPS-PDF now has a PPD file (CUPS-PDF_opt.ppd) that allows setting the following 
   options in the CUPS webinterface (administration/set default options):
   - resolution
   - page size
   - PDF version
   - truncate output file names
   - labelling (with jobid) of output files
   - title source preference
   - log level
   Please note that setting these options in the cups-pdf.conf will have no
   effect if you use the included PPD file as the settings from the PPD-file
   will override the settings in the config file.

If I'm reading that correctly, if you want to do something out of the ordinary, you  use the CUPS webinterface to change the configuration. Changing the conf file won't work. 

Just as an experiment, I used MCC to change the resolution setting of the printer, then attempted to print the Writer document with two jpegs. The dialog indicated the "default" resolution was now 2400 DPI, which should have resulted in a MUCH larger pdf. But when printed, it was the same size as before.

These seem to be things for upstream to be working on. While not perfect, this update does fix the specific issue that prompted the bug, so I am going to send it on.

Validating the update.

@Morgan: The ERRATA should get an update. I don't know if it would be best to just remove the reference to cups-pdf, or to write something about the issues we still see. I leave that decision to you.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK
CC: (none) => sysadmin-bugs

Comment 34 Morgan Leijström 2025-04-12 22:15:34 CEST
I agree about sending on, problem fixed.

I will update the errata saying the problem is fixed, keeping notes on workarounds as they are useful for generating more compact files with text instead of bitmap only. I might try the mentioned cups-brf and note that alternative too.

Really we should have a wiki page on printers and scanners, and from that link to a page o various ways to make pdf...  Maybe a misson for a dull winter day.

I don´t really understand the readme note cited in Comment 33:
I do not see cups-pdf listed in http://localhost:631/printers/ 
Maybe the printer should be installed some other way for that to work.
Comment 35 katnatek 2025-04-13 19:39:54 CEST
(In reply to Morgan Leijström from comment #34)
> I agree about sending on, problem fixed.
> 
> I will update the errata saying the problem is fixed, keeping notes on
> workarounds as they are useful for generating more compact files with text
> instead of bitmap only. I might try the mentioned cups-brf and note that
> alternative too.
> 
> Really we should have a wiki page on printers and scanners, and from that
> link to a page o various ways to make pdf...  Maybe a misson for a dull
> winter day.
> 
> I don´t really understand the readme note cited in Comment 33:
> I do not see cups-pdf listed in http://localhost:631/printers/ 
> Maybe the printer should be installed some other way for that to work.

Check if you have as Virtual_PDF_Printer
BTW I add it from cups we interface as MCC ask to install packages the I don't need right now
Comment 36 Mageia Robot 2025-04-14 19:48:42 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2025-0038.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.