[Top][All Lists]

[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

From: James Lowe
Subject: Re: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36
Date: Wed, 17 Feb 2016 11:26:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 17/02/16 04:04, Paul Morris wrote:
On Feb 16, 2016, at 4:17 PM, James Lowe <address@hidden <mailto:address@hidden>> wrote:

From usage:


*Note for backend svg output:*LilyPond’s default fonts (|LilyPond Serif|,|LilyPond Sans Serif|and|LilyPond Monospace|) are just/local/font aliases. Therefore, when using the backend|svg|command you must explicitly define the default fonts in your source file;

Thanks James, I hadn’t seen that explanation and workaround.

I have created


in at attempt to try to make sure others do not miss this either.

It still seems like it would be better if these local aliases didn’t make it into the svg files by default (when fonts are not user specified). Seems like LilyPond's svg backend code could simply substitute:

“serif” for “LilyPond Serif”
“sans-serif” for “LilyPond Sans Serif”
“monospace” for “LilyPond Monospace”

That would produce svgs that had valid defaults and met expectations, svgs like those produced by 2.18.

(Well, instead of “serif” in 2.18 you would get "Century Schoolbook L” but I think “serif” is the better default. Or we could specify both a specific font and a generic fallback like "TeX Gyre Schola, serif”. That’s an option with the svg font-family property.)

So this seems like a regression to me, or at least a good feature request.

I don't think this is a regression.

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.

As to saying 'LilyPond Serif' vs just 'Serif', isn't that just semantics if it is all an 'alias' anyway?

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).



Maybe embedding (or whatever it is you need for SVG particularly) was more complex or 'impossible' when using this alias method - hence the extra note in Documentation.

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.



B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE

reply via email to

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