Howdy, Stranger!
Categories
- All Categories
- 39 Introductions
- 3.6K Typeface Design
- 764 Font Technology
- 1K Technique and Theory
- 587 Type Business
- 435 Type Design Critiques
- 526 Type Design Software
- 30 Punchcutting
- 132 Lettering and Calligraphy
- 79 Technique and Theory
- 53 Lettering Critiques
- 461 Typography
- 289 History of Typography
- 111 Education
- 61 Resources
- 479 Announcements
- 74 Events
- 104 Job Postings
- 147 Type Releases
- 153 Miscellaneous News
- 259 About TypeDrawers
- 52 TypeDrawers Announcements
- 109 Suggestions and Bug Reports
Options
Fontlab VI messing with my components when generating UFOs
Ramiro Espinoza
Posts: 839
Hi there,
I've noticed that when I use Fontlab VI to generate UFO files many components are changed by other versions of the glyphs, making the files incompatible with UFOs generated with Robofab.
Why is that this happening? I need UFOs that keep the same structure than the original FL file.
Any idea on how to avoid it? I like FL VI speed for dealing with UFOs but this issue is a pain.
I've noticed that when I use Fontlab VI to generate UFO files many components are changed by other versions of the glyphs, making the files incompatible with UFOs generated with Robofab.
Why is that this happening? I need UFOs that keep the same structure than the original FL file.
Any idea on how to avoid it? I like FL VI speed for dealing with UFOs but this issue is a pain.
Tagged:
0
Comments
For example, if you have a periodcentered.uc which is a shifted component of periodcentered, and periodcentered is itself a shifted component of period, then upon conversion, the periodcentered.uc will become a component of period (with the coordinates correspondingly recalculated).
I don’t know why it does this. It isn’t the end of the world, and functionally it is the same (and it’s possible that when it comes time for compilation this same remapping needs to happen anyway; I haven’t investigated). But it can be a nuisance, especially if you aren’t aware of the idiosyncrasy.
I think you’re going to have to take this up directly with the FontLab folks.
If I were making a font tool, I wouldn't even allow that to be possible.
I always recommend that the combining mark glyphs be the outlines, and the spacing accents — which are, after all, mostly legacy characters with little practical use — should be composites. And the combining marks should be used in diacritic composites, never the spacing accents.
Of course I followed this approach. I never use spacing accent to build accented glyphs.
Sorry guys!
Having reusable shapes within a font tool, and being able to nest them as James describes, is clearly useful in design sources. But a composite is a specific kind of entity within a TrueType glyf table. And I take the view that composites should be managed in sources in accordance with how they are handled in glyf tables, as a manufacturing process not as a design process.
This is something that FontLab — at least up to FLS5 — understood and handled sensibly. If you created a glyph and made a composite based on an existing composite, e.g. by identifying /Adieresis/ as the component, what you actually got was the composite of /A/ and /dieresiscomb/ that made up the /Adieresis/ composite, not a new component made up of components.
FLVI and other recent tools, as I say, have tried to conflate composites with more flexible mechanisms for reusable shapes in design soruces. In some cases, this is done quite cleverly, so that management of actual composites is handled by the font tool during font generation. The idea here is that the designer never needs to think about this, and can just rely on the tool to identify which instance of reusable shapes in the source can be written to a glyf table as composites and which should be decomposed and outlines merged. But if one is actively manufacturing TrueType fonts, one really wants control over composites as composites, not least because their positions are hintable.