View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015140||Scribus||public||2018-02-10 15:18||2018-02-10 15:18|
|Target Version||Fixed in Version|
|Summary||0015140: clarification on closed issue 0015135 about image references in pdf|
|Description||Issue 0015135 reported, "Hi, when exporting to pdf it seems that the pdf generates wrong references. I first thought the pdf tool I used afterwards has an issue, but that developer did some very good analysis and I believe now that the issue is that scribus does the pdf export not correctly. For details see https://github.com/qpdf/qpdf/issues/174 "|
The bug was closed with the comment, "Not a Scribus bug. Per PDF specifications, resources can be at any level of the pages tree. Not analyzing resources of parent pages nodes is the real issue."
I wanted to provide some clarification. There is no claim that Scriubs is creating a PDF file that doesn't comform to PDF specification. You are correct that the PDF specification allows resources to be attached at any level of the pages tree. The problem is not that some other software is not analyzing resources of parent pages. The problem is that the resources associated with the page includes images that are not used by that page. This is not a violation of the PDF spec, but it prevents other applications from figuring out which images are needed by a particular page without analyzing the content stream. Analyzing the content stream requires software that actually knows how to interpret PDF at a much deeper level than just analyzing the resources.
If Scribus were to attach the resource dictionary separately to each page and include only the images that are used by that page, it would enable any program that splits PDFs into pages to do so without having to analyze content streams. Hopefully this clarifies the issue. Scribus is creating files that are valid, they are just not set up in a way that provides optimal information to PDF readers.
|Tags||No tags attached.|