View Issue Details

IDProjectCategoryView StatusLast Update
0013128ScribusImport / Exportpublic2016-05-26 16:44
Reporterale Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version1.5.1svn 
Summary0013128: pdf export: pdfcheckpoint does not validate scribus' pdfs
Descriptiona user has reported in the forum that pdfcheckpoint (http://zevrix.com/pdfcheckpoint.php) does not accept scribus' pdfs.

the pdfcheckpoint's developer came to the forum and has posted his point of view on the problem:

"""
For some reason, Scribus stores a single Resources dictionary inside the Pages dictionary. This Resources dictionary contains resources, such as Fonts and XObject, for the entire file.

In all other PDF files I encountered, each individual Page dictionary contains its own Resources. If, for example, you resave a Scribus PDF from Preview or Acrobat, it will be restructured in this exact way.
"""

the pdfcheckpoint is ready to discuss the issue.

i will add in the forum a link to this ticket.
Tagsdiscussion, pdfcheckpoint
PatchNo

Activities

jghali

2015-06-10 13:18

administrator   ~0035360

>> For some reason, Scribus stores a single Resources dictionary inside the Pages dictionary. This Resources dictionary contains resources, such as Fonts and XObject, for the entire file.

This is perfectly valid per PDF specs. Point 3.7.2 of PDF 1.7 specifications : "(Since a page’s Resources attribute is inheritable, as described under “Inheritance of Page Attributes” on page 149, it may actually reside in some ancestor node of the page object.)".

The same wording exists also in point 3.7.2 of PDF 1.3 and PDF 1.4 specs. Finally Acrobat preflight validates our PDF syntax.

cbradney

2015-06-10 18:26

administrator   ~0035361

bug in pdfcheckpoint then...

ale

2015-06-10 18:40

manager   ~0035362

the question is why pdfcheckpoint does not accept it...
let's see if zevrix has good reasons to do so...

zevrix

2015-06-11 08:42

reporter   ~0035375

Thanks for the detailed reply.

I believe there's two aspects here:

First: I totally understand that this structure is perfectly valid per PDF specs.

Second: It looks like Scribus is the only app that employs this structure. Like I mentioned, even if you resave Scribus’ PDF from Acrobat (and Preview), they'll restructure the file by creating Resources in each Page.

To get the Resources info, PDF Checkpoint uses a 3rd party parsing framework (whose code is fully open). This framework goes Page by Page to get data from Resources. That’s also how PDF Checkpoint associates images with specific pages.

The framework doesn’t expect to find any Resources in the Pages node, therefore it comes empty handed after parsing Scribus files - and that’s why PDF Checkpoint eventually crashes (and any other app that uses this framework will fail too).

Prior to using that framework, I used my own parsing based on Cocoa CGPDF stuff and Apple’s guides to PDF parsing - which also instructed to explore Page by Page.

I bring it up to demonstrate that I’m not the only developer who expects a separate Resources dictionary for every Page.

Now, I can definitely make changes to parse Scribus' PDFs properly. it’s a lot of work though - as there’re layers of code based on the existing approach - which in turn is based on working with myriads of PDF documents and other developer tools I mentioned.

Right now it’s easier for me to just resave a Scribus PDF under the hood using PDFKit - which will restructure the file as I mentioned above - and then work with the new file. Which is what I’ll do as an immediate solution.

Now what's my point?

I totally understand if you won't be willing to change your existing PDF structure - as you don't have to. Technically, you're doing everything by the book.

On the other hand, evidently, it's not a commonly used approach. It isn't employed by industry standard tools - and, in fact, is being explicitly changed when resaved from Acrobat and Preview.

So, whatever the reason for it, I wonder if it's worth it to stick to this approach, even if correct?

Let me know what you think - and thanks again for your attention to the matter!

Leo

jghali

2015-06-11 17:53

administrator   ~0035376

>> I bring it up to demonstrate that I’m not the only developer who expects a separate Resources dictionary for every Page.

Yeah, I know. But that is wrong. I have myself developed PDF processing software for years in a big printing company in Europe and this assumption does not allow to reach industrial reliability. Given the pages tree structure used in PDF format, the cited point 3.7.2 is an important one. Tools such as Acrobat, Enfocus Pitstop, or Pitstop server (which does not depend on Acrobat) perfectly accomodate the structure we use as well as all the rips I had the opportunity to test myself.

The resource inheritance is a pretty important property not only for pages, but also for objects such as PDF forms and patterns.

>> Prior to using that framework, I used my own parsing based on Cocoa CGPDF stuff and Apple’s guides to PDF parsing - which also instructed to explore Page by Page.

Not astonished that you changed your parser. Apple PDF stuff is not that good. I even know a company which first wrote a software using Apple PDF components and in the end... they had to rewrite major portions of their code using Adobe PDF Library SDK to solve all the issues they had.

>> So, whatever the reason for it, I wonder if it's worth it to stick to this approach, even if correct?

This approach has never posed any problem for the 10 years I have been working on Scribus. All PDF tools and rips I ever used process resource dictionary inheritance properly. So at this point I do not feel there is an urgent need to change the structure we use.

zevrix

2015-06-20 11:55

reporter   ~0035460

Thanks, I see your point.

And yes, Apple PDF frameworks are limited in many aspects.

Issue History

Date Modified Username Field Change
2015-06-10 09:16 ale New Issue
2015-06-10 13:18 jghali Note Added: 0035360
2015-06-10 18:26 cbradney Note Added: 0035361
2015-06-10 18:40 ale Note Added: 0035362
2015-06-11 08:42 zevrix Note Added: 0035375
2015-06-11 17:53 jghali Note Added: 0035376
2015-06-20 11:55 zevrix Note Added: 0035460
2016-04-20 05:01 Kunda Tag Attached: discussion
2016-05-26 16:44 Kunda Tag Attached: pdfcheckpoint