Re: \markup \sans ... does not always give sans-serif output in svgs in 2.19.36

[Paul Morris]

Hi James,

> 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 
image”.[1]  

“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 
“LilyPond Monospace”.)  

Hope that clarifies things.


[1] Links to svg specification / documentation:

http://www.w3.org/TR/SVG11/text.html#FontFamilyProperty
http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-specification
http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#generic-font-families

<generic-family>
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).
> 
> e.g
> 
> https://code.google.com/archive/p/lilypond/issues/4441
> https://codereview.appspot.com/241340043/

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


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

Thanks,
-Paul