Text rendering cuts off trailing character (depending on zoom level) (rev >= 12488)

Bug #1283194 reported by Shlomi Fish on 2014-02-21
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
David Mathog

Bug Description

Hi all, when opening this SVG file (that was created using Inkscape-0.48.4 and uses the Impact font from the Microsoft corefonts package with a faux Bold+Italics style), the new Inkscape trunk displays the E cut off. It is fine in Inkscape-0.48.4 and all other SVG renderers we tried (Firefox , gwenview, Batik):

https://github.com/shlomif/Shlomi-Fish-Back-to-my-Homepage-Logo/blob/master/back-to-my-homepage-logo/back-to-my-homepage.svg

Here is a log of an IRC conversation on #inkscape with more details:

<rindolf> su_v: http://www.shlomifish.org/Files/files/images/inkscape-trunk-missing-e-curves.png - see the missing curves on the "E" of the homepage.
<rindolf> su_v: well, that's what I found - there may be more.
<su_v> rindolf: and this does not happen with current stable?
* su_v has seen this often, too, but only with certain fonts
<rindolf> su_v: no, it does not.
<su_v> and IIRC it happens with stable too
<su_v> anyway, without file to test (and being sure to have the same fonts installed - ...
<rindolf> su_v: https://github.com/shlomif/Shlomi-Fish-Back-to-my-Homepage-Logo/blob/master/back-to-my-homepage-logo/back-to-my-homepage.svg - I'm opening this file, which uses the font Impact from ms corefonts.
<rindolf> su_v: and on Mageia Linux x86-64 4 Cauldron.
<rindolf> Sorry , s/4 Cauldron/what-will-be-5 Cauldron/
<su_v> reproduced, and indeed with trunk only
<su_v> still ok with r12346, now testing with revisions in-between
<su_v> ok with r12487, not ok with r12488
<su_v> might be reported already, not sure
<su_v> http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12488 merged changes to the text rendering which introduced other known regressions
* a-l-e (~<email address hidden>) has joined
<su_v> (e.g. https://bugs.launchpad.net/inkscape/+bug/1243401 )
<rindolf> su_v: thanks for the investigation.
<rindolf> su_v++
<su_v> rindolf: file a bug report, please
<rindolf> su_v: about what?
<su_v> AFAICT there is none specific to this one
<rindolf> su_v: about the build failure or about the trunk regression?
<su_v> both
<rindolf> su_v: OK, I'll file two bug reports.
* a-l-e has quit (Read error: Operation timed out)
<su_v> rindolf: I think I know what happens (can't be reproduced in trunk in a new file):
<su_v> Impact has no italic or oblique style
<su_v> but with inkscape stable (0.48.4) you could apply a faux italic style
<su_v> trunk no longer supports that (you can only use font styles which are indeed available)
<su_v> the file was created with 0.48.4
<su_v> with trunk, you would have to skew the text object to generate a faux italic style (skew with the select tool transformation handles)
<su_v> still, rendering in current trunk looks wrong (it cuts off the text where the bounding box of the unslanted text version ends)
<rindolf> su_v: https://bugs.launchpad.net/inkscape/+bug/1283174 - here's the build-system bug
<rindolf> su_v: I see. Well, the longer story is that I originally used a font called "Homa" (which is a Persian font) and it had Italics available and fell back to Impact for the Latin characters.
<su_v> the font style in the 0.48.4 actually applies two fake style (bold and italic) - trunk only reports one font style for Impact ("Condensed")
<su_v> still looks like a regression in trunk to me (it should not cut off the text - why does it render the 'K' ok, but cuts off the trailing 'E'?)
<rindolf> su_v: I see.
<rindolf> su_v: well, should I still report it?
<su_v> yes, I think it's worth to be investigated
<su_v> rindolf: did you check how it renders in other SVG viewers?
<rindolf> su_v: let me see.
<su_v> nevermind - Firefox renders it ok (as expected)
<su_v> inkscape should do the same ;)
<rindolf> su_v: it seems fine in gwenview too (I think it's KSVG - not sure).
<rindolf> Or maybe WebKit.
<su_v> Batik 1.7 (Squiggle) renders it ok too (nothing cut off),
<rindolf> Yes.
<rindolf> We can also test rsvg.
<su_v> that one isn't really a reference for SVG compliance ;)
<rindolf> su_v: ah, OK.
<su_v> but it renders it ok, too (nothing cut off) - librsvg 2.40.1
* carandraug has quit (Quit: Leaving)
<rindolf> su_v: OK.
* ksuhku has quit (Quit: Leaving)
<rindolf> su_v: so, what do we do? I'd like to go to bathe now.
<su_v> report a bug, please
<rindolf> su_v: OK.
<rindolf> su_v: I guess I can quote this conversation.

Related branches

Shlomi Fish (shlomif-gmail) wrote :
su_v (suv-lp) wrote :

Reproduced with trunk rev >= 12488 on OS X 10.7.5, as discussed on irc.

Changed in inkscape:
importance: Undecided → Medium
milestone: none → 0.91
status: New → Confirmed
summary: - Bug with drawing the edge of a final "E" with Impact font after a faux
- italics+bold.
+ trunk: text rendering cuts off final "E" with Impact font after a faux
+ italics+bold (rev >= 12488)
tags: added: fonts regression
tags: added: text
su_v (suv-lp) on 2014-11-06
Changed in inkscape:
milestone: 0.91 → 0.92

I experienced the same problem with a proper font variant (not a faux italic style).
I'm attaching a minimal file showing the same problem in the exclamation sign.
The text was composed with Open Sans Ultra-Bold Italic from Google Fonts.
It's apparently a redrawing issue and it depends on the zoom level.

When the text is converted to curves the shape of the glyph is correct.

su_v (suv-lp) on 2015-04-07
summary: - trunk: text rendering cuts off final "E" with Impact font after a faux
+ Text rendering cuts off final "E" with Impact font after a faux
italics+bold (rev >= 12488)
summary: - Text rendering cuts off final "E" with Impact font after a faux
- italics+bold (rev >= 12488)
+ Text rendering cuts off trailing character (depending on zoom level)
+ (rev >= 12488)
su_v (suv-lp) wrote :

New duplicate report bug #1441371 provides test case (SVG file + font file) where the same effect (depending on zoom level) can be observed for the leading (instead of trailing) character (rev >= 12488).

su_v (suv-lp) wrote :

@David - any chance you happen to know what is going on here? The revision (r12488) which likely introduced the reported rendering issue was the original merge of the emf/wmf branch ...

David Mathog (mathog) wrote :

It looks like the bounding box is being specified based on Impact Bold or some other font, and not on Impact Bold + Italic. Select the text and the selection box drops down just to the right of the base of the last E, which is consistent with that. The OP indicates that this is "faux", which I guess means that there is not really a Bold + Italic variant. When that happens the font rendering system has to fall back to some other font, in this case it may be something a bit narrower, which could be why the box is wrong. Other systems may be using other font drawing methods, so they may fall back to a different font, resolving in the sort of difference you see here between Firefox and Inkscape.

Changing the font to Arial, which has a real Bold+Italic gives an appropriate bounding box. That supports the idea it is
a (hidden) font substitution issue.

My memory is a bit murky but I do recall there were some adjustments made somewhere along the line having to do with text decorations and leading and trailing spaces and bounding boxes which might be somewhat involved. The issue was that if text decoration display is to work there must be a bounding box on spaces on the ends of lines - otherwise something like this:

__this_is_underlined_too__

would render like

   this_is_underlined_too

That might be involved here but I'm not quite sure how, since the test case by the OP had no trailing spaces. What it definitely does is provide a way to work around this problem - add a space after the final "E".

It may be that there was some bit of code in older versions of Inkscape that padded out the bounding box specifically to work around this sort of "faux" font issue which was lost at that revision.

David Mathog (mathog) wrote :

1st paragraph: resolving -> resulting

su_v (suv-lp) wrote :

@David Mathog - another example of the text rendering regressions related to changes in r12488 - this time half of the text is cut off at certain zoom levels instead of leading or trailing characters:
* Bug #1450675 “Text is displayed cut in half”
  https://bugs.launchpad.net/inkscape/+bug/1450675

Like duplicate bug #1441371, the test case in bug #1450675 includes all information required to reproduce it (SVG file, links to the fonts used).

ScislaC (scislac) on 2015-05-19
tags: added: blocker
David Mathog (mathog) wrote :

The example in bug #1441371 shows an enormously wide leading J character. Ah, I think I see what might be going on. With these very wide tilted characters advance can be much less than width. Dumping the Queensland font shows for J:

   letter:J advance = 1472 width = 4928

but for Arial it is:

  letter:J advance = 1600 width = 1280

Never mind the absolute scale of those numbers, notice which is larger in each line.

 If advance is being used in lieu of the actual width somewhere this would make the bounding box too small at one end or the other.

David Mathog (mathog) wrote :

The width is calculated here in Layout=TNG-Compute.cpp

    new_glyph.width = unbroken_span.glyph_string->glyphs[glyph_index].geometry.width * font_size_multiplier;

and geometry.width is coming from Pango in this structure:

   https://developer.gnome.org/pango/stable/pango-Glyph-Storage.html#PangoGlyphGeometry

which has only the advance (near as I can tell) called "width".

David Mathog (mathog) wrote :

Please try this patch. It creates a "hybrid" bounding box. The left and right limits come from the glyph's cbox and the top and bottom limits come from the font's ascend and descend values (stretched out slightly to leave room for overline and underline.) In my testing this didn't break text decorations (example to follow) and it seemed to restore the bits of characters cut off on one end or the other of a line of text.

David Mathog (mathog) wrote :

This is an example with text decorations. If anybody reading this messes around with this section of code please be sure that the following still renders OK afterwards.

David Mathog (mathog) wrote :

Here is the text decorations example converted to the Queensland font. I didn't bother fixing up the spacing. Note that the text decorations start from the text origin, not from the left edge of the first character - look at the first capital "A" in any line that starts with "All". I don't know if this the typographically correct thing to do or not. Normal fonts, like Arial, do not have glyphs that are drawn to the left of the origin, but this one does. Note also that if one creates two copies of the word "All", one in Arial and one in Queensland, and left align them as text (the "a over y with a bar on the left" icon), they align to the same place where the text decorations start.

ScislaC (scislac) wrote :

That patch is a huge improvement! I still find certain characters that trigger that rendering issue though, in this case one Q is fine, but more than one Q causes it to cut off. See the attached screenshots.

ScislaC (scislac) wrote :
David Mathog (mathog) wrote :

What font is that?

ScislaC (scislac) wrote :

Affair is the name of it.

David Mathog (mathog) wrote :

That appears to be a font bug.

I obtained a copy of what seems to be a slightly different version of this font here:

  http://www.fontpalace.com/font-download/Affair/

The capital Q in this one did not have the issue you posted, instead of a long tail it turns up and stays only just below the base line. However, the capital R and Z glyphs still have very long tails which get cut off vertically.

Using the ft_example.c program in libTERE from

   http://sourceforge.net/projects/libtere/

as:

  ./ft_example affair

it shows that the font bounding box is:

Face Ascender: 926
Face Descender: -345
Face Bbox: xMin -1140 xMax 4186 yMin -1034 yMax 1584

and those letter's Cboxes are:

letter:R advance = 2304 cbox xMin -483 xMax 4784 yMin -1661 yMax 2976
letter:Z advance = 1408 cbox xMin -1821 xMax 9978 yMin -1667 yMax 2979

but

   http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_FaceRec

says:

 bbox The font bounding box. Coordinates are expressed in font
            units (see units_per_EM). The box is large enough to contain
            any glyph from the font. Thus, bbox.yMax can be seen as the
            `maximal ascender', bbox.yMin as the `minimal descender',
            and the maximal glyph width is given by
            `bbox.xMax-bbox.xMin' (not to be confused with the maximal
            _advance_width_). Only relevant for scalable formats.

Additionally here:

  http://www.freetype.org/freetype2/docs/tutorial/step2.html

it says about the descender:

descender
    The descender is the vertical distance from the horizontal baseline to the lowest ‘character’ coordinate in a font face.
    Unfortunately, font formats don't define the descender in a uniform way. For some formats, it represents the descent of
    all capital latin characters (without accents), for others it is the ascent of the lowest accented character, and finally,
   other formats define it as being equal to bbox.yMin. This field is negative for values below the baseline.

So this is a font error because the yMin of the Cbox of these fonts goes below the descender and outside (below) the face bounding box's yMin. For inkscape it is the former of these problems that causes causing those long flourishes to be truncated.

David Mathog (mathog) wrote :

Patch committed as revision 14192.

Changed in inkscape:
assignee: nobody → David Mathog (mathog)
status: Confirmed → Fix Committed
Krista (kandb435) on 2015-07-06
Changed in inkscape:
status: Fix Committed → Fix Released
su_v (suv-lp) on 2015-07-06
Changed in inkscape:
status: Fix Released → Fix Committed
Christopher M. Rogers (cajhne) wrote :

A temporary "fix" for those using Inkscape 0.91 is to add trailing spaces to the line. This affects the bounding box without affecting the glyphs.

su_v (suv-lp) on 2015-10-01
tags: added: backport-proposed
su_v (suv-lp) wrote :

Fix backported to 0.91.x in rev 13838.

Changed in inkscape:
milestone: 0.92 → 0.91.1
tags: removed: backport-proposed
tags: removed: blocker
Equis (rob-cummingsonline) wrote :

I'm still seeing this in Inkscape 0.92pre2 15127.

David Mathog (mathog) wrote :

That is probably a font or font substitution issue. See post 18 above for instructions on diagnosing what the problem might be. If it is a font problem, unless you can edit the font properties you probably will not be able to fix it. In that case try using a different font. If it is a font substitution issue be sure that the font you think you are using is actually installed in that system.

Equis (rob-cummingsonline) wrote :

It could be. I've seen this bug many, many times in my daily work and I usually work around it by adding a couple spaces to the end or converting the text to a path before I export the artwork to an image.

jazzynico (jazzynico) on 2017-01-28
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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers