[
https://issues.apache.org/jira/browse/FOP-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122144#comment-18122144
]
Jason Harrop commented on FOP-2349:
-----------------------------------
This is still present on main, and since FOP-2722 it is half fixed.
{{processWordMapping}} now returns the letter-space count (from
{{calculateLetterSpaces}}, the same count as {{processWordNoMapping}}), but it
still adds nothing to the word's width, and it is still not passed
{{letterSpaceIPD}}. The renderer spaces every glyph whichever path was taken.
So a letter-spaced paragraph in any font with GSUB or GPOS tables (every
OpenType font while complex-script support is on, the default) is measured
short, and its lines run past the end of the line: 3pt of letter spacing in
12pt Carlito overruns a 260pt line by up to 23pt.
On main a second defect hides this for fonts that kern through GPOS:
{{PDFPainter.drawTextWithDP}} does not paint the letter spacing at all
(FOP-3344, apache/xmlgraphics-fop#113), so the text is both measured and
painted without it. Measured with Carlito, a 260pt line and a paragraph of 29
words:
* main: 4 lines, unspaced, ending at 218.9, 228.9 and 233.9pt;
* main with FOP-3344: the same 4 lines, now spaced, ending at 302.3, 297.3 and
302.7pt, where the line ends at 280pt;
* with -nocs (the plain path): 5 lines, all inside the margin (266.1, 251.8,
275.3, 255.4pt).
The fix goes the way Andreas outlined above, with one difference: it does not
count glyphs ({{mcs.length() - 1}}). It passes {{letterSpaceIPD}} to
{{processWordMapping}} and adds the character count FOP-2722 already computes
to the width, as {{processWordNoMapping}} does, so the width agrees with the
count the method returns. Measured on main with FOP-3344 and the fix: the
complex-script path sets the same 5 lines as -nocs, ending at 265.6, 251.3,
275.2 and 254.9pt. The 0.4pt differences are GPOS kerning, which main applies
even to a font configured kerning="false" (FOP-3343). The fix needs FOP-3344
alongside it: without that, the spacing is measured and then not painted, and
lines come out short. So the pull request, titled FOP-2349, is stacked on #113.
It adds
{{GlyphMappingTestCase.testLetterSpacesInTheWidthOfAWordInAFontWithLayoutTables}}:
"word" in DejaVuLGCSerif with no letter spacing and with 3pt must differ by 3
x 3pt; before the fix they differ by 0.
The mismatch Glenn Adams raised is unchanged by this and not measured here: the
painter spaces glyphs, marks included, while the count is in characters, so the
two differ wherever substitution changes the glyph count (a ligature, a
decomposition) or marks are present.
> Inline elements with letter-spacing and custom font aren't correctly sized
> --------------------------------------------------------------------------
>
> Key: FOP-2349
> URL: https://issues.apache.org/jira/browse/FOP-2349
> Project: FOP
> Issue Type: Bug
> Components: layout/unqualified
> Reporter: Matthias Reischenbacher
> Priority: Major
> Attachments: FOP-2349.fo, inline-letter-spacing.pdf,
> inline-letter-spacing.xml
>
>
> If letter-spacing is applied to an inline element, that uses one of the
> base-14 fonts, the width of the inline element is automatically expanded with
> the letter-spacing.
> However if a custom font is used (e.g. Arial) the inline width isn't expanded
> anymore, which prevents from using background-color or borders for the inline
> element.
> See attached PDF which illustrates the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
