You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ?
The text was updated successfully, but these errors were encountered:
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 :
opentype/api/metadata
intoopentype/api/font
, and add the metadata to theFont
structopentype/api
intoopentype/api/font
: a sharedopentype/api
is only necessary if we want to support multiple font formats, but we settled on only supporting Opentype.opentype/api/font
intofont
.font
would become the real entry point of our Opentype implementationopentype/{loader, tables}
packages tofont/{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 ?
The text was updated successfully, but these errors were encountered: