Hi Mehdi

On 12.11.2010 16:32:45 mehdi houshmand wrote:
> Hi Jeremias,
> 
> This code fails the build, you need to add a ";" (a semi-colon) to the
> last parameter in the enumerated type in
> o.a.f.fonts.truetype.TTFSubSetFile.

I don't see that. Eclipse/ECJ is happy with it and the Sun JDK 1.5.0_22
also doesn't have a problem when running the Ant build. Checking the JLS
3.0, the semicolon is optional if there's no body content after the
entries. An example from the JLS:

public class Example1 {

  public enum Season { WINTER, SPRING, SUMMER, FALL }

  public static void main(String[] args) {
    for (Season s : Season.values()) System.out.println(s);
  }
}

What environment are you working with?

> I was also curious why you made
> TTFSubSetFile.GlyphHandler? Why do you make it an interface, and why
> do you use an anonymous class in PSFontUtils, only to pass it back to
> the same class? If there's only one implementation and if it only
> contains a single method, I wouldn't have thought an interface was
> necessary.

It's a normal callback interface from PSFontUtils back into
TTFSubSetFile, called for each glyph when building the subset.

> TTFSubSetFile already contains various methods that perform
> similar functions (i.e. take an input, convert it to the necessary
> format and write to file), why couldn't this be implemented in the
> handleGlyphSubset(...) method?

My main problem with the way TTFSubSetFile is currently written is that
writing the records is mixed with building the table index. If that were
not so, it would have been easier to go with an approach that you would
have expected. But my approach actually has the advantage that there's
less memory build-up, since not the whole subset including glyphs has to
be buffered in memory. After all, TTF loading is known to take a LOT of
memory.

> Is there another implementation you're
> making this flexible for?

No. The context: my client (your employer) asked for urgent help to
resolve the problem with my first attempt at TTF subsets when printed on
HP printers. I needed a quick resolution after I found out what could be
wrong. I didn't know if I would turn out to be right until after I
committed the changes and Chris/Vincent could run tests. So I didn't
care about too much code beauty. There's actually quite a bit of
copy/paste/change in TTFSubSetFile as a result which I'm not
particularly proud of. I'm still waiting for feedback if my change
really fixed the problem although preliminary results show that the
problem is now solved. I expect that some refactoring would do
TTFSubSetFile some good.

> Also, from a design point, why have you made each glyph a single
> string?

That was no design decision. It's a requirement found in the PS langref
third edition, page 356, describing the contents of /GlyphDirectory.
Each glyph is looked up by its index when an array is used.

> Surely if the string must finish at a glyph boundary, then we
> could pack in several glyphs into the string and make it intelligent
> enough not to write partial glyphs?

That would be useful if we were to keep putting the glyphs in the /sfnts
entry, but not with /GlyphDirectory.

> Will this method have any performance benefits/disadvantages?

The GlyphDirectory allows to keep memory consumption down in the JavaVM.
Otherwise, I see no implications.

> The spec says 65535 is the array limit, will this be hit?

I think that's unlikely. We will hardly have any font with more than
65535 glyphs and no single glyph is likely to be larger than 64KB to
describe its outline. We might still run into problems with the /sfnts
entry, though. If we can improve TTFSubSetFile it should be much easier
to stop strings at record boundaries.

<snip/>

Jeremias Maerki

Reply via email to