Created attachment 27728 [details] FO file that reproduces the issue. When I place an "fo:inline" element which specifies a small font-size inside an "fo:block" element, the line-height in the rendered PDF looks bigger than necessary. Here's a code snippet of my FO: <fo:block> <fo:inline font-size="7pt">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</fo:inline> </fo:block> In contrast, when I just have an "fo:block" which specifies the font-size, the line-height in the rendered PDF looks correct. For example: <fo:block font-size="7pt"> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. </fo:block> I believe this problem is related to the fact that FOP assumes a default font-size (or line-height) for the "fo:block", which turns out to be too large in the example I showed. This issue has been discussed on the mailing list, but I haven't found bug reports: http://osdir.com/ml/fop-users-xmlgraphics.apache.org/2011-02/msg00114.html I'm also attaching an FO file which reproduces the behavior I described.
resetting P2 open bugs to P3 pending further review
please provide an output PDF file that corresponds with the supplied input FO file, along with all console output
Created attachment 28565 [details] PDF generated by Apache FOP
Created attachment 28566 [details] Log written during the PDF generation
Glenn, I've attached the files you requested. I'm also changing the bug status to NEW.
(In reply to comment #5) > Glenn, I've attached the files you requested. I'm also changing the bug status > to NEW. thanks, this should be sufficient to proceed with work on a fix!
I am not sure if this is actually a bug. The line building rules in the spec are anything but easy to understand. For example it says for the line-height property: "If the property is set on a block-level element whose content is composed of inline-level elements, it specifies the minimal height of each generated inline box." In the example given the line-height property value on the fo:block would be "normal" meaning in the FOP implementation the calculated value for line-height set on the fo:block would be 1.2 * font-size. Therefore following the stated rule this would be the minimum height applied to all generated inline areas. The reasoning behind this is also stated in the spec: "Generally, when there is only one value of "line-height" for all inline boxes in a paragraph (and no tall images), the above will ensure that baselines of successive lines are exactly "line-height" apart. This is important when columns of text in different fonts have to be aligned, for example in a table." I could easily be wrong in my interpretation here but this is my recollection on how this behaviour came about.
I see. But I didn't specify the line-height or the font-size of the block element. FOP assumed a "normal" value and this value took precedence over the natural line-height of a 7pt text, which I indeed specified in the inline element. I just think it might be confusing for the end-user to have an implicit value outweighing a value which was explicitly set. Just for comparison, most browsers will render the following HTML snippet as expected: <p><span style="font-size:7pt">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</span></p> In fact, browsers seem to calculate line-height for each line individually based on the maximum font-size of the line, which sounds reasonable. FOP seems to do the same in most cases. However, assuming a default line-height for the block seems to be causing inconsistent results.
(In reply to comment #8) > I see. But I didn't specify the line-height or the font-size of the block > element. FOP assumed a "normal" value and this value took precedence over the > natural line-height of a 7pt text, which I indeed specified in the inline > element. I just think it might be confusing for the end-user to have an > implicit value outweighing a value which was explicitly set. > > In fact, browsers seem to calculate line-height for each line individually > based on the maximum font-size of the line, which sounds reasonable. FOP seems > to do the same in most cases. However, assuming a default line-height for the > block seems to be causing inconsistent results. Keep in mind the semantics of the line-stacking-strategy property, which defaults to max-height and not line-height. The CSS semantics default to line-height, not max-height, so this is a difference between XSL-FO and CSS. Further, at this time, FOP does not support the line-height value. That is, FOP at present supports only max-height and font-height strategies. In the former case, the maximum line rectangle applies (i.e., the maximum needed to contain the line's inline areas) in the latter case, the text-altitude/depth properties (or font metrics) apply, where the font/font-size that applies to the parent block is what determines the font metric flavors of altitude/default. See XSL-FO Section 4.5 Line Areas [1] for more detail. Also, in case of max-height and font-height strategy, the space-{before,after} of the generated line areas is set to the half leading trait value [2]. My conclusion is that the current behavior is not a bug. [1] http://www.w3.org/TR/2006/REC-xsl11-20061205/#area-line [2] http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_block
(In reply to comment #9) > (In reply to comment #8) ... > Further, at this time, FOP does not support the line-height value. That is, FOP > at present supports only max-height and font-height strategies. There was a discussion many years ago questioning if the above statement is actually correct: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200701.mbox/%3C20070112114529.AFE1.DEV@jeremias-maerki.ch%3E
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > ... > > Further, at this time, FOP does not support the line-height value. That is, FOP > > at present supports only max-height and font-height strategies. > > There was a discussion many years ago questioning if the above statement is > actually correct: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200701.mbox/%3C20070112114529.AFE1.DEV@jeremias-maerki.ch%3E thanks for pointing that out; i certainly agree it is a complex area of the spec, and what FOP actually implements may or may not comply; i would have to speculate that the current FOP test cases do not adequately cover the range of different line stacking behaviors
Created attachment 28631 [details] keep-together option used correctly
batch transition resolved+invalid to closed+invalid