Major The attribute fo:line-height is defined in '20.197 fo:line-height'
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-fo_line-height
The text starts with "See §7.15.4 of [XSL].", which is https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#line-height
And that section references CSS2 "line-height" property in http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height
The CSS property "line-height" applies to all elements. In ODF the attribute "line-height" neither belongs to text-properties nor to graphic-properties, but it belongs only to the paragraph-properties. Therefore the CSS inheritance rules are not use-able in case the paragraph element has child elements. ODF needs to specify the behavior itself.
I have examined the consumers LibreOffice, Word, CalligraWords, AbiWord, TextMaker and GoogleDocs. I have used a simple span-element in latin script with only text content and without any explicit change in vertical position. AbiWord does not support the attribute "line-height".
I see these problems:
(A) value type 'percent' with span-element
---------------------------------------------
If there are no child elements, then the ODF consumers do the same as specified in CSS, they multiply the paragraph font-size with the specified percent value to get the final height of the line.
Now take as example a line with a font-size of 12pt and a line-height of 175% from its paragraph style, and in that line a span-element with font-size 36pt.
In CSS as first step the height is calculated as 175%*12pt=21pt. Because the calculated value (here 21pt) is inherited and not the specified value (here 175%), the font-size of the inline element is not multiplied with 175%, but its height is based on its own font-size 36pt. The calculated line height from the paragraph font-size is only a minimal height and browsers extend the height of this line box. I don't know what rules they use for extending, but the browsers use all the same method. I see, that the span-element might overflow the previous and next line.
I have noticed, that the ODF consumers take the maximum font-size of the line (here 36pt) and apply the percent value (here 175%) to it, which results in a final height of 63pt for that line. Doing this, the span-element always fits into the line and has no overflow.
(B) case value type 'percent' with image as child-element
-------------------------------------------------------
Take as example again a line with font-size of 12pt and line-height of 175% from its paragraph style, but now with an image as child element.
CSS does not consider line-height inheritance here, because an image is a "replaced" element and for those their own height is used for calculating the line height. Browsers extend the line height if needed, so that the image fits into the line. Word and others follow this way. Only LibreOffice applies the percentage value to the height of the image. I consider this as bug in LibreOffice.
(C) case value type 'length'
--------------------------
Take as example a line with 12pt font-size and line-height 21pt from its paragraph style and a span-element with font-size 36pt.
CSS handles this the same as the value type percentage, because in case of percentage the calculated value and not the percentage is inherited.
I have noticed, that Word, TextMaker, CalligraWords and LibreOffice treat the line-height 21pt as fixed value. The span-element with 36pt overflows the line into the previous and/or next line. CalligraWords shows the overflow. Word, TextMaker and LibreOffice hide the overflow, they cut the span-element. Only GoogleDocs increases the line-height, similar as browsers.
(D) distribution of additional leading
------------------------------------
In case (A) the height of the line increases. The way that is done, is not uniform.
Word seems to calculate like this: Add the height which is calculated from the paragraph font-size (e.g. 175%*12pt) to the top of the previous line, downwards. Align the top of the span-element with this target line. The height, which is calculated from the span-element (e.g. 175%*36pt) is added downwards to this top position and gives the position of the top of the next line.
LibreOffice seems to calculate like this: Add the extended height of the span-element (e.g. 175%*36pt) to the bottom of the previous line, downwards. Align the bottom of the span-element with this point. For the next line add the height from the paragraph font-size (e.g. 175%*12pt) to this bottom line, downwards, and align the bottom of the next line to it.
As result the previous and the next line are at the same position in Word and LibreOffice, but the span-element is at a different position which results in a different baseline of the characters in the same line.