Hi Peter,
Sorry for taking so long, week's been hectic around here.
>. . .
> I think you will still have attribute resolution problems. Remember
> that some attributes are only going to be resolved during the layout.
>
I understand that some attributes cannot be resolved at the parsing stage,
On Tue, 2002-05-28 at 01:20, Peter B. West wrote:
> <
> I started writing this before the flurry of messages in the last day or
> two, so it may now be redundant. If so, however, I have missed part of
> the conversation. My recollection of consensus of opinion some months
> ago was as I state
Bertrand,
<
I started writing this before the flurry of messages in the last day or
two, so it may now be redundant. If so, however, I have missed part of
the conversation. My recollection of consensus of opinion some months
ago was as I state just below.
>
I think you will still have at
On Mon, 2002-05-27 at 14:22, Bertrand Delacretaz wrote:
> What about:
>
> a) base class with all start/end methods but most of them are empty (costs
> very little to call IMHO compared to the whole rendering process)
>
> b) derived class for RTFHandler and such, where most or all methods do
>
On Monday 27 May 2002 13:37, Keiron Liddle wrote:
>. . .
> I'm thinking of the start as setting up the current context and the
> properties, then when others start it will belong to the current
> context. The end can then indicate context and finish off the formatting
> object and if easier then t
On Mon, 2002-05-27 at 11:37, Bertrand Delacretaz wrote:
> Would this scenario be easy to implement?
>
> startTable
> startRow (maybe after all FOs for the row have been parsed)
> startCell (maybe after all FOs for the cell have been parsed)
> start/end stuff for cell contents
> e
Hi Keiron,
>. . .
> We should be able to set common objects like the logging and config on
> the structure handler itself.
> But the context idea could be useful for other objects that it may need
> to access.
>. . .
ok, It wasn't clear for me either what would go into the context object, but
i
Hi Bertrand,
On Fri, 2002-05-24 at 15:25, Bertrand Delacretaz wrote:
> > It will pass appropriate information, mostly the
> > current fo object.
>
> Maybe passing a compound object (StructureRendererContext?) that *contains*
> the current fo object would help, as the renderer might need to acce
Hi Keiron,
>. . .
> This structure handler will have a number of methods for the start and
> end of elements like block, table, list item etc. and others for
> external graphic etc.
>. . .
I agree that high-level events like start/end block, table, etc. are what we
need for structure rendering
Hi,
I have had a look at the structure handling concept in particular with
reference to the rtf renderer.
The idea is to use a structure handler class that is available to the FO
tree and replaces the current position of the StreamRenderer.
This structure handler will have a number of methods f
10 matches
Mail list logo
