Negative half-leading trait?
In 6.5.2 it says: The .minimum, .optimum, and .maximum components of the half-leading trait are set to 1/2 the difference of the computed value of the line-height property and the computed value of the sum of the text-altitude and text-depth properties. The .precedence and .conditionality components are copied from the line-height property. If the line-height is smaller than the total text height we get a negative half-leading trait value. Is that a legal/sensible/plausible value or should it be forced to 0 in this case? For 2 of the 3 different line-stacking-strategies the half-leading trait becomes a space-before/after specifier on the line area and therefore becomes part of the space resolution algorithm. I assume negative values are OK in that case although I am not sure? Manuel
Re: Negative half-leading trait?
Negative space values are ok. No need to force them to 0. See block_space-before_space-after_1.xml. 4.3 says that negative values are ok and that they are used to create overlapping areas. On 04.10.2005 08:28:43 Manuel Mall wrote: In 6.5.2 it says: The .minimum, .optimum, and .maximum components of the half-leading trait are set to 1/2 the difference of the computed value of the line-height property and the computed value of the sum of the text-altitude and text-depth properties. The .precedence and .conditionality components are copied from the line-height property. If the line-height is smaller than the total text height we get a negative half-leading trait value. Is that a legal/sensible/plausible value or should it be forced to 0 in this case? For 2 of the 3 different line-stacking-strategies the half-leading trait becomes a space-before/after specifier on the line area and therefore becomes part of the space resolution algorithm. I assume negative values are OK in that case although I am not sure? Manuel Jeremias Maerki
DO NOT REPLY [Bug 36871] - Null Pointer exception in xsl mode when match= doesn't match the XML data
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=36871. 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=36871 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-10-04 15:09 --- The same problem was present in FOP Trunk. I've fixed it there. http://svn.apache.org/viewcvs?rev=293596view=rev -- 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: DO NOT REPLY [Bug 36871] New: - Null Pointer exception in xsl mode
On 02.10.2005 01:46:48 J.Pietschmann wrote: [EMAIL PROTECTED] wrote: When your XSL file contains a condition that isn't met, so that you don't have a fo:root to do anything with you get a null pointer execption. Well, the bug report should read no proper error message if there is no fo:root. I vaguely remember Jeremias worked on this, unfortunately I don't remember whether this got into 0.20.5, and I can't currently test it. Does someone else have a 0.20.5 installation ready to run to do a quick test? J.Pietschmann If you fill in well-formed XML you'll get a proper error message in the maintenance branch and in the trunk. In the bug reporter's case however the stylesheet produced non-wellformed output (the XML started with text after the XML header). I've fixed the trunk to provide better error messages. Jeremias Maerki
Re: The space resolution examples
On 30.09.2005 08:50:22 Simon Pepping wrote: Hi, I have a problem with a number of examples on the Wike space resolution examples page. I wonder if I have a major misunderstanding. And I wonder if I ever switched on my brain while writing those examples. I made a number of mistakes like applying the is-first/is-last rule defined only for border and padding to spaces, too. I clarified this on the Wiki. 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. 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!) * Example 0 IMHO it should be: Here we look at the case where a break happens before before break. Doesn't matter IMO. It's the same outcome in both cases. * Example 1 IMHO it should be: The break after first line does not produce a 10pt space because the space is conditional. and my element list is (case 'All spaces are conditional'): box w=lh for first line penalty w=0 p=0 for the break possibility after first line glue w=10pt for the space in case there is no break box w=lh for before break penalty w=0 p=0 for the break possibility after before break box w=lh for after break Agreed. * Example 2 My element list is (case 'Only the first space is conditional'): box w=lh for first block penalty w=0 p=0 for the break possibility box w=0 penalty p=INF aux glue w=10pt for space-before box w=lh for before break penalty w=0 p=0 for the break possibility after before break box w=lh for after break Here we obviously disagree, but I had to fix the element list. It was wrong. * Example 3 Break between the blocks: Both space specifiers are conditional, and are suppressed due to rule 1 in 4.3.1. My element list is (case 'All spaces are conditional'): box w=lh for first block penalty w=0 p=0 for the break possibility glue w=10pt y=0 z=0 box w=lh for second block Agreed. * Example 4 Break between the blocks: The first space specifier is retained, the second is conditional, and is suppressed. My element list is (case 'Only the second space is conditional'): box w=lh for first block glue w=10pt y=0 z=0 penalty w=0 p=0 for the break possibility box w=lh for second block Agreed. * Example 5 Break between the blocks: Both space specifiers are retained. That means that with a break we have more space than without a break, and we need a negative glue (glue #2) to compensate this. My element list is (the full case glue #1 - penalty - glue #2 - box - PENALTY - glue #3): box w=lh for first block glue w=10pt y=0 z=0 penalty w=0 p=0 for the break possibility glue w=-10pt y=0 z=0 box w=0 penalty w=0 p=INF glue w=10pt y=0 z=0 box w=lh for second block Agreed. * Example 8 The space-before of the block with second line is conditional, and therefore is suppressed. My element list is (case 'All spaces are conditional'): box w=lh for first line aux glue w=6pt y=0 z=0 box w=lh for second line Agreed. In example 9 the reasoning was wrong. Thanks a lot, Simon, for going through all this! Jeremias Maerki
Re: Space resolution implementation and break possibility building
On 30.09.2005 10:17:24 Simon Pepping wrote: Hi, Some thoughts about the space resolution implementation notes. I believe that borders and padding are not unresolvable elements. They can always be determined by their LM because they do not interact with the borders and padding of other LMs. They do influence space resolution. They act as fences and break space sequences into several separate stacking constraints. This can be taken into account by the Space Resolver if the Knuth elements for the borders and padding make it clear that they are a fence to stacking constraints. I make a distinction between unresolvable and unresolved. I agree with the above but found it easier to work with border and padding as unresolved elements. Note that this only describes that the resolution is done at a different time. I assume it could be done without the special elements for borders and paddings. Maybe it will be changed later. And some (perhaps irrelevant) observations about break possibility building. The situation regarding retained borders and padding resembles the situation of table headers and footers closely. Nevertheless, Jeremias presents a Knuth element list which is simpler: penalty(pb-after) glue(-pb-before) box PENALTY glue(pb-before) According to the table header/footer treatment, the list would be: penalty(pb-before + pb-after) at each break possibility, representing the border and padding on the page before the break. glue(pb-before + pb-after) at the end, representing the single occurrence of the border and padding that occurs without any break. This solution would be especially more complicated for borders and paddings of nested blocks. I am wondering why the element list for borders and paddings can be constructed in a simpler way than that for table headers/footers. I think it is due to the fact that glue can be undone, while boxes cannot. I'm going to look at this more closely this week. For the moment I ignore spaces and conditional lengths surrounging a table. So I'll come back to this later. As my next step I'll review my code and will upload my changes in a temporary branch. Starting from there I'll jump into handling tables. Jeremias Maerki
Re: referenceBPD in TableLM
Yes, I think so (though not 100% sure). This is a value that was used by the former page breaking algorithm to determine when to do a page break. On 01.10.2005 22:29:31 Simon Pepping wrote: When I put a table in a block in an inline, I get a NPE, from this line: referenceBPD = context.getStackLimit().opt; because the stack limit in the context is null. Obviously, the inline does not pass a stack limit in the context. The problem can be solved easily by removing the field referenceBPD. I would think that with the current approach to page breaking it is not needed by the TableLM and its child LMs. Am I correct? Jeremias Maerki
Re: Alignment handling wiki page
I can only comment on some parts as I still don't have every aspect of this topic present. All in all this looks good and this will be a cool addition to FOP's feature set. :-) Concerning super/subscript, there are values in the PFM file of Type 1 fonts (Extended Text Metrics in Adobe Technical Note #5178): etmSuperScript etmSubScript etmSuperScriptSize etmSubScriptSize But they are currently not parsed. On 03.10.2005 02:58:51 Manuel Mall wrote: I have started a wiki page describing the issues I found in dealing with inline alignments and their proposed resolution: http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling The page is written in a style as if FOP already does those things. Of course it doesn't (my copy sort of does in parts). Comments, criticism, different points of view are most welcome as some of the suggested solutions may be contentious. Manuel Jeremias Maerki
Re: unsubscribe notice
On Oct 4, 2005, at 17:59, guanglei song wrote: Hi, It is time to say good bye with hands full. Could you please unsubscribe this email? [EMAIL PROTECTED] Sorry, you have to do this yourself. Just send an empty mail to [EMAIL PROTECTED] Cheers, Andreas
Re: unsubscribe notice
FWIW, I believe I took care of this already, by sending an e-mail to: [EMAIL PROTECTED] I cc'd him, but neglected to alert fop-dev. On Oct 4, 2005, at 9:54 AM, Andreas L Delmelle wrote: On Oct 4, 2005, at 17:59, guanglei song wrote: Hi, It is time to say good bye with hands full. Could you please unsubscribe this email? [EMAIL PROTECTED] Sorry, you have to do this yourself. Just send an empty mail to [EMAIL PROTECTED] Cheers, Andreas Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: Alignment handling wiki page
On Tue, 4 Oct 2005 11:13 pm, Jeremias Maerki wrote: I can only comment on some parts as I still don't have every aspect of this topic present. All in all this looks good and this will be a cool addition to FOP's feature set. :-) Concerning super/subscript, there are values in the PFM file of Type 1 fonts (Extended Text Metrics in Adobe Technical Note #5178): etmSuperScript etmSubScript etmSuperScriptSize etmSubScriptSize Thanks for pointing these out. I think I leave this to the FOray font project to parse. However, to some extend it supports the point I made on the wiki page that the sub/superscript offsets are somehow coupled to the font size of the actual sub/superscript. To find the most visually appropriate position (especially for subscripts) appears to me as being a non trivial issue as it depends IMO not only on the font size of the subscript (relative to the font size of the main element) but also on the content of the subscript. For example, one would most likely choose a different position for a digit than a lowercase character. Do the typesetting experts on this list have any pointers on this topic? But they are currently not parsed. On 03.10.2005 02:58:51 Manuel Mall wrote: I have started a wiki page describing the issues I found in dealing with inline alignments and their proposed resolution: http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling The page is written in a style as if FOP already does those things. Of course it doesn't (my copy sort of does in parts). Comments, criticism, different points of view are most welcome as some of the suggested solutions may be contentious. Manuel Jeremias Maerki Manuel
DO NOT REPLY [Bug 36928] New: - em specification on font-size broken
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=36928. 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=36928 Summary: em specification on font-size broken Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] A font-size spec like fo:block font-size=32ptText fo:inline font-size=0.5emsmall/fo:inline /fo:block is currently ignored. This is due to the cacheing of prop values in StaticPropertyList as the evaluation of the 0.5em value causes the parent font size value to be retrieved and stored in the property cache for the inline element. The subsequent explicit setting of the font-size property value does not overwrite the cached value. Not sure what the best fix is that's why I bugged it here = for Finn? -- 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.
