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).
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 ?