[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Understanding the eps bounding box (rounding)

From: Urs Liska
Subject: Understanding the eps bounding box (rounding)
Date: Thu, 1 Mar 2018 23:11:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Hi all,

can anyone tell me *exactly* how the bounding box values are generated and especially rounded in LilyPond? What are they exactly referring to, the content *with* or *without* a border (of the bounding box)?

I'm struggling with a peculiar and frustrating bug that I really would like to iron out.

As stated in earlier posts I'm working on code to include scores in LaTeX documents, and I'm using the bounding box information to calculate the alignment of the systems with the text. My problem is that the bounding box written to the .eps file only gives me plain integers while everything else is in floating point numbers. I was aware that this might blur my calculations and make the width and offset of the scores not 100% accurate, but now I've stumbled over an issue where the rounding errors seem to actually trigger really wrong results.

Let's say I have the following score

\version "2.19.80"

\include ""

\paper {
  line-width = 401\pt
  indent = 0\pt
  \set Staff.instrumentName = "Violin I. and II."
  \set Staff.shortInstrumentName = "Violin I/II"
  \repeat unfold 16 { c' d' e' d' }
The attached bbox.pdf shows the LilyPond output of this file.

The bounding box (as per line three of bbox-1.eps) is

%%BoundingBox: -80 -37 400 1

This means that the first system is a cutout with a lower left corner being at (-80/-37)pt and the upper right corner at (400/1)pt. -80pt refers to the amount of space used left of the staff symbol.
Apart from the fact that I don't really know the vertical reference points for this there must be some rounding applied, and I don't know which and in which direction(s).

What my code in the LaTeX package does is recompile the score with changed values for line-width and indent until it looks like I want. This is correctly done in three steps with this example
  • compile as-is, with indent = 0 and the original line width (taken from the text document)
  • determine how much the left protrusion exceeds the given limit (of e.g. 0.5cm)
    add an indent of that amount and recompile
  • determine that the protrusion *still* exceeds the given limit due to the shortInstrumentName:
    shorten the line width by that amount and subtract the same amount from the indent. Recompile

Now the result looks like the attached dynamic-indent-correct.pdf (which I really like).

The weird thing is that with a different \linewidth (actually, a DIV value of 11 or 13 for the package, all others work) I get a wrong result (dynamic-indent-wrong.pdf), and LilyPond has been invoked not three times but seven(!) times. I can only assume that it's the rounding issues that cause my code to be confused, trigger unnecessary recompilations, and eventually stop at the wrong point.

When I started looking at the code I realize that there are somwhat random decisions about when I round values, when I use different comparison operators etc.
But while I could start poking around now, changing details here and there until it *seems* to work correctly I realize that I'd be much better of if I knew exactly what the numbers in the bounding box represent.

Does the -80 mean:

  • any value between -79 and -80
  • any value between -79.5 and -80.4999999
  • or is it even an *outer* box? I mean, the "1" as the Y value of the upper right corner looks suspiciously likeĀ  "exclusive" value, doesn't it?

I'd be glad about any concrete information or other suggestions.


Attachment: bbox.pdf
Description: Adobe PDF document

Attachment: dynamic-indent-correct.pdf
Description: Adobe PDF document

Attachment: dynamic-indent-wrong.pdf
Description: Adobe PDF document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]