The Freetype font rasterizer in the Go programming language.

With freetype-go, is there a way to compute the text extents (width and height) 
of a string given a particular font and size *before* rendering the text?

I've looked around in the source code, and it *appears* that the right 
information is there, but I can't quite seem to figure out how to do it.

As of right now, if I want an image that "snugly" fits some string, I do the 
following:

Over estimate the extents by multiplying the pixel size of one em unit by the 
length of the string. I get the width/height this way (assuming one line of 
text).

I allocate an image with a rectangle of two points: (0, 0) and (width, height).

After rendering the text to the image using DrawText, I use the point returned 
from DrawText to take a sub-image of the initial image. (I convert this point 
to a (x, y) position by simply dividing the X and Y of the point by 256. It 
seems to work OK, but I have no idea if this is correct.)

--------------

And one last question: would the extents include the entire bounding box of the 
string? The (x,y) position returned by DrawText doesn't seem to cover the parts 
of the text the dip below the text's base line. Like the tail in the 'y'. My 
solution has just been to pad the 'y' with a few pixels, but I know this is not 
optimal since it will break if the font size changes too much.

(My apologies if my terminology is off. I don't have much experience in font 
rendering.)

I would happily submit a patch if I was nudged in the right direction :-)

Thanks!

Original issue reported on code.google.com by [email protected] on 2 Jun 2012 at 10:44

This PR aims to address #10 by adding Name and Style funcs to the public Font API.

Name and Style are retrieved from the first nameRecord that includes both.

The luxisr font is the only test case I added because I don't have the optional fonts referenced in TestIndex.

The tests passed when ran against a handful of those available in ttf-mscorefonts-installer.

The UTF-16 string check on line 346 is a hack. If you know of a better option, I'll happily update it. :)

I have added a postscript table parsing which will be used with the Thai languaged rendering problem which mentions in https://github.com/golang/go/issues/27281#issuecomment-750339814

to be able to achieve these glyph combination rules http://www.bakoma-tex.com/doc/fonts/enc/c90/c90.pdf

we need to be able to get an index of the glyph from the glyph name

References

• https://docs.microsoft.com/en-us/typography/opentype/spec/post
• https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6post.html

package main

import (
    "image"
    "image/png"
    "log"
    "os"

    "github.com/golang/freetype/raster"
    "golang.org/x/image/math/fixed"
)

func main() {
    const (
        w = 400
        h = 400
    )
    var p raster.Path
    p.Start(fixed.P(150, 150))
    p.Add1(fixed.P(200, 250))
    p.Add1(fixed.P(300, 250))

    r := raster.NewRasterizer(w, h)
    r.UseNonZeroWinding = true
    r.AddStroke(p, fixed.I(80), raster.RoundCapper, raster.RoundJoiner)

    rgba := image.NewRGBA(image.Rect(0, 0, w, h))
    painter := raster.NewRGBAPainter(rgba)
    painter.SetColor(image.Black)
    r.Rasterize(painter)

    f, err := os.Create("out.png")
    if err != nil {
        log.Fatalf("cannot create file: %v", err)
    }
    defer f.Close()
    if err := png.Encode(f, rgba); err != nil {
        log.Fatalf("writing png: %v", err)
    }
    if err := f.Close(); err != nil {
        log.Fatalf("closing file: %v", err)
    }
}

When I use this module to print text to an image file, everything seems to work correctly. However, in a special case, I want to underline some characters, I tried to use the Combining / Non-spacing character \u0332 for that, but it just comes out as a separate character. There are quite some combining / non-spacing characters, check: http://www.fileformat.info/info/unicode/category/Mn/list.htm

Here's the result:

(the text on the right should be underlined)

