designspace-lint 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- designspace_lint-0.1.0/.gitignore +9 -0
- designspace_lint-0.1.0/CHANGELOG.md +38 -0
- designspace_lint-0.1.0/LICENSE +202 -0
- designspace_lint-0.1.0/NOTICE +42 -0
- designspace_lint-0.1.0/PKG-INFO +162 -0
- designspace_lint-0.1.0/README.md +131 -0
- designspace_lint-0.1.0/designspace_lint/__init__.py +138 -0
- designspace_lint-0.1.0/designspace_lint/axis_span.py +112 -0
- designspace_lint-0.1.0/designspace_lint/checkers/__init__.py +34 -0
- designspace_lint-0.1.0/designspace_lint/checkers/axes.py +237 -0
- designspace_lint-0.1.0/designspace_lint/checkers/base.py +357 -0
- designspace_lint-0.1.0/designspace_lint/checkers/features.py +250 -0
- designspace_lint-0.1.0/designspace_lint/checkers/file.py +69 -0
- designspace_lint-0.1.0/designspace_lint/checkers/fontinfo.py +115 -0
- designspace_lint-0.1.0/designspace_lint/checkers/glyphorder.py +294 -0
- designspace_lint-0.1.0/designspace_lint/checkers/glyphs.py +798 -0
- designspace_lint-0.1.0/designspace_lint/checkers/instances.py +238 -0
- designspace_lint-0.1.0/designspace_lint/checkers/kerning.py +292 -0
- designspace_lint-0.1.0/designspace_lint/checkers/rules.py +242 -0
- designspace_lint-0.1.0/designspace_lint/checkers/sources.py +324 -0
- designspace_lint-0.1.0/designspace_lint/cli.py +104 -0
- designspace_lint-0.1.0/designspace_lint/engine.py +498 -0
- designspace_lint-0.1.0/designspace_lint/glyph_order.py +165 -0
- designspace_lint-0.1.0/designspace_lint/loader.py +153 -0
- designspace_lint-0.1.0/designspace_lint/model.py +154 -0
- designspace_lint-0.1.0/designspace_lint/protocols.py +70 -0
- designspace_lint-0.1.0/pyproject.toml +79 -0
- designspace_lint-0.1.0/tests/fakes.py +279 -0
- designspace_lint-0.1.0/tests/test_designspace_axis_span.py +118 -0
- designspace_lint-0.1.0/tests/test_designspace_lint_isolation.py +83 -0
- designspace_lint-0.1.0/tests/test_validator_features_compat.py +98 -0
- designspace_lint-0.1.0/tests/test_validator_glyph_presence.py +233 -0
- designspace_lint-0.1.0/tests/test_validator_glyphorder_rules.py +103 -0
- designspace_lint-0.1.0/tests/test_validator_kerning_groups.py +179 -0
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to this project will be documented in this file.
|
|
4
|
+
|
|
5
|
+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
|
6
|
+
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
|
+
|
|
8
|
+
## [0.1.0] - 2026-09-22
|
|
9
|
+
|
|
10
|
+
First release. The checks were extracted from the font editor
|
|
11
|
+
[font-rover](https://github.com/typedev/font-rover), where they grew out of a
|
|
12
|
+
reimplementation of [designspaceProblems](https://github.com/LettError/DesignspaceProblems)
|
|
13
|
+
by Erik van Blokland — see [NOTICE](NOTICE).
|
|
14
|
+
|
|
15
|
+
### Added
|
|
16
|
+
|
|
17
|
+
- Ten check categories over a designspace and its UFO masters: file, axes,
|
|
18
|
+
sources, instances, glyph compatibility, kerning, font info, rules, features
|
|
19
|
+
and glyph order.
|
|
20
|
+
- `lint()` for callers whose fonts are already open, `lint_path()` for callers
|
|
21
|
+
with a path, `iter_lint()` to stream results, and `Linter` for phase and
|
|
22
|
+
progress control.
|
|
23
|
+
- A CLI: `designspace-lint <path>`, with `-v`, `-q` and `--json`, exiting 1 on
|
|
24
|
+
problems and 2 when the designspace cannot be read.
|
|
25
|
+
- Checks whose rules were verified against fontTools and ufo2ft rather than
|
|
26
|
+
assumed, and whose messages name what the build will do:
|
|
27
|
+
- **4.11** a glyph that does not reach one end of an axis reverts to the
|
|
28
|
+
default master's shape past its last master;
|
|
29
|
+
- **4.12** a glyph left empty next to masters that draw it;
|
|
30
|
+
- **5.0** a master with no kerning, where every pair resolves to 0;
|
|
31
|
+
- **5.8** a glyph in two kerning groups of the same side, whose second group
|
|
32
|
+
ufo2ft discards whole;
|
|
33
|
+
- **8.3** `features.fea` mixed across masters, which silently moves the build
|
|
34
|
+
off the variable-feature path.
|
|
35
|
+
- Layer-based designspaces are handled throughout: masters sharing a UFO are
|
|
36
|
+
identified by path *and* layer, and glyphs are read from the layer a master
|
|
37
|
+
actually draws.
|
|
38
|
+
- Codes 4.0–4.10 keep the meanings designspaceProblems gave them.
|
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
designspace-lint
|
|
2
|
+
Copyright 2024-2026 TypeDev / Alexander Lubovenko
|
|
3
|
+
|
|
4
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
5
|
+
you may not use this file except in compliance with the License.
|
|
6
|
+
You may obtain a copy of the License at
|
|
7
|
+
|
|
8
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
9
|
+
|
|
10
|
+
--------------------------------------------------------------------------
|
|
11
|
+
|
|
12
|
+
This project began as a reimplementation of designspaceProblems by Erik van
|
|
13
|
+
Blokland (LettError), and follows its way of numbering problems by category
|
|
14
|
+
and code. Codes 4.0 through 4.10 -- the glyph compatibility checks -- carry
|
|
15
|
+
the meanings that project gave them. No source code was copied; the checks
|
|
16
|
+
were rewritten, and several of their definitions were changed after being
|
|
17
|
+
measured against fontTools and ufo2ft.
|
|
18
|
+
|
|
19
|
+
designspaceProblems is available at
|
|
20
|
+
https://github.com/LettError/DesignspaceProblems under the MIT license:
|
|
21
|
+
|
|
22
|
+
Copyright (c) 2017-2018 LettError and Erik van Blokland
|
|
23
|
+
All rights reserved.
|
|
24
|
+
|
|
25
|
+
Permission is hereby granted, free of charge, to any person obtaining a
|
|
26
|
+
copy of this software and associated documentation files (the
|
|
27
|
+
"Software"), to deal in the Software without restriction, including
|
|
28
|
+
without limitation the rights to use, copy, modify, merge, publish,
|
|
29
|
+
distribute, sublicense, and/or sell copies of the Software, and to permit
|
|
30
|
+
persons to whom the Software is furnished to do so, subject to the
|
|
31
|
+
following conditions:
|
|
32
|
+
|
|
33
|
+
The above copyright notice and this permission notice shall be included
|
|
34
|
+
in all copies or substantial portions of the Software.
|
|
35
|
+
|
|
36
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
37
|
+
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
38
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
|
|
39
|
+
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
|
|
40
|
+
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
|
|
41
|
+
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
|
|
42
|
+
USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
@@ -0,0 +1,162 @@
|
|
|
1
|
+
Metadata-Version: 2.5
|
|
2
|
+
Name: designspace-lint
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Tell a designspace what it will do when it is built: silent glyph, kerning, feature and glyph-order problems in UFO masters.
|
|
5
|
+
Project-URL: Homepage, https://github.com/typedev/designspace-lint
|
|
6
|
+
Project-URL: Repository, https://github.com/typedev/designspace-lint
|
|
7
|
+
Project-URL: Issues, https://github.com/typedev/designspace-lint/issues
|
|
8
|
+
Author-email: Alexander Lubovenko <alextypedev@gmail.com>
|
|
9
|
+
License-Expression: Apache-2.0
|
|
10
|
+
License-File: LICENSE
|
|
11
|
+
License-File: NOTICE
|
|
12
|
+
Keywords: designspace,fonts,interpolation,lint,typography,ufo,variable-fonts
|
|
13
|
+
Classifier: Development Status :: 4 - Beta
|
|
14
|
+
Classifier: Environment :: Console
|
|
15
|
+
Classifier: Intended Audience :: Developers
|
|
16
|
+
Classifier: Intended Audience :: End Users/Desktop
|
|
17
|
+
Classifier: License :: OSI Approved :: Apache Software License
|
|
18
|
+
Classifier: Programming Language :: Python :: 3
|
|
19
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
20
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
21
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
22
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
23
|
+
Classifier: Topic :: Text Processing :: Fonts
|
|
24
|
+
Requires-Python: >=3.10
|
|
25
|
+
Requires-Dist: fontparts>=0.12.0
|
|
26
|
+
Requires-Dist: fontpens>=0.2.4
|
|
27
|
+
Requires-Dist: fonttools>=4.40.0
|
|
28
|
+
Provides-Extra: features
|
|
29
|
+
Requires-Dist: ufo2ft>=3.0.0; extra == 'features'
|
|
30
|
+
Description-Content-Type: text/markdown
|
|
31
|
+
|
|
32
|
+
# designspace-lint
|
|
33
|
+
|
|
34
|
+
**What a designspace will do when it is built — before you build it.**
|
|
35
|
+
|
|
36
|
+
A designspace can be perfectly valid and still produce a variable font nobody
|
|
37
|
+
intended. A glyph missing from the master at the end of an axis quietly reverts
|
|
38
|
+
to the default's shape past that point. A master with no kerning drags the
|
|
39
|
+
family's kerning toward zero around its location. A `features.fea` that differs
|
|
40
|
+
from the default's pushes the whole build onto another path, where `varLib`
|
|
41
|
+
fails somewhere that has nothing to do with the cause. None of this is an
|
|
42
|
+
error at build time; the font just comes out wrong.
|
|
43
|
+
|
|
44
|
+
This library reports those cases, and each report names the **consequence**,
|
|
45
|
+
not only the discrepancy.
|
|
46
|
+
|
|
47
|
+
```console
|
|
48
|
+
$ designspace-lint Family.designspace
|
|
49
|
+
error 4.11 /eacute Weight 400 of 900: missing at Weight maximum (900); reverts to the default shape past 400
|
|
50
|
+
error 5.0 Bold.ufo (Bold): no kerning: the family's kerning sags to 0 here
|
|
51
|
+
warn 4.2 /acute missing in 12 sources: anchor '_topacute' missing in 12 sources
|
|
52
|
+
3 problem(s), 2 structural
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
Exit code is `0` when clean, `1` when there are problems, `2` when the
|
|
56
|
+
designspace cannot be read — so a build script can gate on it directly.
|
|
57
|
+
|
|
58
|
+
## Install
|
|
59
|
+
|
|
60
|
+
```console
|
|
61
|
+
pip install designspace-lint # the checks and the CLI
|
|
62
|
+
pip install "designspace-lint[features]" # + the features.fea comparison (ufo2ft)
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
## Use it from Python
|
|
66
|
+
|
|
67
|
+
```python
|
|
68
|
+
from designspace_lint import lint_path
|
|
69
|
+
|
|
70
|
+
for problem in lint_path("Family.designspace"):
|
|
71
|
+
print(problem.category, problem.code, problem.description)
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
When the fonts are already open — inside an editor, or a build script that has
|
|
75
|
+
loaded them anyway — hand them over instead of paying to open them twice. Any
|
|
76
|
+
object with `path`, `doc` and `sources` will do, where each source has `font`,
|
|
77
|
+
`path`, `name`, `location`, `layer_name` and the layer accessors described by
|
|
78
|
+
`designspace_lint.protocols.SourceLike`:
|
|
79
|
+
|
|
80
|
+
```python
|
|
81
|
+
from designspace_lint import lint
|
|
82
|
+
|
|
83
|
+
problems = lint(my_designspace) # nothing is re-opened
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## What it checks
|
|
87
|
+
|
|
88
|
+
| Category | What it looks at |
|
|
89
|
+
|---|---|
|
|
90
|
+
| 0 File | the document can be read at all |
|
|
91
|
+
| 1 Geometry | axis minimum/default/maximum, mappings, duplicate names and tags |
|
|
92
|
+
| 2 Sources | locations, missing UFOs, duplicate locations, the default |
|
|
93
|
+
| 3 Instances | instance locations and names |
|
|
94
|
+
| 4 Glyphs | master compatibility: contours, points, curve types, components, anchors, unicodes, contour direction, empty glyphs, and **how far along each axis a glyph actually reaches** |
|
|
95
|
+
| 5 Kerning | kerning groups, masters with no kerning, a glyph in two groups of one side |
|
|
96
|
+
| 6 Font Info | units per em, required fields, values that differ |
|
|
97
|
+
| 7 Rules | designspace rules |
|
|
98
|
+
| 8 Features | whether the masters' `features.fea` keep the build on the variable path |
|
|
99
|
+
| 9 Glyph Order | extra glyphs, and orders that break the per-master merge |
|
|
100
|
+
|
|
101
|
+
The `(category, code)` pairs are a **public contract**. A retired check keeps
|
|
102
|
+
its number, and new checks only ever get new ones.
|
|
103
|
+
|
|
104
|
+
### The rules come from what the tools actually do
|
|
105
|
+
|
|
106
|
+
Every rule here was checked against `fontTools` and `ufo2ft` rather than
|
|
107
|
+
assumed, and several of them contradict what seems reasonable:
|
|
108
|
+
|
|
109
|
+
- A glyph may skip a master **in the middle** of an axis — varLib builds a
|
|
110
|
+
per-glyph model from the masters that have it. Skipping the master at the
|
|
111
|
+
**end** of an axis is the dangerous one: measured on a 0 / 0.5 / 1.0 axis
|
|
112
|
+
carrying 100 / 150 / 300 with the last master missing, 0.75 gives 125 and
|
|
113
|
+
1.0 gives 100 instead of 225 and 300. The font builds without a word.
|
|
114
|
+
- **Differing kerning pair sets are normal** and are not reported: a pair a
|
|
115
|
+
master does not list resolves to its group value or to 0, which is exactly
|
|
116
|
+
what its absence means in a UFO. A master with *no* kerning is reported,
|
|
117
|
+
because then every pair resolves to 0 there.
|
|
118
|
+
- Groups without pairs do not help — verified by building a variable font and
|
|
119
|
+
reading the values back.
|
|
120
|
+
- `ufo2ft` compiles one variable feature file from the default master **only**
|
|
121
|
+
when every other master's `features.fea` matches it or all of them are
|
|
122
|
+
empty. A mix of the two is not compatible either, and falling off that path
|
|
123
|
+
is silent.
|
|
124
|
+
- Sparse masters need no naming convention. Which masters a glyph may skip
|
|
125
|
+
follows from the axes; which sources carry kerning, features and a glyph
|
|
126
|
+
order of their own follows from whether they are layers.
|
|
127
|
+
|
|
128
|
+
## Relation to designspaceProblems
|
|
129
|
+
|
|
130
|
+
This started as a reimplementation of
|
|
131
|
+
[designspaceProblems](https://github.com/LettError/DesignspaceProblems) by
|
|
132
|
+
**Erik van Blokland (LettError)**, MIT-licensed, and it still owes that project
|
|
133
|
+
its shape: the idea of numbering problems by category and code, and most of the
|
|
134
|
+
category-4 glyph compatibility checks, come from there. The numbering is kept
|
|
135
|
+
deliberately compatible — codes 4.0 to 4.10 mean what they mean in
|
|
136
|
+
designspaceProblems — so anyone moving across reads the same numbers.
|
|
137
|
+
|
|
138
|
+
It was rewritten rather than wrapped because of what using it in a font editor
|
|
139
|
+
asked for, and those needs turned out to be structural:
|
|
140
|
+
|
|
141
|
+
- **Results as data, not as a report.** Every problem is a dataclass carrying
|
|
142
|
+
its location, the masters involved and the diagnosis, so a UI can group,
|
|
143
|
+
filter and navigate them. The original returns a mapping of problem to glyph
|
|
144
|
+
names, which is the right shape for a report and the wrong one for a list
|
|
145
|
+
you click through.
|
|
146
|
+
- **No re-opening fonts.** An editor already holds them; the checks take
|
|
147
|
+
whatever satisfies the protocol.
|
|
148
|
+
- **Layer-based designspaces.** Several masters in one UFO, told apart by
|
|
149
|
+
layer, have to be compared on the layer they actually draw.
|
|
150
|
+
- **Progress and cancellation**, because a family with 84 masters takes long
|
|
151
|
+
enough that a person will want to stop it.
|
|
152
|
+
- **Consequences in the message.** The checks grew to say what the build will
|
|
153
|
+
do, which meant verifying each rule against varLib and ufo2ft — and finding
|
|
154
|
+
a few where the reasonable-sounding rule is not the real one.
|
|
155
|
+
|
|
156
|
+
It is not a drop-in replacement: the entry points and the result type differ.
|
|
157
|
+
For the glyph checks the vocabulary is the same.
|
|
158
|
+
|
|
159
|
+
## License
|
|
160
|
+
|
|
161
|
+
Apache-2.0. See [LICENSE](LICENSE), and [NOTICE](NOTICE) for the
|
|
162
|
+
designspaceProblems attribution.
|
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
# designspace-lint
|
|
2
|
+
|
|
3
|
+
**What a designspace will do when it is built — before you build it.**
|
|
4
|
+
|
|
5
|
+
A designspace can be perfectly valid and still produce a variable font nobody
|
|
6
|
+
intended. A glyph missing from the master at the end of an axis quietly reverts
|
|
7
|
+
to the default's shape past that point. A master with no kerning drags the
|
|
8
|
+
family's kerning toward zero around its location. A `features.fea` that differs
|
|
9
|
+
from the default's pushes the whole build onto another path, where `varLib`
|
|
10
|
+
fails somewhere that has nothing to do with the cause. None of this is an
|
|
11
|
+
error at build time; the font just comes out wrong.
|
|
12
|
+
|
|
13
|
+
This library reports those cases, and each report names the **consequence**,
|
|
14
|
+
not only the discrepancy.
|
|
15
|
+
|
|
16
|
+
```console
|
|
17
|
+
$ designspace-lint Family.designspace
|
|
18
|
+
error 4.11 /eacute Weight 400 of 900: missing at Weight maximum (900); reverts to the default shape past 400
|
|
19
|
+
error 5.0 Bold.ufo (Bold): no kerning: the family's kerning sags to 0 here
|
|
20
|
+
warn 4.2 /acute missing in 12 sources: anchor '_topacute' missing in 12 sources
|
|
21
|
+
3 problem(s), 2 structural
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
Exit code is `0` when clean, `1` when there are problems, `2` when the
|
|
25
|
+
designspace cannot be read — so a build script can gate on it directly.
|
|
26
|
+
|
|
27
|
+
## Install
|
|
28
|
+
|
|
29
|
+
```console
|
|
30
|
+
pip install designspace-lint # the checks and the CLI
|
|
31
|
+
pip install "designspace-lint[features]" # + the features.fea comparison (ufo2ft)
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Use it from Python
|
|
35
|
+
|
|
36
|
+
```python
|
|
37
|
+
from designspace_lint import lint_path
|
|
38
|
+
|
|
39
|
+
for problem in lint_path("Family.designspace"):
|
|
40
|
+
print(problem.category, problem.code, problem.description)
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
When the fonts are already open — inside an editor, or a build script that has
|
|
44
|
+
loaded them anyway — hand them over instead of paying to open them twice. Any
|
|
45
|
+
object with `path`, `doc` and `sources` will do, where each source has `font`,
|
|
46
|
+
`path`, `name`, `location`, `layer_name` and the layer accessors described by
|
|
47
|
+
`designspace_lint.protocols.SourceLike`:
|
|
48
|
+
|
|
49
|
+
```python
|
|
50
|
+
from designspace_lint import lint
|
|
51
|
+
|
|
52
|
+
problems = lint(my_designspace) # nothing is re-opened
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## What it checks
|
|
56
|
+
|
|
57
|
+
| Category | What it looks at |
|
|
58
|
+
|---|---|
|
|
59
|
+
| 0 File | the document can be read at all |
|
|
60
|
+
| 1 Geometry | axis minimum/default/maximum, mappings, duplicate names and tags |
|
|
61
|
+
| 2 Sources | locations, missing UFOs, duplicate locations, the default |
|
|
62
|
+
| 3 Instances | instance locations and names |
|
|
63
|
+
| 4 Glyphs | master compatibility: contours, points, curve types, components, anchors, unicodes, contour direction, empty glyphs, and **how far along each axis a glyph actually reaches** |
|
|
64
|
+
| 5 Kerning | kerning groups, masters with no kerning, a glyph in two groups of one side |
|
|
65
|
+
| 6 Font Info | units per em, required fields, values that differ |
|
|
66
|
+
| 7 Rules | designspace rules |
|
|
67
|
+
| 8 Features | whether the masters' `features.fea` keep the build on the variable path |
|
|
68
|
+
| 9 Glyph Order | extra glyphs, and orders that break the per-master merge |
|
|
69
|
+
|
|
70
|
+
The `(category, code)` pairs are a **public contract**. A retired check keeps
|
|
71
|
+
its number, and new checks only ever get new ones.
|
|
72
|
+
|
|
73
|
+
### The rules come from what the tools actually do
|
|
74
|
+
|
|
75
|
+
Every rule here was checked against `fontTools` and `ufo2ft` rather than
|
|
76
|
+
assumed, and several of them contradict what seems reasonable:
|
|
77
|
+
|
|
78
|
+
- A glyph may skip a master **in the middle** of an axis — varLib builds a
|
|
79
|
+
per-glyph model from the masters that have it. Skipping the master at the
|
|
80
|
+
**end** of an axis is the dangerous one: measured on a 0 / 0.5 / 1.0 axis
|
|
81
|
+
carrying 100 / 150 / 300 with the last master missing, 0.75 gives 125 and
|
|
82
|
+
1.0 gives 100 instead of 225 and 300. The font builds without a word.
|
|
83
|
+
- **Differing kerning pair sets are normal** and are not reported: a pair a
|
|
84
|
+
master does not list resolves to its group value or to 0, which is exactly
|
|
85
|
+
what its absence means in a UFO. A master with *no* kerning is reported,
|
|
86
|
+
because then every pair resolves to 0 there.
|
|
87
|
+
- Groups without pairs do not help — verified by building a variable font and
|
|
88
|
+
reading the values back.
|
|
89
|
+
- `ufo2ft` compiles one variable feature file from the default master **only**
|
|
90
|
+
when every other master's `features.fea` matches it or all of them are
|
|
91
|
+
empty. A mix of the two is not compatible either, and falling off that path
|
|
92
|
+
is silent.
|
|
93
|
+
- Sparse masters need no naming convention. Which masters a glyph may skip
|
|
94
|
+
follows from the axes; which sources carry kerning, features and a glyph
|
|
95
|
+
order of their own follows from whether they are layers.
|
|
96
|
+
|
|
97
|
+
## Relation to designspaceProblems
|
|
98
|
+
|
|
99
|
+
This started as a reimplementation of
|
|
100
|
+
[designspaceProblems](https://github.com/LettError/DesignspaceProblems) by
|
|
101
|
+
**Erik van Blokland (LettError)**, MIT-licensed, and it still owes that project
|
|
102
|
+
its shape: the idea of numbering problems by category and code, and most of the
|
|
103
|
+
category-4 glyph compatibility checks, come from there. The numbering is kept
|
|
104
|
+
deliberately compatible — codes 4.0 to 4.10 mean what they mean in
|
|
105
|
+
designspaceProblems — so anyone moving across reads the same numbers.
|
|
106
|
+
|
|
107
|
+
It was rewritten rather than wrapped because of what using it in a font editor
|
|
108
|
+
asked for, and those needs turned out to be structural:
|
|
109
|
+
|
|
110
|
+
- **Results as data, not as a report.** Every problem is a dataclass carrying
|
|
111
|
+
its location, the masters involved and the diagnosis, so a UI can group,
|
|
112
|
+
filter and navigate them. The original returns a mapping of problem to glyph
|
|
113
|
+
names, which is the right shape for a report and the wrong one for a list
|
|
114
|
+
you click through.
|
|
115
|
+
- **No re-opening fonts.** An editor already holds them; the checks take
|
|
116
|
+
whatever satisfies the protocol.
|
|
117
|
+
- **Layer-based designspaces.** Several masters in one UFO, told apart by
|
|
118
|
+
layer, have to be compared on the layer they actually draw.
|
|
119
|
+
- **Progress and cancellation**, because a family with 84 masters takes long
|
|
120
|
+
enough that a person will want to stop it.
|
|
121
|
+
- **Consequences in the message.** The checks grew to say what the build will
|
|
122
|
+
do, which meant verifying each rule against varLib and ufo2ft — and finding
|
|
123
|
+
a few where the reasonable-sounding rule is not the real one.
|
|
124
|
+
|
|
125
|
+
It is not a drop-in replacement: the entry points and the result type differ.
|
|
126
|
+
For the glyph checks the vocabulary is the same.
|
|
127
|
+
|
|
128
|
+
## License
|
|
129
|
+
|
|
130
|
+
Apache-2.0. See [LICENSE](LICENSE), and [NOTICE](NOTICE) for the
|
|
131
|
+
designspaceProblems attribution.
|