Fontlab VI messing with my components when generating UFOs

Ramiro EspinozaRamiro Espinoza Posts: 839
edited July 2016 in Technique and Theory
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.

Comments

  • 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.
  • 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 LozosChris Lozos Posts: 1,458
    Alpha software, not ready for production work. They need your help more at this stage than this version can provide for your work.
  • Anyway the command line tool is not Alpha and is basically doing the same...
  • attarattar Posts: 209
    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 HudsonJohn Hudson Posts: 2,955
    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 LewKent Lew Posts: 905
    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 EspinozaRamiro Espinoza Posts: 839
    edited July 2016
    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 LewKent Lew Posts: 905
    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.
  • The user and all related content has been deleted.
  • John HudsonJohn Hudson Posts: 2,955
    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 HosnyKhaled Hosny Posts: 289
    I use nested components, transformed components and transformed nested components all the time. A great way of maintaining design consistency.
  • John HudsonJohn Hudson Posts: 2,955
    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 PuckettJames Puckett Posts: 1,969
    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.
  • 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. 

  • Thanks for this, we're looking into it. 
  • @Adam Twardoch I can send you my files, if you need them.
  • 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 LewKent Lew Posts: 905
    Glad you got it sorted. :-)
Sign In or Register to comment.