v4.0.0

• Changed handling of the width axis when building DesignSpace axes and inferring the masters' user-space (i.e. fvar) locations from the corresponding instances' locations -- the change doesn't apply when explicit Axis Location master custom parameters are used.

  Previously, for glyphsLib 3.x (except briefly for 3.3.0, immediately reverted in 3.3.1), locations along width axis where assumed to always be specified already in user-space locations (since Glyphs.app's default for width is 100, which matches the registered wdth axis default value); thus the minimum, default and maximum values for width axis were stored as is in the DesignSpace (and in the fvar table generated from the latter); and no <map> elements for the width axis were generated (unlike we normally do for weight), hence the variable font's avar table would not contain any mappings for wdth.

  This however is not necessarily always true, and it may be that a font designer decided to use internal design coordinates along the width axis which do not exactly match the instances' user-space locations as defined by their OS/2.usWidthClass.
  This creates a problem when comparing a static instance with a variable font (produced from the same source file) that is instantiated at the same nominal width coordinate. E.g. the same CSS font-stretch value applied to both will produce different renderings.

  As of v4.0, glyphsLib will now use the widthClass (percentage) of the instances when inferring the user-space locations of the masters and when mapping these to the internal design coordinates along the width axis, similarly to what already happens for the weight axis. If and when the two sets of coordinates do not match, the axis' minimum, default and maximum will be specified in user-space coordinates and the axis will contain elements which will be used to build an avar table, ensuring that the user-specified locations are normalized to the correct internal coordinates.

  NOTE: if explicit Axis Location master custom parameters are used to define each masters' user-space location, then the latter are not inferred from the instances, thus the above change does not apply.

• Added support for public.skipExportGlyphs for storing export flags (#525).

v4.0.0a1

• Changed handling of the width axis when building DesignSpace axes and inferring the masters' user-space (i.e. fvar) locations from the corresponding instances' locations -- the change doesn't apply when explicit Axis Location master custom parameters are used.

  Previously, for glyphsLib 3.x (except briefly for 3.3.0, immediately reverted in 3.3.1), locations along width axis where assumed to always be specified already in user-space locations (since Glyphs.app's default for width is 100, which matches the registered wdth axis default value); thus the minimum, default and maximum values for width axis were stored as is in the DesignSpace (and in the fvar table generated from the latter); and no <map> elements for the width axis were generated (unlike we normally do for weight), hence the variable font's avar table would not contain any mappings for wdth.

  This however is not necessarily always true, and it may be that a font designer decided to use internal design coordinates along the width axis which do not exactly match the instances' user-space locations as defined by their OS/2.usWidthClass.
  This creates a problem when comparing a static instance with a variable font (produced from the same source file) that is instantiated at the same nominal width coordinate. E.g. the same CSS font-stretch value applied to both will produce different rendering.

  As of v4.0, glyphsLib will now use the widthClass (percentage) of the instances when inferring the user-space locations of the masters and when mapping these to the internal design coordinates along the width axis, similarly to what already happens for the weight axis. If and when the two sets of coordinates do not match, the axis' minimum, default and maximum will be specified in user-space coordinates and the axis will contain <map> elements which will be used to build an avar table, ensuring that the user-specified locations are normalized to the correct internal coordinates.

  NOTE: if explicit Axis Location master custom parameters are used to define each masters' user-space location, then no inference from the instances is performed, thus the above change does not apply.

• Added support for public.skipExportGlyphs for storing export flags (#525).

v3.3.1

• Reverted PR #451 (released in v3.3.0) after discussion in #483.
  This restores the original behaviour from v3.2.0: that is, only when Axis Location custom parameters are not used (i.e. defining user-space locations for each master) -- and therefore, the instances' locations are considered when building DesignSpace axes --, then for the wdth axis, the user-space (i.e. fvar) coordinates are assumed to be the same as the internal design-space coordinates, and the OS/2 widthClass is not used to map from user-space to internal design locations. Hence there are no <map> elements for width axis in the generated DesignSpace document, and thus the variable font's avar will not contain any mappings for wdth.
  The change will be reintroduced in a way that doesn't break existing workflows relying on the previous assumption.
• Generate brace layer name automatically if the user added a brace layer outside Glyphs and forgot to insert the special glyph lib key storing the original brace layer name as used by Glyphs (#522).
• Support com.schriftgestaltung.Glyphs.ComponentInfo glif lib key, used to preserve which non-default anchor a mark is attached to when automatic alignment is active (can be important in e.g. Vietnamese composites) (#521).

v3.4.0b1

• Generate brace layer name automatically if the user added a brace layer outside Glyphs and forgot to insert the special glyph lib key storing the original brace layer name as used by Glyphs (#522).
• Support public.skipExportGlyphs lib key for storing export flags: the export status is no longer written to the glyph lib key com.schriftgestaltung.Glyphs.Export, but to the UFO and Designspace lib key public.skipExportGlyphs, following the addition of it to the UFO specification.
  Needs ufo2ft 2.8.0-b1 or above to honor (#519).
• Support glyph lib key ComponentInfo. It's used to preserve which non-default anchor a mark is attached to when automatic alignment is active (can be important in e.g. Vietnamese composites) (#521).

v3.3.0

• Opportunistically round coordinates and other values of the form x.0 to int
• Round-trip the filter com.github.googlei18n.ufo2ft.filters. It will show up in the custom attributes of masters, where Glyphs ignores it
• Try harder to derive (sub)category for ligatures
• Make use of the OS/2 width class value when determining where on the width axis a Glyphs master is
• Remove 'build_instances' from __all__; fixes AttributeError when doing 'from glyphsLib import *'

v3.2.0

Updated GlyphInfo*.xml files to state of Glyphs 2.6.

Also refer to the beta notes.

v3.2.0b2

• Master, Custom parameters, "Axis Location": run int() on location to work around a bug in Glyphs.app that sometimes stores the number as a string instead of an int.
• Added CLI option --no-store-editor-state to not store state like the currently opened glyph tabs ("DisplayStrings"), as this easily leads to gratuitous merge conflicts.
• build_masters will now correctly store masters on disk. Before, source layers would overwrite the full master UFOs.
• Support automatic generation of bracket layers. They are extracted into freestanding glyphs in glyphs2ufo and back again in ufo2glyphs. Only the foreground layer is currently preserved!

v3.1.4

UFO2Glyphs: Ensure color tuples consist of integers in Python 2.

v3.1.3

Prevent crash of glyphs2ufo when running script from the same directory as the .glyphs file and not explicitly specifying --output-dir.

v3.1.2

• Customize the ufo2ft's featureWriters by setting a key in the generated designspace <lib>. This is necessary in order to keep the current behavior in light of an upcoming change in the KernFeatureWriter default mode which is planned for the next ufo2ft release (#441).

• parser: no longer accept invalid comma-separated lists of unicode values which are not wrapped within quotes (#436).