search

silnrsi / font-shimenkan

Fonts for the Miao script
Other
3 stars 1 forks source link

Please do not use Book as a non-normal #85

Open nim-nim opened 4 years ago

nim-nim commented 4 years ago

Book is defined in https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/02/24/90/36/WPF%20Font%20Selection%20Model.pdf

as a synonym for Regular

Please use standard weight qualifiers (you have a good palette in the Microsoft Whitepaper)

nim-nim commented 4 years ago

Also, fontconfig tells me weight is not set in the font files to sensible values :(

jvgaultney commented 4 years ago

'Book' is not a synonym for Regular, despite what that old paper claims. Its use is not consistent. Some designers (including us) use it for a weight slightly heavier than Regular (which some call Medium). Some use it for a lighter weight. It's just a name and does not signify a standard weight value.

Because of the very inconsistent way that Windows, in particular, uses weight names and values, we have chosen to separate the weights of Shimenkan into four 'families'. These would appear as separate font families in font menus and would not, for example, be joined into a single Shimenkan family with 8 weights.

These four families are, in increasing weight order:

Each of these families has two weights: Regular and Bold. Don't think of "Extra Light' and 'Book' as variants of regular - they are separate font families. We could have just as easily called them 'XL' and 'BK'. This is the only way to have the weights behave reasonably consistently in a variety of Windows apps and OS versions, and also maintain a basic level of cross-platform compatibility.

There is a further benefit. If you have text in Shimenkan, with mixed Regular and Bold, then decide you want a slightly heavier weight you select the text and change it to Shimenkan Book. Both the Regular and Bold text will increase in weight appropriately. If you want a lighter text you switch to Shimenkan Light and everything becomes lighter.

If you are packaging these they should be in four separate font families.

nim-nim commented 4 years ago

Sadly, doing things this way is very broken and does not work well in text stacks that perform large scale font substitutions (like fontconfig or WPF).

For substitution to work reliably the naming must be very regular over all fonts families. I’m pretty sure the only reason Microsoft bothered with WWS rules in the OpenType spec is to get reliable font substitution in its new-generation apps.

Also, variable fonts are starting to become more common, thus supporting i18n run of texts for minority locales, inserted within some other corpus written in a modern latin variable fonts, requires some mapping between the axis uses by the variable part and the styles used by the i18n non-variable fonts.

And that, again, requires strict naming normalization

fontconfig font substitution is intended to help users of those minority locales, a font intended for those locales, that fights the substitution engine, is very counter-productive.

Not coincidently at all the default axis in variable fonts are more or less the width weight slant of WWS naming (+ optical size). There is a clear continuity between the WWS paper, the naming changes added after this paper to the OpenType naming table, and the choices made yet later for variable fonts.

The non-standard naming used by Shimenkan is especially hard to map, because it results in double weight attributes in some names.

Please keep the split in four variants at the Name ID 1 + Name ID 2 level, and use a continuous WWS scale at the Name ID 16 + 17 level, as recommended by the OpenType spec.

https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp

That's the only thing that will be upwards compatible to variable fonts.

https://docs.microsoft.com/en-us/typography/opentype/spec/name states

Note, in particular, that variable fonts can include a large number of named instances, each of which will use a shared typographic family name (name ID 16) and will have a typographic subfamily name (equivalent to name ID 17).

nim-nim commented 4 years ago

And I guess the correct weight mapping is Book or Light Bold → Medium Book Bold → Black Regular or Extra Light Bold → Regular

weight: {ExtraLight: 40, Light: 50, Regular: 80, Medium: 100, Bold: 200, Black: 210 }

And now we see that two visually identical weights are both provided by two fonts. And those fonts are almost, but not 100% identical (just different enough to cause problems when substituting by weight).

Could you at least make sure those have identical font data, and differ only in naming metadata? That would limit user and interop problems for software without the legacy 4-style Name ID 2 limitation.

I suppose I will reuse the mapping for other SIL fonts that use double weight qualifiers in their namings (for example, Dai Banna). Assuming the naming conventions are shared by all SIL font projects?

jvgaultney commented 4 years ago

Actually there are no duplicate weights. Details of the exact weight values are defined in the Designspace file.

As I have said before, please treat the four weight-related families of Shimenkan as different families altogether. I know that results in some odd naming (Shimenkan Extra Light Bold), however in the current project this family construction is set and won't be changing. I know that this causes problems when trying to harmonize the weights into a superfamily, so I suggest you don't try.

We have designed the project carefully so that at any time we can make the leap to a variable font with minimal changes. When we do that we will likely take the regular weight Shimenkan family and add proper weight identifiers to that, and use mapping to connect them with standard CSS values. However that may not happen for a while, and would likely never fully replace the Extra Light, Light, and Book families.

It would be a bad idea to assume that Dai Banna's (or any other SIL font's) weights, family construction, and naming work the same way as Shimenkan. Each script has unique requirements, and there is absolutely no intention to have all of SIL's fonts match each other in size and/or weight.

