Inheritance - when Agrave is typed, use the glyph for A etc

is this possible by code, or do i have to copypaste everything as components?
for example if i have glyphs drawn for a.isol a.init a.medi a.fina, and i want to use the same for Agrave Aacute (not drawn) etc.



  • Options
    I read it now three times in a row, and I didn’t understand it. Glyphs and FontLab should use the base components automatically.
  • Options
    You might mean that hi didn't like to add all the precomposed accented glyphs for all glyphs with a suffix?

    If that is the case, add a ccmp feature that looks like this:

    sub aacute by a acutecomb;
    sub agrave by a gravecomb;

    And add a mark feature that positions the accents over the alternate glyphs.
  • Options
    yes georg, i meant that, thanks!
  • Options
    The solution proposed by Georg is the conceptually correct one, and should in theory also be used for things like small caps: instead of building glyphs such as "aacute.sc", it should be sufficient to use the ccmp -> smcp -> mark route, where smcp deals only with the basic alphabetical glyphs. Unfortunately, when I tested this approach a few weeks ago, it turned out that many apps (including some browsers) don't process "ccmp".

    A workaroud solution could be to create the ccmp lookup as Georg suggests, but to use the lookup not only in the ccmp but also as the first lookup in the other features such as smcp or calt. I haven't yet tested how well this works.
  • Options
    Kent LewKent Lew Posts: 905
    Adam — It would be interesting to know if your workaround succeeds any more broadly (in browsers for example).

    But I suspect that apps that don’t process {ccmp} probably also won’t implement GSUB lookup type 2 one-to-many substitutions. I think that’s the crux of it.

    You probably know: InDesign only processes GSUB type 2 and {ccmp} if one of the World-Ready Composers is applied, which is not a default. And I bet these are not on most Westerners’ radars. Thus, although the suggested approach will work in Indd under those specific circumstances — I just tested the {smcp} example — it may not be a very practical solution for the typical retail market.
  • Options
    Dave CrosslandDave Crossland Posts: 1,394
    edited August 2014
    Seems to me that if the type world produces a lot of such fonts and users complain to app developers, the apps will get better, sooner than if we waited for them before making such fonts.

    Adam, I look forward to you publishing more details about your tests ;)
  • Options
    Mark SimonsonMark Simonson Posts: 1,654
    That's worked so well for OpenType features.
  • Options
    In EB Garamond I tried this approach: I set up a decomposing lookup which decomposes every composed glyph with a canonical decomposition and added it as the first lookup to various features when appropriate (smcp, swash,...) but not to ccmp. Thus it was processed as part of the respective feature without a problem. The downside is that it complicates the kerning a lot because you’ll have to deal with contextual kerning for every combination.

    Finally, I ended up with deactivating this because one of the applications which I use quite often had a bug in its contextual positioning algorithm.
Sign In or Register to comment.