Hi Alexander,
Alexander Kiel wrote:
> Hi Vincent,
>
>>>> Here are my two cents: if you make use of classes in javax.imagio at
>>>> only one place in your font library, then there’s no need to worry about
>>>> creating a more neutral layer. If OTOH you need to use those classes
>>>> everywhere, then it makes sense to use a simplified abstraction layer.
>>>> That abstraction layer could be shipped as a separate module and evolve
>>>> separately. An implementation could be based on imageIO, Apache Commons
>>>> IO (?), your own implementation based on byte arrays for testing
>>>> purpose, etc.
>>> Thanks for that. I think, I will write a OpenTypeDataInputStream which
>>> is not a FilterInputStream, but takes a ImageInputStream as constructor
>>> argument like a FilterInputStream would take a InputStream. This
>>> OpenTypeDataInputStream will be the API for all the Streams on top of
>>> it. So I would have only one point which depends on ImageInputStream.
>> You may want to use a factory a la SAXParserFactory. Although that may
>> go a bit far.
>
> Hmmm. I don't see the benefit of such a factory here. The
> OpenTypeDataInputStream would look like this:
>
> public class OpenTypeDataInputStream {
snip/>
> }
>
> This is the common FilterInputStream pattern. OpenTypeDataInputStream
> only depends on ImageInputStream which is an interface.
> OpenTypeDataInputStream is really simple and straitforward, so that I
> can't imagine different implementations. Except implementations on top
> of other things as ImageInputStream. But than we are at the question, if
> we want ImageInputStream the common interface for different
> implementations (on top of files, streams, byte arrays) or if we want
> OpenTypeDataInputStream to do that. I think that ImageInputStream is the
> right place, because it abstracts from getting bytes and be able to
> seek. OpenTypeDataInputStream on the other hand implements the semantics
> of the common OpenType data types, which are well defined in the
> specification.
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.
<snip/>
>> There’s no such thing as IoC container in FOP. I’m not sure how easy it
>> would be to introduce one. Although that would probably be A Good Thing.
>> So do design your font library with IoC in mind.
>
> Yes, I will. We can use IoC even without a container. And if we want to
> choose one, I have plenty experience with spring.
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/ ?)
>>>> - 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.
HTH,
Vincent
