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

[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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to