googlefonts / decovar Goto Github PK

Is there a VF with the draw versions of IOW and A?

Decovar is not hinted and due to the nature and functionality of the design, and to avoid degradation of transmission, presentation and performance, it is not recommended to add any hinting.

Per comments on https://news.ycombinator.com/item?id=13619509 I suggest making the red label also grab-able and drag-able :)

terminals
E,F,G,L,S,T,V,W,Z

If I try out this font in the browser, which CSS font-variation-settings does it support?

https://github.com/TypeNetwork/fb-Decovar/blob/master/sources/2-build/Decovar.designspace
exists but doesn't appear referenced in any build script (https://github.com/TypeNetwork/fb-Decovar/search?utf8=%E2%9C%93&q=Decovar.designspace&type=)

(Whereas in Amstelvar it is in
https://github.com/TypeNetwork/fb-Amstelvar/blob/a879f3fbcc93826609e0d2bda6a90f0df0748cce/scripts/build.sh#L1)

Possible duplicate of #23? I'm getting a traceback when trying to build with the latest FontTools / FontMake:

INFO:fontmake.font_project:Building interpolation-compatible TTFs
INFO:fontmake.font_project:Converting curves compatibly
Traceback (most recent call last):
  File "./build.py", line 7, in <module>
    project.run_from_designspace(designspace_path, output=["ttf-interpolatable", "variable"])
  File "/Users/michiel/Code/FontMake/Lib/fontmake/font_project.py", line 438, in run_from_designspace
    interpolate_layout_from=interpolate_layout_from, **kwargs)
  File "/Users/michiel/Code/FontMake/Lib/fontmake/font_project.py", line 492, in run_from_ufos
    ufos, reverse_direction, conversion_error, **kwargs)
  File "/Users/michiel/Code/FontMake/Lib/fontmake/font_project.py", line 198, in build_interpolatable_ttfs
    conversion_error=conversion_error)
  File "/Users/michiel/Code/FontTools/Lib/fontTools/misc/loggingTools.py", line 372, in wrapper
    return func(*args, **kwds)
  File "/Users/michiel/Code/FontMake/Lib/fontmake/font_project.py", line 153, in convert_curves
    reverse_direction=reverse_direction, dump_stats=True)
  File "/Users/michiel/Code/Cu2qu/Lib/cu2qu/ufo.py", line 254, in fonts_to_quadratic
    glyphs, cur_max_errors, reverse_direction, stats)
  File "/Users/michiel/Code/Cu2qu/Lib/cu2qu/ufo.py", line 156, in _glyphs_to_quadratic
    raise IncompatibleGlyphsError(*glyphs)
cu2qu.ufo.IncompatibleGlyphsError: 'Allparts'

Should I switch to another branch?

The 'fvar' table doesn't define any named instances, and (corresponding) there are no axis value tables within the STAT table. That makes the font not functional in older applications, even on a platform that can otherwise provide support variable font named instances in older apps transparently.

I believe the width of some letters was changed In the last update. See uppercase letter V in terminal B and G. Aren't they supposed to stay the same across masters?

"V" in Decovar-Regular24.ufo = 1280
"V" in Decovar-Regular24TermB.ufo = 1436.0
"V" in Decovar-Regular24TermG.ufo = 1426.0
... (the rest are all equal to default 1280)

When I install Decovar on my mac (OSX Sierra), Font Book lists all the instances with the same name. TextEdit only shows one instance.

Font Book:

The Decovar font defines axes in the 'fvar' table using these axis tags:

bldA
bldB
sklA
sklB
sklD
trmA
trmB
trmC
trmD
trmE
trmF
trmG
trmK
trmL
wmx2

This doesn't conform to the OT spec requirements for custom axis tags:

"Privately-defined axis tags must begin with an uppercase letter (0x41 to 0x5A), and must use only uppercase letters or digits."

See here for full details on axis tags requirements:
https://www.microsoft.com/typography/otspec/fvar.htm

In https://news.ycombinator.com/item?id=13634775 webmaven says,

it would be nice if the URL reflected the skeleton/terminal combination currently on the screen (and it was bookmark-able)

The enclosed ufo includes three characters A, I and O, that are animate to draw themselves in a generally accepted order.

So, A,I and O appear to have disappeared in the enclosed, which will be the -1, as the fully drawn glyph will be 1.

Each glyph has a different number of layers, representing the number of intermediates required to draw each glyph.

I, has none, it's a single stroke that draws from top to bottom, and as such it will serve as our control character for time, with the other glyphs on the axis being defined relative to I. We'll get to that after the first prototype.

A has three layers/intermediates, one for each stroke being drawn, and O has 8-9 to approximate the drawing of a curved shape.

Please make a new axis (DRAW), and see if we can put these together.

Let me know, thanks.
Decovar-Regular24Draw1redo.ufo.zip

Blend A - Inline (stem)
Blend B - splits stem and terminals

Skeleton A -
Skeleton B - Flowered stem
Skeleton D past 50% is useless

Terminal A - Terminal Round
Terminal B - Serif Latin (triangle)
Terminal C - Serif Round top
Terminal D - Terminal slant (needs a limit)
Terminal E - Terminal Split (breaks
Terminal F - Terminal and mid cross (not sure this adds any value)
Terminal G - Serif Slab
Terminal K - Terminal and mid cross (not sure this adds any value)

Numbers not using most of the axes

Per @dberlow's comment on google/fonts#656 (comment) please generate a new build with the family name Decovar Alpha and filename DecovarAlpha-VF.ttf and then tag a release on https://github.com/TypeNetwork/fb-Decovar/releases

The STAT and fvar tables disagree on what axes are in the font.

>>> [a.axisTag for a in t['fvar'].axes]
['BLDA', 'TRMD', 'TRMC', 'SKLD', 'TRML', 'SKLA', 'TRMF', 'TRMK', 'BLDB', 'WMX2', 'TRMB', 'TRMA', 'SKLB', 'TRMG', 'TRME']
>>> [a.AxisTag for a in t['STAT'].table.DesignAxisRecord.Axis]
['INLN', 'SINL', 'SSTR', 'SWRM', 'TBIF', 'TFLR', 'TINL', 'TOIL', 'TRND', 'TRSB', 'TSHR', 'TSLB', 'TWRM', 'WORM', 'wght']

It seems like the blended axes Worm and Inline are changing vertical alignment when displayed in FontView.

Don’t think this is an issue in the sources. Not sure if this is a fontTools or fontView issue, but this is a reminder for me to investigate further.

If anyone has any thoughts feel free to share...