music-encoding
music-encoding copied to clipboard
music-encoding
deprecate fontname
As @th-we pointed out in https://github.com/music-encoding/music-encoding/pull/704#issue-469038961, we still do have both @fontfam and @fontname. The latter is a very old artifact, and there is no corresponding attribute / value in TEI or CSS. Both are defined in the same attribute class att.typography, which means they are always available in the same spaces. There seems absolutely no reason to preserve both, and I recommend to go with @fontfam, and drop @fontname. Taking this out will change "forward compatibility", but an automatic conversion seems easy, so that shouldn't be an issue.
@kepper Shouldn't we remove @fontname and data.FONTNAME entirely? They are not only used by att.typography (which your commit handles), but also by att.lyricStyle and att.textStyle.
yes, we should. However, I just noticed that some examples use @fontname, namely tempo-01.mei (and there might be others…).
However, I just noticed that some examples use
@fontname, namely tempo-01.mei (and there might be others…).
@fontname has been used because, as far as I know, there is no way to indicate that a SMuFL compliant font should be used. I don't think that fontfam="smufl" would be correct.
@lpugin and I discussed this earlier; would it be feasible to provide CSS-like fallbacks, e.g., fontfam="Leipzig,Bravura,smufl" -- this would choose the first available named font, and if neither were available would choose an available smufl font. (There would be an additional issue of having renderers know all possible 'smufl' fonts installed on a system for this to work automatically, though).
during 2022 dev meeting in Berlin, @fujinaga, @lpugin, @pe-ro, @musicEnfanthen and @kepper came to the conclusion that we keep it as it is, to allow fallbacks and some such. Closing as wontfix…