View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013128 | Scribus | Import / Export | public | 2015-06-10 09:16 | 2016-05-26 16:44 |
| Reporter | ale | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 1.5.1svn | ||||
| Summary | 0013128: pdf export: pdfcheckpoint does not validate scribus' pdfs | ||||
| Description | a 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. | ||||
| Tags | discussion, pdfcheckpoint | ||||
| Patch | No | ||||
|
|
>> 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. |
|
|
bug in pdfcheckpoint then... |
|
|
the question is why pdfcheckpoint does not accept it... let's see if zevrix has good reasons to do so... |
|
|
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 |
|
|
>> 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. |
|
|
Thanks, I see your point. And yes, Apple PDF frameworks are limited in many aspects. |
| 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 |
