[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: \markup \sans ... does not always give sans-serif output in svgs in
Re: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36
Wed, 17 Feb 2016 10:48:22 -0500
> On Feb 17, 2016, at 6:26 AM, James Lowe <address@hidden> wrote:
> Without pretending to understand any of the past history of the reasons we
> changed the font defaults I think the problem was (and I am sure I will be
> corrected) that the results on all the different OSes - where Century
> Schoolbook may or may not be installed would result in unexpected results,
> along with some 'cyrillic' considerations, so I think it seemed to make it a
> better idea to define this via aliases.
Using the aliases is fine, but when creating svg files it is possible to
specify a generic font-family instead of a particular font (or in addition to
it, in case the particular font is not available). So when producing svg files
we could specify a generic font-family when the user asks for that (\markup
\sans …) even if the user has not specified a particular font.
> As to saying 'LilyPond Serif' vs just 'Serif', isn't that just semantics if
> it is all an 'alias' anyway?
“serif” “sans-serif” and “monospace” are officially defined as meaningful
values for the font-family property for svg files. They tell an svg renderer
(like a web browser) to “use a font of this type when displaying this svg
“LilyPond Serif” and friends mean nothing to an svg renderer because they are
neither fonts nor generic font families that they understand.
So my suggestion is that LilyPond should be smart enough to use “serif” in an
svg file rather than “LilyPond Serif” when no particular font has been set by
the user. (Same for “sans-serif” and “monospace” for “LilyPond Sans Serif” and
Hope that clarifies things.
 Links to svg specification / documentation:
The following generic families are defined: 'serif', 'sans-serif', 'cursive',
'fantasy', and 'monospace'. Please see the section on generic font families for
descriptions of these families. Generic font family names are keywords, and
therefore must not be quoted.
Authors are encouraged to offer a generic font family as a last alternative,
for improved robustness.
> Here are the core check-ins (in case we have already discussed what you are
> asking on dev or bug - if only at a programmatic level that I am not
> competent enough to understand).
Thanks. I took a look. My sense is that what I am talking about would need to
happen in the svg backend code, but I’m just making a more or less educated
> I did go round the houses with the devs on this when trying to help the patch
> submitted with the documentation. No one seemed to express concerns about the
> alias part - but of course that doesn't mean it cannot be an enhancement.
Ok, I'd still say it’s a regression since 2.18 produces svg files that better
reflect user input than 2.19, but I’ll take an enhancement. :-)