Glyphslib

Latest version: v6.10.1

Safety actively analyzes 710445 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 12 of 16

5.0.0

The first Python 3.6+ only release.

Fix a bug where applying instance data overwrote the OS/2 width class with the default value when there was no `wdth` axis, e.g. in a condensed subfamily with just a `wght` axis.

4.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's `userData` instead of as a custom parameter. The previous handling was error-prone.

4.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.

4.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](https://glyphsapp.com/tutorials/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).

4.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 <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 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).

4.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).

Page 12 of 16

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.