[ft] Using SVG Font Glyph Data In FreeType

Hi,

I am working on a project that uses an SVG file containing custom font 
data. All the data for working with the fonts are present in the SVG 
file, and I have been scouring the freetype documentation for ways to 
work with this data directly in FreeType.

All the examples I can find access a font (such as TTF) and extract the 
glyps directly from it; Im looking for a way where I can tell SVG the 
glyph data I want to use, and how to then make freetype render it to a 
bitmap so I can put it on screen.

An example of the SVG is here:

<glyph unicode="a"
horiz-adv-x="444"
d="M11,0L111,0L144,184L300,184L333,0L433,0L286,722L170,722L11,0M222,616L224,616L286,268L159,268L222,616 
Z" />
<glyph unicode="b"
horiz-adv-x="389"
d="M37,0L194,0C340,0,360,50,360,206C360,329,344,356,264,371L264,373C332,382,355,405,355,547C355,679,334,722,211,722L37,722L37,0M137,334L202,334C257,334,266,318,266,209C266,95,256,78,199,78L137,78L137,334M137,644L184,644C248,644,261,624,261,542C261,424,255,412,195,412L137,412L137,644 
Z" />
<glyph unicode="e" horiz-adv-x="315"
etc.

If anyone can point me in the right direction to a tutorial, or 
something explaining how to manually add glyph data without having to 
pull from a TTF, I would be very grateful. Thanks.

Kind Regards,

[ft] Decomposing complicated glyphs

Hi all,
I've got some TTF data that I'm trying to extract the outlines of
(Technically they're symbols, not glyphs, but that's not really
important).
To do this, I'm using FT_Outline_Decompose, which I have successfully
used in other cases.  However, with this (non-trivial) data, I'm a
bit stumped about how to best proceed.

In this case, the glyphs/symbols are composed of an arbitrary number
of outer polygons, each of which contains an arbitrary number of
islands.
When I call FT_Outline_Decompose(), it triggers a whole sequence
of calls to my moveTo/lineTo callbacks, but it is unclear to me how
I'm supposed to know/distinguish between a 'move' to start an
island verses a 'move' to start a new outer boundary.
[ And, I am going to need this information in order to get the
polygons/holes filled correctly, re: winding/even-odd rules, etc ]

Obviously, if I was rasterizing the glyph, this wouldn't be a
problem.  However, I need the vector outlines in this case...

Am I required to collect up the points and analyze them to try and
resolve the ambiguity myself?  Or does FT guarantee to pass them
to me in some sort of controlled order?  Or is there some other
info lurking somewhere that I haven't seen?

Many thanks for any info/pointers/etc!
Ian

Re: [ft] Using SVG Font Glyph Data In FreeType

On Apr 1, 2010, at 7:03 AM, Andy Kellett wrote:

> Hi,
> 
> I am working on a project that uses an SVG file containing custom font data. All the data for working with the
fonts are present in the SVG file, and I have been scouring the freetype documentation for ways to work with
this data directly in FreeType.
> 
> All the examples I can find access a font (such as TTF) and extract the glyps directly from it; Im looking for
a way where I can tell SVG the glyph data I want to use, and how to then make freetype render it to a bitmap so I
can put it on screen.
> 
> An example of the SVG is here:
> 
> <glyph unicode="a" horiz-adv-x="444"
>
d="M11,0L111,0L144,184L300,184L333,0L433,0L286,722L170,722L11,0M222,616L224,616L286,268L159,268L222,616
Z" />
> <glyph unicode="b" horiz-adv-x="389"
>
d="M37,0L194,0C340,0,360,50,360,206C360,329,344,356,264,371L264,373C332,382,355,405,355,547C355,679,334,722,211,722L37,722L37,0M137,334L202,334C257,334,266,318,266,209C266,95,256,78,199,78L137,78L137,334M137,644L184,644C248,644,261,624,261,542C261,424,255,412,195,412L137,412L137,644
Z" />
> <glyph unicode="e" horiz-adv-x="315"
> etc.
> 
> If anyone can point me in the right direction to a tutorial, or something explaining how to manually add
glyph data without having to pull from a TTF, I would be very grateful. Thanks.

