jpt
Enable round edges in OTVar by removing all components and overlaps then rounding the font
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
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
I'm not sure about the remove overlap part for a VF
On Jul 16, 2017 7:25 AM, "jeremy tribby" [email protected] 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 .
@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?
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" [email protected] 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 .
@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-
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
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()
@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?