| Summary: | ps created by pdftops in this pdf file does not get printed correctly (missing French characters) | ||
|---|---|---|---|
| Product: | poppler | Reporter: | Mahendra Tallur <mahen> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | cloos, garrett.mitchener, mahen |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
When printed with Okular (pdftops then lpr) most French characters with accents disappear !
pdftops cerfa_14952-01.pdf | gs -sDEVICE=pwgraster | rastertopdf |
||
|
Description
Mahendra Tallur
2014-05-24 07:09:03 UTC
I tried printing with 0.26: pdftops bug.pdf - | lpr -l and it works for me. You could also try: pdftops bug.pdf - | grep -v UniqueID | lpr -l Tried both suggestions from Adrian and i still do not get the characters when on printing (they show up in gs). Is this a cups fault? printer fault? If you use the '-l' option with lpr it bypasses all cups filtering. So the problem is not cups. It may be a printer fault. What printers can this bug be reproduced on? Oh, hadn't seen the -l, sorry, i've tried now with -l and the printer doesn't seem to like that, it doesn't even try to start to print :/ I'm using an HP Deskjet 3050A lpr -l only works for postscript printers. So you are saying the ps files renders correctly on screen with gs but fails to print? I assume it is gs doing the conversion from ps to whatever your printer understands. Bug occurs on Samsung ML 1650 as well. Thanks to everyone for commenting / checking :) (In reply to comment #6) > Bug occurs on Samsung ML 1650 as well. Another non PS printer. The issue seems to be with CUPS (or something CUPS is using) to convert the PS. Does the fact that the bug does NOT occur with Evince give us a clue about the potential triggering factors ? (same printer / distro / etc.) Created attachment 99733 [details] pdftops cerfa_14952-01.pdf | gs -sDEVICE=pwgraster | rastertopdf > Does the fact that the bug does NOT occur with Evince give us a clue about the > potential triggering factors ? (same printer / distro / etc.) pdftocairo -ps should give the same results one gets from printing from evince. I tried having gs output pcl (-sDEVICE=ljet4d -dBATCH -dNOPAUSE -r600) and viewed that with ghostpcl. Nothing seems to be missing. I then used gs’s pwgraster device and cups-filter’s new rastertopdf filter to generate a raster pdf, to get an idea of what printers should get. I’m attaching that. That said, your cups filter chain might use gs to convert the ps back to pdf before rendering it to raster. The current version of cups-filters should avoid that, but you’d have to check by enabling cups debugging (goog for the details). Except in some cases where the printer speaks postscript, it is better to send the original pdf to lp/lpr and let the filters render the pdf directly. Ah. I just replicated the problem by using gs to render the original pdf to raster. The »RÉCÉPISSÉ À REMETTRE AU MANDANT« header on the second page looses its É and À glyphs. Doing the same with gs git master does not show the bug, so they must have fixed it since 9.14 was released. This command line demonstrates the bug: gs -sDEVICE=tiffg4 -dBATCH -dNOPAUSE -r600 -sOutputFile=cerfa_14952-01.tif cerfa_14952-01.pdf Thanks everyone ! Meanwhile, did any of you file an upstream bugreport (Ghostscript) ? May I do it by supplying the information you specificed in this bugreport ? Best regards, Mahen According to comment 10 the bug is in ghostscript. |
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.