Best Practice for removing components

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?

Comments

  • AbrahamLee
    AbrahamLee Posts: 262
    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!
  • 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
  • John Hudson
    John Hudson Posts: 3,229
    1. delete all component-only glyphs

    You mean decompose, right? Not 'delete'.

  • 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.

  • You mean decompose, right? Not 'delete'.
    Sorry, I actually meant:
    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.


  • John Hudson
    John Hudson Posts: 3,229
    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.

  • You mean glyphs that only exist in order to be used as components in composite glyphs. …
    Right. I usually mark these glyphs with a colour so I can spot and select them easily.
  • attar
    attar Posts: 209
    Why would one manually decompose components before exporting fonts?
  • 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).
  • Ray Larabie
    Ray Larabie Posts: 1,436
    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.
  • 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.
  • attar
    attar Posts: 209
    because you might need do remove overlaps.
    Well, that seems like something the toolchain could be doing.
  • 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.
  • ...as if finely outlined around whitespace...

    That can happen when you have two copies of a path overlaying each other.


  • Ah, I'll check that out in the unflattened file. (runs and checks)
    Sure enough, that was it! Thanks.
  • because you might need do remove overlaps.
    Well, that seems like something the toolchain could be doing.
    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.