Re: utf-8-string

[Patrick McCarty]

Hi Mike,

On Mon, Feb 6, 2012 at 4:55 AM, address@hidden
<address@hidden> wrote:
> Hey all,
>
> I see a shortcut for utf-8-strings in pango-font.cc.  This is
> all well and good except that it is hard to do box
> approximations on these guys (it'd require adding lots of code).
> How mad would LilyPond be if I just deleted all of the
> utf-8-string business?  I don't think it'd change the visual
> output...it'd just get rid of a shortcut.  Does anyone have any
> justification for keeping this shortcut?

Yes :)  It's not actually a shortcut, despite the code comment.
Every backend is a Pango-based backend if it uses a text
stencil.

utf-8-string is absolutely critical for the SVG backend (not sure
about the socket backend)...

In the code, description_string() (see lily/pango-font.cc:378)
returns a string in the PangoFontDescription format.  This format
is best described in the pygtk docs:

  http://www.pygtk.org/docs/pygtk/class-pangofontdescription.html

The SVG backend uses this information (font style, weight, etc.)
to assign accurate attribute values.  Then they are output as SVG
text elements with the appropriate font-weight, style, etc.  If
this information did not exist, any string in the SVG output not
using a LilyPond font would likely display incorrectly.

utf-8-string is not used in the PS backend because Pango takes
care of the processing internally, calculating kerning, font
weight, and other attributes before the stencil expression is
evaluated in the backend.  IIRC, every string of text using a
non-LilyPond font is a "glyph-string" in the PS backend.


That said, what issues are you seeing with the box approximations
for utf-8-string?  I'm seeing tight fits when running `lilypond
-dbackend=svg -dpreview', for example with

  \version "2.15.28"
  \markup { "Lily" }


Regards,
Patrick