Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[font, opentype/*] Reorganize and clean up font packages #116

Closed
benoitkugler opened this issue Nov 28, 2023 · 1 comment · Fixed by #130
Closed

[font, opentype/*] Reorganize and clean up font packages #116

benoitkugler opened this issue Nov 28, 2023 · 1 comment · Fixed by #130

Comments

@benoitkugler
Copy link
Contributor

benoitkugler commented Nov 28, 2023

We currently have several packages dealing with font loading, namely font, opentype/api, opentype/api/font, opentype/api/metadata. This is mainly an historical consequence of the fact that go-text used to depend on an external package to support parsing Opentype fonts.

I would like to tidy things up and remove what I think is now an unnecessary API complication. While at it, we could also handle #113. To do so I propose to :

  • merge opentype/api/metadata into opentype/api/font, and add the metadata to the Font struct
  • also merge opentype/api into opentype/api/font : a shared opentype/api is only necessary if we want to support multiple font formats, but we settled on only supporting Opentype.
  • finally merge opentype/api/font into font. font would become the real entry point of our Opentype implementation
  • as cleanup, move the remaing opentype/{loader, tables} packages to font/{loader, tables}

The changes would essentially be API modifications/renaming, but would be backward incompatible. One of the more subtle change user would have to account for is that the font.{Font, Face} types would become struct types, not pointer anymore (they are currently defined as alias to *opentype/font.{Font, Face}), requiring to add * everywhere they use it.

It seems to me that this is still a good time to do such changes, before we enter a more stable phase. As suggested in #99, we could perhaps tag a version before this change (say 0.1.0) and right after (say 0.2.0).

What do you all think ?

@whereswaldon
Copy link
Member

This is a welcome simplification. I see no reason not to do it. I'm open to tagging versions before/after as well.

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 a pull request may close this issue.

2 participants