[
https://issues.apache.org/jira/browse/FOP-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123196#comment-18123196
]
Jason Harrop commented on FOP-1896:
-----------------------------------
This is still present on main, and the second half of the 2011 patch matters
more than the first.
1. OpenFont.determineAscDesc takes OS/2 sTypoAscender and sTypoDescender, in
its first branch and in its fallback, without checking that the descender is at
or below the baseline. Several shipping fonts have the descender's sign wrong.
Windows' Wingdings, Wingdings 2 and 3, Lucida Sans, Lucida Fax and Lucida Sans
Typewriter all have sTypoDescender +420 of 2048 where their hhea descender is
-432. Maiandra GD, Haettenschweiler and Lucida Handwriting are similar. FOP
takes the positive value, so the text area lies wholly above the baseline
(0.565 em for Wingdings), and the underline, placed from the descender, runs
through the letters. That is this issue's report.
2. guessVerticalMetricsFromGlyphBBox replaces the ascender and descender with
the bounds of the 'd' and 'p' glyphs whenever the two together exceed the em,
whether or not it found those glyphs. A font without them gets an ascender and
a descender of 0. TTFFileTestCase asserts exactly that for AndroidEmoji, beside
"TODO: Nedd to be fixed?". Of 2,547 distinct font files loaded through
FontLoader here, 978 get 0 and 0. They include most Noto fonts for scripts
other than Latin (Devanagari, Bengali, Thai, Arabic, Hebrew, Sinhala and the
rest), the Droid script fonts, MT Extra and Algerian. With a text area of
height 0, the baseline sits in the middle of the line and the glyphs rise into
the line above.
Fixing (1) alone makes Wingdings worse: its hhea box exceeds the em and it has
no 'd' or 'p', so it falls to (2) and gets 0 and 0. Both conditions are needed:
- determineAscDesc: use the OS/2 values (first branch and fallback) only when
sTypoDescender <= 0;
- guessVerticalMetricsFromGlyphBBox: replace only when localAscender > 0 &&
localDescender < 0.
Measured at 11pt (area tree, text area height and baseline from its top):
{noformat}
Wingdings 6.215pt, 8.470pt -> 12.188pt, 9.878pt (Word:
12.21pt, 9.89pt)
Lucida Sans 6.215pt, 8.470pt -> 10.582pt, 8.470pt
Noto Sans Devanagari 0pt, 0pt -> 14.344pt, 9.856pt
{noformat}
Every font the change moves had, before it, an ascender of 0 or a descender at
or above the baseline. After it, none of the 2,547 has either. The tests need
no new font: TTFFileTestCase patches sTypoDescender (OS/2 offset 70) in memory.
AndroidEmoji with +650 is Wingdings' case, and expects its hhea 2200 and -650.
DejaVuLGCSerif with +492 is the Lucida case, and expects its glyph bounds 1556
and -426. The AndroidEmoji assertion in testGetLowerCaseAscent becomes 2200.
Pull request: https://github.com/apache/xmlgraphics-fop/pull/119, against main.
The fop-core suite passes with it (3663 tests, 0 failures) and checkstyle
reports 0 violations; the three tests fail without it.
> Incorrect text underlines position for some fonts
> -------------------------------------------------
>
> Key: FOP-1896
> URL: https://issues.apache.org/jira/browse/FOP-1896
> Project: FOP
> Issue Type: Bug
> Components: font/unqualified
> Affects Versions: 1.0
> Environment: Operating System: All
> Platform: All
> Reporter: Alexander Chingarev
> Attachments: TTFFile.java, underlines_issue.zip
>
>
> For some fonts text underlines may be incorrect. They are positioned upper
> than they should be or disappear at all.
> Quick investigation of those fonts and FOP sources shows that it depends on
> sTypoAscender used in FOP.
> Normally sTypoAscender is negative and underlines are positioned correctly in
> this case.
> If sTypoDecender is positive then text is crossed out instead of underlined.
> If it's 0 then underline is invisible.
> Attached are FO file and result PDF.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
