I attempted to build the code on my home system (Windows 7, latest
java release 1.6.0_22) and I got the same thing. After some
investigation it turns our this is a known bug with maven (google
"maven enum bug"). It might be worth putting the semi-colon in there
to prevent anyone else facing this issue since it makes little
difference either way.

Thanks

Mehdi

On 14 November 2010 09:17, mehdi houshmand <med1...@gmail.com> wrote:
> 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
>>
>>
>

Reply via email to