Bug 51993 - Incorrect line-height for fo:inline inside fo:block
Summary: Incorrect line-height for fo:inline inside fo:block
Status: CLOSED INVALID
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 1.0
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-07 15:24 UTC by Tiago Torres
Modified: 2012-04-30 00:11 UTC (History)
0 users



Attachments
FO file that reproduces the issue. (1.32 KB, text/x-xslfo)
2011-10-07 15:24 UTC, Tiago Torres
Details
PDF generated by Apache FOP (5.25 KB, application/pdf)
2012-04-09 14:34 UTC, Tiago Torres
Details
Log written during the PDF generation (15.03 KB, text/plain)
2012-04-09 14:36 UTC, Tiago Torres
Details
keep-together option used correctly (389.11 KB, application/x-rar-compressed)
2012-04-18 07:43 UTC, Alberto Perri
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tiago Torres 2011-10-07 15:24:26 UTC
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.
Comment 1 Glenn Adams 2012-04-07 01:42:22 UTC
resetting P2 open bugs to P3 pending further review
Comment 2 Glenn Adams 2012-04-08 05:25:11 UTC
please provide an output PDF file that corresponds with the supplied input FO file, along with all console output
Comment 3 Tiago Torres 2012-04-09 14:34:59 UTC
Created attachment 28565 [details]
PDF generated by Apache FOP
Comment 4 Tiago Torres 2012-04-09 14:36:13 UTC
Created attachment 28566 [details]
Log written during the PDF generation
Comment 5 Tiago Torres 2012-04-09 14:37:42 UTC
Glenn, I've attached the files you requested. I'm also changing the bug status to NEW.
Comment 6 Glenn Adams 2012-04-09 14:53:09 UTC
(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!
Comment 7 Manuel Mall 2012-04-10 09:35:47 UTC
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.
Comment 8 Tiago Torres 2012-04-10 14:44:42 UTC
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.
Comment 9 Glenn Adams 2012-04-10 16:34:04 UTC
(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
Comment 10 Manuel Mall 2012-04-10 17:16:05 UTC
(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
Comment 11 Glenn Adams 2012-04-10 17:35:05 UTC
(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
Comment 12 Alberto Perri 2012-04-18 07:43:17 UTC
Created attachment 28631 [details]
keep-together option used correctly
Comment 13 Glenn Adams 2012-04-30 00:11:14 UTC
batch transition resolved+invalid to closed+invalid