Re: The space resolution examples
[Simon]
In general, I have a different idea about the retain
condition. Retained spaces do not appear between areas returned by the
FO; all spaces appear before or after all areas returned by the
FO. This is different from retained padding and borders.
[Jeremias]
That's the part where I think you are wrong. 4.2.3 and 7.10.5 make it
clear IMO that space-before|-after are applied to every area generated
by an FO. The following sentence is the key: Specifies the value of the
space-specifier for the space before the areas generated by this
formatting object. (Notice the areas!)
So for inlines we get
fo:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i
iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx
xxx xxx/fo:block
xxx xx xxx xx xxx x
xxx iii i
iii iii ii iii
iii i
ii i ii xxx
xxx xxx
xxx xxx
where a retained space-start is applied to each inline area, not just
the first one generated?
My understanding is more in line with Simon.
I would guess that the key sentence is also true if the space is applied
to only the first area.
regards,
finn
script property
While I am at it (this whole alignment stuff I mean) we may as well do it properly. This would include support for the script property. The allowed values for script are defined for example here: http://www.unicode.org/iso15924/iso15924-codes.html. I assume we don't bother to validate if a correct code has been provided as we don't do that for the country and language properties either (should we? If we do we need more external config files or expand fop.xconf to hold those values as they tend to change over time). But what we do need is a mapping from scripts to default baselines for these scripts. I haven't found a mapping list on the net. Any one come across something like that? Otherwise we may have to make that up. That means entries somewhere similar to: script code=Guru baseline=hanging /. Is the fop config file the right place for this stuff? Any not defined scripts encountered in an fo file would map to baseline=alphabetic (may be with a warning to the user?). What we also need for proper script support is a mapping from Unicode code point to script. The mappings are for example defined here: http://www.unicode.org/Public/UNIDATA/Scripts.txt. How would one best process this (has this been done in FOP before?)? Is there other Unicode stuff FOP needs which should be considered at the same time? Are we better off working with the raw Unicode data (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)? Manuel
Re: The space resolution examples
On 05.10.2005 09:07:36 Finn Bock wrote: [Simon] In general, I have a different idea about the retain condition. Retained spaces do not appear between areas returned by the FO; all spaces appear before or after all areas returned by the FO. This is different from retained padding and borders. [Jeremias] That's the part where I think you are wrong. 4.2.3 and 7.10.5 make it clear IMO that space-before|-after are applied to every area generated by an FO. The following sentence is the key: Specifies the value of the space-specifier for the space before the areas generated by this formatting object. (Notice the areas!) So for inlines we get fo:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx xxx xxx/fo:block xxx xx xxx xx xxx x xxx iii i iii iii ii iii iii i ii i ii xxx xxx xxx xxx xxx where a retained space-start is applied to each inline area, not just the first one generated? Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction and it's what the spec says IMO. My understanding is more in line with Simon. I would guess that the key sentence is also true if the space is applied to only the first area. How so? The spec talks about spaces around the generated areas of an FO, not the space around an FO. Or take the first sentence in 7.11.2: Specifies the minimum, optimum, and maximum values for the space before any areas generated by this formatting object and the conditionality and precedence of this space. I don't read any restriction to only the first and last generated area of an FO for spaces out of this. Once again we probably hit a flaw in the spec. AltSoft repeats the space-before on every page, XEP does not. And no changes to the text in XSL 1.1 WD. :-( I think we should start a Wiki page listing all these bloody flaws in the spec for everyone to see. Jeremias Maerki
Re: script property
On 05.10.2005 09:46:18 Manuel Mall wrote: While I am at it (this whole alignment stuff I mean) we may as well do it properly. This would include support for the script property. The allowed values for script are defined for example here: http://www.unicode.org/iso15924/iso15924-codes.html. I assume we don't bother to validate if a correct code has been provided as we don't do that for the country and language properties either (should we? If we do we need more external config files or expand fop.xconf to hold those values as they tend to change over time). We don't have to but we could. Since this is not something that changes often I wouldn't put it into the config file, but in resource files instead. But what we do need is a mapping from scripts to default baselines for these scripts. I haven't found a mapping list on the net. Any one come across something like that? Nope. Otherwise we may have to make that up. That means entries somewhere similar to: script code=Guru baseline=hanging /. Is the fop config file the right place for this stuff? Again, I'd put it in separate resource files as this is not going to change often and a rebuild of FOP is not the end of the world in this case. Any not defined scripts encountered in an fo file would map to baseline=alphabetic (may be with a warning to the user?). Sure. What we also need for proper script support is a mapping from Unicode code point to script. The mappings are for example defined here: http://www.unicode.org/Public/UNIDATA/Scripts.txt. How would one best process this? shrug/ (has this been done in FOP before?) I don't think so. Is there other Unicode stuff FOP needs which should be considered at the same time? Are we better off working with the raw Unicode data (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)? shrug/ We should simply make sure that this doesn't influence performance too much for the big majority of users happy to use latin scripts. After all, this looks like many lookups are necessary and all these maps have to be loaded at one point. Jeremias Maerki
FOP website refactoring: Status?
Patrick, what's the status of your website refactoring? This is getting more and more important. Would you please wrap up everything you've done so far in a patch and post it? It doesn't need to be perfect, I can do the rest. Thanks a lot! Jeremias Maerki
DO NOT REPLY [Bug 36934] New: - The collapsing border model on an fo:table is currently not supported by FOP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36934 Summary: The collapsing border model on an fo:table is currently not supported by FOP Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] We committed to test latest FOP from SVN, but actually *every* FO file we want to render ends up in the following message, and no PDF output is created: The collapsing border model on an fo:table is currently not supported by FOP So it seems the lack of this 'feature' blocks us from beeing any further help to the project. :-( -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36935] New: - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 Summary: table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100% Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] We've tried out latest SVN code and get this lines when rendering a specific FO file to PDF. The FO actually seems to be correct (it gets produced by a third party tool, and gets rendered well with FOP-0.20.5). So is this a bug us *us*, of *the tool vendor*, or of *fop* actually? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 14:22 --- There's the same problem with the following messages: 'The contents of row 1 are taller than they should be (there is a block-progression-dimension or height constraint on the indicated row). Due to its contents the row grows to 127558 millipoints, but the row shouldn't get any taller than MinOptMax[min=opt=max=70866] millipoints.' and 'Invalid ICC profile: java.lang.IllegalArgumentException: Invalid ICC Profile Data java.lang.IllegalArgumentException: Invalid ICC Profile Data' We actually don't know if *we* have done something wrong, or the *tool vendor* or *fop*, so we need your help to clarifiy this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 14:42 --- (In reply to comment #0) We've tried out latest SVN code and get this lines when rendering a specific FO file to PDF. The FO actually seems to be correct (it gets produced by a third party tool, and gets rendered well with FOP-0.20.5). So is this a bug us *us*, of *the tool vendor*, or of *fop* actually? Your FO is probably correct and you get the warning message table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100% to inform you that FOP doesn't support the automatic table layout and instead uses the fixed table layout, because even though you specified table-layout=fixed, the spec says in 6.7.3 that the automatic table layout is to be used when the inline-progression-dimension (or width) is not specified. So this is no bug, but actually a feature to handle your FO even though automatic table layout is not yet available. Simply specify a width for your table and the warning message goes away. Or simply ignore the warning. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36934] - The collapsing border model on an fo:table is currently not supported by FOP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36934 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 15:04 --- Which project? Yours or ours? :-) FOP 0.20.5 doesn't fully support the collapsing border model, either. It just pretends it does. The borders are simply painted on top of each other. FOP Trunk doesn't do any such ugly hacks right now. Apart from the warning message you got, what did the output look like? Unusable? Does any committer have a good overview of what exactly works on tables in 0.20.5? Currently, the compliance page suggests that 0.20.5 work much better than FOP Trunk WRT table support which is probably not the case. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
For review please
I have attached an fo file (actually a testcase) and the generated pdf. It exercises some more involved alignment-baseline, nested inlines and baseline table rescaling combinations. I would appreciate if others could cast their eye over it and check it for possible mistakes or different interpretations. It looks OK to me but as the discussions on the space resolution shows there is always the possibility of different views how the spec is to be understood. Thanks Manuel ?xml version=1.0 encoding=UTF-8? !-- Copyright 2005 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id: inline_letter-spacing.xml 265720 2005-09-01 13:29:28Z jeremias $ -- testcase info p This test checks inline level alignment-baseline for nested inlines. /p /info fo fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=5in page-height=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true font-family=sans-serif fo:flow flow-name=xsl-region-body fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=50% background-color=yellowalphabetic fo:inline font-size=150% background-color=redalphabetic/fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table unchanged/fo:inline /fo:block fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=50% dominant-baseline=reset-size background-color=yellowalphabetic fo:inline font-size=150% background-color=redalphabetic/fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table changed/fo:inline /fo:block fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=50% alignment-baseline=hanging background-color=yellowhanging fo:inline font-size=50% background-color=red alignment-baseline=middlemiddle/fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table unchanged/fo:inline /fo:block fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=50% dominant-baseline=reset-size alignment-baseline=hanging background-color=yellowhanging fo:inline font-size=50% background-color=red alignment-baseline=middlemiddle/fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table changed/fo:inline /fo:block fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=50% alignment-baseline=text-before-edge background-color=yellowtext-before-edge fo:inline font-size=150% background-color=red alignment-baseline=after-edgeafter-edge/fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table unchanged/fo:inline /fo:block fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=50% dominant-baseline=reset-size alignment-baseline=text-before-edge background-color=yellowtext-before-edge fo:inline font-size=150% background-color=red alignment-baseline=after-edgeafter-edge/fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table changed/fo:inline /fo:block fo:block background-color=silver margin=1pt 0pt 1pt 0pt font-size=24ptBig fo:inline font-size=25% alignment-baseline=central background-color=yellowcentral fo:inline font-size=150% alignment-baseline=text-before-edge background-color=redtext-before-edge fo:inline font-size=200% background-color=greenalphabetic/fo:inline /fo:inline /fo:inline Big fo:inline font-size=8ptBaseline table unchanged/fo:inline /fo:block fo:block background-color=silver
DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 16:00 --- Created an attachment (id=16597) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16597action=view) Icon for ICC-Problem This is the picture we are using to produce the ICC problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 16:01 --- Some more infos for the 'ICC Profile' problem: It seems as if there is a problem with file:// typed URLs. We have put in the following URL: file://localhost/C:/myfolder/myfile.jpg and it tells us it cannot find the file (java.io.FileNotFoundException). If we put that URL in a browser, it shows the picture. If we change the URL to 'file:myfile.jpg', then no exception is shown, but the ICC error is posted. So despite the ICC problem there is a problem using file URLs? Maybe you like to check the picture, please find it attached. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 16:15 --- Looks like we don't parse the host part of the URL when creating a java.io.File from the URL. Want to fix this and send a patch? The JPEG image you attached works fine for me, BTW. I can't reproduce the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36935] - table-layout=fixed and width=auto, but auto-layout not supported = assuming width=100%
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36935. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36935 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 16:34 --- I tried under Linux a file://localhost/... URL and it worked fine is this URL problem Windows specific? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Knuth algorithm problem
I think I've just stumbled over a problem in the Knuth algorithm. Assume the following element list: FINE : ElementList: category=breaker, id= FINE : 0) aux. box w=0 FINE : 1) aux. penalty p=INFINITE w=0 FINE : 2) aux. glue w=5000 stretch=0 shrink=0 FINE : 3) box w=1 FINE : 4) penalty p=0 w=0 FINE : 5) aux. glue w=-5000 stretch=0 shrink=0 FINE : 6) aux. box w=0 FINE : 7) aux. penalty p=INFINITE w=0 FINE : 8) aux. glue w=5000 stretch=0 shrink=0 FINE : 9) box w=1 FINE : 10) penalty p=0 w=0 FINE : 11) aux. glue w=-5000 stretch=0 shrink=0 FINE : 12) aux. box w=0 FINE : 13) aux. penalty p=INFINITE w=0 FINE : 14) aux. glue w=5000 stretch=0 shrink=0 FINE : 15) box w=1 FINE : 16) penalty p=0 w=0 FINE : 17) aux. glue w=-5000 stretch=0 shrink=0 FINE : 18) aux. box w=0 FINE : 19) aux. penalty p=INFINITE w=0 FINE : 20) aux. glue w=5000 stretch=0 shrink=0 FINE : 21) box w=1 FINE : 22) penalty p=0 w=0 FINE : 23) aux. glue w=-5000 stretch=0 shrink=0 FINE : 24) aux. box w=0 FINE : 25) aux. penalty p=INFINITE w=0 FINE : 26) aux. glue w=5000 stretch=0 shrink=0 FINE : 27) box w=1 FINE : 28) penalty p=INFINITE w=0 FINE : 29) glue w=0 stretch=1000 shrink=0 FINE : 30) penalty p=-INFINITE w=0 (forced break) Note the negative glue after each page break penalty here. Further assume a page height of 3 mpt. The first break point is on element 10 (difference=5000). The algorithm currently doesn't create a second break point at element 22 because it thinks it can fit the last 3 boxes into the 3mpt. I believe now that the -5000mpt from the glue are not taken into account when creating the active nodes, or rather that the -5000 is not eliminated when calculating the difference, and therefore the algorithm falls 5000mpt short of the target. I'm still debuggging to see if I can locate the problem point but since I'm still not fully at home here I thought I should make you aware of this in case someone has a quick answer here. I'm not comfortable with uploading my space resolution code. Therefore, I'm afraid I can't provide a testcase for you to easily reproduce. Makes me wonder if it were very difficult to create JUnit test cases just testing the Knuth algorithm... Jeremias Maerki
Re: Knuth algorithm problem
It's easy after all: http://svn.apache.org/viewcvs?rev=295059view=rev On 05.10.2005 17:01:23 Jeremias Maerki wrote: snip/ Makes me wonder if it were very difficult to create JUnit test cases just testing the Knuth algorithm... Jeremias Maerki
Re: The space resolution examples
On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote: On 05.10.2005 09:07:36 Finn Bock wrote: So for inlines we get fo:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx xxx xxx/fo:block xxx xx xxx xx xxx x xxx iii i iii iii ii iii iii i ii i ii xxx xxx xxx xxx xxx where a retained space-start is applied to each inline area, not just the first one generated? Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction and it's what the spec says IMO. I found this unexpected too. But I have realized that it is only true if the conditionality is 'retain'. If it is 'discard', which is the default, you only get the space where an inline area starts inside a line, which is usually only the first area. For block areas a similar situation exists. A space-before with the default conditionality of 'discard' will generally only be present on the first area, because almost always the other areas will start a reference area. This is not true for a block inside another block which has a fence. In general the parent block only has a fence for its non-first areas if the border or padding has a conditionality of 'retain'. In all cases the user has to do quite a lot to get a space-before on non-first areas. My understanding is more in line with Simon. I felt like I had missed something obvious. I feel better now. :-) I would guess that the key sentence is also true if the space is applied to only the first area. How so? The spec talks about spaces around the generated areas of an FO, not the space around an FO. Or take the first sentence in 7.11.2: Specifies the minimum, optimum, and maximum values for the space before any areas generated by this formatting object and the conditionality and precedence of this space. I don't read any restriction to only the first and last generated area of an FO for spaces out of this. The phrase 'before the areas generated by this formatting object' is certainly not unambiguous. I read it as 'before all areas', i.e. only once. Now I am not sure anymore. The other phrase, 'before any areas generated by this formatting object' is clearer, although I have trouble precisely understanding the meaning of the word 'any'. I presume it means the same as 'before each area', but why doesn't the spec use that unambiguous phrase? Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits of a formatting object are present on each of its generated areas, and with the same value.', also indicates that the trait 'space-before' is present with the same value on each area? Once again we probably hit a flaw in the spec. AltSoft repeats the space-before on every page, XEP does not. And no changes to the text in XSL 1.1 WD. :-( I am glad to see that we are not the only ones who have a problem with this part, but it is worrysome at the same time. I think we should start a Wiki page listing all these bloody flaws in the spec for everyone to see. That is a good idea. As an extra benefit, the Wiki allows users to add their interpretations. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: script property
Jeremias Maerki wrote: What we also need for proper script support is a mapping from Unicode code point to script. ... (has this been done in FOP before?) I don't think so. Have a look at http://people.apache.org/~pietsch/linebreak.tar.gz Occasionally I've thought about some sort of Jakarta commons Unicode file component, but the guys there weren't all that enthusiastic about this, and I've not enough time to get the ball rolling all of my own. J.Pietschmann
Re: Knuth algorithm problem
The reference I found was in the section about avoiding psychologically bad breaks. AFAICS the auxiliary flag is used in line breaking in the hyphenation code, but the breaker algorithm actually doesn't care about it. For page breaking the meaning of the auxiliary flag is undefined, but I've used it to mark elements which are handled in a special way like the elements created by the space resolution. It was simply handy for them to stand out in debug output. There's no logic triggered by the flag and I don't have a problem removing the auxiliary flags if anyone prefers that I should not use them. On 05.10.2005 22:16:11 Simon Pepping wrote: I have never really understood the role of the aux flag on the elements. Is it only for the addAreas phase, or does it also play a role in the breaker algorithm? Jeremias Maerki
Re: The space resolution examples
On 05.10.2005 20:32:53 Simon Pepping wrote:
On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote:
On 05.10.2005 09:07:36 Finn Bock wrote:
So for inlines we get
fo:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i
iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx
xxx xxx/fo:block
xxx xx xxx xx xxx x
xxx iii i
iii iii ii iii
iii i
ii i ii xxx
xxx xxx
xxx xxx
where a retained space-start is applied to each inline area, not just
the first one generated?
Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction
and it's what the spec says IMO.
I found this unexpected too. But I have realized that it is only true
if the conditionality is 'retain'. If it is 'discard', which is the
default, you only get the space where an inline area starts inside a
line, which is usually only the first area.
For block areas a similar situation exists. A space-before with the
default conditionality of 'discard' will generally only be present on
the first area, because almost always the other areas will start a
reference area. This is not true for a block inside another block
which has a fence. In general the parent block only has a fence for
its non-first areas if the border or padding has a conditionality of
'retain'.
In all cases the user has to do quite a lot to get a space-before on
non-first areas.
My understanding is more in line with Simon.
I felt like I had missed something obvious. I feel better now. :-)
I would guess that the key sentence is also true if the space is applied
to only the first area.
How so? The spec talks about spaces around the generated areas of an FO,
not the space around an FO. Or take the first sentence in 7.11.2:
Specifies the minimum, optimum, and maximum values for the space before
any areas generated by this formatting object and the conditionality and
precedence of this space. I don't read any restriction to only the
first and last generated area of an FO for spaces out of this.
The phrase 'before the areas generated by this formatting object' is
certainly not unambiguous. I read it as 'before all areas', i.e. only
once.
Hmm, you're right. It could be interpreted that way.
Now I am not sure anymore. The other phrase, 'before any areas
generated by this formatting object' is clearer, although I have
trouble precisely understanding the meaning of the word 'any'. I
presume it means the same as 'before each area', but why doesn't the
spec use that unambiguous phrase?
WG knows :-)
Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits of
a formatting object are present on each of its generated areas, and
with the same value.', also indicates that the trait 'space-before' is
present with the same value on each area?
Oh, thanks for finding that one again. I knew I've read that before but
couldn't remember when I wrote my previous reply.
Once again we probably hit a flaw in the spec. AltSoft repeats the
space-before on every page, XEP does not. And no changes to the text in
XSL 1.1 WD. :-(
I am glad to see that we are not the only ones who have a problem with
this part, but it is worrysome at the same time.
It's sad. My impression that XSL-FO is worse than HTML concerning
interpretation differences gets stronger and stronger lately.
I think we should start a Wiki page listing all these bloody flaws in
the spec for everyone to see.
That is a good idea. As an extra benefit, the Wiki allows users to add
their interpretations.
I'll write up what we found so far on space-resolution tomorrow. We can
then ask the WG for a comment. I want to get this and the first release
off my table quickly.
Jeremias Maerki
Re: script property
On Thu, 6 Oct 2005 04:23 am, J.Pietschmann wrote: Jeremias Maerki wrote: What we also need for proper script support is a mapping from Unicode code point to script. ... (has this been done in FOP before?) I don't think so. Have a look at http://people.apache.org/~pietsch/linebreak.tar.gz Occasionally I've thought about some sort of Jakarta commons Unicode file component, but the guys there weren't all that enthusiastic about this, and I've not enough time to get the ball rolling all of my own. Joerg, thanks for that. Do I understand this correctly that you use a Java code generation approach here. That is you generate Java source code from the Unicode text files which is then compiled as part of the line breaking code? Not so sure I like that but then again if it works. For me this type of stuff feels more like pure data but of course we don't want to parse these text files each time FOP loads. What about the hyphenation pattern approach? Store it as a serialized object and treat it more like a resource? Accessing that should be comparable in time to class loading (I think as I haven't ever empirically tested that). I haven't studied your code in detail but could we / should we integrate this into the FOP trunk to support 'Unicode compliant' line breaking? My main goal still is to make FOP happen therefore I wouldn't like to dilute my effort / time in trying to argue / establishing another commons subproject at the moment. What about we create a org.apache.fop.unicode package for the time being where we keep unicode specific support stuff? That can then at a later stage be refactored into a commons subproject if the time/will/energy is there. J.Pietschmann Manuel
Re: script property
On Wed, 5 Oct 2005 04:17 pm, Jeremias Maerki wrote: On 05.10.2005 09:46:18 Manuel Mall wrote: While I am at it (this whole alignment stuff I mean) we may as well do it properly. This would include support for the script property. The allowed values for script are defined for example here: http://www.unicode.org/iso15924/iso15924-codes.html. I assume we don't bother to validate if a correct code has been provided as we don't do that for the country and language properties either (should we? If we do we need more external config files or expand fop.xconf to hold those values as they tend to change over time). We don't have to but we could. Since this is not something that changes often I wouldn't put it into the config file, but in resource files instead. OK - makes sense. But what we do need is a mapping from scripts to default baselines for these scripts. I haven't found a mapping list on the net. Any one come across something like that? Nope. Otherwise we may have to make that up. That means entries somewhere similar to: script code=Guru baseline=hanging /. Is the fop config file the right place for this stuff? Again, I'd put it in separate resource files as this is not going to change often and a rebuild of FOP is not the end of the world in this case. My suggestion was based around the assumption that if we have to make up the mappings from script to baseline ourselves we may get it wrong. Therefore leave it up to the user to add the mappings for his/her language/script environment to the config file. Most users will deal only with a very few scripts so its not a big deal. Any not defined scripts encountered in an fo file would map to baseline=alphabetic (may be with a warning to the user?). Sure. What we also need for proper script support is a mapping from Unicode code point to script. The mappings are for example defined here: http://www.unicode.org/Public/UNIDATA/Scripts.txt. How would one best process this? shrug/ (has this been done in FOP before?) I don't think so. See Joerg's response. Is there other Unicode stuff FOP needs which should be considered at the same time? Are we better off working with the raw Unicode data (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)? shrug/ Seems like line breaking (and hyphenation, e.g. script specific hyphenation character) may also need Unicode stuff (not necessarily from the raw data file though). We should simply make sure that this doesn't influence performance too much for the big majority of users happy to use latin scripts. After all, this looks like many lookups are necessary and all these maps have to be loaded at one point. Yes, that is a valid consideration. May be it needs to be designed in a way that these lookups can be disabled and replaced by defaults from the config file. Jeremias Maerki Manuel
Re: The space resolution examples
Sounds like you guys are converging along these line: 1. Space properties are set as traits on each area. 2. Appearance of spaces is (largely) controlled by a combination of the conditionality setting, being the first/last area of a reference area, and the presence of fences (non zero border / padding). Manuel On Thu, 6 Oct 2005 04:50 am, Jeremias Maerki wrote: On 05.10.2005 20:32:53 Simon Pepping wrote: On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote: On 05.10.2005 09:07:36 Finn Bock wrote: So for inlines we get fo:blockxxx xx xxx xx xxx x xxx fo:inline space-start=nniii i iii iii ii iii iii i ii i ii/fo:inline xxx xxx xxx xxx xxx/fo:block xxx xx xxx xx xxx x xxx iii i iii iii ii iii iii i ii i ii xxx xxx xxx xxx xxx where a retained space-start is applied to each inline area, not just the first one generated? Unexpected for inlines maybe, yes, but not necessarily for the b-p-direction and it's what the spec says IMO. I found this unexpected too. But I have realized that it is only true if the conditionality is 'retain'. If it is 'discard', which is the default, you only get the space where an inline area starts inside a line, which is usually only the first area. For block areas a similar situation exists. A space-before with the default conditionality of 'discard' will generally only be present on the first area, because almost always the other areas will start a reference area. This is not true for a block inside another block which has a fence. In general the parent block only has a fence for its non-first areas if the border or padding has a conditionality of 'retain'. In all cases the user has to do quite a lot to get a space-before on non-first areas. My understanding is more in line with Simon. I felt like I had missed something obvious. I feel better now. :-) I would guess that the key sentence is also true if the space is applied to only the first area. How so? The spec talks about spaces around the generated areas of an FO, not the space around an FO. Or take the first sentence in 7.11.2: Specifies the minimum, optimum, and maximum values for the space before any areas generated by this formatting object and the conditionality and precedence of this space. I don't read any restriction to only the first and last generated area of an FO for spaces out of this. The phrase 'before the areas generated by this formatting object' is certainly not unambiguous. I read it as 'before all areas', i.e. only once. Hmm, you're right. It could be interpreted that way. Now I am not sure anymore. The other phrase, 'before any areas generated by this formatting object' is clearer, although I have trouble precisely understanding the meaning of the word 'any'. I presume it means the same as 'before each area', but why doesn't the spec use that unambiguous phrase? WG knows :-) Maybe this phrase in 4.2.2, 'Unless otherwise specified, the traits of a formatting object are present on each of its generated areas, and with the same value.', also indicates that the trait 'space-before' is present with the same value on each area? Oh, thanks for finding that one again. I knew I've read that before but couldn't remember when I wrote my previous reply. Once again we probably hit a flaw in the spec. AltSoft repeats the space-before on every page, XEP does not. And no changes to the text in XSL 1.1 WD. :-( I am glad to see that we are not the only ones who have a problem with this part, but it is worrysome at the same time. It's sad. My impression that XSL-FO is worse than HTML concerning interpretation differences gets stronger and stronger lately. I think we should start a Wiki page listing all these bloody flaws in the spec for everyone to see. That is a good idea. As an extra benefit, the Wiki allows users to add their interpretations. I'll write up what we found so far on space-resolution tomorrow. We can then ask the WG for a comment. I want to get this and the first release off my table quickly. Jeremias Maerki
