Victor Mote wrote:
Jeremias Maerki wrote:
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
I think my approach could work in this
On 11.01.2003 18:35:37 Victor Mote wrote:
> Keiron Liddle wrote:
>
> > If I understand it correctly we could have:
> > - multiple output targets for one rendering run
> > - targets with the same font metrics can layout to a common area tree
> > - targets with similar or substitute metrics could f
On 13.01.2003 19:18:18 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Can we sketch that on the Wiki in some simple way? Defining some Java
> > interfaces and things like that? Anyway, as you mentioned we should sort
> > out things like "Session" and "Document" on another page first.
>
> OK,
Jeremias Maerki wrote:
> Can we sketch that on the Wiki in some simple way? Defining some Java
> interfaces and things like that? Anyway, as you mentioned we should sort
> out things like "Session" and "Document" on another page first.
OK, I just put a proposal out there in the section discussing
Victor Mote wrote:
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
Apart from this is the fact that our processing model for any rend
Keiron Liddle wrote:
> If I understand it correctly we could have:
> - multiple output targets for one rendering run
> - targets with the same font metrics can layout to a common area tree
> - targets with similar or substitute metrics could force layout
> to one area tree
> - other targets can ha
Hi Keiron
> If I understand it correctly we could have:
> - multiple output targets for one rendering run
> - targets with the same font metrics can layout to a common area tree
> - targets with similar or substitute metrics could force layout to one area tree
> - other targets can have different
> > > properly discuss things like Session, Document, Rendering run, FOP
> > > instances etc. Where to cache what? What objects/services hold/provide
> >
> > In my mind Document and Rendering run (as defined in the glossary) are
> > probably the same thing (??). I added something called Rendering
Hi Victor
On 09.01.2003 19:09:17 Victor Mote wrote:
> Let me say up front that I am going to follow your lead here.
I'm not taking the lead. We'll work together on this. I see that you
have some ideas yourself, so let's see what we can come up with together.
As far as I can see from your commen
Jeremias Maerki wrote:
> A Wiki is probably easier to work with in this case. CVS update, edit,
> CVS commit, Website update is a lot of work. I'll start a Wiki page and
> add my thoughts to it. We can always transfer the contents back to XML
> later.
Good. I don't think I knew what a wiki was wh
I've added my current thoughts to a Wiki page for those interested in
this discussion:
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign
You're all welcome to participate.
Jeremias Maerki
-
To unsubscribe, e-
Hi Victor
Good that you spoke up, so we can discuss this.
On 08.01.2003 19:31:35 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > TextInfo looks better but could IMO be merged with FontState which only
> > hold the font name and size and a link to the FontMetrics. Anyway, I
> > think this merge
12 matches
Mail list logo
