|
Description
Alex
2012-04-05 11:31:15 UTC
What exactly does "funny" mean? I did not laugh. I didn't try to print this either, but just opening it in a PDF viewer I get "character soup". What should this look like? The print will be exactly as the pdf example. The result are the same "character soup" using cups-pdf printer and phisical a printer. (In reply to comment #1) > What exactly does "funny" mean? I did not laugh. In this case 'funny' means odd. So... The PDF print just fine and the result is the same thing that is visible on screen? What you see is what you get? What's the bug then? Created attachment 59534 [details]
The correct print.
(In reply to comment #5) > Created attachment 59534 [details] > The correct print. The bug is exactly the "character soup" when printing. Sorry, I should also have attached the corrects one at the first time. Could you tell me how to reproduce the bug. The first pdf you attach was produced by ghostscript, not cairo. Assuming you are using gtk, print to a file in both PS and PDF format it check if it is correct. The first pdf I created printing the original pdf (the second attached). Yes, I'm using gtk (Gnome 3.4) _________________________________________________ How to reproduce the bug: (using Arch Linux - testing) 1- Take some pdf made using LaTeX; 2- Print the PDF with cairo-1.12.0 installed; 3- Get the "character soup". Another way: 1- Take some pdf made using LaTeX; 2- Print the PDF with cairo-1.10.2 installed; 3- Get the correct print. ___________________________________________________ Attachements: lipsum.pdf - Made by pdflatex command printed_lipsum.pdf - printed from lipsum.pdf (using evince - maybe a Evince bug?) printed2_lipsum.pdf - printed from lipsum.pdf (using command line) printed_lipsum.ps - printed from lipsum.pdf (using command line) Created attachment 59547 [details]
Created by pdflatex
Created attachment 59548 [details]
Printed from lipsum.pdf (using evince - maybe a Evince bug?)
Created attachment 59549 [details]
Printed from lipsum.pdf (using command line)
Created attachment 59550 [details]
Printed from lipsum.pdf (using command line)
Created attachment 59551 [details]
Printed from printed_lipsum.ps (using Evince)
I did forget this.
Fixed with this commit: http://cgit.freedesktop.org/cairo/commit/?id=70b2856ed3d31b41e69b3d82fb9c5c11c2b3d3d4 Thanks!!! Compiling git version... Now! Unfortunately, until this commit http://cgit.freedesktop.org/cairo/commit/?id=8886220b5027296f5b3b95e9c2f93509108d3b9e not fixed here. Exactly same issue. Using git version. Are you saying it is not working with git master or it was working and the last commit broke it? Can you attach the pdf output when using git master. I compiled for each at last three commits updates, and none of that solved the issue here. Created attachment 59558 [details]
Printed now.
(In reply to comment #20) > Created attachment 59558 [details] > Printed now. This file was created by ghostscript. Does the cairo pdf and ps output work correctly? Created attachment 59560 [details]
Created with LibreOffice pdf export.
I don't know how to create a pdf/ps file directly using Cairo. So, I created with Libreoffice pdf export now.
Created attachment 59561 [details]
Original pdf imported with Inkscape and after printed with cups-pdf.
Open the original pdf in evince then print to a file. The pdf output will be produced by cairo (you can check with pdfinfo or file->properties in evince). Evince uses cairo to generate PS/PDF output. If you print to CUPS-PDF the cairo PS output is converted to PDF by ghostscript. In this case it is not possible to determine whether the bug is in cairo or ghostscript. Also you will get better quality pdf output by using print to file. The text in the CUPS-PDF output can not be copied and pasted. The last three attachments do not have the very large glyph spacing so I'm not sure why you are still seeing the problem. Although the inkscape pdf output has a small issue with the the glyph spacing but this could be a limitation of the pdf import. Created attachment 59562 [details]
Evince print to a file (pdf)
Created attachment 59563 [details]
Evince print to a file (ps)
How can I help to grow the glyph spacing? (In reply to comment #28) > How can I help to grow the glyph spacing? The glyph spacing looks to same as the pdflatex PDF. If you want to increase the glyph spacing you will need to do that from within pdflatex. Once printed to PDF the layout is fixed. I don't know if it help, but I make a test using my master dissertation and printing with cups-pdf or cairo the issue doesn't happens. Created attachment 59564 [details]
Printed using cups-pdf.
Created attachment 59565 [details]
Evince using print to a file.
Created attachment 59566 [details]
Evince using print to a file.
These lasts are a little big files.
(In reply to comment #30) > I don't know if it help, but I make a test using my master dissertation and > printing with cups-pdf or cairo the issue doesn't happens. So the bug has been fixed? Or is there still a problem? Well, the dissertation prints perfect but others not. I'm thinking the issue is only with one(some) font(s). The issue ever happens when using "latin modern" (lmodern) font (not used in dissertation), but it is the default in latex.
I'll try with a big document using latin modern font to see if it will happens.
Could you attach a pdf that doesn't work. You can also use pdftocairo to simplify testing. It is a poppler utility that outputs directly to cairo. eg to print to ps: pdftocairo -ps pdffile.pdf output.ps to print to pdf: pdftocairo -pdf pdffile.pdf output.pdf Thank you for the tip, really easily on this way! From cups-pdf the issue happens. (it's seems very slow to print) From Cairo pdf/ps perfect. Attaching... Created attachment 59569 [details]
Using cairo (ps).
Created attachment 59570 [details]
Using cairo (pdf).
I need to reduce the document, the cups-pdf output is going to 4.5MB.
You can use the -f and -l last options with pdftocairo to select a range of pages. Created attachment 59571 [details]
Using cups-pdf.
The issue happens.
Only the cups-pdf version goes bigger in MBs.
(In reply to comment #37) > Thank you for the tip, really easily on this way! > > From cups-pdf the issue happens. (it's seems very slow to print) > > From Cairo pdf/ps perfect. > > Attaching... If the cairo output is correct but the cups-pdf output wrong the bug is in cups-pdf. Thank you for your time. I'll report to cups-pdf upstream now. > From cups-pdf the issue happens. (it's seems very slow to print)
Based on the earlier comments on this thread, the cups-pdf likely
involves transparancy.
I suspect your cups filter chain first converts to postscript, uses
the pstops filter to set various options as per the ppd, and then
sends that ps to ghostscript’s pdfwriter DEVICE. The conversion to
postscript step necessarily involves rasterizing any sections which
include transparancy to a pixmap. It may do any page rather than
just any block.
In general, it is best to avoid cups-pdf if the program from which
you are printing has a print-to-file option.
Separately, the fact the evince re-generates a file for print rather
than passing the original document to the print flow is its own bug.
But one that they have refused to fix in the past.
Since the fonts might be an issue, does your ΤεΧ install use the type1
or the otf version of Latin Modern? LM has more built-in leading than
most (Free) fonts; that may be related.
I use type1 fonts in latex. Since you talked about filters, I removed the "cups-filters-1.0.11" package and reinstall cups and foomatic*. Now every seems perfect. So, the bug seems to be in cups-filters. I'll attach the new results. Created attachment 59596 [details]
Original from pdflatex.
Created attachment 59597 [details]
Printed by cups-pdf.
Created attachment 59598 [details]
Evince print to a file (pdf)
Created attachment 59599 [details]
Evince print to a file (ps)
Really sorry, I did the last tests with cairo-1.10.2. So, all is the same as before. But I found a workaround. If I take the original file and use 'print to a file' postscript (pdf not work) and after I print (using cups-pdf or phisical printer) it's just works. Also, I found the same issue using phisical printer, but I have no reliable ink amount now (only monday I will receive a new one). In this case, I think this issue is a cups bug and not a cups-pdf specific bug. I'll wait to the next monday to test with reliable amount of ink in the printer, and if I confirm the same issue using a phisical printer, I will report to cups upstream. Thanks! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.