laerm0/opensans

Open Sans font

Open Sans

variable font

Originally designed by Steve Matteson of Ascender
Hebrew by Yanek Iontef
Weight expansion by Micah Stupak
Help and advice from Meir Sadan and Marc Foley

Building fonts

# Create a new virtual env and install dependencies
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt


# Change to source dir and generate fonts
cd source
sh build.sh

opensans's Issues

Normalize UFO and document how to do so

Normalizing UFOs can make commits smaller and diffs more relevant.
As mentioned in #10, you can either use a tool like ufoNormalizer or fontTools.ufoLib, or also psfnormalize.

Whichever one you pick, please document it so any contributor can use the same.

Cond ExtraBold Italic Glyphs master

@laerm0 @m4rc1e @davelab6

What are the origins of the new "OpenSansCondensed-ExtraBoldItalic" master?

The spacing and letterforms are highly suspect. See the Glyphs source file "OpenSans-Italic.glyphs" from Nov 27, 2019.

bracket layers are hiding somewhere

OpenSans-Italic.glyphs has bracket layers stuck somewhere inside it.

fontmake -g OpenSans-Italic.glyphs -o ufo returns

  File "/Users/stupakm/venvs/type-tools-py3/lib/python3.7/site-packages/glyphsLib/builder/builders.py", line 343, in _apply_bracket_layers
    "Only bracket layers with one numerical (design space) location "
ValueError: Only bracket layers with one numerical (design space) location (meaning the first axis in the designspace file) are currently supported.

@m4rc1e had given me the following short script that would clean this up but no luck here.

font = Glyphs.font

for glyph in font.glyphs:
	new_layers = []
	for layer in glyph.layers:
		if not layer.isSpecialLayer:
			new_layers.append(layer)
	glyph.layers = new_layers

Any thoughts from him or a fellow Glyphs driver out there?

vertical metrics regressions

A request came in to add math glyphs to Open Sans so the whole Noto Sans math set has been added to Open Sans Roman (at the same weight – i.e. the glyphs look the same in all weights – these glyphs have not been added to italic). Because many of the math glyphs are large, the vertical metrics are now different.

Question: when the files are subset upon delivery, are the vert metrics recalculated? I assume not, but I was hoping if someone requests math Unicodes that that would be the only time we have giant YMax and YMin values.

Here are the extrema:

MinX g888 -1196.0
MinY summationWithIntegral -860.0
MaxX bottomcurlybracket 3471.0
MaxY bigReverseSolidus 2189.0

g888 is a stacked accent, but the other three are math.

Thought One for me is that maybe we could serve Open Sans Math as well?

Opinions welcome from @davelab6 @m4rc1e @rsheeter and @garretrieger.

switching to UFO + designspace source

The build process for a font with multiple axes + bracket layers in Glyphs source has been rather difficult. Also, hint matching is more complex. Therefore, moving forward, the source will be UFO + designspace. The contours will be converted to quadratic using cu2qu to ensure greater fidelity. (Point numbers will undoubtedly change, therefore manual hinting will have to be done again.)

to-do:

• make UFOs
• convert using cu2qu
• make quadratic outlines compatible
• make designspace
• build TTFs using fontmake
• proof metrics/kerning/outlines using diffenator
• manually hint VFs
• proof rendering using diffenator/diffbrowsers
• instantiate static weights from hinted VFs
• manually tune instances (if necessary)
• write post-mortem doc on bumps and tips and optimistic timeframe for completing a project like this

hinting regressions

There will be hinting regressions on the accented glyphs because these files were originally hinted by someone at Ascender many years ago and they used special functions to position accents. Those functions became the IP of Monotype once Monotype bought Ascender. Because this is proprietary information (albeit proprietary information that I have partially forgotten), those techniques cannot be used again. As I am clearly not a lawyer, I don't want to drag any of that info out of my head to use again.

Anyway, the result you will see is that there will be occasional accent collision and bouncing at small sizes.

_example_

Perhaps with the aid of @josh-hadley I can rewrite these functions and make them look "different" enough to pass muster with lawyers, but because it's essentially assembly code, the stuff will kinda always be in the same order.

This is all way outta my pay grade, so opinions welcome from @davelab6 and @rsheeter.

Instantiation of varfont

I took a look at the fonts on the path https://github.com/laerm0/opensans/blob/quad_UFOs/source/quadratic/variable_ttf/ and it appears that there is a problem with the font https://github.com/laerm0/opensans/blob/quad_UFOs/source/quadratic/variable_ttf/OpenSans-Roman-quadratic-VF.ttf (top image). When you view it in Axis Praxis and FontView the weights are only reflected in a few of the glyphs. The rest remain at the 300 weight irrespective of the definition when you create instances or use sliders in the VF viewers.

