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