https://bugzilla.redhat.com/show_bug.cgi?id=1436077
--- Comment #15 from fujiwara <tfujiwar(a)redhat.com> ---
(In reply to Mike FABIAN from comment #13)
I think it works also when the width of A and B are the same and
also when width of A < width of B.
Because the patch resets the iterator remembering the current width
to the width of the next character after the zwj or skin tone modifier:
iter->wide = width_iter_iswide (ch)
So Pango would only break if yet another width change is encountered
and that new width change is *not* at a zwj or skin tone modifier.
OK, I think iter->wide is used the return value and mean what value is applied
to iter->wide finally and wide is the member of PangoWidthIter instead of a
local variable.
But you believe it's used in locally only so it's ok.
Probably I think width_iter_next() also needs to have the exception of 0xfe00 -
0xfe0f.
And I'm thinking another patch:
--- pango-1.40.4/pango/pango-context.c.orig 2017-03-30 19:03:28.081488378
+0900
+++ pango-1.40.4/pango/pango-context.c 2017-03-31 18:@@ -1395,11 +1407,13 @@
itemize_state_process_run (ItemizeState
* characters if they don't, HarfBuzz will compatibility-decompose them
* to ASCII space...
* See bugs #355987 and #701652.
+ * U+0023 FE0F 20E3 has G_UNICODE_NON_SPACING_MARK
*/
type = g_unichar_type (wc);
if (G_UNLIKELY (type == G_UNICODE_CONTROL ||
type == G_UNICODE_FORMAT ||
type == G_UNICODE_SURROGATE ||
+ type == G_UNICODE_NON_SPACING_MARK ||
(type == G_UNICODE_SPACE_SEPARATOR && wc != 0x1680u /*
OGHAM SPACE MARK */)))
{
shape_engine = NULL;
58:21.526336181 +0900
--
You are receiving this mail because:
You are on the CC list for the bug.