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 whitespa
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 line
Possibly (I haven't studied fo:float at this
time)--but we were speaking about a very specific
case, there may be many others that cause fo:blocks to
be split into multiple areas.
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Not that I'm a specialist in this area, but won't
> fo:float also cau
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 f
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 - downlo
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 cal
--- 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 see
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 indiv
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
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 obliged
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
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
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 va
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
> >
>
> Tha
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 enoug
--- 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
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.
J
Hi Glen and other devs,
I'm responding to an earlier message where you said:
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 block).
18 matches
Mail list logo
