freetype-go has moved to github.com/golang/freetype

[Nigel Tao]

The Go port of Freetype has moved from code.google.com/p/freetype-go
to github.com/golang/freetype

I have taken the opportunity of the import path change to make some
breaking API changes. (The original Go code dates from 2010, before
things like the append built-in function existed). I was hoping to
have made all of those changes by the time that Google Code Hosting
became read-only on August 24, but that was not the case. Nonetheless,
in the long term, the code.google.com page should probably redirect to
the github.com page, and since I couldn't flip that switch after GCH
went read-only, the switch was flipped earlier this week.

Unfortunately, this seems to have broken "go get
code.google.com/p/freetype-go/freetype". I thought that GCH would
still serve svn or hg in read-only mode, but I was mistaken.

This has broken projects like github.com/gonum/plot and
github.com/llgcode/draw2d that depended on
code.google.com/p/freetype-go, in that they are now not "go get"table.
Sorry.

I'm happy to answer questions from any such projects about how they
can unbreak their builds. In the short term, they could vendor the old
code.google.com/p/freetype-go code, or they should be able to change
their import paths, possibly also importing some extra packages under
the golang.org/x tree:

import (
"golang.org/x/exp/shiny/font"
"golang.org/x/image/math/fixed"
)

After that, most changes should be mechanical, such as:
- truetype.Font.Kerning becomes truetype.Font.Kern.
- truetype.NoHinting becomes font.HintingNone.
- Some values (like a font scale and an advance width) changes from
int32 to fixed.Int26_6, a common type for sub-pixel measurements. (The
golang.org/x font packages can't depend on
github.com/golang/freetype).
- Similarly, raster.Point becomes fixed.Point26_6.

The golang.org/x/exp/shiny/font package lets programmers use a variety
of font files (such as the Plan 9 font files), not just the truetype
implementation of the freetype project. It might move in the future
out from golang.org/x/exp/..., maybe to golang.org/x/image/..., but
that's where it lives for now.

The long term solution is to favor golang.org/x/exp/shiny/font and its
font.Drawer type over github.com/golang/freetype and its
freetype.Context type (which is deprecated). A font.Drawer can draw
text from a variety of formats, via the font.Face interface, an
implementation of which is a recent addition to the
github.com/golang/freetype/truetype package. One long standing feature
request that was finally implemented is that a font.Drawer can measure
a string without drawing its glyphs. The font.drawer example [0] shows
how to horizontally center the "Jabberwocky" title on the output image
with a truetype.Face. You can compare that to the (deprecated)
freetype.Context example [1], which has similar output, without a
horizontally centered title string.

[0] https://github.com/golang/freetype/blob/master/example/drawer/main.go
[1] https://github.com/golang/freetype/blob/master/example/freetype/main.go

The new packages are not feature-complete, optimized, or API frozen,
by any means. There certainly needs more API to be able to line-break
a paragraph of text. I wasn't intending to talk much about the new API
until it was further along, but the Google Code Hosting read-onliness
made me break "go get", which has prompted me to announce it earlier.

I'm happy to hear your feedback.

[burns...@gmail.com]

Thanks, Nigel.

Are there any plans to make a design doc for the new font package? That may aid discussion.


Ethan

[Fredrik Ehnbom]

Any plans on future gpu-acceleration support, like signed distance fields (http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf) or http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html?

/f

[Laurent Le Goff]

Hi Nigel

First we need to fix that import error and type errors. Next we will use the font.Face interface and Drawer type. I'm happy to see Drawer type and a function to compute string width. 

Do you have a bidirectionnal conversion function/code from fixed.Int26_6 to float64 ? I think I will need it, we use float64 type to represent a point. 

Can you explain briefly what do you mean by a 'dot' please? Does it reference a truetype point unit or an abstract unit.

Thanks Nigel. 

[Nigel Tao]

On Fri, Aug 28, 2015 at 4:53 PM, Nigel Tao <nige...@golang.org> wrote:
> After that, most changes should be mechanical, such as:
> - truetype.Font.Kerning becomes truetype.Font.Kern.
> - truetype.NoHinting becomes font.HintingNone.
> - Some values (like a font scale and an advance width) changes from
> int32 to fixed.Int26_6, a common type for sub-pixel measurements. (The
> golang.org/x font packages can't depend on
> github.com/golang/freetype).
> - Similarly, raster.Point becomes fixed.Point26_6.

I forgot to mention that some scales have changed:

- A fixed.Point26_6 is, as its name suggests, a 26.6 fixed point. The
old raster.Point was 24.8, not 26.6. The rationale for the change is
at https://github.com/golang/go/issues/11906

