Fontlab VI messing with my components when generating UFOs

Ramiro Espinoza

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.

George Thomas

Since FLVI isn't even considered Beta yet this is something you should ask in the FLVI forum. They need to know about all these bugs so they can work on fixing them.

Ramiro Espinoza

Your are right, sorry. I will do so. I just had the feeling I've seen the same problem posted about their command line UFO tool, but I can't find it now.

Chris Lozos

Alpha software, not ready for production work. They need your help more at this stage than this version can provide for your work.

Ramiro Espinoza

Anyway the command line tool is not Alpha and is basically doing the same...

attar

Ramiro Espinoza said:

Anyway the command line tool is not Alpha and is basically doing the same...

Well I bet FLVI is calling into the command line tool anyway so.. yeah.

John Hudson

I've noticed that when I use Fontlab VI to generate UFO files many components are changed by other versions of the glyphs

I don't understand what you mean. Can you illustrate the problem?

Kent Lew

When a glyph is a component of a component, vfb2ufo tends to remap it to the original component when converting.

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.

Ramiro Espinoza

Correction after dinner: Fontlab is not correcting components of components in my files because I rarely make them. A typical situation is that it replaces all non spacing acute components (unicode: 0301) with the acute character (unicode: 00B4). And it does the same with all non spacing accents.

Kent Lew

Ramiro — Whoa, it should definitely not do that! Yeah, that’s bad. I don’t get that from vfb2ufo. I’m working with good ol’ fashioned FL 5.1.4 vfbs, not FL VI. I don’t know if that makes a difference.

I think you’re going to have to take this up directly with the FontLab folks.

[Deleted User]

The user and all related content has been deleted.

John Hudson

When a glyph is a component of a component...

If I were making a font tool, I wouldn't even allow that to be possible.

Khaled Hosny

I use nested components, transformed components and transformed nested components all the time. A great way of maintaining design consistency.

John Hudson

A typical situation is that it replaces all non spacing acute components (unicode: 0301) with the acute character (unicode: 00B4). And it does the same with all non spacing accents.

How have you made those combining and spacing accents? Is one a composite of the other? If so, then the same mechanism that Kent describes may be at work, i.e. that FontLab is — quite correctly in my view — falling back to the true component.

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.

James Puckett

John Hudson said:

When a glyph is a component of a component...

If I were making a font tool, I wouldn't even allow that to be possible.

It’s great for Kannda. The jhu in Padyakke is made of a components made of components made of components made of glyphs. I nearly ended up in the psych ward when Georg changed the way automatic alignment of components worked halfway through the 2.3 betas, but it’s still useful.

Ramiro Espinoza

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. 

Of course I followed this approach. I never use spacing accent to build accented glyphs. 

Adam Twardoch

Thanks for this, we're looking into it. 

Ramiro Espinoza

@Adam Twardoch I can send you my files, if you need them.

Ramiro Espinoza

Fresh news: I made some new tests and I could not reproduce the problem, which makes me think perhaps it was the previous FL VI build the one that had the flaw.
Sorry guys!

Kent Lew

Glad you got it sorted. :-)

John Hudson

It’s great for Kannda. The jhu in Padyakke is made of a components made of components made of components made of glyphs.

I think a critical distinction must be made between composites and modular shape sources. This is a point that Luc(as) de Groot and I made — strongly, I hope — during the FLVI workshop session at TYPO Labs in May. There is a tendency in font tools now to try to conflate these two things, and they're really not conflatable.

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.