Skip to content

fix(deps): update module github.com/go-opentype/opentype to v0.12.0 - autoclosed - #13

Closed
tannevaled wants to merge 1 commit into
mainfrom
renovate/github.com-go-opentype-opentype-0.x
Closed

fix(deps): update module github.com/go-opentype/opentype to v0.12.0 - autoclosed#13
tannevaled wants to merge 1 commit into
mainfrom
renovate/github.com-go-opentype-opentype-0.x

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/go-opentype/opentype v0.6.0v0.12.0 age confidence

Release Notes

go-opentype/opentype (github.com/go-opentype/opentype)

v0.12.0

Compare Source

v0.11.0

Compare Source

v0.10.0

Compare Source

v0.9.0: — PostScript Type 1, and the dots back on the letters

Compare Source

ParseType1 reads the format a PDF carries as a FontFile: eexec, the private dictionary, /Encoding, /Subrs, /CharStrings, and an interpreter for the Type 1 charstring operators — accent composition, flex, hint replacement and arithmetic included.

Two defects the corpus found:

  • hint replacement called the wrong subroutine, so glyphs using it came out empty;
  • dotsection — a Type 1 hint operator that fonts converted to CFF still carry — was refused as unknown, which took the dot off every i, j, colon and semicolon in such a font.

Measured over 118 863 real PDFs: 14 606 of 14 614 Type 1 programs read and 15 178 of 15 178 bare CFF ones; every glyph that does not draw is one with nothing to draw.

Details in #​30.

v0.8.0: — a bare CFF program, addressed by name

Compare Source

ParseCFF reads a Compact Font Format program with no sfnt container around it — how a PDF carries one as FontFile3/Type1C. Font.GlyphName, Font.GlyphIndexByName and Font.GlyphIndexByCode address a font the way a document does: by name, or by a byte through the program's own built-in encoding.

The 391 names every CFF font shares are checked rather than believed: against this package's own Standard Encoding table, and against 38 real OpenType fonts whose character maps say independently which character each named glyph is — 559 names, all agreeing.

Details in #​29.

v0.7.0: — a font need not carry a character map

Compare Source

A font subset embedded in a PDF as a CIDFontType2 is addressed by glyph number through the document's own map, so the subset that gets embedded routinely leaves its cmap table out. Parse required one, and refused every such font outright — leaving every glyph in it undrawn with nothing to say why.

cmap is no longer required. A font without one parses, reports the new Font.HasCharacterMap() == false, and answers GlyphIndex with ok=false rather than dereferencing a table it has not got. Outlines and metrics by glyph number — everything such a font is for — work unchanged.

Details in #​28.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

@tannevaled tannevaled changed the title fix(deps): update module github.com/go-opentype/opentype to v0.12.0 fix(deps): update module github.com/go-opentype/opentype to v0.12.0 - autoclosed Aug 30, 2026
@tannevaled tannevaled closed this Aug 30, 2026
@tannevaled
tannevaled deleted the renovate/github.com-go-opentype-opentype-0.x branch August 30, 2026 12:30
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.

1 participant