nim-nim commented 4 years ago

Actually there are no duplicate weights. Details of the exact weight values are defined in the Designspace file.

Practically, they are duplicated weights. You can overlay one with the other, and they will match almost perfectly (almost because they are generated in a different way, so you get slight fringing).

I understand this is not by design, but that’s the practical end result of using a dual-weight scale, instead of following the CSS and OpenType weight model. You end up with collisions you did not plan for.

Just make those weights match perfectly (not almost), that will remove weird bugs when used in software that cares about weight. The human end result is the same, but you avoid the problems that will be triggered by the slight differences.

As I have said before, please treat the four weight-related families of Shimenkan as different families altogether. I know that results in some odd naming (Shimenkan Extra Light Bold), however in the current project this family construction is set and won't be changing. I know that this causes problems when trying to harmonize the weights into a superfamily, so I suggest you don't try.

I've spend years now devoting some of my free time distributing SIL fonts. I grew up in a family that used a non-latin script. I know how wonderful it is when your script get finally supported in computer systems enabling you to participate in modern life using your own script and language. I was (still am) grateful for the foundries that made it possible for me then. I expect the people I distribute SIL fonts to feel the same.

However, because I did live this situation from the user side, I also understand what the compromises are when designing such fonts. I do not share the common language expert or font designer opinion, that as long as the new font works for a script in a limited context (with a limited subset of faces, with limited mixing with other scripts), all is fine.

I want to enable my users to be full citizens of the world, being able to use their script in all apps as Latin users use theirs, being able to mix it with any other script they may care about:

I know those are strong worlds but this is the level of betrayal a user feels when he realizes the nice font he had been relying on assumed he would never need to use his script except in a limited context.

So, because apps that care about weight exists (for example Inkscape, because SVG follows the CSS weight model), I will assign weights to SIL fonts that do not follow this model. Of course I’d rather it wasn’t necessary, and the font files were designed from the start up to also work in such apps. But, since they aren’t, I’d rather stray from SIL’s choices, than lock my users in legacy Name ID 1/2 land.

It would be a bad idea to assume that Dai Banna's (or any other SIL font's) weights, family construction, and naming work the same way as Shimenkan. Each script has unique requirements, and there is absolutely no intention to have all of SIL's fonts match each other in size and/or weight.

That is quite unfortunate, but practically speaking, users expect the same weight keyword to mean the same thing in font lists, at least for fonts produced by the same foundry. Convention differences only work when you expect to lock users in a specific font. As I wrote before, I deeply resent such lock-in assumptions.

jvgaultney commented 4 years ago

Thank you for your good and generous work to help so many people. I'm sorry that we disagree about how to best serve users. Your priority seems to be enabling a rich range of weights in apps that support it. I'd agree that that's the best in the longer-term, and we will eventually move to that model. However to do that now would mean that the additional weights are broken or difficult to use in older apps and OSes.

For example, some users of Shimenkan strongly prefer the Book weight family and want the heavier Book Bold when they press the 'B' button in their preferred (old) word processor. If we put all the weights in one family, it would mean that in their main apps they could not get the Book weight simply by choosing "Shimenkan". They would need to choose the font, then the Book weight, and the "B" button would not give them the correct Book Bold.

I want to enable my users to be full citizens of the world, being able to use their script in all apps as Latin users use theirs, being able to mix it with any other script they may care about:

We certainly share this goal.

without degradation as soon as they stray from a Bantoustan of “safe” Latin glyphs copied into the font (and then modified, breaking interop with other fonts).

As I've said in a different thread in a different project, sizing is a difficult issue. It is not possible to make 20+ fonts for different scripts and include the same sized Latin glyphs in all of them without making the Latin wrongly sized in many of them. The only reasons that the Noto Sans project can do this is that they are all sans serifs in a similar style and they have chosen to have poor sizing relationships in some cases.

I think you'll find that we support more Latin characters in our non-Latin fonts than most foundries do. We also work with language communities to provide their preferred style of Latin glyphs. We don't always use one source (sometimes Charis, sometimes Andika, and in this case Source Sans Pro).

If you find that a particular language community needs a more extensive Latin set - and needs that set to be part of the main font - please let us know.

I will assign weights to SIL fonts that do not follow this model

I know you feel strongly that we're doing the wrong thing. You would be most welcome to make your own version of Shimenkan (with a different name) with weights exactly as you want them. The project is free and open (OFL license) as is the complete toolchain used to build them.

users expect the same weight keyword to mean the same thing in font lists, at least for fonts produced by the same foundry

I think that's reasonable within a foundry, and you'll find that 'Book' always is slightly heavier than 'Regular' in SIL fonts. How much heavier differs between projects.

nim-nim commented 4 years ago

