Bug 697525 - PS to PDF creates blank page
Summary: PS to PDF creates blank page
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 9.20
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-30 11:40 UTC by clark
Modified: 2017-02-08 00:16 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
original PDF (109.92 KB, application/pdf)
2017-01-30 11:40 UTC, clark
Details
PS file (61.18 KB, application/postscript)
2017-01-31 02:09 UTC, clark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description clark 2017-01-30 11:40:43 UTC
Created attachment 13332 [details]
original PDF

When converting this PDF to PS and back to PDF the PDF is more or less blank

PDF file
http://docdro.id/qY5UQ8l

pdftops fak.pdf out.ps
gs \
  -o output.pdf \
  -sDEVICE=pdfwrite \
  -dPDFSETTINGS=/prepress \
  -dHaveTrueTypes=true \
  -dEmbedAllFonts=true \
  -dSubsetFonts=false \
  -f out.ps

pdftops 0.51
ghostscript 9.20
Comment 1 Ken Sharp 2017-01-30 23:55:51 UTC
(In reply to clark from comment #0)
> Created attachment 13332 [details]
> original PDF
> 
> When converting this PDF to PS and back to PDF the PDF is more or less blank

You haven't supplied the PostScript output from pdftops, only the original PDF file.

I'm going to need the PostScript file that you send to Ghostscript.
Comment 2 clark 2017-01-31 02:09:50 UTC
Created attachment 13334 [details]
PS file
Comment 3 clark 2017-01-31 02:10:04 UTC
PS file added :)
Comment 4 Ken Sharp 2017-01-31 02:33:20 UTC
Running the PostScript file through Ghostscript gives an error "rangecheck in --xyshow--" for me, which you seem to have neglected to mention in your report.

Adobe Acrobat Distiller gives exactly the same error.

Looks like pdftops produced a broken PostScript program, nothing *we* can do about that for you. The PostScript contains (simplifying considerably):

(\000\015)
[6.972
0] xyshow

Each character code in the string (note its a 2 byte string, so 2 character codes)  uses one pair of numbers from the array for positioning. Since there are two character codes, it needs an array with 2 pairs of positions, 4 numbers. This array contains only 2, hence the rangecheck error.

It 'looks like' the poppler developers thought they could define a simple font with 2 byte character codes (the font is created by a routine called pdfMakeFont16), but that's not possible. You need a type 0 font or a CIDFont to use more than a single byte code. This is, of course, caused by the fact that the original PDF file contains a CIDFont.

So basically poppler is broken, you're opening a bug report against the wrong product, maybe you should send it to the poppler developers.

Of course, PDF->PS->PDF is a dumb thing to do anyway, you are practically bound to lose quality doing so. If for some strange reason you absolutely must do this, perhaps you should consider using Ghostscript's ps2write device to produce the intermediate PostScript file, since that actually works, though it does produce bitmaps for the glyphs; this is what I mean when I say that the refrying loses quality.

If I were you I would think carefully about why you are doing this multi-step process and whether the intermediate PostScript file is actually required.
Comment 5 clark 2017-01-31 04:51:16 UTC
Thanks for the very detailed answer.. Im doing it to reduce the filesize and poppler is fastest and the final PDF is smaller than using gs built-in tool

I didnt know if the problem was poppler or gs
Comment 6 Ken Sharp 2017-01-31 05:04:01 UTC
(In reply to clark from comment #5)

> Thanks for the very detailed answer.. Im doing it to reduce the filesize and

Using /prepress is not the best solution to reduce filesize, and going via PostScript is entirely likely to *increase* the file size, especially if the source PDF file contains transparency.


> poppler is fastest and the final PDF is smaller than using gs built-in tool

But it doesn't work, whereas the Ghostscript output does.....

 
> I didnt know if the problem was poppler or gs

The error message would be a clue in this case.

I would suggest that you simply drop the PostScript intermediate stage, go direct to PDF. And rather than using canned settings (and in particular the /prepress settings) you choose the options carefully to reduce the file size.
Comment 7 clark 2017-01-31 05:09:22 UTC
I use /screen in production.. This was just for testing :)

But this is the only file where it doesnt work, and poppler is still alot faster and thats also an important parameter

I actually both split it in to different processes.. One where the file is converted to PS and back and one directly from PDF to PDF.. I use the smallest file of the two
Comment 8 Ken Sharp 2017-01-31 05:15:16 UTC
(In reply to clark from comment #7)

> But this is the only file where it doesnt work,

I would add 'so far' to that. It looks to me like a complete failure on the part of Poppler to handle CIDFonts when converting to PostScript. CIDFonts are not unusual (even in Latin languages) in PDF files.

> I actually both split it in to different processes.. One where the file is
> converted to PS and back and one directly from PDF to PDF.. I use the
> smallest file of the two

Well its your choice. I would not do this and would not recommend it.
Comment 9 clark 2017-02-07 15:17:32 UTC
Btw. You say that the issue rise because the orginal PDF has CIDFont?

Is it possible to convert these fonts before sending the file to pdftops so it might work? :)
Comment 10 Ken Sharp 2017-02-08 00:16:04 UTC
(In reply to clark from comment #9)
> Btw. You say that the issue rise because the orginal PDF has CIDFont?

In a sense. The PDF file has at least one CIDFont (CIDFonts are not the same as Fonts).

CIDFont support was added to the PostScript language during the lifetime of the level 2 specification. This means that strict level 2 PostScript implementations (version 2010 of Adobe implementations) cannot support CIDFonts. As I recall this was added in version 2015 of the Adobe implementation, but that isn't helpful.

So in order to send a CIDFont to a language level 2 interpreter, its best to convert the CIDFont into 'something else', which is what Ghostscript's ps2write device does. Poppler appears to try and do something as well, but fails, resultig in broken PostScript. Presumably this is a bug in Poppler.

 
> Is it possible to convert these fonts before sending the file to pdftops so
> it might work? :)

Possible ? Yes. Easy ? Absolutely not.