Enable round edges in OTVar by removing all components and overlaps then rounding the font about barlow

[davelab6]

Agree

[jpt]

I am thinking of a build step something like this, although it will be hard/impossible to script it all now that I think about it -- letters like Ø are going to become incompatible across masters once overlap is removed. This also assumes italic and roman masters will be compatible but I think that should be easy for Barlow

[davelab6]

I'm not sure about the remove overlap part for a VF

…

On Jul 16, 2017 7:25 AM, "jeremy tribby" ***@***.***> wrote: I am thinking of a build step something like this, although it will be hard/impossible to script it all now that I think about it -- letters like Ø are going to become incompatible across masters once overlap is removed. This also assumes italic and roman masters will be compatible but I think that should be easy for Barlow [image: image] <https://user-images.githubusercontent.com/5319916/28247094-ad6ba7cc-69de-11e7-8655-d2773dcfa989.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9y12mSzP9ILMLMA5sNYa3oqotfHjTks5sOfMygaJpZM4OXD7B> .

[jpt]

@davelab6 I would prefer not to remove the overlap, but I think the interior/negative rounding makes it difficult to avoid --
for example, this is the desired output for /H

but this is what happens to the outlines if I were to apply my rounding settings without removing the overlap

is there an advantage/loss from doing it? do GX binaries have components like Glyphs for reducing repetition/file size?

[davelab6]

Take a look at Decovar in trufont or robofont; it's converted to ps curves in glyphsapp but the way TT curves work can solve this.....

…

On Jul 16, 2017 9:23 PM, "jeremy tribby" ***@***.***> wrote: @davelab6 <https://github.com/davelab6> I would prefer not to, but I think the interior/negative rounding makes it difficult not to. this is the desired output for /H [image: screen shot 2017-07-16 at 6 14 21 pm] <https://user-images.githubusercontent.com/5319916/28253039-39ec6ff0-6a53-11e7-96df-88589b58c582.png> but this is what happens to the outlines if I were to apply my rounding settings without removing the overlap [image: screen shot 2017-07-16 at 6 15 21 pm] <https://user-images.githubusercontent.com/5319916/28253073-c56844be-6a53-11e7-873e-eec2cd29efa9.png> what is the advantage/loss from doing it? do GX binaries have components like Glyphs for reducing repetition/file size? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9y-HkPtc4N6jfm_gcz9aInxEewtPoks5sOresgaJpZM4OXD7B> .

[jpt]

@davelab6 what am I looking at in Decovar exactly? there's so much going on in every file! it's also possible there's something you can see that I can't --- /sources/2-build/ implies there is maybe a /sources/1-something/ folder somewhere :)

Looking in RoboFont I see it's easy enough to handle some interior curves, but doesn't help any with things like crossbars-

[jpt]

or are you suggesting this? (upper right)

in which case: are the crazy half-outlines done manually? or is there some step to get there? I admittedly don't know much about the difference between TT and PS curves

[jpt]

Alright so I've scripted the first part of this as a Glyphs script. It decomposes letters in a way that transfers brace layers from components to the parent glyph first, cause otherwise you lose them when decomposing. And it only does it to [a-zA-Z] letters, not to diacritic marks etc. This is the first step in flattening the file for VF -- or for anything.

If I remove overlaps, then the layers become incompatible, so I think I still need to learn about the TrueType feature mentioned above -- still not sure what I'm looking for exactly.

#MenuTitle: Brace Layer Decompose
# -*- coding: utf-8 -*-

__doc__="""
Brace Layer Decompose
"""

import GlyphsApp, re, string

font = Glyphs.font
brace = re.compile("^{\s*\d+\s*,\s*\d+\s*}$")

letters = string.ascii_uppercase + string.ascii_lowercase
letter_clones = []

for glyph in font.glyphs:
  if glyph.name in letters and len(glyph.name) == 1:
    for i, layer in enumerate(glyph.layers):
      for component in layer.components:
        if glyph.layers[i].name == font.masters[0].name:
          if component.componentName not in letters:
            for component_layer in font.glyphs[component.componentName].layers:
              if brace.match(component_layer.name):
                newBraceLayer = GSLayer()
                newBraceLayer.name = component_layer.name
                font.glyphs[glyph.name].layers.append(newBraceLayer)
                newBraceLayer.reinterpolate() 
          elif component.componentName in letters:
            letter_clones.append([glyph,component.componentName])
         
for glyph, letter in letter_clones:
  for layer in font.glyphs[letter].layers:
    if brace.match(layer.name):
      newBraceLayer = GSLayer()
      newBraceLayer.name = layer.name
      glyph.layers.append(newBraceLayer)
      newBraceLayer.reinterpolate()
      
for glyph in font.glyphs:
  for layer in glyph.layers:
    layer.decomposeComponents()

[jpt]

@davelab6 Still wondering what you meant about TT curves above if you don't mind! To clarify, the problem is the "negative"/"interior" rounding in the counters... just not sure if it's possible to do it with VF while maintaining components. Could definitely flatten it entirely and take care of problem glyphs like Ø manually, but then the masters become lossy. The Glyphs suggestion is not making rounded variable fonts 😅! Maybe this is the kind of wizardry that exists in FontLab IV?