Re: Understanding the eps bounding box (rounding)

[Urs Liska]

Am 02.03.2018 um 16:02 schrieb Alexander Kobel:
> Hi again,
>
> On 03/02/2018 03:10 PM, Urs Liska wrote:
> > [...]
> > First I thought this is the solution.
> > Then the confusion came.
> > But now I think again that it's the solution :-)
> >
> > I assume the difference between the BoundingBox and the 
> > HiResBoundingBox is exactly what I'm after.
> > Unfortunately the box is shifted to a new origin: the lower left 
> > corner now is the origin of the resulting image and not related to 
> > the staff symbol anymore.
> > However, I can
> > - read the "rough" values from the original .eps file
> > - run your gs command on the final .pdf
> > - use the .eps values to shift the rectangle.
> >
> > $ head -n 3 bbox-1.eps | tail -n 1
> > %%BoundingBox: -80 -37 400 1
> > $ gs -sDEVICE=bbox -q -dBATCH -dNOPAUSE bbox-1.pdf
> > %%BoundingBox: 0 0 480 38
> > %%HiResBoundingBox: 0.504000 0.522000 479.510774 37.025999
> >
> > So I have to shift the X coordinates by -80 (the llx) and the Y 
> > coordinates by -37 (the lly) to get
> > -79.504 -36.5222 399.519774 0.025999
> >
> > I think this is the way to go and should actually be quite manageable.
>
> Now apparently it's me who's confused. You just want to get the proper 
> line lengths, right? 

No.

> Why do you even need to touch the .eps then?

Because the bounding box in the PDF is missing crucial information.
The precision issues aside, the BoundingBox in the .eps says:

%%BoundingBox: -80 -37 400 1

This gives me the following information:
* the space *left* of the staff symbol is 80 units wide
  => This is the space where the instrument names, brackets or bar 
numbers protrude into
* then the line to the right of this is 400 units wide

If I want to align the staff symbol with the surrounding text I need 
that "80" to apply an offset when including the image.

> (The more I deal with it, the more I dislike PDF, but apparently I 
> *passionately* dislike EPS - there's even more intricacies in (E)PS, 
> and my PDF swiss army knives seems to be sharper than the EPS ones. 
> (Not talking about insane PDFs with Flash, forms and fireworks and 
> whatever.))
>
> Just compile your file in Lily and inspect the individual PDFs for the 
> systems. Barring unexpected (and anyway unhandled) stuff like marks 
> protuding over left and right margin, you get
>
> % gs -sDEVICE=bbox -q -dBATCH -dNOPAUSE test-?.pdf
> %%BoundingBox: 0 0 480 38
> %%HiResBoundingBox: 0.504000 0.522000 479.510774 37.025436
> %%BoundingBox: 28 0 480 40
> %%HiResBoundingBox: 28.709999 0.846000 479.510774 39.995999
> %%BoundingBox: 28 0 480 40
> %%HiResBoundingBox: 28.709999 0.018000 479.510774 39.005999
>
> (actual values differing slightly, probably due to font handling, Lily 
> version etc. on my system; but ballpark like yours).
>
> So, the corresponding line lengths are
>     (479.510774-0.504000) bp
>   = 479.006774 bp (TeX "big point" / PostScript point)
>   = 477.217209 pt (TeX's and Lily's point; 72.27 pt = 72 bp)
>   = 6.652872 in (1 in = 72 bp)
> for the first system, including instrumentName, and
>   (479.510774-28.709999) bp = 6.261122 in
> for the second and third, including shortInstrumentName.
>
> That should be enough to figure out the required line length / indent 
> settings.

As said I also need the reference to the start of the staff symbol. But 
now I know that I can access that by shifting by the (integer) info from 
the EPS bounding box. Of course it would be more convenient if the .eps 
would contain the HighResBoundingBox in the first place.

However, there's still one more information I don't seem to be able to 
obtain: the actual width of the staff symbol.
When the system is justified the staff symbol's width is exactly the 
line-width parameter (minus an indent).
The information I get from the bounding box, however, is the width until 
the right edge of the *image*, i.e. including any protruding elements. 
In a justified system I can get the width of the right protrusion by 
taking the X value of the upper left corner of the bounding box minus 
the given line-width of the score. But in a ragged system this isn't 
possible (at least to my knowledge) Unfortunately this leaves a small 
margin of error to my alignment and protrusion handling code. But I'll 
bother with this later in a separate thread.

> Once you compiled your final output, include the pdfs directly, and if 
> you want sub-bp accuracy for alignment (or are worried about margins 
> that are set too loose by Lily), use the crop/trim/bb/bb* options of 
> \includegraphics (via the graphicx package) rather than cropping the 
> PDF files separately, or rewriting the EPS. Note that I didn't test 
> the bounding box-options of graphicx yet, only trim; if they don't 
> work for PDF, you need to resort to trim.

No, I'm not worried ybout loose edges. My problem is that in a sequence 
of comparisons (do I have to modify the indent, do I have to modify the 
line width before recompiling) truncating to integers obviously 
introduces errors that don't lead to sloppy alignment but to completely 
wrong results (as seen in the attachments to my original post.

I'm not sure whether fixing the rounding issue will fix my bug, but at 
least now I know the route to go.

Urs


> HTH,
> Alex