--- Comment #4 from Mehdi Houshmand <> 2011-08-03 08:40:41 UTC 
Hi Simon,
I guess it's best to address each of these, individually:

>The title suggests that the patch cleans up something; it does not; it
>implements a redesign.

Well, I guess so, the reason I call it clean up is because previously there was
a lot of duplicated code, magic numbers, poorly named variables... all the big
names. I started it with the intention of not changing the working code, but as
I got into it, it seemed that there the old code was iterating over the whole
of the subset glyph list several times... A job that could have been made
simpler through recursion. I didn't redesign it, because if I were to do so, I
would have changed FontFileReader by removing the write method, and remapping
the glyphs when the glyph data is extracted from "glyf". (see the TODO)

>Without knowing much detail about Glyf tables, I was a bit surprised about the
>method names GlyfFlags.offsetToNextComposedGlyf(int flags)...

Ok, for this you have to read the TTF spec. But, the flags represent the
properties and parameters of the composed glyph and, depending on which flags
are set, the number of bytes until the next glyph data.. That method returns
the offset to the next composed by reading which flags are set, and which
aren't. Since none of the glyph parameters are changed, we just want the offset
to the next composed glyph.

> GlyfFlags.moreComposites(int flags)

This analyses the flags, checks whether the current data is the last glyph in
the "glyf" data we are reading. It is simply used to control the do-while loop.

Hope that helps, the glyf table spec can be found at:

I think this change more is more consistent with the spec, since composite
glyphs can be recursive, it seemed prudent to me to clean-up/redesign the code
to match that.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to