Right, this highlights that there is a round-off problem involved
as well, which further illustrates that the current solution isn't
really stable. The problem is that LaTeX points "pt" don't exactly
correspond to PostScript points "bp". In fact 72.27pt = 72bp =1 inch.
The default text width in a LaTeX document is 345pt which corresponds
to 343.7111bp (Postscript points). Since the bounding box of an EPS
file is specified in integer number of points, the bounding box of
the .eps file will be 344pb wide. This corresponds to 345.29pt and if
you watch the printouts from LaTeX, it will report that each line
is 0.29pt too wide.
The default text width if you use the geometry package is 430pt
(=428.3935bp). Then, the .eps will be 428bp wide (=429.6050pt).
Since the first .eps file is shorter than the line width, LaTeX
prints also the second .eps file (i.e. the second score line) on
the same line.
Note that the same problem would have appeared even if LaTeX and
PostScript had used the same definition of point, since the text
width of a LaTeX document does not have to be an integer number
of points, whereas the width of an eps file is rounded to the
closest integer number of points.
Consequence: We should always have a \linebreak between the
consequent .eps files to ensure that they appear on a new line.
This can be obtained using the workaround
\newcommand{\betweenLilyPondSystem}[1]{\linebreak}
but should be done already in lilypond-book.
However, this doesn't solve all the problems. For example, the
bounding box of the different .eps files may still differ from
score line to score line, for example due to bar numbers sticking
out to the left or added instrument names.
For example, if I add back the bar number engraver to Nicholas
example and use the default LaTeX layout, the bounding boxes of
the score lines will be
> grep BoundingBox lily-484087831-*.eps
lily-484087831-1.eps:%%BoundingBox: 0 -40 344 0
lily-484087831-2.eps:%%BoundingBox: -4 -40 344 2
lily-484087831-3.eps:%%BoundingBox: -8 -40 344 2
lily-484087831-4.eps:%%BoundingBox: -8 -40 344 2
Manually changing the -4 and -8 to 0 will give the correct alignment
even though the .eps figures might extend a bit into the left margin.
I'm not sure that it's a good solution to modify the output routine
for .eps files in LilyPond to always fake the bounding box this way,
though.
/Mats
Graham Percival wrote:
On 1-Aug-05, at 11:59 PM, Mats Bengtsson wrote:
Please search the mailing list archives for discussions on
this topic.
I think that this is new information, though -- at least, I've been
following
this with some interest, and I didn't know that this bug was triggered
by including
\usepackage{geometry}
- Graham
--
=============================================
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=============================================
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond