From: J.Pietschmann [EMAIL PROTECTED]
Chris Bowditch wrote:
I'm not sure where Layout Contexts should be instantiated. Any thoughts?
The are created in the getNextBreak stuff.
Yes they are created in getNextBreak and passed down to getNextBreak of
child LMs, but they are not passed to the calls
From: Glen Mazza [EMAIL PROTECTED]
Yes, that it what I did. Thanks for your
suggestion--space-before seems to work well now.
Great-one step closer to a working layout in head.
Chris
_
Express yourself with cool emoticons -
Not that I'm a specialist in this area, but won't fo:float also cause an
fo:block to be split into multiple areas even if the block itself
doesn't span multiple pages?
On 11.11.2003 01:30:18 Peter B. West wrote:
I've always assumed that the one or more areas are a logical consequence
of the
As I read it, no more than normal. If a block contains text, the
individual glyph areas will, conceptually, be assembled into line-areas.
There is no FO corresponding to a line-area. Where side-floats are
introduced, intrusion adjustment occurs, which may affect the placement
of text in
Peter B. West wrote:
Recall that the contents of fo:block are defined as
(#PCDATA|%inline;|%block;)*
and that there are some interesting complications in the contents of
inline; which, frankly, I still don't understand in spite of
clarifications from the editors.
One complication is whitespace
From: Glen Mazza [EMAIL PROTECTED]
That *could* be a solution--I added toString() methods
in the LayoutContext to help track the state of values
in that class.
Glen
Thanks to Glen and Joerg for replying to this. Setting FIRST/LAST flags on
LayoutContext in the layoutMgr.addArea code isnt enough
I'm still analyzing the problem at this time.
--- Chris Bowditch [EMAIL PROTECTED] wrote:
From: Glen Mazza [EMAIL PROTECTED]
That *could* be a solution--I added toString()
methods
in the LayoutContext to help track the state of
values
in that class.
Glen
Thanks to Glen and Joerg
Chris Bowditch wrote:
I'm not sure where Layout Contexts should be instantiated. Any thoughts?
The are created in the getNextBreak stuff.
I'm sure conditional spaces as well as keeps and proper line breaking
will need enhancements, in particular an object holding the cond-space
state across the
Question, Joerg, we implement fo:block as multiple
Area.Blocks in those cases where an fo:block would
consume more than one page (or, more precisely, its
assigned region on the page). One Area.Block for each
page the fo:block consumes.
I am assuming this is just an implementation
convenience for
Glen Mazza wrote:
I am assuming this is just an implementation
convenience for us--just to confirm, the spec does
allow for an fo:block to consume more than one page,
correct? I wasn't able to find otherwise.
Well, the spec always has this phrase one or more areas.
It doesn't really explicitely
I've always assumed that the one or more areas are a logical consequence
of the fact that generating FOs may overflow a page. The area tree
describes laid-out areas to be rendered on some medium, and every area
which describes a mark on a page must have a region in its ancestry, we
are
Thank you both for the clarifications.
--- Peter B. West [EMAIL PROTECTED] wrote:
The area tree
describes laid-out areas to be rendered on some
medium, and every area
which describes a mark on a page must have a region
in its ancestry, we
are obliged to consider individual FOs
Glen Mazza wrote:
Thank you both for the clarifications.
--- Peter B. West [EMAIL PROTECTED] wrote:
The area tree
describes laid-out areas to be rendered on some
medium, and
as
every area
which describes a mark on a page must have a region
in its ancestry, we
are obliged to consider
--- Chris Bowditch [EMAIL PROTECTED] wrote:
One possible workaround is for Layout Managers to
record this state
themselves. Not sure if thats acceptable though as
it means greater memory
consumption.
Chris
Yes, that it what I did. Thanks for your
suggestion--space-before seems to
--- Chris Bowditch [EMAIL PROTECTED] wrote:
Is the LayoutContext
object supposed to be the
mechanism for checking such state? Currently
LayoutContexts in the parent
FlowLayoutManager are created with flags=0. Do you
think it should be
setting FIRST, LAST, etc?
That *could* be a
Hi Glen and other devs,
I'm responding to an earlier message where you said:
quote
Another issue I was working on last weekend--still
unsolved--was that in 1.0 layout, fo:block
space-before is being added to the top of *each* page
that the block consumes (instead of just once at the
top of the
Chris Bowditch wrote:
The BlockLayoutManager.addAreas seems to be responsible for adding space
before/after. Currently there is no check to see whether or not this is
the first/last call to addAreas. Is the LayoutContext object supposed to
be the mechanism for checking such state?
I think so.
17 matches
Mail list logo
