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 {
private final ImageInputStream in;
public OpenTypeDataInputStream(ImageInputStream in) {
this.in = in;
}
public final int readUnsignedShort() throws IOException {
[...]
}
public final Tag readTag() throws IOException {
[...]
}
}
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.
> > If you only need the metrics, parsing the glyf or CFF table would be
> > really unnecessary. So maybe a TableFilter interface would be useful.
> > Like this:
> >
> > public class OpenTypeFileInputStream {
> >
> > private TableFilter tableFilter = TableFilter.NO_FILTERING;
> >
> > public OpenTypeFileInputStream(OpenTypeDataInputStream in) {}
> >
> > public void setTableFilter(TableFilter tableFilter) {}
> > }
> >
> > public interface TableFilter {
> >
> > public static final TableFilter NO_FILTERING = new TableFilter() {
> > public doReadTable(Tag tableTag) { return true; }
> > }
> >
> > boolean doReadTable(Tag tableTag);
> > }
> >
> > A client which isn't aware of TableFilter would not notice any burden
> > using the API. And the implementation in OpenTypeFileInputStream isn't
> > so difficult.
>
> This is an interesting idea. But how would you combine filters?
> I’d suggest to keep it aside for the moment, and implement it if we are
> actually running into performance issues. After all, if some caching is
> done, the font should be parsed only once.
The idea of TableFilter is borrowed from java.io.FileFilter. If you look
at org.apache.commons.io.filefilter.AndFileFilter and so on, you get an
Idea how one could combine such filters.
Sure we had to implement some sort of dependencies between tables, if we
want to save the user from surprises.
> 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. So if I should vote,
it would properly vote for spring.
> >> - 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?
Best Regards
Alex
signature.asc
Description: This is a digitally signed message part
