Testing Variable Font
Igor Petrovic
Posts: 297
1. Is it usual that InDesign and Photoshop can't load and use a variable font if the static instances of the same typeface (same naming) are also installed?
Illustrator loads and operates both in parallel without problems.
2. I have noticed that my variable font (let's say at semi-bold 600 point on the axis) makes a somewhat shorter text line than Semi Bold static instance. The difference is relatively subtle in normal text, most obvious using repetitive OOO...I thought it might be due to the fact that instances have hints while variable does not, but it's the same with unhinted instances as well. Here is how the end of the line looks. Is this a problem?
Illustrator loads and operates both in parallel without problems.
2. I have noticed that my variable font (let's say at semi-bold 600 point on the axis) makes a somewhat shorter text line than Semi Bold static instance. The difference is relatively subtle in normal text, most obvious using repetitive OOO...I thought it might be due to the fact that instances have hints while variable does not, but it's the same with unhinted instances as well. Here is how the end of the line looks. Is this a problem?
Tagged:
0
Comments
-
Does the first /O overlaid in the line look like those? If so, they are just offset, not shorter. I don't know why though so would try to find out why and fix it if possible.
0 -
I suggest testing in Fontgoggles — you can have the static file and the variable file at that same instance next to each other (above and below, rather).
1 -
I'd second testing in FontGoggles. Some questions: How are you exporting/generating your font? Do you have an axis map (i.e. avar table)? Instances and variable fonts at the same coordinates should be the same.0
-
Thanks for the replies.
They are well aligned at the beginning of the line, but the difference increases cumulatively going from left to right.
Also, masters (Thin & Bold) have no problem (interpolation-related problem?).
I tried the different tests, all without success:
Given the size of the difference, I thought that rounding might make a difference, especially for spacing or kerning (because I have integer nodes and handles, and checked rounding in both export profiles). I turned off rounding in both export profiles.
My font has PS outlines, and static instances are exported as PS OTF, while Variable is exported as TTF. So for exporting variable, I tried different curve conversion options ("Keep existing curve type" vs "All curves to TrueType", and conversion tolerance from "Current" to "Precise").
Then tried exporting static instances as TTF. Also tried exporting Variable PS (beta) in FontLab, but I got an output problem with a lot of those red warnings.
Then I tried to flat kerning, and removed all kerning classes in both masters.
I defined instances in FL7 font info, with all classic values Thin (100)-to-Black (900). One axis-weight (2 masters at extremes+7 instances in between. Some glyphs have the "intermediate glyph master" at Semi-Bold (600). I wasn't sure if this was a bug, so to post it on FL forum, or is a general case.
Thanks for the tip about Fontgoggles, looks pretty neat and useful, but I work on Windows
0 -
Igor Petrovic said:
2. I have noticed that my variable font (let's say at semi-bold 600 point on the axis) makes a somewhat shorter text line than Semi Bold static instance.If your variable font has no master at that location, then it is likely a rounding issue.1 -
@Erwin Denissen Thanks, that was a good track!
I realized that every second instance has a problem:
Thin - ok
Extra Light - problem
Light - ok
Regular - problem
Medium - ok
Semi Bold - problem
Bold - ok
Extra Bold - problem
Black - ok
And then I took one which has a problem (Regular) and added font master to it, and that fixed it. So yes, most likely a rounding problem.
And then I remember that while checking the vertical metrics of exported instances, I noticed that every second instance (the same problematic ones) has a rounding error for x-height (Font Info > Font dimension > x-height), because its value is interpolated between masters. So for them, the actual zone is one pixel higher than the defined x-height, and all nodes, hints, etc are attached to the zone, not to the x-height line.
Thanks for the MainType heads-up, I'll check it!0 -
I would suggest to post this (or link to this) on the FontLab forum anyway.
1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports