After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 612561 - Text tool cuts off last character in Italic text
Text tool cuts off last character in Italic text
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.6.6
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 647861 654136 670848 683597 700745 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-03-11 13:04 UTC by Michal Ludvig
Modified: 2018-05-24 12:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example with cut-off last chars on every line (23.45 KB, image/jpeg)
2010-03-11 13:04 UTC, Michal Ludvig
Details
XCF version of the example (24.02 KB, image/x-xcf)
2010-03-11 13:05 UTC, Michal Ludvig
Details
test xcf (38.69 KB, image/x-xcf)
2015-02-13 11:47 UTC, Massimo
Details

Description Michal Ludvig 2010-03-11 13:04:08 UTC
Created attachment 155852 [details]
Example with cut-off last chars on every line

When writing text with essentially any Italic-style font and the text is set to Justify:filled the last character on the line (or part of the char) is cut off. It doesn't depend on the font used, whether or not it's with accents or plain ascii. See the attached example - the first three lines should end with "textu", "do" and "koncová".

My OS is OpenSUSE 11.1 and OpenSUSE 11.2, two different PCs, same problem.
Comment 1 Michal Ludvig 2010-03-11 13:05:11 UTC
Created attachment 155853 [details]
XCF version of the example
Comment 2 Michael Schumacher 2010-03-11 15:30:46 UTC
I think that this is a duplicate, but so far my Bugzilla searches haven't turned up any existing bugs.
Comment 3 Michael Natterer 2010-03-11 18:39:53 UTC
And I can reproduce it, even with master.
Comment 4 Michael Natterer 2010-03-11 21:33:46 UTC
I'm starting to think the bug might be in pango. In your example, and in
various cases I tried, the text is rendered larger than the text layer,
even though we set the text layer's size on the pango layout
using pango_layout_set_width().
Comment 5 Michael Natterer 2010-03-11 21:50:06 UTC
Or maybe not, pango_layout_set_width() apparently sets the logical width
at which a line break should happen, and text can be larger than its
logical size. Will talk to Behdad about this problem because I don't
think there is pango API that does what we want.
Comment 6 Sven Neumann 2010-03-11 22:04:46 UTC
There is. We need to use the ink rectangle to dimension the text layer. The problem is just that this means that the layer size may be different from the size of the text box. And the other problem is that you want to use the logical text boundaries when aligning text layers with respect to each other. So we'd have to somehow have text layers that have a logical size that may differ from their pixel size.
Comment 7 Michael Natterer 2010-03-12 09:22:53 UTC
Exactly :) I was in fact wrapping my mind around new GIMP API to do just that.
However, pango indeed lacks API to say "this is the available space for the
layout, in pixels", because giving the available space in terms of logical
extents doesn't help a bit when there is limited real space (unlike in
GIMP, where we can simply choose to make the layer large enough to hold the
ink extents).
Comment 8 Michael Natterer 2011-04-16 08:36:06 UTC
*** Bug 647861 has been marked as a duplicate of this bug. ***
Comment 9 Michael Natterer 2012-01-08 02:34:59 UTC
*** Bug 654136 has been marked as a duplicate of this bug. ***
Comment 10 Michael Natterer 2012-02-28 10:45:11 UTC
*** Bug 670848 has been marked as a duplicate of this bug. ***
Comment 11 Michael Natterer 2012-09-08 06:34:11 UTC
*** Bug 683597 has been marked as a duplicate of this bug. ***
Comment 12 Michael Natterer 2013-05-20 22:11:32 UTC
*** Bug 700745 has been marked as a duplicate of this bug. ***
Comment 13 Massimo 2015-02-13 11:47:42 UTC
Created attachment 296768 [details]
test xcf

So, this bug is a limitation in GIMP: when box mode is fixed
GIMP uses text->box_width for setting both the width at which
lines are broken:

https://git.gnome.org/browse/gimp/tree/app/text/gimptextlayout.c?h=gimp-2-8#n169

and the size of the layer:

https://git.gnome.org/browse/gimp/tree/app/text/gimptextlayout.c?h=gimp-2-8#n195

this despite it previously computed a layer width large enough
to include all layout ink extent:

https://git.gnome.org/browse/gimp/tree/app/text/gimptextlayout.c?h=gimp-2-8#n617

When box_width is smaller than ink.width the text layer is
smaller than necessary.

But there is also a cut off when box_width is much bigger than
necessary with right aligned LTR texts and likely with left
aligned RTL texts, because the text layer x-offset is computed using
the layout width and not the effective MAX (logical, ink)width.

The xcf attached has two copies of two pairs of text layers one
rendered with todays master and the other after patching GIMP.

diff --git a/app/text/gimptextlayout.c b/app/text/gimptextlayout.c
index 02c43ad..1109eba 100644
--- a/app/text/gimptextlayout.c
+++ b/app/text/gimptextlayout.c
@@ -633,7 +633,7 @@ gimp_text_layout_position (GimpTextLayout *layout)
       GimpTextDirection base_dir = layout->text->base_dir;
       gint              width;
 
-      pango_layout_get_pixel_size (layout->layout, &width, NULL);
+      width = layout->extents.width;
 
       if ((base_dir == GIMP_TEXT_DIRECTION_LTR && align == PANGO_ALIGN_RIGHT) ||
           (base_dir == GIMP_TEXT_DIRECTION_RTL && align == PANGO_ALIGN_LEFT))


This bug is much more evident using fonts like the font
mentioned in this (also relevant) cairo bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=89080
Comment 14 Michael Natterer 2016-03-15 22:51:24 UTC
That seems to make total sense.
Comment 15 GNOME Infrastructure Team 2018-05-24 12:45:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/325.