Releases: googlefonts/glyphsLib
v5.0.1
v5.0.0
v4.1.2
- Introduce new "UFO Filename" custom parameter for masters and instances. They inform the filenames of the master (on disk) and instance (in Designspace) UFOs when going from Glyphs to UFO plus Designspace.
- ufo2glyphs: When finding mismatched kerning groups, display reference and current glyphs the right way around
- glyphs2ufo: Make sure that master UFO filenames are unique even when they have a "UFO Filename" parameter set. This prevents a crash when a master is duplicated in Glyphs without changing the custom parameter.
- Any ufo2ft filters stored in master UFOs under
com.github.googlei18n.ufo2ft.filters
will be stored in a master'suserData
instead of as a custom parameter. The previous handling was error-prone.
v4.1.1
Fixed issue when applying "Replace Prefix" custom parameter, and a "Replace Feature" is also present that contains a reference to lookup that is only present in the prefix to be replaced. The "Replace Prefix" custom parameter needs to be applied before the "Replace Feature" one.
v4.1.0
- Added support for
Replace Prefix
custom parameter (#537, #529). - Added support for 'reverse' bracket layers (e.g.
]500]
), for glyphs where not all the master layers have an explicit bracket layer associated with them (see "Switch Only One Master" paragraph in the "Alternating Glyph Shapes" tutorial), and for composite glyphs with bracket layers where components also define bracket layers at the same location (#538). - Added
apply_instance_data_to_ufo
to apply Glyphs instance data to in-memory fonts (#531).
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 thefvar
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'savar
table would not contain any mappings forwdth
.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 CSSfont-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 anavar
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 whenAxis 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 thewdth
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'savar
will not contain any mappings forwdth
.
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 keycom.schriftgestaltung.Glyphs.Export
, but to the UFO and Designspace lib keypublic.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
toint
- 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__
; fixesAttributeError
when doing 'from glyphsLib import *'