Open litherum opened 5 years ago
@kojiishi @jfkthame
This was discussed at the most recent OpenType F2F, and there was interest in the font using two distinct low-level physical controls for vertical stretching and horizontal stretching, and the browser/app determining which of those types of stretching to use.
Important thing to remember is that value of font-stretch property affects font matching. Right now 'wdth' axis is used for this purpose. But if choice of axis will depend on orientation of particular character, then font matching can't be done before character orientation analysis is complete.
This was discussed at the most recent OpenType F2F, and there was interest in the font using two distinct low-level physical controls for vertical stretching and horizontal stretching, and the browser/app determining which of those types of stretching to use.
Important thing to remember is that value of font-stretch property affects font matching. Right now 'wdth' axis is used for this purpose. But if choice of axis will depend on orientation of particular character, then font matching can't be done before character orientation analysis is complete.
Note that for Roman fonts, using the 'wdth' axis all the time should be ok -- it is only when characters are upright that the 'vwid' axis would give a better result, when matching other squashed in that dimension, for example, fonts. I am of course speaking out of turn with little knowledge of CJK font matching using that axis...
Note that for Roman fonts, using the 'wdth' axis all the time should be ok
Not if text-orientation: upright
is used, I guess.
Thank you for raising this, @litherum. I feel great for our efforts to try to solve this problem, and I agree that we should solve both stretch and style.
Fonts using two distinct low-level physical controls look reasonable to me. Blink layout engine runs in logical, but converts all logical information to physical before calling the shaping engine, and convert the shaping results back to logical. Adding a few more conversions looks reasonable to me.
For the font matching, my preference is to keep it simple; i.e., match using horizontal control only. If vertical control is missing, we can fallback to synthesized result. If vertical is available but horizontal is missing, it's considered as missing for the font matching purpose.
Technically speaking, Blink can probably implement orientation-dependent matching if desired, because we compute glyph orientation before matching fonts. But I think the additional code has little-to-no benefits. Using horizontal control only for matching will give authors more predictable results.
Masataka Hattori (from Adobe) just gave a presentation at ATypI where he describes struggling with the problem described in this issue.
Here's a proposal: Make a layer of indirection between font facilities and CSS facilities.
As described above, the OpenType group feels that having two variation axes, one for width, and another for "vertical width", where the browser applies the relevant one, is a good fit. This has to work even for non-variable fonts, so fonts should probably be able to be annotated as "this font has a vertical width of 115%" in the same way a font can be annotated (today; this is existing behavior) as "this font has a horizontal width of 115%." I can work with OpenType to see if it's possible to provide these annotations for non-variable fonts.
The @font-face
descriptors for font-stretch
and font-style
can be extended to take vertical arguments. The new grammar for the font-stretch
descriptor would change from something like
font-stretch: 110% 120%
(for a variable font)
to
font-stretch: vertical 110% 120%
. Alternatively, a font that supports both horizontal stretching and vertical stretching could say font-stretch: 80% 90% vertical 110% 120%
.
The same approach would apply to font-style
, too.
This way, a font can declare that it is horizontally stretched or vertically stretched. It supports ranges for variable fonts, too.
Also, the font-style
and font-stretch
properties are not modified. The browser already performs a layout before it knows which fonts to download (for unicode-range
), so the browser can consider writing-mode
, text-combine
, etc. when determining which font to download. When content is written vertically, the browser will search for a font that has vertical width. When content is written horizontally, the browser will search for a font that has horizontal width. The same would happen for font-style
.
Also, all common browsers support font-style
synthesis. This would continue to work; we're allowed to synthesize horizontal oblique or vertical oblique, depending on use.
The CSS Working Group just discussed [css-fonts] Vertical text doesn't play nicely with font-style and font-stretch
, and agreed to the following:
RESOLVED: Adopt the proposal for font-stretch
So we have an (old) resolution to put the proposal into the spec. Are we waiting for a signal from OpenType to allow this to work, or can we just go ahead?
(Context - issue cleanup for an updated working draft)
I haven't seen any sign of a "vertical-width" axis in the OpenType spec, so this seems more aspirational than concretely implementable at this point. Maybe we should put it in a spec in the hope that OpenType will catch up? Or maybe that's premature and not really useful until the font support exists.
Vertical text will never play nice with font-style, because East Asian glyphs and Western glyphs have different axes of slant. If you look carefully, you’ll notice that typographically italic (by which I mean flowing styles that aren’t calligraphic – i.e. the Kai styles) East Asian glyphs slant upwards (anchored to the baseline on the left), while Western italic glyphs slant to the right. East Asian glyphs slant upwards because they were originally designed for vertical writing, but you’ll not likely find many Western fonts that will slant upwards when rotated 90° clockwise
@litherum are we still adding this proposal?
I think we should ask Nat McCully and Masataka Hattori if the problem is still worth solving. (My intuition is that it is.)
I think we should ask Nat McCully and Masataka Hattori if the problem is still worth solving. (My intuition is that it is.)
Yes, it definitely is worth solving so each app didn't have to do its own solution, perhaps also relying on certain fonts' implementations (or influencing them with a particular hack behavior).
I suspect something lacking in the font data, as well, unless we agree on a foolproof method of determining uprightness in vertical that is cheap, and then further agree on conventions for when things switch axes. My assumption is always that the lowest level expects Latin horizontal behaviors, and requires a no-op (i.e. no difference in code) when rendering Latin text in any direction. Thus all the special-casing happens with Japanese in vertical, with rotation upright and x- and y-axis-reversal, change of slant (see above -- actually the slant is not just a shear from the Roman baseline but rather a shear, scale, and rotate all about the glyph center), uneven scaling, other distortions, etc. All this could be codified in the font data better, and make other improvements for vertical text that acknowledge the mix of orientation when mixing scripts (even in the same font).
Consider a font that supports both Japanese and Latin, and wants to work well in both vertical writing mode and horizontal writing mode. It's totally reasonable for such a font to want to react to
font-style
andfont-stretch
.Naively, such a font would react to
font-stretch
by making all its characters horizontally wider, and would react tofont-style
by making the tops of the characters skew to the right.However, in vertical writing mode, this isn't right. In vertical writing mode, some characters are upright (i.e. Japanese characters) while some characters are rotated (i.e. Latin characters). Therefore, the naive solution would lead to bad behavior.
Here's a video of this bad behavior of
font-stretch
, courtesy of Nat McCully at Adobe: varfontbad.m4v.zipInstead, the desired result of
font-stretch
is where the upright characters grow vertically and the rotated characters grow horizontally (image also courtesy of Nat McCully at Adobe):It's unclear whether the font can do this automatically.
vert
feature might not be hooked up totext-orientation: mixed
andtext-orientation: upright
in every browservert
and variation axes is correct.This was discussed at the most recent OpenType F2F, and there was interest in the font using two distinct low-level physical controls for vertical stretching and horizontal stretching, and the browser/app determining which of those types of stretching to use. (Sort of like how browsers are supposed to apply the
vert
feature just for some of the characters in the vertical line.)Doing this at the CSS level is tricky because
font-stretch
andfont-style
are font selection properties. Changing their meaning causes side effects, like new different fonts get downloaded.This issue probably requires coordination between OpenType and CSS to come up with a story for how this is supposed to work and what font creators can do to make their font work properly.
This discussion should include both
font-stretch
andfont-style
. The solutions for these two properties may end up being different.This problem has existed since before variable fonts, but is particularly visible now as companies are more active in making CJK variable fonts that react to
wdth
andslnt
.