- The maximum alpha value for a raster.Painter has changed from
1<<32-1 to 1<<16-1, to be consistent with the image/color package in
the standard library.

These are relatively low level concepts, so if you're changing from
the code.google.com version to the github.com version, you probably
won't notice the difference (for example, changing freetype.Pt(10, 10)
to fixed.P(10, 10) will work fine). But there is a difference.

[Nigel Tao]

On Fri, Aug 28, 2015 at 9:13 PM, <burns...@gmail.com> wrote:
> Are there any plans to make a design doc for the new font package? That may aid discussion.

I hadn't planned on writing an extensive design doc. It all makes
sense to me though, obviously. Is there any particular part that isn't
clear?

[Nigel Tao]

On Fri, Aug 28, 2015 at 9:28 PM, Fredrik Ehnbom <quar...@gmail.com> wrote:
> Any plans on future gpu-acceleration support, like signed distance fields
> (http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf)
> or http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html?

I have no plans for using the GPU in the short term. There's more than
enough higher priority work to do first. But perhaps the gxui people
would be interested in exploring that.

[Nigel Tao]

On Fri, Aug 28, 2015 at 6:03 PM, Laurent Le Goff
<legoff....@gmail.com> wrote:
> Do you have a bidirectionnal conversion function/code from fixed.Int26_6 to
> float64 ? I think I will need it, we use float64 type to represent a point.

If i is an int26_6, to convert it to float64:
f := float64(i) / 64

If f is a float64, to convert it to Int26_6:
i := fixed.Int26_6(f * 64)
you may want to adjust for rounding up / down / to nearest, the same
as for converting a float64 to an int.

> Can you explain briefly what do you mean by a 'dot' please?

The dot is the small filled circle on the Baseline, just to the left
of the 'j', in the image at
https://developer.apple.com/library/mac/documentation/TextFonts/Conceptual/CocoaTextArchitecture/Art/glyph_metrics_2x.png

The black / gray circles are the before / after locations of the dot
when drawing the 'j' glyph. The difference between the two is the
advance width, also known as the advancement.

[Nigel Tao]

On Fri, Aug 28, 2015 at 4:53 PM, Nigel Tao <nige...@golang.org> wrote:

> The golang.org/x/exp/shiny/font package lets programmers use a variety
> of font files (such as the Plan 9 font files), not just the truetype
> implementation of the freetype project. It might move in the future
> out from golang.org/x/exp/..., maybe to golang.org/x/image/..., but
> that's where it lives for now.

I filed a proposal to move x/exp/shiny/font to x/image/font:
https://github.com/golang/go/issues/12410

[Laurent Le Goff]

Thanks Nigel,

just last question to be sure I'm undestanding well.

How to convert one int26_6 to one pixel? 

[Fredrik Ehnbom]

Divide it by 64. It uses the lowest 6 bits for fractional precision so you can think of it as shifting the int26_6 number right 6 bits and thus discarding the subpixel precision entirely, or you can convert it to a floating point type and divide it by 64 (= 1<<6) to just convert it.

[Nigel Tao]

On Mon, Aug 31, 2015 at 8:00 PM, Laurent Le Goff
<legoff....@gmail.com> wrote:
> just last question to be sure I'm undestanding well.
> How to convert one int26_6 to one pixel?

I'm not sure if I understand the question. There are 100 centimetres
in 1 metre; to convert, multiply or divide by 100. There are 64
Int26_6's in 1 unit; to convert, multiply or divide by 64.

[Ethan Burns]

I didn't have anything specific in mind, but I also haven't looked in a while.

[Laurent Le Goff]

:-)

thanks for explanation. I mixed in mind poscript point, dot and subpixel precision ^^.

sorry for the confusion.

-- Laurent.

[Nigel Tao]

On Mon, Aug 31, 2015 at 4:32 PM, Nigel Tao <nige...@golang.org> wrote:
> I filed a proposal to move x/exp/shiny/font to x/image/font:
> https://github.com/golang/go/issues/12410

This move has happened.

(Well, a copy, not a move, for now. The x/exp/shiny/font edition is
deprecated and I'll delete it after a grace period.)

[Christoph Schunk]

Hi Nigel, does that mean that the truetype package will also move to image/font (like plan9font) in the future?

Christoph

[Nigel Tao]

On Tue, Sep 1, 2015 at 7:27 PM, Christoph Schunk
<schunk.c...@gmail.com> wrote:
> Hi Nigel, does that mean that the truetype package will also move to
> image/font (like plan9font) in the future?

No plans to move it. The freetype code has a different license than
the standard Go license.