Re: FOTree Table FOs -- definitely non-urgent, just probing...
As all of the table FOs are direct descendants of FObj this is a reasonable thought. Might really be worthwhile. On 25.08.2005 21:45:16 Andreas L Delmelle wrote: Hi all, Has anyone ever thought about introducing an abstract class for table-related FOs, say TableFObj, that would be extended by all those FOs? It just occurred to me that there are: a) the border-precedences that are applicable only to those types of FO (=all of them) b) the borders themselves that behave differently when specified on table-FOs in case of collapse(-with-precedence) I just got to thinking that an abstract superclass could be used to bundle some of that functionality. (For example: binding the border-*-precedence properties. Right now, the related code has to be repeated in at least five classes...) Although currently I don't see a compelling reason to do so, it might be an idea that's worth revisiting later on... I'll keep it on my personal list of ideas to consider, unless anyone has strong objections against such a move. WDYT? Jeremias Maerki
Re: Non-implemented props: border-*-precedence
On 26.08.2005 09:09:45 Finn Bock wrote: [Andreas L Delmelle] Any hint appreciated. I have added support for the default values in a TableBorderPrecedence property maker class. Cool. It's so good to see names other than mine on the commits list. Since I have added a new file to SVN must I do something to make line ending right? I've just added svn:keywords (Id) and svn:eol-style (native) to the file. In the meantime I've made good experiences by doing a few settings in my SVN config file. In Windows under %USERPROFILE%\Application Data\Subversion\config. I've enabled enable-auto-props = yes. Furthermore, I've added the following entries under [auto-props]: *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg *.java = svn:eol-style=native;svn:keywords=Id *.xml = svn:keywords=Id That takes care of 95% of all cases. Is there a way in our test system to check the values of properties in the fo tree? Not yet, I'm afraid. It would really be good to JUnit-test the FO tree and property subsystem. The layout engine test facility only tests the layout engine and the visual testing facility only the generated output. We still have a few gaps WRT testability. Ideas welcome. Jeremias Maerki
Re: Non-implemented props: border-*-precedence
Finn Bock wrote: [Andreas L Delmelle] Any hint appreciated. I have added support for the default values in a TableBorderPrecedence property maker class. Since I have added a new file to SVN must I do something to make line ending right? Yes you need to set the SVN property svn:eol-style=native Is there a way in our test system to check the values of properties in the fo tree? No. The layout engine tests can only check values in the Area Tree XML. So you could modify the XML Renderer to output FO Tree values that you want to check. ALthough you might want to make this optional as I'm not very keen on having FO Tree data in the Area Tree output. Chris
percentages on i-p-d/b-p-d/height
The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is interpreted as auto. The second sentence of the above statement is currently not implemented resulting in messed up output. What is the best way to fix this? Can we do it on the fo tree when the property is constructed, i.e. walk up the tree and see if a corresponding dimension is set explicitly and if not not force the property to auto? There are complications like width and height are corresponding properties to i-p-d/b-p-d and writing mode and reference orientation are also relevant. May be this is too much for the fo tree / property construction phase? Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. Currently the getValue() call just returns an int. If we want to use an int value to signal back cannot resolve we need to reserve a value for that purpose, may be MIN_INT? But this then has to flow through the expression validation logic. Reminds me a bit of handling of NULL values in SQL - nasty. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). Or we put more logic into the LMs for this. They would have to test the property if it is of type Relative...Property. If so they have to go up the LM chain and check if the ancestor block has an explicit b-p-d, if yes do normal property resolution, if no behave as if the property was set to auto. Any one with better ideas / comments? Manuel
Re: Relative font weights and font selection
On 25.08.2005 18:10:51 Victor Mote wrote: Victor Mote wrote (August 8): Manuel Mall wrote: Regarding the bolder, lighter issue and the general font selection I looked at the pre-patch for FOrayFont adaptation to Fop (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and concluded that meddling with the font selection system will interfere with the FOray font integration and that the FOray font system has addressed most of the font selection issues any way (not sure about the bolder, lighter bits though). I will therefore back-off from that line of work and wait for the FOray font integration to complete, assuming that it is still going ahead. Sorry to be so slow responding. I think Vincent is taking August off, but is still working on the font integration work. Manuel and I have had an off-line conversation about the bolder/lighter issue, and I think we will need to improve both the interface and the implementation to handle this and the similar issues for font-stretch. I'll work on that in the next week or two. First, sorry to be so slow. I can finally get to all my tools again. I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. I believe that font-stretch has to included just like font-weight to select the actual font. If you look at Adobe's Kepler collections below you have all the font-weight variants for each of the three font-stretch variants (Std, SemiCondensed and Extended). It's simply an additional dimension in the matrix to choose a font. Not that font-stretch is used so often. That's probably the reason why it was removed. CSS probably doesn't need this level of detail for font selection, but XSL-FO might just be a little closer to the market where people are very picky about what font they use. Anyway, nobody uses 32 font variants in one document and a little font mapping configuration would do away with the need for font-stretch. So supporting font-stretch and font-size-adjust are low-priority especially since they are both in the Extended conformance level. http://store.adobe.com/type/browser/P/P_1432.html http://store.adobe.com/type/browser/P/P_1435.html http://store.adobe.com/type/browser/P/P_1437.html Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! font-size-adjust was removed, too. CSS versions at W3C: http://www.w3.org/TR/REC-CSS1 http://www.w3.org/TR/REC-CSS2/ http://www.w3.org/TR/CSS21/ For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. I think this is really up to the user agent to define the exact strategy as long as the visual order is preserved. In order to move forward, I suggest the addition of the following methods in org.axsl.font.Font: public byte nextBolderWeight(); public byte nextLighterWeight(); public org.axsl.font.Font nextBolderFont(); public org.axsl.font.Font nextLighterFont(); This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. I got the impression that's what the spec tried to establish. Hmm. There is another area complexity in font selection that has not yet been addressed, so I pose it here to Vincent and Manuel especially, and to any others who wish to comment. The whole issue of whether the Font has a glyph for the character(s) has not yet been addressed. The best idea I have for this is as follows: 1. Add a char to the signature of org.axsl.font.FontServer.selectFont. This char represents the first char of the text for which the font is being selected. This allows the selection process to pass by a font-family if it cannot paint the character. 2. Add the following method to org.axsl.font.Font: /** * Examines each character in string to ensure that a glyph exists in the font for that * character. If a character has no glyph in the font, the character's index in string * is returned. * @return The index in string of its first character for which no glyph exists in this * font. If all characters in the string have glyphs in this font, -1 is returned. */ public int unavailableChar(String string); Add also an overridden version of this method with char[] as the parameter. I like that! Between these two, I think an application should be able to efficiently subdivide a chunk of text based on the various fonts that may
Re: percentages on i-p-d/b-p-d/height
On 26.08.2005 10:41:31 Manuel Mall wrote: The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is interpreted as auto. The second sentence of the above statement is currently not implemented resulting in messed up output. What is the best way to fix this? Can we do it on the fo tree when the property is constructed, i.e. walk up the tree and see if a corresponding dimension is set explicitly and if not not force the property to auto? There are complications like width and height are corresponding properties to i-p-d/b-p-d and writing mode and reference orientation are also relevant. May be this is too much for the fo tree / property construction phase? Yes, I think so. It also duplicates code. See below. Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. Yes, but the LMs have to resolve the auto values anyway with the help of the LayoutContext they get passed by the parent. That's one more reason why it's a good idea IMO to let the LM provide the percentage resolution context. Currently the getValue() call just returns an int. If we want to use an int value to signal back cannot resolve we need to reserve a value for that purpose, may be MIN_INT? But this then has to flow through the expression validation logic. Reminds me a bit of handling of NULL values in SQL - nasty. Not necessary IMO. The LM needs to check width.getEnum() != EN_AUTO, for example, and chose the right value. I think this paragraph would only have applied if we'd consider doing the resolution in the FO tree, right? Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Uh, oh. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). I believe checking getEnum() should be enough. Or we put more logic into the LMs for this. They would have to test the property if it is of type Relative...Property. If so they have to go up the LM chain and check if the ancestor block has an explicit b-p-d, if yes do normal property resolution, if no behave as if the property was set to auto. Have a look at BlockContainerLM. I really think this needs to be done in the LMs since they have to know these values anyway and they resolve them, too. Any one with better ideas / comments? No better comments other than try to provide the necessary values through the percentage resolution context and the LMs. I believe it's the best way. HTH (and I hope I understand this stuff enough to give good advice/comments). Jeremias Maerki
Re: percentages on i-p-d/b-p-d/height
On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote: On 26.08.2005 10:41:31 Manuel Mall wrote: The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is interpreted as auto. The second sentence of the above statement is currently not implemented resulting in messed up output. What is the best way to fix this? Can we do it on the fo tree when the property is constructed, i.e. walk up the tree and see if a corresponding dimension is set explicitly and if not not force the property to auto? There are complications like width and height are corresponding properties to i-p-d/b-p-d and writing mode and reference orientation are also relevant. May be this is too much for the fo tree / property construction phase? Yes, I think so. It also duplicates code. See below. Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. Yes, but the LMs have to resolve the auto values anyway with the help of the LayoutContext they get passed by the parent. That's one more reason why it's a good idea IMO to let the LM provide the percentage resolution context. They do, that's correct. But in this case they have to figure out that although a percentage is set on the property they should treat it like auto. Currently the getValue() call just returns an int. If we want to use an int value to signal back cannot resolve we need to reserve a value for that purpose, may be MIN_INT? But this then has to flow through the expression validation logic. Reminds me a bit of handling of NULL values in SQL - nasty. Not necessary IMO. The LM needs to check width.getEnum() != EN_AUTO, for example, and chose the right value. I think this paragraph would only have applied if we'd consider doing the resolution in the FO tree, right? The problem is that getEnum() != EN_AUTO is true because a percentage was set but the percentage value should be ignored and treated like EN_AUTO if no explicit b-p-d was set on the parent. It is that particular decision which is not currently handled. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Uh, oh. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). I believe checking getEnum() should be enough. I don't think it is - see above. Or we put more logic into the LMs for this. They would have to test the property if it is of type Relative...Property. If so they have to go up the LM chain and check if the ancestor block has an explicit b-p-d, if yes do normal property resolution, if no behave as if the property was set to auto. Have a look at BlockContainerLM. I really think this needs to be done in the LMs since they have to know these values anyway and they resolve them, too. Any one with better ideas / comments? No better comments other than try to provide the necessary values through the percentage resolution context and the LMs. I believe it's the best way. HTH (and I hope I understand this stuff enough to give good advice/comments). Jeremias Maerki Manuel
Re: percentages on i-p-d/b-p-d/height
On Fri, 26 Aug 2005 06:00 pm, Finn Bock wrote: [Manuel Mall] The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is interpreted as auto. The second sentence of the above statement is currently not implemented resulting in messed up output. What is the best way to fix this? Can we do it on the fo tree when the property is constructed, i.e. walk up the tree and see if a corresponding dimension is set explicitly and if not not force the property to auto? There are complications like width and height are corresponding properties to i-p-d/b-p-d and writing mode and reference orientation are also relevant. May be this is too much for the fo tree / property construction phase? It sounds just like a job for the property system since it already deals with the corresponding properties and knows if a property is explicitly set. You feel like having a go at it :-)? snip/ regards, finn Manuel
Re: percentages on i-p-d/b-p-d/height
Finn Bock wrote: It sounds just like a job for the property system since it already deals with the corresponding properties and knows if a property is explicitly set. I don't think that there is an existing way to check if a fo is block-level but that can be added (like generatesReferenceAreas()) or just done by hand: The FO's used to have this property. I think Glen removed it o: if (fo.getNameId() == Constants.FO_BLOCK || ... yuk! snip/ Chris
Re: percentages on i-p-d/b-p-d/height
I'm sorry, I'd better shut up if I can't dive fully into this matter. I'm just wasting your and my time. Finn seems to have a better grip on this area. On 26.08.2005 11:21:58 Manuel Mall wrote: On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote: On 26.08.2005 10:41:31 Manuel Mall wrote: The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is interpreted as auto. The second sentence of the above statement is currently not implemented resulting in messed up output. What is the best way to fix this? Can we do it on the fo tree when the property is constructed, i.e. walk up the tree and see if a corresponding dimension is set explicitly and if not not force the property to auto? There are complications like width and height are corresponding properties to i-p-d/b-p-d and writing mode and reference orientation are also relevant. May be this is too much for the fo tree / property construction phase? Yes, I think so. It also duplicates code. See below. Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. Yes, but the LMs have to resolve the auto values anyway with the help of the LayoutContext they get passed by the parent. That's one more reason why it's a good idea IMO to let the LM provide the percentage resolution context. They do, that's correct. But in this case they have to figure out that although a percentage is set on the property they should treat it like auto. Currently the getValue() call just returns an int. If we want to use an int value to signal back cannot resolve we need to reserve a value for that purpose, may be MIN_INT? But this then has to flow through the expression validation logic. Reminds me a bit of handling of NULL values in SQL - nasty. Not necessary IMO. The LM needs to check width.getEnum() != EN_AUTO, for example, and chose the right value. I think this paragraph would only have applied if we'd consider doing the resolution in the FO tree, right? The problem is that getEnum() != EN_AUTO is true because a percentage was set but the percentage value should be ignored and treated like EN_AUTO if no explicit b-p-d was set on the parent. It is that particular decision which is not currently handled. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Uh, oh. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). I believe checking getEnum() should be enough. I don't think it is - see above. Or we put more logic into the LMs for this. They would have to test the property if it is of type Relative...Property. If so they have to go up the LM chain and check if the ancestor block has an explicit b-p-d, if yes do normal property resolution, if no behave as if the property was set to auto. Have a look at BlockContainerLM. I really think this needs to be done in the LMs since they have to know these values anyway and they resolve them, too. Any one with better ideas / comments? No better comments other than try to provide the necessary values through the percentage resolution context and the LMs. I believe it's the best way. HTH (and I hope I understand this stuff enough to give good advice/comments). Jeremias Maerki Manuel Jeremias Maerki
page-number and page-number-citation problem
There is a layout problem with fo:page-number and fo:page-number-citation, already pointed out but still unresolved. I think, these formatting objects are very similar, even if their actual handling is quite different: they both must be replaced by an information (a page number) that is (or could be) not available during the line breaking, so that a provisional width is used instead of the real one during the creation of the elements. The method PageNumberCitationLM.get() allocates the width of the string MMM if the id is not already known; PageNumberLM.get() calls getCurrentPV().getPageNumberString(), but, as pagination is performed later, it always get the page-sequence initial page number (I am going to add a testcase showing a situation in which this makes some text overlap). The real number could be known as soon as the pagination for the current page-sequence is done (for a fo:page-number) or even later (if there is a fo:page-number-citation whose referenced object is in a page-sequence following the current one). In both cases, if there is a differnce between the allocated width and the real one, indents and / or adjustment ratios should be re-computed. The computation, in itself, is easy, as the LineLM already has all the necessary information: line width, unadjusted width, available stretch and shrink. The point is that this information is stored in the LineBreakPositions, while the actual value (and the actual width) is set directly into the area tree. In order to adjust the inline content of a line when the page number is resolved, I see two alternative strategies: 1) the LineLM has to handle this: this needs the LineAreas to hold a reference to the LineLM that creates them, and that knows all the needed information; 2) the LineArea has to handle this: this means that the LineArea (and the InlineAreas too) must be given the information about MinOptMax ipd and provisional adjust ratio I don't like 1 very much, because I think the creator LM is not a significant attribute of an area, but 2 involves adding many attributes too (and maybe even less significant!) ... What do you think? Do someone see a different strategy? Regards Luca
RE: Relative font weights and font selection
Jeremias Maerki wrote: I believe that font-stretch has to included just like font-weight to select the actual font. Sorry to be unclear. I understand that font-stretch must be included. The issue is whether the wider and narrower constraints can be processed in the FOTree by simply bumping the description up / down, or whether (as seems to be the case for font-weight) they must be resolved in the font system by looking at the actual fonts available. I originally read the spec to mean the latter, but I think Manuel reads the spec as the former. I am not sure which is right. If the latter is correct, then we will need to do something similar to what I have described for font-weight to handle the font-stretch relative values. For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. I think this is really up to the user agent to define the exact strategy as long as the visual order is preserved. OK. That is a third theory. This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. I got the impression that's what the spec tried to establish. Hmm. I have never seen such a thing explicitly. I have been working under the assumption that font A could be part of two font-families if a user wished to do so. (I am not sure why a user would want to do so -- this was just known to be possible with the data structured as it is). Thanks for your comments. Victor Mote
DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
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=36379. 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=36379 Summary: [PATCH] Revised percentage resolution system Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Wow, this is the big one (from my perspective any way). See http://marc.theaimsgroup.com/?t=11243792742r=1w=2 for some background info. This patch affects a lot of classes (most in a minor way) especially in the LM section. It passes all layout engine tests and I have compared the area trees with the current trunk code. I therefore sincerely hope it is not a step backwards. There are also some steps forward. Percentages on leader-length and leader-pattrern-width should work. background-position-x/y percentages should also work in a generic way. Percentages relative to cell dimensions should be ok. There is more work to be done in this area. This is not the final word on percentages. But because of its size I would like to get this reviewed and if accepted put into SVN so my code base doesn't branch too badly from the main stream. BTW, I haven't got rid completely of the LayoutDimension stuff. It is still used for tables columns with proportional-column-width() specs. This still needs to be looked at. -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 --- Additional Comments From [EMAIL PROTECTED] 2005-08-26 15:16 --- Created an attachment (id=16213) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16213action=view) The main patch -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 --- Additional Comments From [EMAIL PROTECTED] 2005-08-26 15:17 --- Created an attachment (id=16214) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16214action=view) One new class to go into org.apache.fop.layoutmgr -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 --- Additional Comments From [EMAIL PROTECTED] 2005-08-26 15:18 --- Created an attachment (id=16215) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16215action=view) Another new class for org.apache.fop.datatypes -- 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 36379] - [PATCH] Revised percentage resolution system
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=36379. 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=36379 --- Additional Comments From [EMAIL PROTECTED] 2005-08-26 15:19 --- Created an attachment (id=16216) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16216action=view) A few additional testcases -- 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.
Re: page-number and page-number-citation problem
Luca Furini wrote: snip/ The computation, in itself, is easy, as the LineLM already has all the necessary information: line width, unadjusted width, available stretch and shrink. I think shrinking/stretching the spaces in the case where the guessed space doesnt match the actual is an improvement on what we have today. Sure, there will be people who are not satisfied but it is good enough for version 1.0. After all we are not talking about having to find 100em of extra space from a line. It should be 1 or 2em at most. Are there any applications requiring a 100 page document??? The point is that this information is stored in the LineBreakPositions, while the actual value (and the actual width) is set directly into the area tree. In order to adjust the inline content of a line when the page number is resolved, I see two alternative strategies: 1) the LineLM has to handle this: this needs the LineAreas to hold a reference to the LineLM that creates them, and that knows all the needed information; yuk! The area objects should not reference any more objects than necessary. For large documents that have been broken up into multiple page-sequences to keep memory down, this will cause memory usage to explode. 2) the LineArea has to handle this: this means that the LineArea (and the InlineAreas too) must be given the information about MinOptMax ipd and provisional adjust ratio This is the preferred option as it only increases memory a little. Perhaps the Min/max/opt objects can be null unless the area contains dynamic information? I don't like 1 very much, because I think the creator LM is not a significant attribute of an area, but 2 involves adding many attributes too (and maybe even less significant!) ... What do you think? Do someone see a different strategy? I'm against a 2 pass approach too as XSL-FO processing is slow enough already. The shrink/stretch strategy is a good strategy. Don;t forget as well as word spacing there is letter spacing and font stretch that can be altered, when in a tight spot. Chris
Re: Relative font weights and font selection
Victor Mote a écrit : I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! As I understand the spec, this works differently from font-weight and can be resolved in the FO Tree: just select the next expanded value for wider or next condensed for narrower. The font selection would be performed only after, when it is time to decide e.g. which font the keyword semi-expanded matches. That's true that it is an extra-feature that IMO can be simulated with a good font configuration file. For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. I'd go with 1. Get the inherited font; find a darker one in the fonts database; get its weight value. That's it. In order to move forward, I suggest the addition of the following methods in org.axsl.font.Font: public byte nextBolderWeight(); public byte nextLighterWeight(); public org.axsl.font.Font nextBolderFont(); public org.axsl.font.Font nextLighterFont(); This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. That seems OK. The only interest I see for a font to belong to several families is when there is a specific family (Times, Helvetica) and a generic one (serif, sans-serif...). In this case a generic family would be mapped to a specific one, and I don't think your proposed methods prevents that. Otherwise I don't see much interest to mix several families to build a complete set. The result would be visually bad IMO. I may have missed something: I haven't studied that point yet. There is another area complexity in font selection that has not yet been addressed, so I pose it here to Vincent and Manuel especially, and to any others who wish to comment. The whole issue of whether the Font has a glyph for the character(s) has not yet been addressed. The best idea I have for this is as follows: 1. Add a char to the signature of org.axsl.font.FontServer.selectFont. This char represents the first char of the text for which the font is being selected. This allows the selection process to pass by a font-family if it cannot paint the character. So let's assume that I have a line of text to render. IIUC I would use it like this: * first call with the first char of the text to get the font that will be generally used * an additional call for each character for which there is no glyph in the general font Is that what you mean? 2. Add the following method to org.axsl.font.Font: /** * Examines each character in string to ensure that a glyph exists in the font for that * character. If a character has no glyph in the font, the character's index in string * is returned. * @return The index in string of its first character for which no glyph exists in this * font. If all characters in the string have glyphs in this font, -1 is returned. */ public int unavailableChar(String string); Add also an overridden version of this method with char[] as the parameter. Why not directly return an array of all indexes where there is a missing glyph? Or add a beginIndex parameter so that one doesn't have to artificially recreate a String made of the initial String minus all characters up to the first missing glyph? Between these two, I think an application should be able to efficiently subdivide a chunk of text based on the various fonts that may need to be used to process it. In the long-term the font-selection-strategy will have to be implemented. The preceding stuff may need to be completed. Comments on any of this are very welcome. I had hoped to defer some of these font selection issues for a while yet, and you guys are frankly ahead of me in needing to resolve them, so I will be glad to react to those who may have thought it through more than I have. I wish I could be more helpful, but I haven't considered all aspects of the problem yet and I don't catch the whole point. I'd like to first finish the font integration work. IMHO this feature is for now not that important. What do other committers think? Vincent
Re: page-number and page-number-citation problem
Luca Furini wrote: Yes, undoubtedly a two-pass rendering would produce a better output: and after all, even LaTex needs to be run twice if there are page number citations. Backtracking with some attempts to minimize the scope for re-layout should be enough, though somewhat less straightforward to implement. J.Pietschmann
DO NOT REPLY [Bug 36391] - [PATCH] reference-orientation and negative values
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=36391. 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=36391 --- Additional Comments From [EMAIL PROTECTED] 2005-08-27 02:37 --- Created an attachment (id=16221) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16221action=view) Test FO file -- 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 36391] - [PATCH] reference-orientation and negative values
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=36391. 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=36391 --- Additional Comments From [EMAIL PROTECTED] 2005-08-27 02:38 --- Created an attachment (id=16222) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16222action=view) PDF output before applying the patch -- 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 36391] - [PATCH] reference-orientation and negative values
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=36391. 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=36391 --- Additional Comments From [EMAIL PROTECTED] 2005-08-27 02:39 --- Created an attachment (id=16223) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16223action=view) PDF output with the patch -- 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.
Re: FOP website, release preparations: refactoring necessary
Ok, so from what I understand you want to do, I think that what the Lenya project did looks good. http://lenya.apache.org/ What do you think ? Patrick Paul Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
I have figured out how the documentation files work and how to edit them. I still have to figure out how to get the site to build on my local machine and then I will be in business. What way you suggest I send the changes to you ? Thanks, Patrick Paul Jeremias Maerki wrote: Very cool! Thanks a lot! If you need any help, just yell. On 23.08.2005 14:37:38 Patrick Paul wrote: I would like to take care of that. I should have some free time in the next few weeks, so I will start doing a little bit everyday starting Wednesday. Patrick Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki Jeremias Maerki
