Testing feature variations with DirectWrite
Simon Cozens
Posts: 732
I'm trying to find a variable font debugging tool for Windows that uses the DWrite shaper, because I want to answer a question about how it processes feature variations. Not finding one, I tried writing my own, first with DWriteShapePy and then with Harfbuzz. But neither of these seem to get DirectWrite to process feature variations at all.
For example, with Bahnscrift I would expect the dollar sign to be gid 696 for wght<=319 and gid 730 for wght >= 320. With the Harfbuzz OT shaper, that's what I see:
But with the DWrite shaper, the substitution is not made. (DWriteShapePy gives same result.)
So:
For example, with Bahnscrift I would expect the dollar sign to be gid 696 for wght<=319 and gid 730 for wght >= 320. With the Harfbuzz OT shaper, that's what I see:
simon@DESKTOP-1I8LMGB MINGW64 ~/DWriteShapePy (main) $ /c/bin/hb-shape.exe /c/Windows/Fonts/bahnschrift.ttf 'A$' --variations=wght=319 --shaper=ot [gid2=0+1246|gid696=1+1181] simon@DESKTOP-1I8LMGB MINGW64 ~/DWriteShapePy (main) $ /c/bin/hb-shape.exe /c/Windows/Fonts/bahnschrift.ttf 'A$' --variations=wght=320 --shaper=ot [gid2=0+1246|gid730=1+1181]
But with the DWrite shaper, the substitution is not made. (DWriteShapePy gives same result.)
simon@DESKTOP-1I8LMGB MINGW64 ~/DWriteShapePy (main) $ /c/bin/hb-shape.exe /c/Windows/Fonts/bahnschrift.ttf 'A$' --variations=wght=319 --shaper=directwrite [gid2=0+1246|gid730=1+1181] simon@DESKTOP-1I8LMGB MINGW64 ~/DWriteShapePy (main) $ /c/bin/hb-shape.exe /c/Windows/Fonts/bahnschrift.ttf 'A$' --variations=wght=320 --shaper=directwrite [gid2=0+1246|gid730=1+1181]
So:
- Is there a good tool for testing variable fonts on the DirectWrite shaper?
- Why are feature variations not being processed correctly in DirectWrite?
0
Comments
-
I'll inquire. Things work as expected in Notepad (hence GDI), but not in Word on-screen (hence DWrite) or in WordPad (RichEdit).1
-
It works in Word online (Web) in Safari, but not in Edge on the Mac—though I can't confirm that it's actually using Bahnschrift in that case (it doesn't look like Bahnschrift to me).0
-
Thanks. The real question I want to answer, which sparked my need for a testing tool is: do the (various, by the sound of things) Windows shapers process feature variations even if they are not in the rvrn feature?0
-
My understanding Direct Write should process feature variations applied to any feature, not only <rvrn>. It's possible however there are subtleties in how the client calls Direct Write where that behavior may not happen. That could be the reason why DWriteShapePy and the DWrite Shaper in Harfbuzz is not seeing the result. I'll look into that further.
Regarding Bahnschrift, the correct substitution for the $ is performed by DWrite. This can be verified as follows:
- Open the Settings app, and navigate to the Personalization / Fonts page.
- Select Bahnschrift.
- Scroll down to the Metadata and click the “Variable font properties” link.
- In the Variable font properties page, type $ under Preview text.
- Drag the Weight slider and the appearance of the $ changes between 319 and 320.
1 -
I looked into why DWriteShapePy was not showing expected behavior and found there was a bug when setting variations. HarfBuzz tags and DWrite tags are reversed. I had accounted for this in feature tags but not variation tags. I fixed it and posted update to PyPi.0
-
Simon Cozens said:Thanks. The real question I want to answer, which sparked my need for a testing tool is: do the (various, by the sound of things) Windows shapers process feature variations even if they are not in the rvrn feature?0
-
Peter Constable said:I'll inquire. Things work as expected in Notepad (hence GDI), but not in Word on-screen (hence DWrite) or in WordPad (RichEdit).0
-
Thanks, both, for your comments. Now I have to wonder why rvrn exists. It feels like a mistake. Doing a variation-based substitution so early on in the process means that all following rules now have multiple glyphs to track instead of just one...0
-
I believe the thinking of rvrn is similar to that of ccmp and locl, i.e. that there might be substitutions that set up subsequent inputs, based on, respectively, variation instance, cmap output, or language system. I always thought of rvrn as an option, as a feature that would be reliably processed at an early stage, to produce output specific to the variation instance—bearing in mind that selecting an instance in a VF design space is akin to selecting a font: rvrn produces the default forms for that font. I never expected that all GSUB feature variations would belong in rvrn, any more than all GSUB substitutions belong in ccmp: you put the lookups in the features that make most sense for the project.1
-
John Hudson said:bearing in mind that selecting an instance in a VF design space is akin to selecting a font: rvrn produces the default forms for that font.
That's a fair way to think of 'rvrn'.I never expected that all GSUB feature variations would belong in rvrn, any more than all GSUB substitutions belong in ccmp: you put the lookups in the features that make most sense for the project.
Certainly not. In particular, for instance, if you had a discretionary feature like 'swsh' and the substitutions needed to be different for certain portions of the design space, you'd simply use a feature variation for the 'swsh' feature table.0
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 609 Type Business
- 443 Type Design Critiques
- 536 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 494 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 161 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports