[font] Consider reducing public API

[benoitkugler]

The font package currently exposes several types and methods only meant to be used internally by the harfbuzz shaper. Since we very closely follow the C++ implementation, we may introduce breaking changes every time we port new changes (see #225 for some examples).

The font package has this structure because it seemed better to have a separation of concerns between Harfbuzz logic and font metrics access, but it appears now that this separation is not worth holding to.

As hinted by @andydotxyz (in #225 (review)), we should consider hiding away the internal methods.

Here are the types and methods to look for :

• type AATStateTable
• func (f *Face) FontHExtents() (FontExtents, bool)
• func (f *Face) FontVExtents() (FontExtents, bool)
• func (f *Face) GlyphVOrigin(glyph GID) (x, y int32, found bool)
• func (f *Face) HorizontalAdvance(gid GID) float32
• func (f *Face) VerticalAdvance(gid GID) float32
• func (f *Font) GetGlyphContourPoint(glyph GID, pointIndex uint16) (x, y int32, ok bool)
• func (f *Font) GlyphHOrigin(GID) (x, y int32, found bool)
• func (f *Font) GlyphName(glyph GID) string
• func (f *Font) HasVerticalMetrics() bool
• func (f *Font) VariationGlyph(ch, varSelector rune) (GID, bool)
• type GPOS
• type GPOSLookup
• type GSUB
• type GSUBLookup
• type Kern0
• type Kern1
• type Kern2
• type Kern3
• type Kern4
• type Kern6
• type KernSubtable
• type Kernx
• type Layout
• type LookupOptions
• type Morx
• type MorxChain
• type MorxContextualSubtable
• type MorxInsertionSubtable
• type MorxLigatureSubtable
• type MorxNonContextualSubtable
• type MorxRearrangementSubtable
• type MorxSubtable
• type SimpleKerns
• type UnicodeVariations ¶

One solution could be to move them to unexported symbols in the harfbuzz package. What do you think ?

(cc @andydotxyz @whereswaldon)

[andydotxyz]

A smaller (simpler?) change might be to move that to an "internal" parent package - but I'm not certain how much of each package is the public-but-shouldn't-be.

I do worry that mixing it into the harfbuzz package directly could make it harder to maintain?

[benoitkugler]

A smaller (simpler?) change might be to move that to an "internal" parent package - but I'm not certain how much of each package is the public-but-shouldn't-be.

I do worry that mixing it into the harfbuzz package directly could make it harder to maintain?

Fair enough. We could (I think) move the content of the font package to internal/font and then re-export only the types and methods we want via type aliases and type Font internal.Font definitions (with method forwarding).

[benoitkugler]

Hum... I've tried implementing the above proposal, moving font to internal/font (imported as ifont in the following code), and defining in package font the following types :

type Font ifont.Font
type Face ifont.Face

This works well, except it still introduces a breaking change because the (embedded) field Face.Font has type ifont.Font instead of font.Font

An idea that we might consider : define

type Font = ifont.Font // note the alias here
type Face ifont.Face

and actually move all internal methods from Font to Face. I think it is possible since Face embeds a Font and harfbuzz deals with Faces anyways; the tradeoff will be that we loose a bit of concerns separation.

(Note that keeping two distincts types (Font and Face) is still important, to enable memory reuse : a Font is a read-only view which is concurrency safe and may be shared among multiple Faces objects.)

[whereswaldon]

I'm okay with your idea if you'd like to pursue it.