I'm trying to build a VF file, have Prepolated all masters, and can't find the source of incompatibility for a large number of glyphs. Just taking the AE as an example, I've checked:

• point structure/count
• anchors
• guides
• objects on other layers

Is something happening with the cu2qu converter that is creating the incompatibility?? Or are there other parameters I should be checking for?

Current naming scheme for the optical size and goofy axes rely on the additional quantifier “Min”, “Mid”, and “Max”. This makes instance names very similar and clutters them with repetitive data.

As an alternative, the optical axis could be described by point size (9, 76, 144) following the recommendation in the spec or it could be called by more general intended size, so OpMin becomes S, OpMid corresponds to M and OpMax would turn into L.

Another riddle to be solved are the states of the GOOF axis (GoofyMin, GoofyMid, GoofyMax) which highlight a similar problem.

Following instance_names.csv in Recursive repo, I quickly sketched out the current state and the 2 options outlines above.

Instance_names_options.zip

@davelab6 What are the Google Fonts Standards when it comes to this? Do you have any preferences among the ideas outlined here? Or do you have another solution in mind?

@sponcey please could you confirm these default values?

Dropping the current font in Wakamai Fondue shows some things that might not be intended:

• Font name is Fraunces 144pt S100 Black
• Axes defaults are all at their max (144 opsz, 900 weight, 100 soften, 1 wonk)

Readme says it's 100, I didn't check the files

@davelab6: In addition to the GOOF axis (which controls the contrast/goopiness of the letterforms) I would like to give the user independent control of the extremely wonky characters with a WONK axis. The WONK axis will be a binary axis that toggles these substitutions, in case users really don't want the leaning h/n/m at large optical sizes.

WONK: 1 [default]

WONK: 0

In order to achieve the addition of this new axis, I reinserted the masters at all extremes. As far as I can tell, this increased the file size roughly 20%.

Is this an effective solution for introducing a new axis, which only substitutes a few characters? Is this an acceptable increase in file size to give the users more control? Or is there another approach that can give us the same effect?

The Fontbakery tests were run per each Subfamily, e.g. Fraunces9ptS100.

This Warn is useful to identify issues that could come from differences between masters, whether it is in the order of paths or nodes, path direction, or anything that could be causing interpolation issues.
Please check each report to see the detailed info on each font and verify if everything is as expected.

E.g. Fraunces9ptS100-Black.ttf

--- Rationale ---

Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be
constructured in a handful of ways. This means a glyph's contour count will
only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3
contours, depending on whether its double story or single story.

However, a quotedbl should have 2 contours, unless the font belongs to a
display family.

This check currently does not cover variable fonts because there's plenty of
alternative ways of constructing glyphs with multiple outlines for each feature
in a VarFont. The expected contour count data for this check is currently
optimized for the typical construction of glyphs in static fonts.

Please include carets for Ligatures across the Family

--- Rationale ---

All ligatures in a font must have corresponding caret (text cursor) positions
defined in the GDEF table, otherwhise, users may experience issues with caret
rendering.

If using GlyphsApp, ligature carets can be set directly on canvas by accessing
the `Glyph -> Set Anchors` menu option or by pressing the `Cmd+U` keyboard
shortcut.

stylemapfamilyname entries defined in the .designspace files do not end up in the final variable fonts. I don’t really know why this happens but I am very eager to learn what the recommended workflow is to get them there. Or is that something that is ignored when generating a variable font?

Maybe @anthrotype knows?

See google/fonts#3411

At the moment the optical size axis is mapped as follows:

<axis default="9" maximum="144" minimum="9" name="optical" tag="opsz">
            <labelname xml:lang="en">Optical Size</labelname>
            <map input="9" output="9" />
            <map input="18" output="36" />
            <map input="24" output="72" />
            <map input="36" output="100" />
            <map input="48" output="130" />
            <map input="72" output="138" />
            <map input="96" output="142" />
            <map input="122" output="143" />
            <map input="144" output="144" />
        </axis>

