[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 11:26:32 +0000
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
*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
“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