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 of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container. It suggests that what you are saying is correct and that block-level elements create a block area outside the immediate line area. So to have a block area inside a line area you must use the inline-container, a block is never automatically embedded. Also in this section, reading between the lines (it's amazing how they manage to contradict themselves in such a short section) 4.7.3. Inline-building An inline fo element with a block element as a child will create inline areas and return the block area. It will create a single inline area that can fit consecutive child inline areas on a single line. So the child inline areas are put into parent inline areas that are separated by line breaks and block areas. So Karen's approach is looking better. I really wish this spec would say relevant things in the right places and mention how everything is handled rather than being so vague. On 2002.05.01 04:00 Arved Sandstrom wrote: 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 managers? If we have an example like this: blockSome text basic-linka paragraph of textblockwith a block/blockand more text/basic-link and inline background=blueblue backgroundinline color=green green text blocka block/block more green/inline/inline/block The basic link produces/returns both inline areas and a block area, so it is not possible to say that the basic-link element or its layout manager would produce inline areas. So how should this be handled. If it is flattened things are easier. The layout manager can then keep range information like: starts link, ends link. I think this FO snippet is sufficiently complex as to be a good Gedankenexperiment. I prepared a PNG which illustrates the area tree as _I_ interpret the spec applying to this FO. You'll have to view the image in colour. I have taken liberties with WS, border colours, spaces, padding etc etc. I threw in one page break to make things interesting. Also, I have shown runs of texts as combined inlines, where we know in fact that they are really containers for a bunch of glyph areas. Here's some of the main principles I am keeping in mind: 1. An area must have its child areas all of the same type (inline or block); 2. No area may have more than one normal block area returned by the same fo:block; 3. No area may have more than one normal inline area returned by the same inline (fo:inline, fo:basic-link); 4. A block generates normal block areas. If a child FO returns a block area this becomes a direct child of one of those block areas. If a child returns a sequence of inline areas, these become children of line areas which are in turn children of a normal block area; 5. An inline generates normal inline areas. Each such may contain a sequence of inline areas or a single block area. Absolutely nobody else is going to agree 100% with my interpretation, but I think if we can hash this out it will allow us to really move forward with confidence. a) There are no block-level children of the top block, only inlines, so we know that the one or more block areas generated by the top-level block are going to contain line areas. Because of the page break there are 2 normal block areas generated by the top-level block; b) some text is simple - the inline goes neatly into the first line area as its first child; c) Now we hit the basic link. This generates one or more normal inlines, which are outlined in orange. The a paragraph of text is the first inline child of the first normal inline area generated by the basic-link; d) we hit the nested block. OK, this is where the anguish starts. :-) It produces at least one normal block area, by definition. I have given this a pale green background. This _cannot_ occupy the first normal inline area generated by the basic-link, because that already contains an inline area (rule 1). So it must be in a second normal inline area generated by the basic-link. By rule 3, the first line area may not contain 2 areas generated by the same inline, so that's why we terminate line aea 1 and start another; e) In the second line area (outlined in dark blue), we have the second normal inline area generated by the basic-link, outlined in orange. This contains a single block area generated by
Re: Czech translation for AWT viewer
Buchtk, Michal wrote: Hi Fops, I translate messages and resources for AWT viewer, can you commit it? It's in ISO-8859-2 coding. Does this work with current maintenance branch (or 0.20.3 final) ? The reason I'm asking is that the enconding of the resources has been changed to utf-8 with fop 0.20.3rc2 (see http://marc.theaimsgroup.com/?l=fop-devm=101217471420036w=2 ) If it's ok I'll commit it. Thanks Michal Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Czech translation for AWT viewer
Hi, i forgot for encoding change. I convert it to UTF-8 a test it with current maintain branch. It works ok. See new attachment. Thanks for notice. Michal -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 11:45 AM To: [EMAIL PROTECTED] Subject: Re: Czech translation for AWT viewer Buchtk, Michal wrote: Hi Fops, I translate messages and resources for AWT viewer, can you commit it? It's in ISO-8859-2 coding. Does this work with current maintenance branch (or 0.20.3 final) ? The reason I'm asking is that the enconding of the resources has been changed to utf-8 with fop 0.20.3rc2 (see http://marc.theaimsgroup.com/?l=fop-devm=101217471420036w=2 ) If it's ok I'll commit it. Thanks Michal Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] AWTczech-utf8.zip Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/viewer/resources messages.cs resources.cs
chrisg 02/05/02 04:01:22 Modified:.Tag: fop-0_20_2-maintain CHANGES Added: src/org/apache/fop/viewer/resources Tag: fop-0_20_2-maintain messages.cs resources.cs Log: Added czech translation for AWT viewer Submitted by: Michal Buchtik [EMAIL PROTECTED] Revision ChangesPath No revision No revision 1.10.2.13 +5 -3 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.12 retrieving revision 1.10.2.13 diff -u -r1.10.2.12 -r1.10.2.13 --- CHANGES 26 Apr 2002 23:19:22 - 1.10.2.12 +++ CHANGES 2 May 2002 11:01:22 - 1.10.2.13 @@ -9,9 +9,11 @@ - Changed build.sh to work under cygwin Submitted by: Andriy Palamarchuk [EMAIL PROTECTED] - Added turkish hyphenation patterns - Submitted by: Togan Muftuoglu [EMAIL PROTECTED] -- Aportuguese hyphenation patterns - Submitted by: Paulo Soares [EMAIL PROTECTED] + Submitted by: Togan Muftuoglu [EMAIL PROTECTED] +- Added portuguese hyphenation patterns + Submitted by: Paulo Soares [EMAIL PROTECTED] +- Added czech translation for AWT viewer + Submitted by: Michal Buchtik [EMAIL PROTECTED] == Done since 0.20.2 release *** General No revision No revision 1.1.2.1 +80 -0 xml-fop/src/org/apache/fop/viewer/resources/Attic/messages.cs 1.1.2.1 +17 -0 xml-fop/src/org/apache/fop/viewer/resources/Attic/resources.cs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Master reference for fo:page-sequence
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' My header looks like this and is copy/pasted from the examples ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-right=0cm margin-left=7mm margin-bottom=0mm margin-top=3mm page-width=8.71cm page-height=54mm master-name=first fo:region-body/fo:region-body /fo:simple-page-master fo:simple-page-master margin-right=0pt margin-left=7mm margin-bottom=0mm margin-top=3mm page-width=87.1mm page-height=54mm master-name=rest fo:region-body/fo:region-body /fo:simple-page-master fo:page-sequence-master master-name=basicPSM fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-name =first page-position=first / fo:conditional-page-master-reference master-name =rest page-position=rest / !-- recommended fallback procedure -- fo:conditional-page-master-reference master-name =rest / /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-name=basicPSM What am I doing wrong? Cheers Claes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Czech translation for AWT viewer
Buchtk, Michal wrote: Hi, i forgot for encoding change. I convert it to UTF-8 a test it with current maintain branch. It works ok. See new attachment. Committed, thanks for your contribution. Thanks for notice. Michal Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Master reference for fo:page-sequence
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 Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Configuration mods to allow embedded apps to change font base path in userconfig
Title: Message
Hi
all,
Sorry in advance if
I'm not doing this right, it's my first official contribution (or attempt
thereof) to FOP!
I ran into issues
where my servlet was getting installed and run from a number of locations,
making the relative paths in fop-userconfig.xml not work, so I made a couple of
minor modifications to make this something the user can
configure.
1. I added
"getBasePath" and "setBasePath" methods to configuration/Configuration.java,
both in a static context
2. I updated
configuration/FontInfo.java to call these methods when returning font
paths
I also made a couple
of other mods that seemed to make sense.
3. I changed
Configuration.java to use a singleton pattern instead of static methods to make
future conf migration easier (so that the same JVM could in theory have multiple
Configurations by removing the singleton - now each Configuration can stand on
its own). I added static helper methods to ensure backwards
compatibility.
4. In
apps/Driver.java, I changed the "ERROR - no logger set" message to "ERROR - no
logger set - using System.out" just for clarity (I was confused until I saw the
source code).
I'm attaching a cvs
diff of my changes (against thefop-0_20_3 tag). I think this is the right
thing to do, let me know if it's not.
If it's useful, I
can make these changes work from the command line, or go ahead and refactor the
Options to not be JVM-global - just depends if folks are interested. I guess
this would make sense on the latest dev branch, not the 0.20.3
branch.
Brian
? bokconfdiffs.txt
Index: apps/Driver.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/apps/Driver.java,v
retrieving revision 1.36.2.1
diff -r1.36.2.1 Driver.java
226c226
log.error(Logger not set);
---
log.error(Logger not set - using System.out);
Index: configuration/Configuration.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/configuration/Configuration.java,v
retrieving revision 1.6
diff -r1.6 Configuration.java
31,37c31,39
/**
* stores the configuration information
*/
private static Hashtable standardConfiguration = new Hashtable(30);
;
private static Hashtable pdfConfiguration = new Hashtable(20);
private static Hashtable awtConfiguration = new Hashtable(20);
---
/**
* base path for font paths
*/
private String basePath = null ;
/**
* Singleton instance
*/
private static Configuration singleton = null ;
42,51c44
private static Hashtable configuration = new Hashtable(3);
/**
* loads the configuration types into the configuration Hashtable
*/
static {
configuration.put(standard, standardConfiguration);
configuration.put(pdf, pdfConfiguration);
configuration.put(awt, awtConfiguration);
}
---
private Hashtable configuration = null ;
52a46,70
/**
* HashTables for each configuration type
*/
private Hashtable standardConfiguration = null ;
private Hashtable pdfConfiguration = null ;
private Hashtable awtConfiguration = null ;
/**
* Constructor for singleton pattern
* Creates hash of hashes for different config types
*/
private Configuration() {
standardConfiguration = new Hashtable(30) ;
pdfConfiguration = new Hashtable(20) ;
awtConfiguration = new Hashtable(20) ;
configuration = new Hashtable(3) ;
configuration.put(standard, standardConfiguration) ;
configuration.put(pdf, pdfConfiguration) ;
configuration.put(awt, awtConfiguration) ;
}
/**
* Hashtable accessor method for singleton pattern
*/
54,55c72,115
return configuration;
}
---
if (singleton == null)
singleton = new Configuration() ;
return singleton.getHashMap() ;
}
/**
* Object accessor method for singleton pattern
*/
public static Configuration getInstance() {
if (singleton == null)
singleton = new Configuration() ;
return singleton ;
}
/**
* Get base Hashtable
*/
public Hashtable getHashMap() {
return configuration ;
}
/**
* Set the base Path for font paths
*/
public void setBasePath(String basePath) {
this.basePath = basePath ;
}
/**
* Get the base Path for font paths
*/
public String getBasePath() {
return this.basePath ;
}
/**
* static helper for getValue
* when caller code is changed, remove this method for the non-static
Shrink oversized pages to paper size
I have a fo document for printing mailing labels and positioning on the printed document needs to be exact. FOP generates a perfectly spaced PDF document, but when I print it, Acrobat scales it down a bit and throws the whole thing off. Digging around I found that unchecking "Shrink oversized pages to paper size" makes it print exactly what I want, but "Shink" is checked by default and all users would need to remember to uncheck it before printing. My page was defined with a .5in top and bottom margin and a .1875in left/right margin, and I experimented with the margins to try to keep it from shrinking, but had no luck. No matter how large I make the margins, it still shrinks it. Is there something in a FOP PDF that tells Acrobat that there is content in the full 8.5x11space and it needs to be scaled down? Is there any way to prevent the automatic shrink? Dave
Re: Shrink oversized pages to paper size
David Frankson wrote: I have a fo document for printing mailing labels and positioning on the printed document needs to be exact. FOP generates a perfectly spaced PDF document, but when I print it, Acrobat scales it down a bit and throws the whole thing off. Digging around I found that unchecking Shrink oversized pages to paper size makes it print exactly what I want, but Shink is checked by default and all users would need to remember to uncheck it before printing. My page was defined with a .5in top and bottom margin and a .1875in left/right margin, and I experimented with the margins to try to keep it from shrinking, but had no luck. No matter how large I make the margins, it still shrinks it. Use the width and heigth properties of your page-master(s) to define the page size. Fiddling with the margins is of no use here. Check what measurements Acrobat Reader provides for the paper, and use this, perhaps something slightly smaller to account for round-off errors. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
What the spec says about table-row, table-cell etc.
I've been working on a schema for FO documents so that I can off-load the validation chore. I created the schema from the W3C documents which state the following for table-cell: Contents: (%block;)+ In addition this formatting object may have a sequence of zero or more fo:markers as its initial children. The following properties apply to this formatting object: * [7.4 Common Accessibility Properties] * [7.6 Common Aural Properties] * [7.7 Common Border, Padding, and Background Properties] * [7.12 Common Relative Position Properties] * [7.26.1 border-after-precedence] * [7.26.2 border-before-precedence] * [7.26.4 border-end-precedence] * [7.26.6 border-start-precedence] * [7.14.1 block-progression-dimension] * [7.26.8 column-number] * [7.13.4 display-align] * [7.13.6 relative-align] * [7.26.10 empty-cells] * [7.26.11 ends-row] * [7.14.4 height] * [7.28.2 id] * [7.14.5 inline-progression-dimension] * [7.26.13 number-columns-spanned] * [7.26.14 number-rows-spanned] * [7.26.15 starts-row] * [7.14.12 width] FOP, in addition, both allows and implements the setting of block's inheritable attributes such as color and text-align which are then propagated down to the enclosed blocks. My questions are as follows: Is there a place in the spec that says Containers may hold inheritable attributes so they can be passed on to their child objects? Or is this just a side-effect of inheritabliity? Or is this illegal and will disappear in future FOP versions to be compatible with the spec? and Is there a list of these inheritable attributes ? Or do I just generate the list from those attributes that have an enumeration value of inherit? Chuck Paussa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP has not implemented defined enumerated attribute values
I wrote a test document that implemented all of the enumerated values for block attributes. Here are the results where FOP complained. All of the other enumerated values seem to be implemented. For the value inherit FOP implements inheritability. It just doesn't recognize the inherit enumerated value. font-weight bolder = unknown font lighter = unknown font inherit = unknown font font-style backslant = unknown font inherit = unknown font position inherit = Unknown enumerated value breaks inherit = Unknown enumerated value hyphenate inherit = Unknown enumerated value white-space-collapse inherit = Unknown enumerated value wrap-option inherit = Unknown enumerated value span inherit = Unknown enumerated value border-style inherit = Unknown enumerated value text-decoration inherit = Unknown enumerated value text-align-last inside = Unknown enumerated value outside = Unknown enumerated value left= Unknown enumerated value right = Unknown enumerated value inherit = Unknown enumerated value text-align inside = Unknown enumerated value outside = Unknown enumerated value inherit = Unknown enumerated value color inherit = unknown colour name dominant-baseline property is not implemented yet white-space-treatment property ignored linefeed-treatmentproperty is not implemented yet alignment-baselineproperty is not implemented yet alignment-adjust property is not implemented yet Chuck Paussa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
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 manager discussion Arved, Keiron et. al. I guess logically it's true that the blocks nested in inlines should be wrapped in inline areas, but it makes me nervous :-) At least they cause line breaks, that much seems sure. Good...if we all agree with that then I think it is the main point gotten out of the way, because every other situation has to do with child FOs all being inline or block-level, for which the results are less dubious. I still think that we should put pressure on the spec editors to either get rid of structure or clarify it in the next version (ha, ha). If people need blocks in inlines, they have inline-container. In fact, I'd like to think that the possibility of including block-level FOs in inline-level FOs is purely for convenience or semantic nesting and should not really affect the area tree, except to cause line breaks before and after the block areas. The most legitimate use I can see for this kind of semantic nesting is basic-link, because it could spread the link semantics over several areas; kind of a link-wrapper. The main thing is, let's make sure that we have agreement (codified through use of these diagrammed examples) on all matters that affect placement. I understand that we want to have a warm fuzzy about our understanding of the spec, but that's not going to happen with everything. To be precise, if I can get a number of these examples created, what we can do is identify situations where we can say, this one is 100% solid (we know this is right, there is no uncertainty in the spec), this one is iffy (there may be small inconsistencies between our placement and what the spec authors intended), or this one is problematic (contradictions, for example). Once we have classified the examples, we can do damage control on the uncertain ones. Namely, let's do it this way, but let's be aware that things could be interpreted another way, and if so, how heavily committed are we in our code? On a related matter when it comes right down to brass tacks I am really only concerned about placement (accuracy of rendering). Both with Fop and with my other project I find it easier to use the conceptual areas, and I get the sense that others also feel this way, but let's face it, as long as our final result is consistent it doesn't really matter if our internal structures deviate. - For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. On this particular point I think we are fortunate insofar as it is not going to affect placement. Also, if we look at 4.7.3 (inline-building), I find it curious that it starts by saying TWICE that an inline FO places inline areas and anchor inline areas returned by its child FOs in inline areas which it generates, and then suddenly throws a block-area into the condition described in point 1. Looks more like a hasty copy/paste from the list for Line-building! As Keiron says, if the spec writers had been clearer, we wouldn't have to spend hours chasing our tails like this! I find the transitions from relatively formal set-oriented treatments to casual prose disconcerting. As soon as I see formal then my Pedant-O-Meter cranks way up, and I find it hard to switch off. :-) Regards, Karen Arved Sandstrom wrote: [SNIP] _If_ there were blocks nested inside the top-level block these would produce normal block areas that are single children of normal block areas produced by the top-level block. My reading of Line-Building is that normal block areas generated by a fo:block have either _single_ block areas _or_ one or more line areas as children, not a mixture. Final comment: it is the close intermingling of inlines and blocks in this example that causes so much line breaking. Clearly each of the 2 nested blocks could be wrapped in inlines (fo:inline or whatever), and as a result everything in the example, in theory, could be in _one_ line area. Anyhow, please critique away. :-) Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: What the spec says about table-row, table-cell etc.
Comments below. -Original Message- From: Chuck Paussa [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 7:16 PM To: [EMAIL PROTECTED] Subject: What the spec says about table-row, table-cell etc. I've been working on a schema for FO documents so that I can off-load the validation chore. I created the schema from the W3C documents which state the following for table-cell: Contents: (%block;)+ In addition this formatting object may have a sequence of zero or more fo:markers as its initial children. The following properties apply to this formatting object: * [7.4 Common Accessibility Properties] * [7.6 Common Aural Properties] * [7.7 Common Border, Padding, and Background Properties] * [7.12 Common Relative Position Properties] * [7.26.1 border-after-precedence] * [7.26.2 border-before-precedence] * [7.26.4 border-end-precedence] * [7.26.6 border-start-precedence] * [7.14.1 block-progression-dimension] * [7.26.8 column-number] * [7.13.4 display-align] * [7.13.6 relative-align] * [7.26.10 empty-cells] * [7.26.11 ends-row] * [7.14.4 height] * [7.28.2 id] * [7.14.5 inline-progression-dimension] * [7.26.13 number-columns-spanned] * [7.26.14 number-rows-spanned] * [7.26.15 starts-row] * [7.14.12 width] FOP, in addition, both allows and implements the setting of block's inheritable attributes such as color and text-align which are then propagated down to the enclosed blocks. My questions are as follows: Is there a place in the spec that says Containers may hold inheritable attributes so they can be passed on to their child objects? Or is this just a side-effect of inheritabliity? Or is this illegal and will disappear in future FOP versions to be compatible with the spec? Yes, at Section 5.1.4. Every inheritable property exists on every formatting object, whether or not the property is actually applicable to (useable by) that FO. This isn't just a side-efefct of inheritability, this _is_ inheritability. :-) and Is there a list of these inheritable attributes ? Or do I just generate the list from those attributes that have an enumeration value of inherit? Don't do the latter...what you want to want to look at is the Inherited: field in the property descriptions. Chuck, one thing you may find helpful (maybe you've done it already) is to work off the XML version of the spec, and extract the property tables, at which point you can do SAX or XSLT to get at interesting bits. This was my approach. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, This is a good idea. I half-heartedly suggested as much to Matthew Huggett when he asked what a non-programming technical writer might contribute. It requires too deep an insight into the spec, but he (or Cyril) may of some assistance to you. What would be even more generally useful would be to get the spec editors to put up a site, possibly with disclaimers plastered all over it, to which they post FAQs on the spec. They must get a lot of repeating questions from the various parties who are trying to implement. I'm not subscribed to the xsl-editors mailing list (which I suppose I should be.) Is anyone else subscribed? If so, have requests like this been made before? Peter Arved Sandstrom wrote: Hi, Keiron I think what I should do is establish a section on the website with all the other design notes that is a central location for these kinds of studies. This could be the first one. I can undertake to start churning these out on a fairly regular basis - I think we need them. Once they are in CVS then it would be easier for others to annotate them, modify them, and what have you. We'll have to settle on a mutually agreeable figure format so as not to unduly restrict access. As far as the spec goes, absolutely, I agree. That's why I think that these diagrams help so much - in order to draw them you must work your way through the spec in detail. The process also exposes any gotchas before too much code has been written based on different assumptions. I'll proceed on the above basis and set up a place for these diagrams/studies, and crank out some more. I am somewhat reluctant to do any coding at the moment until such a time (hopefully not far away) where I am satisfied that I understand the new design well. Arved -Original Message- 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 of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container. It suggests that what you are saying is correct and that block-level elements create a block area outside the immediate line area. So to have a block area inside a line area you must use the inline-container, a block is never automatically embedded. Also in this section, reading between the lines (it's amazing how they manage to contradict themselves in such a short section) 4.7.3. Inline-building An inline fo element with a block element as a child will create inline areas and return the block area. It will create a single inline area that can fit consecutive child inline areas on a single line. So the child inline areas are put into parent inline areas that are separated by line breaks and block areas. So Karen's approach is looking better. I really wish this spec would say relevant things in the right places and mention how everything is handled rather than being so vague. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
