Bug 79168 - ps created by pdftops in this pdf file does not get printed correctly (missing French characters)
Summary: ps created by pdftops in this pdf file does not get printed correctly (missin...
Status: RESOLVED NOTOURBUG
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-24 07:09 UTC by Mahendra Tallur
Modified: 2016-07-16 05:54 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Attachments
When printed with Okular (pdftops then lpr) most French characters with accents disappear ! (80.18 KB, application/pdf)
2014-05-24 07:09 UTC, Mahendra Tallur 		Details
pdftops cerfa_14952-01.pdf | gs -sDEVICE=pwgraster | rastertopdf (225.09 KB, application/pdf)
2014-05-24 19:12 UTC, James Cloos 		Details
View All

Description Mahendra Tallur 2014-05-24 07:09:03 UTC 
Created attachment 99691 [details]
When printed with Okular (pdftops then lpr) most French characters with accents disappear !

Hi ! Here is a bugreport I make after filing one for Okular and based on the advice of one of its developers (https://bugs.kde.org/show_bug.cgi?id=334692)

I first noticed that when printing a specific (French administration) PDF (attached here), most characters with accents (é, è, à...) appeared on the screen but not on the printer ! I then noticed that the bug didn't occur with Evince but did occur with Okular on the very same machine (Kubuntu 14.04 i386).

Then an Okular developer confirmed the issue by saying that basically all that Okular did was "pdftops" then "lpr". The problem doesn't appear onscreen with the PS file either !

I provide you with the PDF document that triggers the issue.

Thanks a lot to everyone ! Best regards,
Mahen
Comment 1 Adrian Johnson 2014-05-24 10:20:55 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
Comment 2 Albert Astals Cid 2014-05-24 10:37:58 UTC 
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?
Comment 3 Adrian Johnson 2014-05-24 10:47:42 UTC 
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?
Comment 4 Albert Astals Cid 2014-05-24 11:07:31 UTC 
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
Comment 5 Adrian Johnson 2014-05-24 11:54:51 UTC 
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.
Comment 6 Mahendra Tallur 2014-05-24 12:24:02 UTC 
Bug occurs on Samsung ML 1650 as well. Thanks to everyone for commenting / checking :)
Comment 7 Adrian Johnson 2014-05-24 12:56:04 UTC 
(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.
Comment 8 Mahendra Tallur 2014-05-24 15:56:30 UTC 
Does the fact that the bug does NOT occur with Evince give us a clue about the potential triggering factors ? (same printer / distro / etc.)
Comment 9 James Cloos 2014-05-24 19:12:35 UTC 
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.
Comment 10 James Cloos 2014-05-24 19:28:42 UTC 
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
Comment 11 Mahendra Tallur 2014-06-04 15:57:51 UTC 
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
Comment 12 Adrian Johnson 2016-07-16 05:54:53 UTC 
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.