Thanks a lot for taking the time to answer even if we disagree on some things. Even if my target platform has its share of legacy apps, the situation is not so dire as in others, so we mostly try to enable new font handling features for everyone.

I realize that sizing is a difficult issue and there will be drawbacks no matter what compromise is chosen. I will lean heavily towards global and long term benefits due to the target population I serve. A project that focuses on short-term local benefits on another platform will choose differently.

We may end up, blacklisting the the Latin core in SIL non-latin fonts to force the use of the original Latin font for Latin and avoid Latin sizing clashes (that’s how it was done historically for many large-coverage font projects, where encoding overlaps resulted in app problems and poor user experience; it’s a routine fixup for many CJK font files). It's just one more fixup to maintain, I'm not overly fond of them, that requires maintaining blacklist lang tables, which are another source of errors. I prefer font files that do not need any downstream fixing.

We don't always use one source (sometimes Charis, sometimes Andika, and in this case Source Sans Pro).

Is the latin core of SIL fonts always Charis, when not specified otherwise? It's not always documented. I'd very much like avoiding matching a non-latin font with the incorrect fuller-featured latin original.

Sometimes SIL choices for Latin are very strange (ie Tagmukay is clearly monolinear-ish, but the latin part uses serif glyphs). As long as those choices do not cause user problems, I leave them as is.

I know you feel strongly that we're doing the wrong thing. You would be most welcome to make your own version of Shimenkan (with a different name) with weights exactly as you want them.

Right now it is all done via fontconfig rules (prepending a synthetic naming/weighting layer over the original one).

If you wish, this layer can include a font family rename. That’s not terribly user friendly and my experience is that entities that ask those renamings downstream come to regret it, but sure, it is perfectly doable if you insist (even if the font files themselves are 100% identical to SIL’s).

Also no matter what renamings we do at the fontconfig layer, some apps like inkscape will perform another style naming normalization pass application side before constructing font lists, and they will definitely not change the font name. So no matter what I do, the only way to keep your style naming intact up to the app layer, is to follow strictly Opentype naming specs.

I think that's reasonable within a foundry, and you'll find that 'Book' always is slightly heavier than 'Regular' in SIL fonts. How much heavier differs between projects.

Yes that was more or less my question. I do not care if the various SIL fonts are perfectly synchronized sizing-wise (that would be nice, but as you wrote, that is a gigantic task). I just want the style naming to mean the same thing so I can use a consistent normalization table, whenever the original SIL style naming conflicts with the expectations of our apps.

Or, as the OpenType spec puts it:

Note that interoperability is assumed to be attained in varying degrees, depending on the nature of an axis and the scale that it uses. For example, the scale for the Weight axis provides a limited degree of interoperability. Two different fonts with a Weight axis value of 700 (or “Bold”) may not result in the same amount of darkness or “color” when applied to the same text; but in both cases, a user can expect these to be darker than the “Regular” or “Semibold” fonts from each respective font family, and application developers can produce results that will be predictable for users if they associate that axis value with a particular state of a user-interface control or with a strong markup tag.

jvgaultney commented 4 years ago

Is the latin core of SIL fonts always Charis, when not specified otherwise? It's not always documented. I'd very much like avoiding matching a non-latin font with the incorrect fuller-featured latin original.

No it's not always Charis. It may be Doulos, Andika, Gentium, Charis, or some variant of them. It may also be a non-SIL OFL font (Source Sans Pro, Crimson, others). It may also be a completely original Latin unavailable outside that project. The Latin glyphs may also be adjusted in some way from the original source - to make them a little heavier, or wider, in addition to resizing. The project may also have interpolated weights that do not exist in the Latin project.

The Latin glyphs in our non-Latin fonts are usually based on other fonts, but are often changed in some way. When the font is a non-SIL font we do document and credit that source. However when it's our own font, and especially if we've modified it in some way, we don't usually document that as that might make people assume that the font is brought in unchanged.

IOW you can't just make a table that says: for SIL non-Latin font X use Latin font Y. The Latin glyphs in our non-Latin fonts are just for those fonts only and are carefully matched.

The way users handle this is that in cases where they need occasional words in Latin script the internal Latin almost always works just fine. That's because we include, at a minimum, all the characters recommended in this ScriptSource document. If they find they need it for longer passages, or for characters not supported, they use some other Latin font of their choice. They usually find out about missing chars easily because the fallback fonts kick in and look terrible!

Sometimes SIL choices for Latin are very strange (ie Tagmukay is clearly monolinear-ish, but the latin part uses serif glyphs). As long as those choices do not cause user problems, I leave them as is.

The preferred style for secondary Latin glyphs does not always seem to match the style (in European thinking). It is always deliberate, but we try to match them reasonably (given practical and licensing limitations). However, when the style seems oddly different it's because the language community has asked for a particular style. For example I'm working at the moment on a two very clearly monoline sans serif fonts for two different scripts. In both cases they want a serif Latin font because that provides extra contrast between the primary script and secondary Latin.