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

[jpt]

Similar to #9, it also (incidentally) fixes the rendering error in webkit with overlapping shapes in the variable TTF file

I imagine I will write a Glyphs script to do this using its own rounding function, because I would like to maintain a separate source file with a "lossless" (i.e. non-rounded, still has components) version of Barlow. This will be a separate source file step for variable font compilation only I suppose

[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" notifications@github.com 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 https://github.com/jpt/barlow/issues/10#issuecomment-315602796, 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" notifications@github.com 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 https://github.com/jpt/barlow/issues/10#issuecomment-315652642, 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?

[jpt]

7 years laters and Glyphs 3.2 supports this 😃

From https://glyphsapp.com/news/glyphs-3-2-released:

Some filters now work as custom parameters in variable font settings, provided they treat each layer equally in order to maintain compatibility. For instance, Offset Curve, Round Corner and Transformations should work now. (Please don’t ask for Roughen, ahem.) Special trick: if you use the Round Corner filter as custom parameter, you can sneak in the keyword compatible and Glyphs will attempt to round all masters in the same way:

(cc @davelab6 - Barlow VF may yet see the light of day as a result of this, though there is a lot of point placement to work out before a VF can render without kinks everywhere - and a few glyphs that will need alternates due to incompatible paths once the rounding filter gets applied by Glyphs. I have some questions for you RE what GF can tolerate on changes to outlines and metrics)