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

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

# 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

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

Created attachment 13956 [details]
Diff from https://raw.githubusercontent.com/archlinux/svntogit-packages/packages/cups-pdf/trunk/remove-deprecated-ghostscript-setpdfwrite-operator.diff

The diff looks suitable for use as a a patch.

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

I install cups-pdf-3.0.1-3.1.mga9.x86_64.rpm    

But output is wrong.  See attachment.

Created attachment 13961 [details]
wrong output from  patched cups-pdf

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.

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

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.

Upgrading breaks pdf printing.

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

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

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?

(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

Not works, try to print this bug report from firefox, and produce a blank pdf

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.

(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

Created attachment 14143 [details]
Pdf generated with BRF

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

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

(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

So to drop in mga10?

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

SRPMS:
cups-pdf-3.0.2-1.mga9

RPM:
cups-pdf-3.0.2-1.mga9

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

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.

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

MGA9-64 Plasma Wayland on Compaq H000SB
No installation issues.
Cann't see any difference with previous version, so it works.

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.

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.

(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

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

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

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.

(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

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