I was building from the command line, using "ant package" and
referencing I've got the same version as you... Curious... Though I
completely agree with your comments on TTFSubSetFile, it needs a
little sprucing.
> 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
>
>
