Bug 53159 - Provide HiResBoundingBox or even ExactBoundingBox comment in EPS
Summary: Provide HiResBoundingBox or even ExactBoundingBox comment in EPS
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: utils (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-06 12:15 UTC by Sven
Modified: 2012-08-14 22:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
PDF file that makes pdftops -eps generate identical BoundingBox and HiResBoundingBox (10.74 KB, application/pdf)
2012-08-08 21:15 UTC, Sven
Details

Description Sven 2012-08-06 12:15:34 UTC
Run pdftops -eps input.pdf output.eps and observe that the EPS file neither has a HiResBoundingBox comment not an ExactBoundingBox comment. It merely has a BoundingBox comment, which provides limited precision as it's limited to integer values only.
Comment 1 Thomas Freitag 2012-08-06 12:41:57 UTC
You're not true: If the PDF file has an exact size in points, You don't need it, than BoundingBox is sufficient. And that's how poppler implemented it: HiResBoundingBox is written and only is written if the size has float values.

And BTW: Applications designed for accuracy will tend to look for and use
HiResBoundingBox, but never require it.

Sample:

%!PS-Adobe-3.0 EPSF-3.0
%Produced by poppler pdftops version: 0.18.0 (http://poppler.freedesktop.org)
%%Creator: cairo 1.9.5 (http://cairographics.org)
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%BoundingBox: 0 0 842 596
%%HiResBoundingBox: 0 0 841.9 595.3
%%DocumentSuppliedResources: (atend)
%%EndComments
Comment 2 Sven 2012-08-06 13:12:52 UTC
Hmm. Then the PDF I used must have had a size which is a multiple of the point size.

Why do you not always emit a HiResBoundingBox? Why have the logic to avoid emitting HiResBoundingBox in case the decimal places are all zero?

I understand your point, that application that look for a HiResBoundingBox use the BoundingBox as a fallback. Now imagine a software that is designed for accuracy and therefore emits a warning if the HiResBoundingBox is not found.
Comment 3 Thomas Freitag 2012-08-06 13:37:34 UTC
Please read http://partners.adobe.com/public/developer/en/ps/5644.Comment_Ext.pdf.
which extends http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

I know that there are a lot of freeware tools available which behaves in different ways, but poppler cannot support them all. You already point to one of "funny" extensions: ExactBoundingBox was never defined by Adobe, and the postscript bible still comes from Adobe.

And if You have a look at the date of the latest spec, You can also say: all tools have time enough to support DSC conventions in a proper way.

But I'm not an official poppler member, You may hope to get other responses.

Cheers,
Thomas
Comment 4 Sven 2012-08-06 13:45:53 UTC
(In reply to comment #3)
> Please read
> http://partners.adobe.com/public/developer/en/ps/5644.Comment_Ext.pdf.
> which extends
> http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

Please don't point me at a bunch of documents without making a statement that you see confirmed by that documents.

I assume, that you intend to say that these documents state that a HiResBoundingBox should be omitted whenever possible. However, at first sight I cannot find such a statement in the two documents.

Also, I was not able to find an answer to my question, namely why it is useful to omit the HiResBoundingBox whenever possible. I have found the recommendation to never omit a BoundingBox. But that doesn't imply that the HiResBoundingBox should be omitted when possible.

> I know that there are a lot of freeware tools available which behaves in
> different ways, but poppler cannot support them all. You already point to one
> of "funny" extensions: ExactBoundingBox was never defined by Adobe, and the
> postscript bible still comes from Adobe.

Agreed. Forget about the ExactBoundingBox then.
Comment 5 Albert Astals Cid 2012-08-06 13:54:07 UTC
(In reply to comment #3)
> But I'm not an official poppler member.
Come on, you are underplaying yourself ;-)


(In reply to comment #4)
> I assume, that you intend to say that these documents state that a
> HiResBoundingBox should be omitted whenever possible. However, at first sight > I cannot find such a statement in the two documents.
Do they say it's mandatory?

> Also, I was not able to find an answer to my question, namely why it is useful
> to omit the HiResBoundingBox whenever possible.
Makes file smaller :D
To be honest, i don't know and i don't care, but it seems that you are making a lot of noise on something that is "i wish this was true", but it isn't, if you are using software that *wrongly* mandates HiResBoundingBox to be there, maybe you should bug them instead of us?
Comment 6 Sven 2012-08-06 14:16:05 UTC
(In reply to comment #5)
> Do they say it's mandatory?

Of course not.

> > Also, I was not able to find an answer to my question, namely why it is useful
> > to omit the HiResBoundingBox whenever possible.
> Makes file smaller :D
> To be honest, i don't know and i don't care, but it seems that you are making a
> lot of noise on something that is "i wish this was true", but it isn't, if you
> are using software that *wrongly* mandates HiResBoundingBox to be there, maybe
> you should bug them instead of us?

Why should i bug them? They didn't ask you to implement it the way you did.
At some point, somebody decided to omit the HiResBoundingBox. So I was curious whether you know why. Obviously you don't.

My point why it should always be there? Simplicity (less logic in the code) and uniformity (the output file always has the same format). Not very strong points, rather weak ones.
Comment 7 Sven 2012-08-06 14:24:53 UTC
Found the code in PSOutputDev.cc:

    if (floor(x1) != ceil(x1) || floor(y1) != ceil(y1) ||
        floor(x2) != ceil(x2) || floor(y2) != ceil(y2)) {
      writePSFmt("%%HiResBoundingBox: {0:.6g} {1:.6g} {2:.6g} {3:.6g}\n",
                 x1, y1, x2, y2);
    }

First a small hint: floor(x1) != ceil(x1) is equivalent to floor(x1) != x1.
Second: the logic can still yield a HiResBoundingBox where all numbers are of the form <int>.000000 unless you can exclude the float numbers differ from an integer number by at least 5e-7. Not sure, whether the latter always holds.
Comment 8 Albert Astals Cid 2012-08-07 22:49:08 UTC
Do you have any real reason why we should always output the HiResBoundingBox?

As said, i don't mind commenting that if, but i want to know if there is a real reason or it is just to make you happier.
Comment 9 Sven 2012-08-08 21:15:13 UTC
Created attachment 65312 [details]
PDF file that makes pdftops -eps generate identical BoundingBox and HiResBoundingBox

(In reply to comment #8)
> Do you have any real reason why we should always output the HiResBoundingBox?

What is a "real reason"? We have already established, that there there shouldn't be any technical problems with the eps generated by pdftops.

> As said, i don't mind commenting that if, but i want to know if there is a real
> reason or it is just to make you happier.

What is a "real reason"?

I have pointed out two "aesthetic" reasons: simplicity and uniformity.
I have also pointed out, that the check which decides whether HiResBoundingBox is emitted is numerically flawed as it fails to achieve the presumable goal of omitting the HiResBoundingBox if it is equal to the ordinary BoundingBox. Along with posting this comment, I will attach a PDF file that will make pdftops -eps write the following into the eps:
%%BoundingBox: 0 0 2 2
%%HiResBoundingBox: 0 0 2 2

If nothing of that is enough for you to remove the two lines, then so be it.
Comment 10 Albert Astals Cid 2012-08-14 22:03:36 UTC
Made the change so that poppler 0.22 will always output HiResBoundingBox.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.