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 >> >> >
