Glyphslib

Latest version: v6.7.1

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

Scan your dependencies

Page 10 of 14

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

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

Page 10 of 14

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.