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 <[email protected]> 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 <[email protected]> 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 >>> >>> >> >