It's not quite clear what you're looking for. Are you just trying to use an existing SVG font, or do you want to

[ft] Porting Freetype to Go

Hello.

I'm porting the Freetype library to the Go programming language
(http://golang.org/). This is a pure Go implementation, not a Go
wrapper around the C library. Amongst other things, Go is a safer
programming language: it has pointers but no pointer arithmetic, it is
garbage collected, variables are zero-initialized, and array accesses
are bounds-checked.

The port is very much a work in progress, but I've just made my first check-in.
http://code.google.com/p/freetype-go/

cheers,
Nigel.

[ft] Using SVG Font Glyph Data In FreeType

Hi Andy,

I looked into this last week while filing bug reports about the SVG Font 
support in various libraries/applications. (It is quite disappointing that 
most SVG rendering libraries process SVG fonts by treating the glyphs as if 
they were just regular paths --- but I digress.)

My conclusion was that it should be possible by using FreeType's outline 
processing functions. See 
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-
outline_processing.htm

Polemically yours, Freddie.

Re: [ft] Porting Freetype to Go

Nigel Tao wrote:
> Hello.
> 
> I'm porting the Freetype library to the Go programming language
> (http://golang.org/). This is a pure Go implementation, not a Go
> wrapper around the C library. Amongst other things, Go is a safer
> programming language: it has pointers but no pointer arithmetic, it is
> garbage collected, variables are zero-initialized, and array accesses
> are bounds-checked.
>

Sounds really slow.  

> The port is very much a work in progress, but I've just made my first check-in.
> http://code.google.com/p/freetype-go/
> 
> 
> cheers,
> Nigel.
> 
> 
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/freetype
> 

Re: [ft] Porting Freetype to Go

On Apr 1, 2010, at 4:19 PM, Nigel Tao wrote:

> Hello.
> 
> I'm porting the Freetype library to the Go programming language

Very interesting! I hope you'll post some progress reports here.

Good luck!

Tom

文林 Wenlin Institute, Inc.        Software for Learning Chinese
E-mail: wenlin <at> wenlin.com     Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯

Re: [ft] Decomposing complicated glyphs

> In this case, the glyphs/symbols are composed of an arbitrary number
> of outer polygons, each of which contains an arbitrary number of
> islands.  When I call FT_Outline_Decompose(), it triggers a whole
> sequence of calls to my moveTo/lineTo callbacks, but it is unclear
> to me how I'm supposed to know/distinguish between a 'move' to start
> an island verses a 'move' to start a new outer boundary.  [ And, I
> am going to need this information in order to get the polygons/holes
> filled correctly, re: winding/even-odd rules, etc ]

The contours stored within a TrueType font don't contain a flag which
indicates the orientation.

> Am I required to collect up the points and analyze them to try and
> resolve the ambiguity myself?

I think so.  It's rather easy to find out the direction of a contour –
I assume you know how to do that efficiently.

> Or does FT guarantee to pass them to me in some sort of controlled
> order?

No.  It simply walks over the contours sequentially.


    Werner

_______________________________________________
Freetype mailing list

Re: [ft] Modifying/Enhancing the Truetype Interpreter

Sorry for the late response.

> Another thing I'm struggling with is how to detect whether points
> have been touched in the non-freedom vector direction during
> deltaps.  Do you have any insights into this, Werner?

Can you elaborate?  What do you want to achieve?

> Also, I'm still having a hard time understanding the whole 1/16
> pixel in the x direction.

What's do you mean with a `whole 1/16 pixel'?

> Perhaps doing this helps with the stem-snapping?

I don't understand the question right now...

    Werner

Re: [ft] Decomposing complicated glyphs

Werner LEMBERG wrote:
> The contours stored within a TrueType font don't contain a flag which
> indicates the orientation.
> 
>> Am I required to collect up the points and analyze them to try and
>> resolve the ambiguity myself?
> 
> I think so.  It's rather easy to find out the direction of a contour –
> I assume you know how to do that efficiently.

Ya, I can do that, if that's the criteria.

So, can you confirm then that outer boundaries are always stored in
one direction, and islands/holes are stored in the other?
[ I'm not familiar with the TT file format.  I could experiment, but
I'd rather not base my final solution just on observations... ]

Many thanks for the info!
Ian