When I build instances with https://github.com/laerm0/opensans/blob/quad_UFOs/source/quadratic/variable_ttf/OpenSans-Roman-quadratic-VF copy.ttf, the weight information translates into the instances appropriately, but the width does not for some reason (see other views in images below). I can confirm that the width axis works for this font with the VF viewer sliders.

I don't know why this is the case. I built directly with fonttools varLib.mutator and this was the output that I get using the verbose setting (and with no relevant OT table diff c/w the builds that came from the vf2s.py script):

$ fonttools varLib.mutator --verbose -o test40060.ttf OpenSans-Roman-quadratic-VF-copy.ttf wght=400 wdth=60

Location: {'wght': 400.0, 'wdth': 60.0}
Loading variable font
Reading 'fvar' table from disk
Decompiling 'fvar' table
Reading 'avar' table from disk
Decompiling 'avar' table
Normalized location: {'wght': 0.23333740234375, 'wdth': 0.0}
Mutating glyf/gvar tables
Reading 'gvar' table from disk
Decompiling 'gvar' table
Reading 'post' table from disk
Decompiling 'post' table
Reading 'maxp' table from disk
Decompiling 'maxp' table
Reading 'glyf' table from disk
Decompiling 'glyf' table
Reading 'loca' table from disk
Decompiling 'loca' table
Reading 'head' table from disk
Decompiling 'head' table
Reading 'hmtx' table from disk
Decompiling 'hmtx' table
Reading 'hhea' table from disk
Decompiling 'hhea' table
Mutating MVAR table
Reading 'MVAR' table from disk
Decompiling 'MVAR' table
Reading 'OS/2' table from disk
Decompiling 'OS/2' table
Mutating FeatureVariations
Reading 'GSUB' table from disk
Decompiling 'GSUB' table
Reading 'GPOS' table from disk
Decompiling 'GPOS' table
Reading 'GDEF' table from disk
Decompiling 'GDEF' table
Mutating GDEF/GPOS/GSUB tables
Pruning name table
Reading 'name' table from disk
Decompiling 'name' table
Removing variable tables
Saving instance font test40060.ttf
compiling 'glyf' table
writing 'glyf' table to disk
compiling 'maxp' table
writing 'maxp' table to disk
compiling 'loca' table
writing 'loca' table to disk
compiling 'head' table
writing 'head' table to disk
compiling 'hmtx' table
writing 'hmtx' table to disk
compiling 'hhea' table
writing 'hhea' table to disk
compiling 'OS/2' table
Reading 'cmap' table from disk
Decompiling 'cmap' table
writing 'OS/2' table to disk
compiling 'cmap' table
writing 'cmap' table to disk
compiling 'name' table
writing 'name' table to disk
compiling 'post' table
writing 'post' table to disk
compiling 'GDEF' table
writing 'GDEF' table to disk
compiling 'GPOS' table
writing 'GPOS' table to disk
compiling 'GSUB' table
writing 'GSUB' table to disk

Built with fontTools v3.40.0. This sounds like an issue for the fontTools repository. Unfortunately, I don't know how to troubleshoot it further. Sorry...

ordfeminine in italic

It's single-story in the regular but two-story in the condensed. 🤔 I'm inclined to go single-story on all, @davelab6. Thoughts?

composites in hinted instances are broken from instantiation

Looking for a gftools script to accept a list of GIDs (to account for unencoded glyphs) and then swap in the same glyph from a different font. Issue filed at googlefonts/gftools#141

Instances will never match source TTFs

This isn't a solvable issue; it's a note for future users.

These files were originally designed without the aid of multiple masters; therefore, there will be slight differences between stem weights throughout and some consistency/predictability lacking in the vertical design dimension (vertical = in a specific glyph between weights; horizontal = in a specific weight among glyphs).

These GIFs show this. The glyphs with the red bars are from the original TTFs.

Regular

Semibold

The interpolations between weights used the Pablo distribution. The weights match ±2 units in the horizontal dimension: getting them to match in the vertical dimension – i.e. horizontal stems – would require a different weight value than the horizontal dimension. As vertical stems are more common and more important to legibility than horizontal stems, the decision was made to make sure those are correct. Interpolation by different values in the X and Y directions is currently unsupported, so this isn't happening.

Another solution would be to find which glyphs are off the most and then set up sparse masters for them. A sparse master is a master that would otherwise be an interpolation and has an incomplete glyph set. This is supported, however, it would also greatly increase the file size, offsetting the gains by going to variable fonts.

For added fun, this awkward relationship between weights also means the sidebearings are not equal to source glyphs. Hopefully the improved kerning takes care of this (and provides an upgrade across the board).