Oh and could you also update the build.xml to use Java 5, it won't
build with 1.4 since enums weren't a part of the Java 4 spec.

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