> Ah yes, so this formula comes from the statement in 7.10.7 (BTW, in
> case
> of mixed writing modes / reference-orientations this statement is wrong;

I don't think so. FOs like block-container create a viewport/reference
pair. The viewport-area does the rotation, the reference-area is already
in the same rotation as its immediate children.

Well, again I may be wrong, but: in section 4.2.3 we have the following:
"the content-rectangle of an area uses the inline-progression-direction
and block-progression-direction of that area; but the border-rectangle,
padding-rectangle, and allocation-rectangle use the directions of its
parent area. Thus the edges designated for the content-rectangle may not
correspond to the same-named edges on the padding-, border-, and

So if we want to put, say, some Japanese in an English text, the main
flow would be in lr-tb writing-mode, and we would put an
fo:block-container with a tb-rl writing-mode. The block-container would
generate a viewport-reference pair of areas with the following mapping:

   border-rectangle, padding-rectangle, allocation-rectangle
        before-edge    top
        after-edge     bottom
        start-edge     left
        end-edge       right
        before-edge    right
        after-edge     left
        start-edge     top
        end-edge       bottom

Note that in section 4.2.2, it is stated that "the start-edge and
end-edge of the content-rectangle of [the reference-area] are parallel
to the start-edge and end-edge of the content-rectangle of [the

If we set a start-indent for the fo:block-container, this would be the
space between the left-edge (start-edge) of the flow's content-rectangle
and the left-edge (after-edge) of the block-container's


> I thought they introduced the allocation-rectangle just for dealing with
> that).
> But then, the formula of 4.4.1 may be (greatly) simplified:
>     xa = start-intrusion-adjustment
> If it is so complicated, is it because the formula (J1) may not always
> be true?

I don't think it's that complicated. The spec just tries to explain the
relationships of the various properties and traits. I don't think all of
these statements are meant to be used as literal formulas. I think we
rarely, if at all, have to deal with the space-start trait, for example.
Right now, we shift in by start-indent and out again by padding-start
and border-start. That's all that's necessary to paint everything. Of

Of course, but independantly of how this is actually implemented, I'd
like to make sure I understand the formulae rightly.

> Well, I think I get it now. It's frustrating to spend so much time
> in
> just trying to understand a spec...

Imagine how I felt in the first half of 2005 while getting up to speed
with the mean details of the spec. It's just normal you feel that way.
If you look in the archives, you'll see that you're not alone. A feeble
consolation, I know.

Yes, but still one. This seems to confirm that the problem relies in the
spec, not in my brain ;-)

> Thank you, Jeremias.
> Vincent
> PS: There seems to be a problem, then, with the third paragraph of the
> attached fo file. IIUC it should be placed 1 cm right from the black
> border. And if I remove the start-indent="0" attribute from the fo:block
> it should be placed 2 cm right. WDYT?

Yes, that's what's happening and what should be happening. I don't see
the problem, sorry.

Well, with my working copy I get the following results:
When start-indent is explicitly set to "0cm" for the third paragraph,
the text is placed 1 cm /left/ from the black border:

When start-indent is unset, the text is placed 2 cm left from the black

Same result with Fop 0.92beta. My working copy is up-to-date with the
repository and contains no local modification. I wonder where is the
problem. May I ask which results do others get?


Reply via email to