Hi Vincent, > > I had a look at SeekableStream and I can imagine how the needs resulted > > in the ImageInputStream interface. I haven't decided yet if I should use > > ImageInputStream directly. Maybe someone else can throw it's two cents > > in here. > > 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.
> And another bunch of thoughts and questions:
> - I think priority should be given to having a sound API that can be
> re-used by other projects than FOP, rather than memory optimization.
Agree.
> - is memory consumption that much of a problem anyway? I mean, fonts are
> intrinsically big, complex objects and there’s not much we can do
> about that. Many scripts in the world can’t do without advanced
> features. Making the parsing of some tables optional doesn’t look to
> me like the right way to optimise things. That would unnecessarily
> complicate the code.
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.
> - instead of seekable streams, what about a filter that would re-order
> the font stream, caching whatever is necessary before re-sending it to
> the consumer object?
I don't want to do this. In the OpenType GPOS and GSUB tables you have
maybe 5 levels of nested structures with headers and offsets. It gets
really complex there.
> - what about giving the font library a “playground” directory by
> inversion of control, that it can use to cache things? And if no
> directory is given it would use the memory. Maybe a common interface
> could be used for that, targeting either the hard drive or the memory.
Sure. By the way - is there any IoC container used in FOP? I did not see
one so far. How is the bootstrapping done? This could be important for a
central FontSource or such thing.
> - 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 about looking at how fontconfig [1] (a font configuration library
> for Linux systems) does things? I know it makes use of a cache to
> speed up things. Maybe there are good ideas to borrow from there.
>
> [1] http://www.fontconfig.org/wiki/
I don't see speed a a problem as long as we parse every font only once.
Parsing the OpenType font "Old Standard Regular" and converting it into
a CustomFont is currently about 100 ms.
Best Regards
Alex
--
e-mail: alexanderk...@gmx.net
web: www.alexanderkiel.net
signature.asc
Description: This is a digitally signed message part
