Hi,
The NIST test suite has no example of an fo:block within an fo:inline
element. Neither does the XSL spec have an example. Apparently the
construction is not very popular.
I have read through the XSL spec, sections 4.4. Block Areas, 4.5. Line
Areas, 4.6. Inline Areas, and especially 4.7.2.
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
[Me:]
which is then supposed to be rendered as two very
large letters 'A' and 'B' with, for example, a story
in very small letters in between.
snip /
The layout you describe can be achieved using an
Simon Pepping wrote:
Indeed. Something like ICLM is needed, which creates an inline area
containing the block areas.
A block inside another block
fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block
creates 3 different paragraphs:
- Normal text
- inner block
- normal text.
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Hi,
A block inside an inline inside a block
snip /
creates:
a) 3 different paragraphs too:
snip /
b) a single paragraph with all the text:
snip /
I'd say a), but I'm not sure.
My very first thought was a) too, but
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
Just noticed a slight error...
Maybe something like this makes it clearer:
fo:block font-size=40pt
A
fo:inline font-size=6pt
fo:block
The smaller font-size should be added as a property to the inner
On Fri, Nov 19, 2004 at 08:14:35PM +0100, Andreas L. Delmelle wrote:
-Original Message-
Hi,
My very first thought was a) too, but then again, I'm still wondering what
the intention is of allowing this sort of block-inline-block nesting in the
first place.
I'm unsure what the
On Fri, Nov 19, 2004 at 06:22:35PM +0100, Luca Furini wrote:
A block inside another block
fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block
creates 3 different paragraphs:
- Normal text
- inner block
- normal text.
and each paragraph's layout is unrelated to the
On Wed, Nov 17, 2004 at 10:03:54PM +0100, Andreas L. Delmelle wrote:
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
That would definitely solve the second case, but still leaves the first.
Hmm.. On second thought, that would ultimately depend
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
Hi Simon,
...Sorry for the inconvenience in the mean time.
You must be joking! Inconvenience? Far from it. The remarks/additions so far
have been very helpful. Nobody --ahem, certainly not me-- expects you to
solve
On Wed, Nov 17, 2004 at 02:25:02PM +0100, Luca Furini wrote:
Simon Pepping wrote:
Marker extends FObjMixed, which adds InlineStackingLM. This is a
problem. In the new model there should be a strict separation between
LMs implementing InlineLevelLM and those that do not. InlineStackingLM
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Simon Pepping wrote:
Hi Luca / Simon,
Marker extends FObjMixed, which adds InlineStackingLM.
snip /
I still have to really understand InlineStackingLM, I find it very
enigmatic! It generates inline areas, but it has
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
That would definitely solve the second case, but still leaves the first.
Hmm.. On second thought, that would ultimately depend on:
- the parent of fo:retrieve-marker
- the child of fo:marker
if
fo:inline
--- Additional Comments From [EMAIL PROTECTED] 2004-11-15 22:53 ---
...but this leads to yet another CCE, this time in
RetrieveMarkerLM.getNextKnuthElements() line 82
I figured that the InlineLevelLM methods would only be invoked if
replaceLM is an InlineLevelLM, and otherwise
13 matches
Mail list logo
