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 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, the proposal is to clarify the text of the spec. In that context, the treatment of the area tree and its relationship to the fo tree must be coherent and consistent, or we will be in even deeper difficulties. Peter Arved Sandstrom wrote: 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 bubble up to become direct children of the containing block area. I can't see that that is feasible, given the basic design principle of the spec that the area tree follows the fo tree. [ SNIP ] With respect to the second sentence of the above, I think we should be very clear at all times about exactly which area tree we are talking about - the conceptual area tree as described in the spec, or the real one constructed by Fop. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-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 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, the proposal is to clarify the text of the spec. In that context, the treatment of the area tree and its relationship to the fo tree must be coherent and consistent, or we will be in even deeper difficulties. Peter My last post was motivated by one thing - the statement that a block area bubbles up. Well, it does not, not in the conceptual area tree described in the XSL spec. As a result I thought it worth our time to ask for some specificity when the area tree being referred to is not immediately obvious. I agree with your sentiments, particularly the last sentence. As such I think it is very important to establish exactly what area tree we are talking about in any given context. In theory there are at least 2 - the XSL 1.0 conceptual area tree, and the real tree (really, whatever structure we happen to use). There could be more. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/docs/xml-docs xml2pdf.xsl
Sorry for the delay - this got stuck in a moderator queue - and I missed it as it had the same size, down to the last byte, as a spam message I got on -all- asf accounts. Dw -- Dirk-Willem van Gulik On 5 May 2002 [EMAIL PROTECTED] wrote: jeremias02/05/05 05:17:42 Modified:docs Tag: fop-0_20_2-maintain xml2pdf.xsl docs/xml-docs Tag: fop-0_20_2-maintain xml2pdf.xsl Log: Changed master-name to master-reference. Revision ChangesPath No revision No revision 1.4.4.1 +1 -1 xml-fop/docs/xml2pdf.xsl Index: xml2pdf.xsl === RCS file: /home/cvs/xml-fop/docs/xml2pdf.xsl,v retrieving revision 1.4 retrieving revision 1.4.4.1 diff -u -r1.4 -r1.4.4.1 --- xml2pdf.xsl 16 Dec 2000 22:48:48 - 1.4 +++ xml2pdf.xsl 5 May 2002 12:17:41 - 1.4.4.1 @@ -21,7 +21,7 @@ /fo:simple-page-master /fo:layout-master-set - fo:page-sequence master-name=simple + fo:page-sequence master-reference=simple fo:static-content flow-name=xsl-region-before fo:block text-align=end font-size=10pt No revision No revision 1.9.2.1 +1 -1 xml-fop/docs/xml-docs/xml2pdf.xsl Index: xml2pdf.xsl === RCS file: /home/cvs/xml-fop/docs/xml-docs/xml2pdf.xsl,v retrieving revision 1.9 retrieving revision 1.9.2.1 diff -u -r1.9 -r1.9.2.1 --- xml2pdf.xsl 20 Aug 2001 16:19:58 - 1.9 +++ xml2pdf.xsl 5 May 2002 12:17:41 - 1.9.2.1 @@ -37,7 +37,7 @@ /fo:simple-page-master /fo:layout-master-set - fo:page-sequence master-name=simple + fo:page-sequence master-reference=simple fo:static-content flow-name=xsl-region-before fo:block text-align=end font-size=10pt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Master reference for fo:page-sequence
Thanks. This is now fixed in CVS (Yeah, my first commit!). The two files were already updated for the redesign but not in the maintenance branch. On 03.05.2002 18:20:06 BuchtÃk, Michal wrote: There are docs/xml2pdf.xsl docs/xml-docs/xml2pdf.xsl in fop-0.20.2-maintain branch with master-name attribute in page-sequence tag. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: Re: Master reference for fo:page-sequence If there are still any examples left in the current distribution would you please point out which? All examples should have been upgraded by now. Are you sure you don't have any old files in your FOP directory? On 03.05.2002 11:05:51 claes.bergsten wrote: Thanks missed that one. Maybe should fix that in the examples provided. Claes Your stylesheet still uses pre-Recommendation XSL:FO. Please see the release notes for instructions to resolve this: http://xml.apache.org/fop/relnotes.html When trying to process my fo-file I get the following error: FATAL ERROR: 'master-reference' for 'fo:page-sequence'matches no 'simple-page-master' or 'page-sequence-master' Cheers, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop STATUS
jeremias02/05/05 08:49:50
Modified:.Tag: fop-0_20_2-maintain STATUS
Log:
Updated committer list.
Revision ChangesPath
No revision
No revision
1.47.2.2 +3 -0 xml-fop/STATUS
Index: STATUS
===
RCS file: /home/cvs/xml-fop/STATUS,v
retrieving revision 1.47.2.1
retrieving revision 1.47.2.2
diff -u -r1.47.2.1 -r1.47.2.2
--- STATUS18 Feb 2002 18:27:36 - 1.47.2.1
+++ STATUS5 May 2002 15:49:50 - 1.47.2.2
@@ -12,10 +12,13 @@
Fotis Jannidis
Karen Lease
Keiron Liddle
+Jeremias Maerki
Jordan Naftolin
+Joerg Pietschmann
Eric Schaeffer
Jon Smirl
Art Welch
+Peter B. West
THINGS WORKED ON *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop STATUS
jeremias02/05/05 08:52:35 Modified:.STATUS Log: Updated committer list. Revision ChangesPath 1.49 +8 -3 xml-fop/STATUS Index: STATUS === RCS file: /home/cvs/xml-fop/STATUS,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- STATUS5 Mar 2002 14:39:45 - 1.48 +++ STATUS5 May 2002 15:52:34 - 1.49 @@ -4,16 +4,21 @@ James Tauber (started it all and wrote most of the code) Kelly Campbell -Steven Coffman +Steven Coffman +Bertrand Delacretaz +Tore Engvig +Christian Geisert Stanislav Gorkhover Fotis Jannidis Karen Lease Keiron Liddle +Jeremias Maerki Jordan Naftolin +Joerg Pietschmann Eric Schaeffer Jon Smirl -Christian Geisert -Bertrand Delacretaz +Art Welch +Peter B. West Initial development of new layout managers, area tree and renderers. Altered xml handling. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Border properties
Hello, I tried to make something out of bug 684. Again, after reading the spec in depth, I'm nearly biting pieces off my keyboard. In the tables.fo examples, the left edge of the table content rectangle is the same as the edge of the reference area, and left border (should I use start edge border?) is tacked on so that it extends outside the reference area. The upper and lower border, however, do not overlap previous or following blocks, as expected. Well 4.4.1 says the start-edge of its allocation-rectangle ... offset from it inward by a distance equal to the block-area's start-indent plus its start-intrusion-adjustment (as defined below) minus its border-start, padding-start, and space-start values... given that the start-indent of the tables are zero (hopefully), the behaviour regarding the border extending left beyond the edge of the refernce area appears to be consistent with the spec, albeit IMO a bit counter-intuitive, because not consistent with what happens in BPD. Now, what is the problem bug 684 complains about? Does it mean the border in BPD should be handled similarly to what happens in IPD? Or does he mean something else? And, of course: is my understanding on how borders/padding should be handled resonable? I feel very confused. BTW what happens if both start-indent and margin-start were defined on the same block area? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8815] New: - Irritating overlapping regions in examples
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815 Irritating overlapping regions in examples Summary: Irritating overlapping regions in examples Product: Fop Version: 0.20.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Many of the examples distributed with FOP define a region-after but don't set corresponding margin-bottom, thereby creating overlapping regions. This could irritate users. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8816] New: - content for xsl-footnote-separator doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8816. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8816 content for xsl-footnote-separator doesn't work Summary: content for xsl-footnote-separator doesn't work Product: Fop Version: 0.20.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Defining static content for the xsl-footnote-separator as specified in 6.10.1.3 doesn't work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug report for Fop [2002/05/05]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 664|Opn|Nor|2001-02-21|Basic-Link does not move with its content, when us| | 684|New|Nor|2001-02-23|border width in tables adds up| | 839|New|Nor|2001-03-05|Positioning of blocks in a block section. | | 902|New|Nor|2001-03-08|line-height is not applied corectly when using the| | 928|New|Nor|2001-03-10|Font metrics and setComponent | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1130|New|Nor|2001-03-27|Alignment of page-number-citation inside a ToC| | 1154|New|Nor|2001-03-29|nested lists more than 3 level depth | | 1171|New|Nor|2001-03-30|small-caps in static content becomes all-caps | | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1261|New|Nor|2001-04-09|problem with rendering of external-graphic in Fop-| | 1318|New|Nor|2001-04-12|problems with tables (column width and when used i| | 1391|New|Blk|2001-04-19|Bug in border-top-style | | 1474|New|Maj|2001-04-24|fo:external-graphic rendered as block level object| | 1531|New|Cri|2001-04-26|Cell Spacing | | 1724|Opn|Nor|2001-05-11|Text alignment in table cells | | 1759|New|Nor|2001-05-15|table-omit-footer-at-break sometimes cause crash | | 1766|New|Maj|2001-05-15|Text matrix in svg get doubled when run thru FOP | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1923|New|Nor|2001-05-28|text-decoration does not work | | 1952|New|Cri|2001-06-01|color attribute to table content overflowing on ne| | 1967|New|Nor|2001-06-02|blank-or-not-blank behavior | | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2106|New|Nor|2001-06-11|broken justification with numeric umlaut entities | | 2107|New|Min|2001-06-11|indentation in em units is larger than the lette| | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2153|New|Cri|2001-06-13|Borders are calculated incorrectly| | 2207|New|Maj|2001-06-18|Embedding problems| | 2279|New|Nor|2001-06-22|block-container property position does not exist| | 2460|New|Cri|2001-07-05|Mulitple boder lines between the colums in a table| | 2463|New|Nor|2001-07-05|No of lines per page in a PDF output file | | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2491|New|Cri|2001-07-06|footnote can't fit remaining space and crash | | 2504|New|Nor|2001-07-08|Some font properties in tables are not preserved a| | 2532|New|Cri|2001-07-10|FOP 0.17 does not work with WebSphere V3.5 OS/390 | | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2867|New|Nor|2001-07-27|external-graphic content-width and content-height | | 2880|New|Maj|2001-07-30|Incorrect rendering on non-ASCII machines | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|New|Nor|2001-08-02|problems with height of cells in tables | | 2987|New|Nor|2001-08-03|Large graphics put FOP 0.19 into an infinite loop | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3007|New|Nor|2001-08-06|broken basic-link when referencing a following pag| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3061|New|Nor|2001-08-09|Link 'click' location doesn't take padding-top int| | 3073|New|Nor|2001-08-10|Whitespace does not scale | | 3116|New|Nor|2001-08-14|0.19.0 Error on IE5 refresh with external graphics| | 3208|New|Nor|2001-08-21|Blocks aligned incorrectly in PDF | | 3215|New|Nor|2001-08-21|fo:leader with a percentage as leader-length does | | 3216|New|Enh|2001-08-21|break-after=page throws a break when page is ful| |
DO NOT REPLY [Bug 1154] - nested lists more than 3 level depth
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1154. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1154 nested lists more than 3 level depth [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Priority||High Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 17:24 --- Nested lists four levels deep appear to work in 0.20.3 A test case would have helped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1261] - problem with rendering of external-graphic in Fop-18
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1261. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1261 problem with rendering of external-graphic in Fop-18 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 17:35 --- The test case works in 0.20.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1318] - problems with tables (column width and when used in the xsl-after-region)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1318. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1318 problems with tables (column width and when used in the xsl-after-region) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 19:28 --- Both problems are fixed in 0.20.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1391] - Bug in border-top-style
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1391. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1391 Bug in border-top-style [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED OS/Version||All Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 19:45 --- Can't reproduce the problem with 0.20.3. A complete testcase would have helped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1474] - fo:external-graphic rendered as block level object
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1474. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1474 fo:external-graphic rendered as block level object [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 19:52 --- Fixed in 0.20.3, even the line height is adjusted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1759] - table-omit-footer-at-break sometimes cause crash
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1759. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1759 table-omit-footer-at-break sometimes cause crash [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED OS/Version||All Priority||High Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-05 20:29 --- No crash nor a warning with 0.20.3. I assume the problem is fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Border properties
Comments intermingled.Default reference orientation and lr-tb writing mode assumed. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 5, 2002 1:34 PM To: fop dev Subject: Border properties Hello, I tried to make something out of bug 684. Again, after reading the spec in depth, I'm nearly biting pieces off my keyboard. In the tables.fo examples, the left edge of the table content rectangle is the same as the edge of the reference area, and left border (should I use start edge border?) is tacked on so that it extends outside the reference area. What it really boils down to is, the start-indent and end-indent are content-rectangle to content-rectangle distances. If the start-indent is zero then borders and padding and space are outside the content rectangle of the reference area. Similarly for end-indent. The upper and lower border, however, do not overlap previous or following blocks, as expected. I would not expect this - see below. At least not with initial values. Well 4.4.1 says the start-edge of its allocation-rectangle ... offset from it inward by a distance equal to the block-area's start-indent plus its start-intrusion-adjustment (as defined below) minus its border-start, padding-start, and space-start values... given that the start-indent of the tables are zero (hopefully), the behaviour regarding the border extending left beyond the edge of the refernce area appears to be consistent with the spec, albeit IMO a bit counter-intuitive, because not consistent with what happens in BPD. The treatment is different; there is no BPD counterpart to start-indent and end-indent. The separation between content-rectangles is determined by padding+border+space (before after). Borders and padding are length-conditional values so unless they are at the leading or trailing edge of a reference area they will definitely have the specified length. None of them are negative. The spaces _can_ be negative so this is the sole mechanism by which areas (including borders padding) can overlap (and space-specifier resolution is involved of course). Now, what is the problem bug 684 complains about? Does it mean the border in BPD should be handled similarly to what happens in IPD? Or does he mean something else? And, of course: is my understanding on how borders/padding should be handled resonable? I feel very confused. Join the club. :-) I constantly remind myself of what the definitions really mean in simple language. I also try to minimize use of allocation rectangles - I understand the concept but find it confusing. BTW what happens if both start-indent and margin-start were defined on the same block area? margin-* properties are absolute only (top, bottom, left, right). In any case, according to 5.3.2 and 5.3.1 the absolute properties take precedence. margin-left if explicitly specified has priority over start-indent. I took a quick look at table.fo (the FO) and I think this will probably help out. I have to admit if there is one area of the spec that I am not particularly familiar with it is tables - in this case I don't think there is any weirdness involved stemming from table border properties. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
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 your diagram, I am talking about the fo:block embedded in the basic-link. I have attached another diagram describing a subset of your original example. Let me clarify what I meant by the term bubble up in the reply to Karen. Then what seems to me to be the *intention* that layout within fo:inline and fo:basic-link proceed as though these wrappers were layout-transparent, would be made clear. That is, blocks bubbling up from below will be stacked in the BPDir without IPDir attachments from surrounding inline-areas. This refers to the spec's conceptual area tree. It arises out of my misapprehension that the nesting of fo:blocks within inline-area generators would involve a nesting of the layout within the generated inline-area. The fo:inline inline-area in the area tree would grow within the bounds of the containing line-area and block area, but limited by it. It doesn't work that way, though, as we have all discussed. These block areas bubble-up, not in terms of their containment within the appropriate set of line-area-inline-area-block-area, bu in terms of their layout consequences. Apart from any layout-altering properties defined on the containing inline-area generator, e.g.font or border changes, the text and any nested blocks are treated for layout as though they had occurred as direct children of the outer fo:block. That's what the term layout-transparent means. That, at least, is what I take the *intention* of the authors to be. And that is why I want to see some clarification of the relationship between 4.7.2 Line-building and 4.7.3 Inline-building. It seems to me that the spec decrees that the initial text of the basic-link (In basic-link in my example) is constructed into an inline-area by the Inline-building process of 4.7.3. In order to do this, it has to know about the constraints that it inherits from the already partially constructed line-area which contains Text in block . It seems to me that, conceptually at least, in the conceptual area tree model of the spec, the inline-building process needs to take account of all of the glyph substitution, insertion and deletion considerations that apply to 4.7.2, because it is now the responsibility of the inline-area generator to generate a *single* inline-area to complete the pending line-area of the parent. To do that, it will have to be able to do its own line-breaking. Clarifying this is a matter of the coherence and consistency of the spec. It is also important if you are tempted, as I am, by the idea of mimicking this conceptual model and procedure in actual code. All of the above may just mean that, while I thought I had been brought around to your way of thinking on this aspect of the spec, I may still be thinking about it very differently. Peter Arved Sandstrom wrote: My last post was motivated by one thing - the statement that a block area bubbles up. Well, it does not, not in the conceptual area tree described in the XSL spec. As a result I thought it worth our time to ask for some specificity when the area tree being referred to is not immediately obvious. I agree with your sentiments, particularly the last sentence. As such I think it is very important to establish exactly what area tree we are talking about in any given context. In theory there are at least 2 - the XSL 1.0 conceptual area tree, and the real tree (really, whatever structure we happen to use). There could be more. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
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, instead I just edit by hand and view it using batik. In this case it was fairly easy since everything is placed in a definite position. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
