[Top][All Lists]

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

Re: utf-8-string

From: Patrick McCarty
Subject: Re: utf-8-string
Date: Tue, 7 Feb 2012 19:19:10 -0800

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  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
>'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

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

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

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" }


reply via email to

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