[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Maintaining font-size regardless of staff-size
From: |
David Kastrup |
Subject: |
Re: Maintaining font-size regardless of staff-size |
Date: |
Sat, 19 May 2018 22:20:02 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
Torsten Hämmerle <address@hidden> writes:
> dak wrote
>> David Kastrup <
>
>> dak@
>
>> > writes:
>>
>> I think it's more likely that LilyPond messes up when reusing fonts with
>> a particular size under different circumstances and your "correction"
>> just keeps it from reusing a font, instead calculating a fresh one.
>
> By Belenos, right you are!
>
> The exact value of the additional homoeopathic "correctional" term doesn't
> even matter.
> 0.001 is too small, but changing it to 0.002 will suddenly change the
> spacing from "catastrophic" to "correct".
> Making it too big, however, will result in a noticeable change in glyph size
> (and spacing).
>
> Be that as it may, obviously we need to re-trigger /something/...
I read in lily/modified-font-metric.cc the following:
Stencil
Modified_font_metric::text_stencil (Output_def *state,
const string &text,
bool feta,
const string &features_str) const
{
Box b;
if (Pango_font *pf = dynamic_cast<Pango_font *> (orig_))
{
Stencil stc = pf->text_stencil (state, text, feta, features_str);
Box b = stc.extent_box ();
b.scale (magnification_);
Stencil scaled (b, stc.expr ());
return scaled;
}
return Font_metric::text_stencil (state, text, feta, features_str);
}
This only adjusts stencil dimensions for magnification_ without
adjusting the stencil. For a Pango font, that is.
For a non-Pango font, it doesn't adjust anything.
I have really no clue about how font inclusion works but this appears
extraordinarily fishy.
--
David Kastrup
- Re: Maintaining font-size regardless of staff-size, (continued)
Re: Maintaining font-size regardless of staff-size, Thomas Morley, 2018/05/19