OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OFFICE-3997) Be more precise about differences to XSL_FO for attribute fo:line-height


     [ https://issues.oasis-open.org/browse/OFFICE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis Cave updated OFFICE-3997:
---------------------------------
    Resolution: 
The defined values for the {{fo:line-height}} attribute are {{normal}}, a value of type {{percent}}, or a value of type {{nonNegativeLength}}.

In the OpenDocument XSL compatible namespace, the {{fo:line-height}} attribute does not support the {{inherit}}, {{number}}, and {{space}} values.

In the OpenDocument XSL compatible namespace the values are interpreted as this:
 * {{normal}}: activates the default line height calculation. The calculation method is not specified, but should be similar to a percentage in the range of 100% to 120%. It may consider font metrics. The value {{normal}} disables the effects of {{style:line-height-at-least}} 20.320Âand {{style:line-spacing}} 20.321.

 * {{a value of type }}{{percent}}: The font-size is multiplied with the percent value. In case the line contains content of descendants of the paragraph, for which a different font-size is specified, the maximum of the font-sizes is used. This calculated value is a minimum line-height. If content would vertically overflow the line area, e.g. an image with a larger specified height, the height of the line is increased till the content does not overflow. The vertical position of the baseline is implementation-dependent. In case a {{style:line-height-at-least}} 20.320 or a {{style:line-spacing}} 20.321 attribute occurs in addition in the same element, the attribute {{fo:line-height}} 20.207 has precedence.

 * a value of type {{nonNegativeLength}}: The value specifies a fixed line-height. The content of the line might vertically overflow the line area. It is implementation-dependent, whether the overflow is shown or hidden. In case a {{style:line-height-at-least}} 20.320 or a {{style:line-spacing}} 20.321 attribute occurs in addition in the same element, the attribute {{fo:line-height}} 20.207 has precedence.

{quote}Note: The effect of this attribute value in the OpenDocument XSL compatible namespace differs from the XSL and the associated CSS specifications.
{quote}

> Be more precise about differences to XSL_FO for attribute fo:line-height
> ------------------------------------------------------------------------
>
>                 Key: OFFICE-3997
>                 URL: https://issues.oasis-open.org/browse/OFFICE-3997
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Improvement
>          Components: Text
>            Reporter: Regina Henschel
>            Assignee: Regina Henschel
>            Priority: Major
>             Fix For: ODF 1.4
>
>
> 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.



--
This message was sent by Atlassian Jira
(v8.3.3#803004)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]