An example would be a filled rectangle (not, as here, a rectangle with a hole in it, that just adds more complexity) So avoid text, the resulting paths are complicated.Ī simple file would be one consisting of a single object (or at least the absolute minimum number of objects required to reproduce it). In fact you application hasn't included any actual text at all, its all drawn as linework and just happens to have the same shape as characters. If you must use text, then keep it to one glyph. Repeating the graphic simply doubles the complexity, I would have thought that was obvious.
Pdfwriter el capitan pdf#
In fact in PDF terms this file is *more* complex than the one you originally sent (the original did not contain any forms XObjects for example).Īs noted below I certainly cannot reproduce this error, the output from pdfwrite renders as expected on every PDF consumer I have tried. The pdfwrite output decompresses to 2.4MB. Decompressing this file results in a 2.5MB PDF which is (surprising though it may seem) actually very complicated. Your designer may think this is simple, I'm afraid I have to disagree. > the error now, maybe we can find a solution together. > So I asked our designer to make a very basic example. > You wrote, that you can't compare the PDFs, because they were too complex. If (and I suspect its a big if) Apple will tell you what's wrong with the file then I'm prepared to look again but right now I can't see that we have a bug.
I did decompress the two files and examine them, but they are radically different and the content is too complex to make comparison possible. Ghostscript, on the other hand, particularly a debug build which is what I was using, will complain about anything it thinks is wrong, and pdf.js usually gets anything complex wrong.
It doesn't mean there *isn't* a problem, Acrobat (in all its guises) is notorious for silently ignoring problems with PDF files. > I can totally see you point, that currently there is no issue with > which I renamed before upload into "pdf_with_error.pdf".Īh, I was expecting to find a file with a name of the form 'page_xxxxx.pdf'. On the evidence so far I cannot see any problem with the output from Ghostscript and would have to say that this seems to be a fault in the Apple OS (Quartz ?). This is in itself slightly surprising, since pdf.js does not have a good reputation for dealing with transparency, if the output file works on that it is a reasonably reliable indication that there is no actual problem with the file. *All* of these viewers opened the file without warning and displayed what appeared to me visually the same as the original PDF file. However, I can open the resulting file (attached here) in a variety of PDF consumers including Ghostscript, Acrobat X Pro, Acrobat Reader DC (2015.009.20069 version), MuPDF and pdf.js. The only version of MacOS I have access to is 10.8 which you say will work correctly, so there's no real point in me opening it there. I did try taking your original file and running it through Ghotscript and the pdfwrite device. You are also using a slightly out of date version of Ghostscript, the current shipping version is 9.18.
Pdfwriter el capitan mac#
As I'm a non Mac user I'm afraid that referring to Mac versions by name doesn't mean much to me either. You haven't attached the output file you created, just screenshots, which don't really tell me much except that you see a problem. Simpler example (not weboptimized): After ghostscript Simpler example (not weboptimized): Before ghostscript Screenshot including the PDF as visible on Yosemite
Screenshot including the error as visible on El Capitan
0 kommentar(er)
