On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote:
From a practical viewpoint it makes sense to wrap the block in an inline
area with the traits and treat the block normally in layout terms but it
still feels uncomfortable. It also introduces a whole lot of other
questions about line
Comments down under...
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: May 7, 2002 4:40 AM
To: [EMAIL PROTECTED]
Subject: RE: [REDESIGN] Line layout manager discussion
On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote:
From a practical viewpoint
Keiron Liddle wrote:
On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote:
I couldn't tell from the SVG source what you prepared the file with. I
would
like to use SVG myself. There is no way I am going to handcode it,
though
(just as with FO).
I actually wrote it by hand.
I tried
By writing renderer code with FOP 0.20.1 I observed :
A basic link
fo:basic-link internal-destination=dest0link wordst/fo:basic-link
arrives 3 times in the PDFrenderer asynchronously, without any connection
between each other.
1. as word link
2. as word words
3. as annotation rectangle
This
Hi All,
What it boils down to seems to be if the inline fo returns the block
area or generates an inline area that contains the block area. If it
generates an inline area then it will set traits on that area (border,
background, link, padding etc.).
If that is the case why is a footnote inline
Interleaved commentary...
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: May 6, 2002 5:21 AM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
Hi All,
What it boils down to seems to be if the inline fo returns the block
area
Arved,
I agree that there is no need to tie the rendering to any particular
model, as long as the results are equivalent. The discussions that span
this list and the Xslfo-proc-devel list testify that there are many
approaches to process of layout. However, if I am reading this
correctly,
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: May 5, 2002 12:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
Arved,
I agree that there is no need to tie the rendering to any particular
model, as long as the results
Arved,
Again, I agree that, in the conceptual area tree described in the spec,
blocks embedded in inline-area generating FOs in the fo tree (e.g.,
fo:inline and fo:basic-link), themselves embedded in a parent fo:block,
do not bubble up to the same level as the parent fo:block. Going back
to
On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote:
I couldn't tell from the SVG source what you prepared the file with. I would
like to use SVG myself. There is no way I am going to handcode it, though
(just as with FO).
I actually wrote it by hand.
I tried using an editor but gave up,
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: May 3, 2002 9:31 AM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
Hi devs,
Be careful with the abbreviations. :-) One small slip of the keys and we'll
all be referred
Arved Sandstrom wrote:
I couldn't tell from the SVG source what you prepared the file with. I would
like to use SVG myself. There is no way I am going to handcode it, though
(just as with FO).
Tell me what you need and i design a diagram description
language and an XSL to transform it into
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: May 2, 2002 11:26 PM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
Karen Lease wrote:
[ SNIP ]
For the record, I disagree with Arved's reading of Line-Building. I read
4.7.2
Hi devs,
I have attached a picture of how I think this process should work (in
principle not necessarily with actual areas or code).
The spec should say something like:
4.7.2
A block level formatting object which contains inline level formatting
objects that will create inline areas will
Hi devs,
I have attached a picture of how I think this process should work (in
principle not necessarily with actual areas or code).
The spec should say something like:
4.7.2
A block level formatting object which contains inline level formatting
objects that will create inline areas will
Keiron,
Keiron Liddle wrote:
I'm almost thinking of going a step further.
Maybe we could add annotations to the spec to clarify these things
with our understanding and then present this information.
Yes indeed. And an index, including especially a concept index.
It seems to me that
Arved,
My apologies. I was just taking the opportunity to think aloud about
aspects of the interaction between inline-areas and block-areas. Trying
to make sense of the various elements of the spec leaves your ears buzzing.
Peter
Arved Sandstrom wrote:
For the record, I disagree with
Peter,
Here's my point of view on where line-breaking (perhaps including
hyphenation) happens.
The end result of layout is a sequence of nested areas. However while
layout is happening, line-breaking logic has to pretend that it's only
working on a flat row of characters and other inline leaf
Arved,
I'm definitely in favor of deciding how we think things are supposed to
be laid out. Of course it would be nice if we were on the same
wavelength with the majority of FO users and implementors... but I'm not
too worried about that.
Besides the stuff we're talking about currently, we need
Hi Keiron,
I think this is a good start. I especially like the illustration which
covers all aspects of the problem.
I have some suggestions for the proposed text (see below).
-Karen
Keiron Liddle wrote:
Hi devs,
I have attached a picture of how I think this process should work (in
Keiron et al.,
Just a quick reaction to this - I'm off to sit next to the footpath
reading the newspapers and drinking tea.
From what I see here you are changing the shape of the tree. The
motivation seems to be to make it explicit that block areas contained
within an inline area must
Comments below.
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: May 3, 2002 10:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
[ SNIP ]
From what I see here you are changing the shape of the tree. The
motivation seems
29, 2002 5:39 PM
To: [EMAIL PROTECTED]
Subject: [REDESIGN] Line layout manager discussion
Keiron Liddle wrote:
So why flatten the inline layout managers?
If we have an example like this:
blockSome text basic-linka paragraph of textblockwith a
block/blockand more text/basic
Comments inline...actually, no, they're not, they are really block-stacking,
but you get the drift. :-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Karen Lease
Sent: May 2, 2002 7:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout
-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: May 2, 2002 6:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
I agree with you (except for the last statment about one line).
I found this statement interesting:
6.6.7. fo:inline
An fo:inline that is a child
Comments inline.
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: May 1, 2002 2:19 AM
To: [EMAIL PROTECTED]
Subject: Re: [REDESIGN] Line layout manager discussion
[ SNIP ]
Look at
basic-linka paragraph of text blockwith a block/block and more
text/basic
Questions:
o A basic-link in PDF means an annotation - an annotation defines a
rectangle. What's the effect, if the annotation text breaks to a new line?
If the basic-link contains more blocks and children?
o Middle Easterner write left-to-right, top-to-bottom. Far Easterners write
from
Comments inline.
-Original Message-
From: J.U. Anderegg [mailto:[EMAIL PROTECTED]]
Sent: May 1, 2002 5:19 PM
To: [EMAIL PROTECTED]
Subject: AW: [REDESIGN] Line layout manager discussion
Questions:
o A basic-link in PDF means an annotation - an annotation defines a
rectangle
Karen,
Some extra topics I have been thinking about:
Determining best break.
(What is the level of keep broken by a hyphenation, is it 0 for
hyphenating and always for not?)
The best break position has an equal or lower keep value and is closer to
the optimum position.
If there are keeps
Keiron Liddle wrote:
Karen,
On 2002.04.29 22:39 Karen Lease wrote:
It's certainly true that mixing blocks in inlines, as the spec says is
allowed, gets very complicated. I remember some discussion of this on
the list a long while ago and I think we actually asked the XSL editors
what
Discussion follows below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Karen Lease
Sent: April 29, 2002 5:39 PM
To: [EMAIL PROTECTED]
Subject: [REDESIGN] Line layout manager discussion
Keiron Liddle wrote:
So why flatten the inline layout
Arved,
Firstly, thanks for taking the trouble to do this. Your diagrams make
your argument beautifully clear, and facilitate discussion for everyone,
even XSL spec novices. Even me, who struggles to follow text-only
arguments. I haven't followed all of the posting yet, but one question
Keiron,
I thought it would be better to start a new thread.
I've continued the discussion below.
Keiron Liddle wrote:
Hi Karen,
Its seems that there are gotcha's no matter what direction we take.
+1 :-)
I will try to present the reasons behind the approach I am taking.
I welcome your
33 matches
Mail list logo
