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

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

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.

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).

@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 ...

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.

1st paragraph: resolving -> resulting

@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).

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.

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".

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.

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.

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.

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.

What font is that?

Affair is the name of it.

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.

Patch committed as revision 14192.

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.

Fix backported to 0.91.x in rev 13838.

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

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.

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.