As a result, named instances of the 72 kind (what was previously known as OpMed) get a real value of 24. You can observe this in Axis Praxis for example.

Is this on purpose? Do you thin this discrepancy is fine? Or should this somehow be fixed?

Following Google’s standard:
https://github.com/googlefonts/gf-docs/tree/master/VerticalMetrics

This can be done once drawing is finished and extreme points on tops and bottoms are properly set.

At the moment the source UFOs still include old style names like “Light OpMin GoofyMin” in the font info. These sometimes polute the naming entries of generated fonts.

On a related note: Should this also result in us changing the file names of the source UFOs? I don’t know if there are standards for this on Google’s side. This might cause a few more changes, most notably in the designspace files.

Hey, amazing work. What a lovely family! 🙂

I was just checking out the minisite and noticed that on my Linux machine, some of the characters don't render that well at the particular font size specified for the sample site (1.375rem – it happens between 1.35rem and 1.5rem). This is an issue in both Firefox and Chrome. It's most noticeable for g:

This doesn't seem to happen on Windows:

Kern information for non-ligated ligature sequences could be needed to prevent spacing Issues. Please check if that would be needed in Fraunces case.

--- Rationale ---

Fonts with ligatures should have kerning on the corresponding non-ligated
sequences for text where ligatures aren't used (eg
https://github.com/impallari/Raleway/issues/14).

On https://fraunces.undercase.xyz right now there's an interpolation error on the o in the GOOF axis:

Overall
– swashy ampersand larger
– italic Th lig in non-flag?

Op Min Light
– Numbers too heavy
– f loose right?
– too much contrast in brace

Bold Op Min
– italic spacing of quotes

Italic Wonk Subs
– w nub smaller/sharper like nub of n

When running the build.sh, in the "Generating VFs" step, at Italic font subtask, the process is stopped with the following Error is reported:

INFO:fontTools.varLib:Merging OpenType Layout tables
fontmake: Error: In 'Italic/FrauncesItalic.designspace': Generating fonts from Designspace failed: ((0, [0, 8, 8, 0, 8, 0]), 'int', '.LookupFlag', 'Lookup', '[0]', 'list', '.Lookup', 'LookupList', '.LookupList', 'GPOS', '.table', 'table_G_P_O_S_')

https://github.com/undercasetype/Fraunces/tree/master/sources README has some "To Do" items:

• Explain steps for using scale&interpolate script
• Steps/method for mounting accents
• How to use build script to generate font

@davelab6 It was brought to my attention that there is a typeface by the name of Chauncy already available on Typekit: https://fonts.adobe.com/fonts/chauncy

I propose we go back to Chauncey with an 'e': https://namecheck.fontdata.com/?q=Chauncey

... or explore other names :)

Wonk axis defaults to 1 and has a second state for 0.

Both of them are defined in the add_STAT.py script. However in the final font, only the 1 state shows up. The reason for this might be some interference with the axis setting elsewhere, or a state/value of 0 is a problem for one of the tools involved. A wonk value of 1 is defined in fvar, wonk 0 is (and should) not.

I had a conversation with the Google team last week, and there are two final pieces of confirmation we are waiting for:

• Custom axis values between 0 to 100 are ok.
• Goofy axis renaming to one of the following:
• GOOP (goopy)
• BLOB (blob)
• CUSH (cushion/cushy)
• SOFT (soften)

Below is a summary of the new axis names and axis values, that will need to be reflected in the updated instance names.

opsz: 9pt, 36pt, 72pt, 144pt, default 36pt
WONK: 0 to 1, default 1 (not shown in instance names)
GOOF (or chosen axis name): 000 to 100, default 050

Forgive me for maybe not using the right terminology here. I'm just some guy. :)

I've got Fraunces installed and I'm playing with it in Sketch. When I change the character spacing to anything but 0, everything seems to react normally except the "th" in "the", which pops out a bunch of extra space. Seems to happen across the fixed fonts. Quick screencast: https://cozy.es/7qq91v

@arialcrime I'm not sure what is happening here... seems like it can't load the file, but the path looks correct to me?

