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"

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

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.

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

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