Best Practice for removing components
Beau Williamson
Posts: 80
It is that time of the font design where I remove overlaps and components.
In the past, I always did the removal, then generated a font and carefully closed the .vlb without saving. Even though it is finished, I may want to come back at some point. Would it be possible to generate a font, then open the font to remove the overlaps etc. and then resave from Fontlab? Would this cause problems?
In the past, I always did the removal, then generated a font and carefully closed the .vlb without saving. Even though it is finished, I may want to come back at some point. Would it be possible to generate a font, then open the font to remove the overlaps etc. and then resave from Fontlab? Would this cause problems?
Tagged:
0
Comments
-
I usually use a simple script that takes care of these changes, generates the binary font, and then closes without saving the changed font. That way, I can be certain I haven't changed the original file. I've never had a problem with that approach.
The other option you propose wouldn't be a problem, but it's just more manual intervention. If that way works better for you, I'd just make a copy of the original and give it an obvious name (e.g., "...-ERASE_ME.vlb") and once you've done all the final production steps on that and generated the fonts, delete it. It's a lot of extra steps that I'd probably mess up on, but do what works for you!2 -
The file I generate the font from is a last-step derivative from the actual font master file.
1. delete all component-only glyphs (I mark them all with a specific colour, for safety)
2. select all glyphs
3. Merge contours
and you’re done.
4. Generate font
1 -
1. delete all component-only glyphs
You mean decompose, right? Not 'delete'.
2 -
I almost always generate my fonts with scripts, so I decompose and remove overlap before generating the font and usually not change the sources. Before that I used to remove overlaps right after I finish drawing the glyph, but I have long learnt how foolish was that.
1 -
Sorry, I actually meant:John Hudson said:
You mean decompose, right? Not 'delete'.
1. delete all component-only glyphs (this will delete only the component glyph itself, all incidents of the comp. will change to contour this way)
2. select all glyphs
3. Decompose
4. Merge contours.
This is the way I do it.
0 -
1. delete all component-only glyphs (this will delete only the component glyph itself, all incidents of the comp. will change to contour this way)
Ah. I didn't understand what you meant by 'component-only glyphs'. You mean glyphs that only exist in order to be used as components in composite glyphs. I call these ingredient glyphs, and usually prefix their names with 'xx' in order to make them easy to search for and filter.
0 -
Right. I usually mark these glyphs with a colour so I can spot and select them easily.John Hudson said:… You mean glyphs that only exist in order to be used as components in composite glyphs. …
0 -
Why would one manually decompose components before exporting fonts?0
-
Adrien Tétar said:Why would one manually decompose components before exporting fonts?
because you might need do remove overlaps. And for CFF it doesn’t make a difference. For TrueType it would be bad (to remove all).
2 -
Why would one manually decompose components before exporting fonts?180° rotated components such as () [] {} <> «» ‹› \/ EƎ eə !¡ ?¿
I use x-100,y-100 scale for these and decompose before final export.0 -
FontForge has a glyph flag “unlink and remove overlap before export” which I used to set for such glyphs, and I guess other editors have something similar so that one does not have to do it manually each time.
1 -
Well, that seems like something the toolchain could be doing.Georg Seifert said:because you might need do remove overlaps.1 -
I have also found that certain glyphs will glitch in use if I don't decompose. For instance, just the 'oacute' was showing up hollow in illustrator (as if finely outlined around whitespace). The other glyphs that used the same 'o' component were fine. I'm sure there was some good explanation, but as I import to CFF outlines, I find it safer to just decompose.0
-
...as if finely outlined around whitespace...
That can happen when you have two copies of a path overlaying each other.
1 -
Ah, I'll check that out in the unflattened file. (runs and checks)
Sure enough, that was it! Thanks.0 -
Of cause. But the toolchain we are speaking about here doesn't. It was one of the key things I implemented in Glyphs.app years ago: having one master file and automatically decompose and remove overlap when needed on export.Adrien Tétar said:
Well, that seems like something the toolchain could be doing.Georg Seifert said:because you might need do remove overlaps.3
Categories
- All Categories
- 46 Introductions
- 3.9K Typeface Design
- 486 Type Design Critiques
- 561 Type Design Software
- 1.1K Type Design Technique & Theory
- 654 Type Business
- 854 Font Technology
- 29 Punchcutting
- 519 Typography
- 119 Type Education
- 323 Type History
- 77 Type Resources
- 112 Lettering and Calligraphy
- 33 Lettering Critiques
- 79 Lettering Technique & Theory
- 550 Announcements
- 91 Events
- 114 Job Postings
- 170 Type Releases
- 174 Miscellaneous News
- 276 About TypeDrawers
- 54 TypeDrawers Announcements
- 120 Suggestions and Bug Reports