OSError: Error reading file 'current_masters/Roman/Fraunces.designspace': failed to load external entity "current_masters/Roman/Fraunces.designspace"

The 1.000 release does not have a copy of the OFL license (which is part of this repository) included in the release & distribution packaging as it should be. I suggest a 1.001 release to correct this as it makes a different for distribution packaging (I'm trying to update the Arch Linux package).

The following feedback is based on the proofs generated here.

OpMin Light:
– Q tail heavy, too sharp?
– H crossbar high (should be upside down)
– C contrast off, less weight on top, more weight in left bowl
– bottom of G curve up more
– p top branching too heavy
– bottom of t too narrow, needs to curl a little higher
– sharper turn at top of g spine to more closely match in black
– ball of brace might jump out as too heavy
– bottom right serif of r slightly longer
– too much contrast bottom of J, ball lighter, open up to the right more (like f)
– top left counter of B E F R P round instead of square

OpMin Black:
– C, G light
– throw weight towards bottom in C
– R crossbar slightly lower
– S doesn't feel upside down?
– H crossbar high (should be upside down)
– stumps on bottom of V W more rounded, pronounced
– top of g spine to the right a smidge to more closely match in light
– top left serif of B D E F P R looks slightly lighter than bottom
– does the u overshoot at bottom too much?
– top left counter of B E F R P round instead of square

The following feedback is based on the proofs generated here.

OpMin Light:
– K slightly wide
– X Y ball too stiff?
– tiddle more horizontal
– top left counter of E F round instead of square

OpMin Black:
– take weight out of caps
– take weight OR open interiors to match weight in Roman
– K too wide
– X Y ball too stiff?
– z too wide
– tiddle more horizontal
– top left counter of E F round instead of square
– Q thin too heavy (maybe alt not necessary?)
– O too heavy, less square?
– less weight in branching
– right stem n heavier than left stem

Hi!
I’ve found an odd issue when setting Fraunces to the max value for opsz and a font size greater than 256px. When these conditions are matched It doesn‘t renders the correct font variation.
In the screenshot below you can see two lines.
Both uses the same font variation settings but different font files. The top line uses the current font files from the "fonts" folder of this repo and the bottom line, that is working as expected, uses a font file from the Fraunces Minisite.

From Left to Right: Chrome, Safari, Firefox.

Probably it‘s a FF bug but I couldn’t reproduce this error with other fonts that has opsz too.
Here I attach the test html so you can see this by yourselves.

FrauncesTestCase.zip

Best.

@davelab6: I've been having trouble finding a clear answer of how font family/style naming works for implementing an ital axis in a Variable Font. I did some research, and found this issue in the Amstelvar repo.

This is from early last year, should I assume this approach (using the STAT table) is still valid and the way to go for Fraunces?

The main Fails reported on the Roman VF Fraunces[SOFT,WONK,opsz,wght].ttf are on the Typographic Subfamily Name for Windows (Name ID 17) and Instance Names. The latter must be related to what is required according to the Spec about Instances.

Note: Despite the Italic font couldn't be produced for an Error when running the build.sh, this same Fails would be expected for that font too.

It's pretty cumbersome to download files directly from a repo's fonts/ folder. Instead, if you set up a release in the proper "Releases" area of the repo, it's much more convenient for people, because you can provide a zip with all files, licensing, and a README together in a one-click download.

For example, see https://github.com/arrowtype/recursive/releases. For what is probably an even better example, see https://github.com/rsms/inter/releases.

Let's test a couple of updates to the VF to see if this helps font menus.

STAT table update

Then, replace your STAT table with this:

<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="\x00\x01\x00\x00" ttLibVersion="3.36">
    <STAT>
        <Version value="0x00010002"/>
        <DesignAxisRecordSize value="8"/>
        <!-- DesignAxisCount=2 -->
        <DesignAxisRecord>
            <Axis index="0">
                <AxisTag value="opsz"/>
                <AxisNameID value="256"/>
                <!-- Optical Size -->
                <AxisOrdering value="0"/>
            </Axis>
            <Axis index="1">
                <AxisTag value="wght"/>
                <AxisNameID value="257"/>
                <!-- Weight -->
                <AxisOrdering value="1"/>
            </Axis>
        </DesignAxisRecord>
        <!-- Regular -->
        <ElidedFallbackNameID value="2"/>
        <!-- AxisValueCount=0 -->
        <AxisValueArray>
            <!-- ===== OPTICAL SIZE ===== -->
            <AxisValue index="0" Format="1">
                <AxisIndex value="0"/>
                <Flags value="0"/>
                <!-- Thin -->
                <ValueNameID value="276"/>
                <Value value="250.0"/>
            </AxisValue>
            <!-- ===== WEIGHT ===== -->
            <AxisValue index="0" Format="1">
                <AxisIndex value="1"/>
                <Flags value="0"/>
                <!-- Thin -->
                <ValueNameID value="276"/>
                <Value value="250.0"/>
            </AxisValue>
        </AxisValueArray>
    </STAT>
</ttFont>

Name table update

Replace your name table with this:

<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="\x00\x01\x00\x00" ttLibVersion="3.36">

  <name>
    <namerecord nameID="256" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Optical Size
    </namerecord>
    <namerecord nameID="257" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Weight
    </namerecord>
    <namerecord nameID="258" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular OpMax
    </namerecord>
    <namerecord nameID="259" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-RegularOpMax
    </namerecord>
    <namerecord nameID="260" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Semibold OpMax
    </namerecord>
    <namerecord nameID="261" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-SemiboldOpMax
    </namerecord>
    <namerecord nameID="262" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Bold OpMax
    </namerecord>
    <namerecord nameID="263" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-BoldOpMax
    </namerecord>
    <namerecord nameID="264" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular OpMid
    </namerecord>
    <namerecord nameID="265" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-RegularOpMid
    </namerecord>
    <namerecord nameID="266" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Semibold OpMid
    </namerecord>
    <namerecord nameID="267" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-SemiboldOpMid
    </namerecord>
    <namerecord nameID="268" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Bold OpMid
    </namerecord>
    <namerecord nameID="269" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-BoldOpMid
    </namerecord>
    <namerecord nameID="270" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular OpMin
    </namerecord>
    <namerecord nameID="271" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-RegularOpMin
    </namerecord>
    <namerecord nameID="272" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Semibold OpMin
    </namerecord>
    <namerecord nameID="273" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-SemiboldOpMin
    </namerecord>
    <namerecord nameID="274" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Bold OpMin
    </namerecord>
    <namerecord nameID="275" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Fraunces-BoldOpMin
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Fraunces Regular OpMin
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      0.001;NONE;Fraunces-RegularOpMin
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      Fraunces Regular OpMin
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
      Version 0.001
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      Fraunces-RegularOpMin
    </namerecord>
    <namerecord nameID="8" platformID="3" platEncID="1" langID="0x409">
      Charles&amp;Thorn
    </namerecord>
    <namerecord nameID="9" platformID="3" platEncID="1" langID="0x409">
      Spencer Charles
    </namerecord>
    <namerecord nameID="11" platformID="3" platEncID="1" langID="0x409">
      http://www.charlesandthorn.com
    </namerecord>
    <namerecord nameID="12" platformID="3" platEncID="1" langID="0x409">
      http://www.spencercharles.com
    </namerecord>
    <namerecord nameID="13" platformID="3" platEncID="1" langID="0x409">
      Copyright 2019 The Fraunces Project Authors (https://github.com/sponcey/Fraunces)
    </namerecord>
    <namerecord nameID="16" platformID="3" platEncID="1" langID="0x409">
      Fraunces
    </namerecord>
    <namerecord nameID="17" platformID="3" platEncID="1" langID="0x409">
      Regular OpMin
    </namerecord>
    <namerecord nameID="256" platformID="3" platEncID="1" langID="0x409">
      Optical Size
    </namerecord>
    <namerecord nameID="257" platformID="3" platEncID="1" langID="0x409">
      Weight
    </namerecord>
    <namerecord nameID="258" platformID="3" platEncID="1" langID="0x409">
      Regular OpMax
    </namerecord>
    <namerecord nameID="259" platformID="3" platEncID="1" langID="0x409">
      Fraunces-RegularOpMax
    </namerecord>
    <namerecord nameID="260" platformID="3" platEncID="1" langID="0x409">
      Semibold OpMax
    </namerecord>
    <namerecord nameID="261" platformID="3" platEncID="1" langID="0x409">
      Fraunces-SemiboldOpMax
    </namerecord>
    <namerecord nameID="262" platformID="3" platEncID="1" langID="0x409">
      Bold OpMax
    </namerecord>
    <namerecord nameID="263" platformID="3" platEncID="1" langID="0x409">
      Fraunces-BoldOpMax
    </namerecord>
    <namerecord nameID="264" platformID="3" platEncID="1" langID="0x409">
      Regular OpMid
    </namerecord>
    <namerecord nameID="265" platformID="3" platEncID="1" langID="0x409">
      Fraunces-RegularOpMid
    </namerecord>
    <namerecord nameID="266" platformID="3" platEncID="1" langID="0x409">
      Semibold OpMid
    </namerecord>
    <namerecord nameID="267" platformID="3" platEncID="1" langID="0x409">
      Fraunces-SemiboldOpMid
    </namerecord>
    <namerecord nameID="268" platformID="3" platEncID="1" langID="0x409">
      Bold OpMid
    </namerecord>
    <namerecord nameID="269" platformID="3" platEncID="1" langID="0x409">
      Fraunces-BoldOpMid
    </namerecord>
    <namerecord nameID="270" platformID="3" platEncID="1" langID="0x409">
      Regular OpMin
    </namerecord>
    <namerecord nameID="271" platformID="3" platEncID="1" langID="0x409">
      Fraunces-RegularOpMin
    </namerecord>
    <namerecord nameID="272" platformID="3" platEncID="1" langID="0x409">
      Semibold OpMin
    </namerecord>
    <namerecord nameID="273" platformID="3" platEncID="1" langID="0x409">
      Fraunces-SemiboldOpMin
    </namerecord>
    <namerecord nameID="274" platformID="3" platEncID="1" langID="0x409">
      Bold OpMin
    </namerecord>
    <namerecord nameID="275" platformID="3" platEncID="1" langID="0x409">
      Fraunces-BoldOpMin
    </namerecord>
    <namerecord nameID="276" platformID="3" platEncID="1" langID="0x409">
      OpMin
    </namerecord>
    <namerecord nameID="277" platformID="3" platEncID="1" langID="0x409">
      Bold
    </namerecord>
  </name>

</ttFont>

Once these are saved, use ttx to merge them back into the main font:

ttx -m yourpathhere/Fraunces-VF.ttf yourpathhere/Fraunces-VF.ttx

then

ttx -m yourpathhere/Fraunces-VF.ttf yourpathhere/Fraunces-VF_STAT.ttx

The README showing off the axes is great! Just a couple of small requests

• Please add a table to the README.md with the axis label, tag, and min, default, max range definitions (similar to the table at https://github.com/arrowtype/recursive/#variable-axes)

• I suggest to use an easing method on the GIFs so that the ends of the axis are given enough time; since the axes are 'curved' with avar data, the 'linear' GIF animation doesn't illustrate what is happening well (especially the ungoofing of opsz-min :)

According to this comment the weight value for Thin should now be 200 (following the OT spec, it is currently set to 100).

Waiting until further confirmation that this is indeed the desired value. Ultimately this might also require the weight axis mapping to be recalculated (and possibly a few other steps I am currently missing).

It would be good for someone to look critically at the angles of handles across all of the masters and make a decision as to how they should be oriented in each spot (i.e., if a particular spot will have points on extremes or handles at some other angle), especially at the rounded terminals and inflection points. As it stands there are some funky/kinky interpolations that could be solved by taking a macroscopic look at point structures and thinking about how they are going to interpolate.

Here are a couple examples of funky matches I’ve come across.

The WONK axis is described in the README as a binary (perhaps Boolean would be better?) axis, but then the default value is 0.5; it is unclear to me if that means equivalent to 0 or 1, or something else :)

The most recent fontbakery report can be found here and the fonts here. Below are notes about a few of the FAIL and WARN messages found in there.

To further proceed with the project it would be important to hear from @davelab6 and @m4rc1e. What are the things that still need to be fixed to consider this a worthy version 1.0? What are your thoughts on the treatment of the stat table? Thanks for your comments!

In my opinion this output can be ignored because it stems from fontbakery not being able to parse the custom axes naming.

--- Rationale ---

Variable font family directories kept in the google/fonts git repo must include
a static/ subdir containing static fonts.
These files are meant to be served for users that still lack support for
variable fonts in their web browsers.

To speed up the first release of Fraunces, it was agreed that there won’t be any static fonts for now.

--- Rationale ---

All ligatures in a font must have corresponding caret (text cursor) positions
defined in the GDEF table, otherwhise, users may experience issues with caret
rendering.

Ligature carets are now included in the UFO spec, but I wasn’t able to find an indication that they are handled by ufo2ft or fontmake. related issue

--- Rationale ---

Fonts with ligatures should have kerning on the corresponding non-ligated
sequences for text where ligatures aren't used (eg
https://github.com/impallari/Raleway/issues/14).

There are a few issues related to kerning that might need some attention.

--- Rationale ---

According to a GlyphsApp tutorial [1], in order to make sure all versions of
Windows recognize it as a valid font file, we must make sure that the
concatenated length of the familyname (NameID.FONT_FAMILY_NAME) and style
(NameID.FONT_SUBFAMILY_NAME) strings in the name table do not exceed 20
characters.

After discussing the problem in more detail at `FontBakery issue #2179 [2] we
decided that allowing up to 27 chars would still be on the safe side, though.

[1]
https://glyphsapp.com/tutorials/multiple-masters-part-3-setting-up-instances
[2] https://github.com/googlefonts/fontbakery/issues/2179

This issue seems to be a hot topic, especially with multi-axes variable fonts. For now, I would leave this as it is.

@RoelN asked,

Do you have an idea how to show off the opsz axis, or introduce some "serious" specimen bits?

For opsz, I think you need to show 3-5 things:

1. A large and fixed-pt-size text of a few key glyphs, showing them mutate along the optical size axis.

2. Possibly, a large and fixed-pt-size text of a few key glyphs with a fixed (default) opsz design - so you can see what the difference is "before and after" or "with and without" optical size.

3. A headline and a paragraph(s) underneath it, with an animating change to pt size, and opsz changing in tandem (as per 'font-optical-sizing: auto' in CSS). The headline should probably have a fixed baseline and the paragraph's line spacing probably needs to change as the point size changes, and probably needs to overflow and be cut off so that the overall paragraph frame stays fixed.

4. Possibly, a headline and a paragraph(s) underneath it, with a changing pt size, but again no opsz changes, just sticking with default. The headline should probably have a fixed baseline and the paragraph's line spacing probably needs to change as the point size changes, and probably needs to overflow and be cut off so that the overall paragraph frame stays fixed.

5. A description to narrate what is going on. The interactive illustration of the Casual axis on recursive.design does this in a nice way:

Also, as I noted in #117, I think easing the animation of the size changes is important, to slow down around key 'dramatic moments' in the axis, such as the min, default and max, and any substitution break points that may occur.

I talked with @davelab6 yesterday, and the Google engineering team has requested that custom axes be defined with a 0 to 1 range. They will provide final confirmation of that in the next few days hopefully.

Since the period isn't viable to have in the instance name, we will need to redefine the instances for the goofy axis with the following values: G00, G05, and G10. It's not 100% ideal in my opinion, but nothing about the truncated instance names is.

Based on the discussion in issue #175, I think we should also define the default in the Goofy axis as 1.

Please check this across the Family (that is, on each master)

--- Rationale ---

This check enforces adherence to recommended whitespace (codepoints 0020 and
00A0) glyph names according to the Adobe Glyph List.

Currently, FontBakery flags this problem for the family:

 >> com.google.fonts/check/description/max_length
    DESCRIPTION.en_us.html must have less than 1000 bytes.
    with /Users/stephennixon/type-repos/google-font-repos/fonts/ofl/fraunces/Fraunces[SOFT,WONK,opsz,wght].ttf

    * FAIL: DESCRIPTION.en_us.html must have size smaller than 1000 bytes. [code: too-long]

Unless @davelab6 has given written permission for this family to exceed that, can you please provide a shorter description, @sponcey or @flaviazim? Or, please point to a place where Dave / someone at GF has granted an exception, and I will point to that in the PR.

Thank you!

Hi,
I noticed your lovely font has a few problems related to alternative vertical caron.
First of all, kerning is missing for lcaron, dcaron and tcaron followed by letters with ascender (loďka, paľko, puťka) or some symbols – ď! ľ) ť? to name a few. This is a problem only in darker weights.
Letter tcaron has misplaced accent, it should be much closer to the stem, above the horizontal bar, not next to it. This way you can also avoid kerning pairs.
Please check The Insects Project book http://theinsectsproject.eu/ for more information about vertical caron.
Thanks,
Filip

Hello! I’ve been trying to compile the static files by running the build.sh script on Ubuntu 20.04 through WSL2 but I’ve had no success. I tried installing the dependencies as they came up in the bash log but I can’t seem to properly install the gftools package even though I have pip, brew and its dependencies up-to-date.

Is there a possibility you guys upload the prebuilt static files to the repository?

The Fontbakery tests were run per each Subfamily, e.g. Fraunces9ptS100.
This Fail is present on each subfamily tested although values may differ. Please check each report to see the detailed info.

--- Rationale ---

Dave C Lemon (Adobe Type Team) recommends setting the underline thickness to be
consistent across the family.

If thicknesses are not family consistent, words set on the same line which have
different styles look strange.

See also:
https://twitter.com/typenerd1/status/690361887926697986

Forgive me for maybe not using the right terminology here. I'm just some guy. :)

I've got Fraunces installed and I'm playing with it in Sketch. When I change the character spacing to anything but 0, everything seems to react normally except the "th" in "the", which pops out a bunch of extra space. Seems to happen across the fixed fonts. Quick screencast: https://cozy.es/7qq91v

I'm currently having this problem with just the italic. Will make a build of the Roman and see if a similar problem occurs.

Multiple browsers are having problems recognizing the default for the Optical Min. In Chrome, the Weight axis appears to take on the mapping values that are only intended for the opsz axis.

In Safari, when the OpSz is at min (9) it reverts to the Optical Max instead of the optical min. Very strange.

While testing Variable Font support in my software, I tried Fraunces and it seems that the Italic font has different information than I expected.

Please see below image of the fonts open in FontForge:

The italic font does not seem to have a preferred family name, and the Family entry is Fraunces instead of "Fraunces 144pt S100 Black Italic", which would be the same structure as the Regular font.

In my case I use the preferred Family name to group the different fonts into one entry eg. "Fraunces", and then map the entries back to their actual the font Family name, which doesn't work with the current structure.

To test, I checked Arial and Arial Black which seem to have the same preferred name but unique Family names.

Apologies if this has been logged somewhere, I couldn't find an issue.
Please close this issue if intentional/not a real bug.

Screenshots

Environment

• OS: Windows 10 v1709

Google Fonts currently creates static fonts by instantiating all possible axis combinations from a VF. For Fraunces, this means we'll have around 1729 static fonts.

I see you've included a static fonts directory, would you prefer us to use these style combinations instead for the downloadable static fonts? We may still end up deriving the static fonts from the VF but we can limit the amount of generated static fonts based on what's in this dir.

Another option is to highlight the rows in the linked spreadsheet