Text is displayed cut in half (rev >= 12488)

Bug #1450675 reported by WarrenSensei
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
David Mathog

Bug Description

Inkscape v. 0.91
Windows 7

When trying to input a text object, only the bottom half of the text is displayed.
This seems to be only some fonts. Harrington used to work fine before updating to 0.91, but now does this. Gentium, at the same font size and everything, displays correctly.

Related branches

Revision history for this message
WarrenSensei (warren-sensei) wrote :
su_v (suv-lp)
tags: added: regression
removed: typeface
Revision history for this message
su_v (suv-lp) wrote :

Please add information about which installer package from inkscape.org was used for Inkscape 0.91 -- arch (32bit|64bit), file type (msi|exe|paf.exe|7z) -- to the bug description.

Could you please also attach a reduced test case as Inkscape SVG file to the bug report, to ease further investigation of the reported issue on other systems, and provide information about the fonts required to be installed locally (ideally download links if available for fonts with open licenses)?

Possibly related to the regression tracked in
* Bug #1283194 “Text rendering cuts off trailing character (depending on zoom level) (rev >= 12488)”

Changed in inkscape:
status: New → Incomplete
Revision history for this message
WarrenSensei (warren-sensei) wrote :

Further detail:
Inkscape 0.91 r13725
64bit
.msi installer

Revision history for this message
WarrenSensei (warren-sensei) wrote :

svg

Revision history for this message
WarrenSensei (warren-sensei) wrote :

Screenshot of what I see for this example, in case you don't see it.

Revision history for this message
WarrenSensei (warren-sensei) wrote :
su_v (suv-lp)
Changed in inkscape:
status: Incomplete → New
Revision history for this message
su_v (suv-lp) wrote :

Reproduced with Inkscape 0.91 r 13725 and 0.91+devel r14119 on OS X 10.7.5

Based on tests with archived builds:
- not reproduced with rev <= 12487,
- reproduced with rev >= 12488;
this text rendering regression is caused by changes in r12488, as are those reported in bug #1283194.

A workaround is to convert the text to path (the outlines of the converted glyphs render as expected).

Changed in inkscape:
importance: Undecided → Medium
milestone: none → 0.92
status: New → Confirmed
summary: - Text is displayed cut in half
+ Text is displayed cut in half (rev >= 12488)
su_v (suv-lp)
tags: added: text
Revision history for this message
David Mathog (mathog) wrote :

This apparently has something to do with the bounding box calculations in conjunction with something about the problem fonts which is not quite the same as the fonts which work. Probably some implicit assumption I made about the way fonts behave that these violate. I will try to get to this next week.

Revision history for this message
David Mathog (mathog) wrote :

I found the problem: there are invalid ascender and descender values in the harrington font.

Those value are: ascender 750 descender -170
The bounding box Y limits are: yMin -885 yMax 3080

In fonts that are not broken ascender is ~yMax and descender is ~yMin. Here ascender is a fraction of yMax,
so the glyph gets cut in half.

The revision that broke this changed the bounding box from the one in the font to one based
on ascender and descender. It had to do that so that it could figure out where to place overline
and underline text decorations.

So, on to working around this. Bad ascender and descender values are apparently common,
as described here:

http://www.freetype.org/freetype2/docs/reference/ft2-truetype_tables.html

So it looks like I need to figure out how to get freetype to use the values from the OS/2 tables as these are said to be more reliable.

Revision history for this message
David Mathog (mathog) wrote :

On further consideration, I suggest that the OP contact the people who distribute "Harrington" and get them to fix the Ascender/Descender values. If they won't then find some tool to edit TT fonts and make the change locally.

Or better yet, use a font which isn't broken!

The relevant values in the tables for Harrington are:

Face Ascender: 750
Face Descender: -170
Face Height: 929
Face Bbox: xMin -430 xMax 3162 yMin -885 yMax 3080
Face UpEM: 4096
OS/2 version:2
OS/2 sTypoAscender: 750
OS/2 sTypoDescender: -170
OS/2 sTypoLineGap: 30
OS/2 line spacing: 950
OS/2 usWinAscent: 3080
OS/2 usWinDescent: 885
OS/2 Win line spacing: 3965

750 Ascender value is just wrong, compare it to yMax of 3080, that's why the font is cut in "half". (750 could have
been right if this was some special font meant to be written as squat little characters on a line.)

The sTypoAscender, sTypoDescender values are also wrong. The sum of sTypoAscender + sTypoDescender + sTypoLineGap
is supposed to be about 1 Em. Here it is 950 units, but Units per Em is 4096, so this is only about ~1/4 Em.

The usWinAscent and usWinDescent values correspond 1:1 with the bounding box y limits. This is correct for what those are:

https://www.microsoft.com/typography/otspec/os2.htm

Before the patch Inkscape used the font face bounding box, which is equivalent to the usWinAscent/usWinDescent. The patch stopped doing that because it provided poor information about where to place overline and underline, and that is needed for text decorations.

The issue with trying to work around the broken font is that even when Inkscape can guess with good probability that values are broken it may not be able to guess how to fix the issue. The sum sTypoAscender + sTypoDescender + sTypoLineGap is way off given unitsPerEm. Inkscape can only _guess_ what might be wrong, if all values are scaled wrong it could rescale them to a sum of about 1 em. But what if it is only sTypoAscender which is off? Or sTypoDescender?

Revision history for this message
ScislaC (scislac) wrote :

David: Unfortunately the problem is worse than just relating to ascending and descending as is evidenced by Bug 1283194 . With some fonts it makes editing incredibly unpredictable and really difficult to use. The issue is that if it's inside the bounding box, it should be rendered correctly. In his screenshot, the bounding box is correct, so it should be rendered. Attached is a fun video showing some of the issues the misrendering does to make things even more unpredictable.

tags: added: blocker
Revision history for this message
David Mathog (mathog) wrote :

Patch committed for bug 1283194 as revision 14192.

I don't see the problems with this patch shown in the video of post 11 other than those related to some of the flourishes being truncated. That issue is discussed under bug 1283194.

Changed in inkscape:
status: Confirmed → Fix Committed
assignee: nobody → David Mathog (mathog)
Revision history for this message
su_v (suv-lp) wrote :

Fix for bug #1283194 and this one (bug #1450675) backported to 0.91.x in rev 13838.

Changed in inkscape:
milestone: 0.92 → 0.91.1
su_v (suv-lp)
tags: removed: blocker
jazzynico (jazzynico)
Changed in inkscape:
milestone: 0.91.1 → 0.92
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.