Hi Vincent, > I see. I had in mind to use OpenTypeDataInputStream as the common > interface. It actually makes sense to use ImageInputStream instead. > Simpler and just as flexible. That will add a direct dependency on > a class in the javax.imageio package, but this is not a problem as it is > part of the standard library. That ImageInputStream interface is > unfortunately named really.
What did you mean with your last sentence? That ImageInputStream isn't named good? > > So if I should vote, it would properly vote for spring. > > Well I’m not sure I like the abundance of XML in spring actually. POJOs > powaaa! Also, spring may be overkill to just deploy FOP. Anyway, this is > probably a bit early to discuss that. (What do you think of the > following though: http://code.google.com/p/google-guice/ ?) I heard of it before, but didn't inform myself about it. So I took your pointer as motivation to have a look at it. I watched the Google I/O - Big Modular Java with Guice [1] talk on youtube. It looks very promising. I'm not agains this XML config stuff, but if I can get the same with annotations and standard Java code - why not. Of course I like this whole type safety stuff, but with Intellij I get this in Spring XML too. [1]: <http://www.youtube.com/watch?v=hBVJbzAagfs> > >>>> - does the use of serializable objects make sense? What would be more > >>>> efficient: re-parsing font data all the time or re-loading > >>>> serializable object representation of them? > >>> You mean the font metrics XML files? I've alwas asking me for what > >>> propose they are there. No, I don't think, we need this. I really don't > >>> want to serialize the Advanced OpenType Features! It took me already a > >>> good amount of code to parse just a bit of it. > >> What I meant was to use the java.io.Serializable interface. I don’t > >> indeed think XML representations are any useful, apart maybe for > >> debugging purpose or to have a more human-readable version of the font > >> file. > >> IIC there would be next to nothing to do to cache Serializable objects > >> on the hard drive and retrieve them? > > > > Hmmm. Ok. But if we want to use Serializable for that, your classes have > > to be very stable. Versioning the Serializable stuff is a real burden in > > my opinion. So we will need a cache which detects version changes and > > invalidate the objects if so. Do you know such a lib? > > I was thinking that just catching the InvalidClassException when reading > the object would be enough to conclude that the cache is no longer valid > and must be re-created. Maybe I’m wrong? I must confess that I have no > experience with serialization. Yes this could work. But I find it always difficult and time consuming to design classes for serialization. And reading the serialized version is most likely not much faster than reading the actual OpenType file. So I would really want to wait until we have a real performance problem. Best Regards Alex
signature.asc
Description: This is a digitally signed message part
