Closed attah closed 10 months ago
Please attach the output you are getting.
Hmm, strange I'm not seeing this for current master but your output file is definitely damaged somehow... Can you try current master (I just tested 14e32422a)?
That's just a one commit diff to where i was... but retested none the less. Same result. (reinitialized the submodule, git-cleaned, ./configure'd and recompiled) Double-checked the input file - still looks good.
Hmm, what processor, compiler, and glibc are you using? The locale definitely shouldn't be an issue...
Also, can you attach the stderr output from ipptransform (all the DEBUG: messages from ipptransform)?
AMD Ryzen 9 3950X gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Ubuntu GLIBC 2.35-0ubuntu3.6
The output indicates a different locale than en_US.UTF-8
. How about attaching the output of "env"?
This will likely require some changes to force the LC_NUMERIC
locale category to "C" when reading/writing PDF files (or update PDFio to go through the same hoops that libcups already does to work around the locale stuff), but I'd like to confirm what is happening on your system...
Seems my hunch was right then. I just wasn't aware there were multiple environment variables for this.
Running with LC_NUMERIC=C
indeed fixes the issue. (LC_NUMERIC=sv_SE.UTF-8 is what i have normally).
OK, thanks for confirming. I've opened a PDFio issue to track the fix, and will update this bug once we update the pdfio submodule in libcups.
OK, fix for PDFio is pushed...
[master 886726b0a] Pickup locale fix for PDFio (Issue #76)
For completeness; this does indeed fix the issue. Thanks!
Describe the bug When running ipptransform the resulting file comes out (visually) empty.
To Reproduce Steps to reproduce the behavior:
LD_LIBRARY_PATH=./cups/ ./tools/ipptransform -m application/pdf ~/Downloads/cs-ippraster10-20120420-5102.4.pdf > out.pdf
Expected behavior Output files show the same content (visually) as the input.
System Information:
Additional context XPDF manages to open/render the file (still printing the same errors), but anything Poppler-based, Firefox and Chromium all fail to show anything at all. Poppler not being able to display the PDF also makes the issue propagate to raster formats if ipptransform uses Poppler pdftoppm. I have this happening for all the handful of PDFs tested, but should i have been extraordinarily unlucky, use http://ftp.pwg.org/pub/pwg/candidates/cs-ippraster10-20120420-5102.4.pdf
The problem is not entirely new, but has been around a while now, i just didn't get around to reporting it.
I was suspecting locale float formatting issues, but my shell has $LANG en_US.UTF-8.