I tried to look into the code to pinpoint the issue, but the code is a little too advanced for me to understand it in a quick look but I'm pretty sure it's in func (g *GlyphBuf) Load(f *Font, scale fixed.Int26_6, i Index, h font.Hinting) error { in truetype/glyph.go, where it calculates the advanceWidth. The font I'm using is DejaVu Sans Mono and DejaVu Sans Mono Bold.

@nigeltao Do you take pull requests? Here's a fix. Let me know if anything else needs to be done.

Some constants were not updated properly when switching from raster.Point to fixed.26_6

Before the fix:

After the fix:

go get github.com/golang/freetype

package golang.org/x/image/math/fixed: unrecognized import path "golang.org/x/im age/math/fixed" package golang.org/x/image/font: unrecognized import path "golang.org/x/image/fo nt"

This adds the ability to set stroke width for font drawing. Drawing a black stroked glyph and then a white normal glyph will give the font a black stroke.

The only problem is that the rasterizer doesn't allow closing paths. If the start and end point are at the same position, the strokes will overlap and appear thicker (alpha channel overlaps). If the start and end points are at an angle, using ButtCapping will reveal that they do not properly connect. The rasterizer must support path closing for this.

Secondly, this should be added to github.com/golang/freetype/freetype.go too?

Freetype-go generates artifacts close to start and end path points,
output differs from Freetype-C.

Font is automatically converted from C to Q by FontForge, no problems detected.
Rearanged canonical start point to leftmost on the contour produces expected 
output.

Original issue reported on code.google.com by [email protected] on 20 Feb 2015 at 9:48

Attachments:

• ftError.ttf
• out.png
• main.go

I have no idea how to submit patches, so forgive me if this is an inappropriate 
venue.

Attached is a patch fixing TTC parsing.
The constant 12 was hardcoded instead of using `offset`.

Tested on a TTC v2.0 file, I don't have a v1.0 file to test on but based on 
what I understand of the file format I don't think there should be any issues 
with that.

Original issue reported on code.google.com by [email protected] on 10 Sep 2014 at 4:30

Attachments:

• freetype-go.patch

I would like to be able to get at the font name(s) stored in the truetype in 
the font file. 

Original issue reported on code.google.com by [email protected] on 29 May 2014 at 12:39

Describe the bug: When using the WorkSans-Black font certain cross-elements are corripted. The font shows gaps instead of a solid character, as per images below

To Reproduce: Steps to reproduce the behaviour:

• Go to google fonts and download WorkSans-Black.ttf
• Any code that rasterises using "image/draw" call to DrawMask passing the parsed font (from truetype.Parse)
• render any label with "t" or "H"

Notice the holes in the output:

The same does not happen when you download the font from https://www.1001fonts.com/work-sans-font.html...

Go 1.17.6 Windows 11 amd64 github.com/golang/freetype v0.0.0-20170609003504-e2365dfdc4a0

I'm trying to use the library to draw some text in transparent background, but it doesn't matter what font I use, it fails to correctly rasterize non-latin characters:

Here is a screenshot of Notepad using the same font:

Some ttf files contain several sub-tables. For example, a ttf file may contain one unicodeEncodingBMPOnly table, one microsoftUCS2Encoding table, and one microsoftUCS4Encoding table. In this case, we choose microsoftUCS4Encoding as the best one. Since there are most valid codes in it.

panic: runtime error: index out of range [104] with length 104

goroutine 319 [running]:
github.com/golang/freetype/truetype.(*GlyphBuf).loadSimple(0x17e9590, 0x1583df0, 0x68, 0x75cb5, 0x1, 0x1583ce6, 0x0, 0x75dbf)
	C:/gowork/pkg/mod/github.com/golang/[email protected]/truetype/glyph.go:331 +0x590
github.com/golang/freetype/truetype.(*GlyphBuf).load(0x17e9590, 0x0, 0x10012, 0x0, 0x0)
	C:/gowork/pkg/mod/github.com/golang/[email protected]/truetype/glyph.go:229 +0x264
github.com/golang/freetype/truetype.(*GlyphBuf).Load(0x17e9590, 0x10d6100, 0x900, 0x12, 0x0, 0x0, 0xd)
	C:/gowork/pkg/mod/github.com/golang/[email protected]/truetype/glyph.go:102 +0x90
github.com/golang/freetype/truetype.(*face).GlyphAdvance(0x17e8000, 0x33, 0x33, 0x0)
	C:/gowork/pkg/mod/github.com/golang/[email protected]/truetype/face.go:345 +0x58
golang.org/x/image/font.MeasureString(0x61f42c, 0x17e8000, 0x1530da0, 0xc, 0x0)
	C:/gowork/pkg/mod/golang.org/x/[email protected]/font/font.go:301 +0x80
golang.org/x/image/font.(*Drawer).MeasureString(...)
	C:/gowork/pkg/mod/golang.org/x/[email protected]/font/font.go:215

With this change, the computation of the scale factor becomes identical across the freetype and truetype packages, removing deviations in the font metrics that are derived from scale.

Apply the same change to the Context.PointToFixed method to keep it in sync.

The rounding computation is newer; it was introduced when the truetype.Face type was added in commit 6deea2414309d03c665a7b.

Fixes #85.

I noticed there's sometimes a tiny discrepancy in font metrics as computed by freetype.Context and truetype.NewFace.

As a reproducible example, using the Go Mono font of size 86.4 exactly, at 72.0 DPI, the advance width for the glyph 'H' differs by 1/64 (the smallest value a fixed.Int26_6 can represent).

See the complete program on the Go Playground. Its output:

advance width of 'H' via truetype: 51:55
advance width of 'H' via freetype: 51:54

I've tracked it down and found the root cause. When computing the scale factor, the float64 → fixed 26.6 conversion is done differently between those two packages. In truetype, it rounds to the nearest 26.6 fixed point value:

scale:      fixed.Int26_6(0.5 + (opts.size() * opts.dpi() * 64 / 72)),

But in freetype, it uses the floor:

c.scale = fixed.Int26_6(c.fontSize * c.dpi * (64.0 / 72.0))

Between those two, it seems taking the nearest value is the better behavior, so I'll send a PR that adjusts freetype to fix this discrepancy. CC @nigeltao.