Re: [PATCH] option to prevent EPS backend from creating .tex/.texi/.count files

[Werner LEMBERG]

>> While you are at it, please investigate why there are still
>> clipping problems during the EPS->PNG conversion.  For an example,
>> look at the snappizzicato example image in the notation reference.
> 
> The bounding box of the generated eps files is simply obtained from
> the scencil extents plus the value of the 'eps-box-padding option on
> each side.

I know that.

> Unfortunately, the skyline for the snappizzicato is wrong as a run of 
>     lilypond -ddebug-skylines articulation-snappizzicato.ly
> clearly shows.  The vertical stroke is not counted towards the
> skyline!

Yes.  You are probably misunderstanding me: There are *a lot * of
glyphs where the skyline is incorrect -- for some, it's just the
overshoot which isn't taken into account, for others it's more.  In
other words, the bbox as computed by lilypond currently is not
suitable for clipping at all.

Some time ago we have discussed this here on the list; a kind of
concensus was to use FontForge for automatical computing of bbox
values, adding them as additional metrics information.

What I suggest is to let GhostScript completely unfold the font paths
with eps2eps or something similar so that lilypond's bbox inaccuracy
can be circumvented.


    Werner