From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Rah Guzar <rahguzar@zohomail.eu>
Cc: 50951@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
larsi@gnus.org, Visuwesh <visuweshm@gmail.com>
Subject: bug#50951: 28.0.50; Urdu text is not displayed correctly
Date: Tue, 20 Sep 2022 12:41:40 +0900 [thread overview]
Message-ID: <wlzgeubtl7.wl-mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <87mtayymk5.fsf@zohomail.eu>
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]
On Sun, 18 Sep 2022 01:37:39 +0900,
Rah Guzar wrote:
>
>
> I finally tested the patches and both of them improve the situation by a
> lot but problems still remain. One word that is not rendered by
> accurately by them is
>
> ہنگام
>
> Where is problem is fourth character which is
> character: گ (displayed as گ) (codepoint 1711, #o3257, #x6af)
> charset: unicode-bmp (Unicode Basic Multilingual Plane (U+0000..U+FFFF))
> code point in charset: 0x06AF
> script: arabic
>
> This character should be rendered as a circle and two slanted lines
> which seem to get clipped.
Thanks for testing.
The width of grapheme cluster corresponding to U+06AF (ARABIC LETTER
GAF) is rounded to zero, and Emacs does not display such clusters:
xdisp.c:
32424 gstring = composition_gstring_from_id (it->cmp_it.id);
32425 it->pixel_width
32426 = composition_gstring_width (gstring, it->cmp_it.from, it->cmp_it.to,
32427 &metrics);
32428 if (it->pixel_width == 0)
32429 {
32430 it->glyph_not_available_p = true;
32431 it->phys_ascent = it->ascent;
32432 it->phys_descent = it->descent;
32433 it->pixel_width = face->font->space_width;
32434 }
32435 else
The attached patch avoids zero-width grapheme clusters by adding 1 to
the width of the last glyph in such clusters.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
[-- Attachment #2: avoid-zero-width-grapheme-clusters.diff --]
[-- Type: application/octet-stream, Size: 2464 bytes --]
diff --git a/src/composite.c b/src/composite.c
index 249d7587f6..5e856fd5e5 100644
--- a/src/composite.c
+++ b/src/composite.c
@@ -800,6 +800,48 @@ composition_gstring_width (Lisp_Object gstring, ptrdiff_t from, ptrdiff_t to,
return width;
}
+/* Adjust the width of each grapheme cluster of GSTRING because
+ zero-width grapheme clusters are not displayed. If the width is
+ zero, then the width of the last glyph in the cluster is
+ incremented. */
+
+void
+composition_gstring_adjust_zero_width (Lisp_Object gstring)
+{
+ ptrdiff_t from = 0;
+ int width = 0;
+
+ for (ptrdiff_t i = 0; i < LGSTRING_GLYPH_LEN (gstring); i++)
+ {
+ Lisp_Object glyph = LGSTRING_GLYPH (gstring, i);
+
+ if (NILP (glyph) || from != LGLYPH_FROM (glyph))
+ {
+ eassert (i > 0);
+ Lisp_Object last = LGSTRING_GLYPH (gstring, i - 1);
+
+ if (width == 0)
+ {
+ if (NILP (LGLYPH_ADJUSTMENT (last)))
+ LGLYPH_SET_ADJUSTMENT (last,
+ CALLN (Fvector,
+ make_fixnum (0), make_fixnum (0),
+ make_fixnum (LGLYPH_WIDTH (last)
+ + 1)));
+ else
+ ASET (LGLYPH_ADJUSTMENT (last), 2,
+ make_fixnum (LGLYPH_WADJUST (last) + 1));
+ }
+ if (NILP (glyph))
+ break;
+ from = LGLYPH_FROM (glyph);
+ width = 0;
+ }
+ width += (NILP (LGLYPH_ADJUSTMENT (glyph))
+ ? LGLYPH_WIDTH (glyph) : LGLYPH_WADJUST (glyph));
+ }
+}
+
static Lisp_Object gstring_work;
static Lisp_Object gstring_work_headers;
diff --git a/src/composite.h b/src/composite.h
index d77dd0d506..8a6fd203d0 100644
--- a/src/composite.h
+++ b/src/composite.h
@@ -340,6 +340,7 @@ #define LGLYPH_WADJUST(g) (VECTORP (LGLYPH_ADJUSTMENT (g)) \
extern bool composition_gstring_p (Lisp_Object);
extern int composition_gstring_width (Lisp_Object, ptrdiff_t, ptrdiff_t,
struct font_metrics *);
+extern void composition_gstring_adjust_zero_width (Lisp_Object);
extern bool find_automatic_composition (ptrdiff_t, ptrdiff_t, ptrdiff_t,
ptrdiff_t *, ptrdiff_t *,
diff --git a/src/font.c b/src/font.c
index 413cb381ee..defbb5084b 100644
--- a/src/font.c
+++ b/src/font.c
@@ -4678,6 +4678,7 @@ DEFUN ("font-shape-gstring", Ffont_shape_gstring, Sfont_shape_gstring, 2, 2, 0,
from = LGLYPH_FROM (glyph);
to = LGLYPH_TO (glyph);
}
+ composition_gstring_adjust_zero_width (gstring);
return composition_gstring_put_cache (gstring, XFIXNUM (n));
shaper_error:
next prev parent reply other threads:[~2022-09-20 3:41 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 20:11 bug#50951: 28.0.50; Urdu text is not displayed correctly Rah Guzar
2021-10-02 6:07 ` Eli Zaretskii
[not found] ` <CAP094xCyzg62eHeYCUkWy+eBCbEXC_AAU5YFbhTCcCR0cAOCQw@mail.gmail.com>
2021-10-02 11:43 ` bug#50951: Fwd: " Rah Guzar
2021-10-02 12:18 ` Eli Zaretskii
2021-10-02 12:47 ` Rah Guzar
2021-10-02 13:09 ` Eli Zaretskii
2021-10-02 14:19 ` Rah Guzar
2021-10-02 14:50 ` Eli Zaretskii
[not found] ` <CAP094xBq9YjL6xS56t-C3uhSH69TawhsCrF2FdSMySeDpZfGNw@mail.gmail.com>
2021-10-02 15:09 ` Eli Zaretskii
2021-10-02 15:18 ` Rah Guzar
2021-10-02 14:18 ` Andreas Schwab
2021-10-02 14:40 ` Eli Zaretskii
2021-10-02 15:07 ` Rah Guzar
2021-10-02 15:14 ` Eli Zaretskii
[not found] ` <CAP094xAoHdQZoPL9y6aZOq-WGZe0cYtNsm9Trm+yBiyjyZ4j7g@mail.gmail.com>
2021-10-02 15:54 ` Eli Zaretskii
2021-10-02 16:06 ` Rah Guzar
2021-10-02 16:09 ` Eli Zaretskii
2022-09-04 21:07 ` Lars Ingebrigtsen
2022-09-05 11:22 ` Eli Zaretskii
2022-09-05 11:57 ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-05 12:29 ` Eli Zaretskii
2022-09-05 13:03 ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-05 13:55 ` Eli Zaretskii
[not found] ` <87pmg97vsg.fsf@zohomail.eu>
2022-09-05 15:47 ` Eli Zaretskii
2022-09-06 4:26 ` Visuwesh
2022-09-06 11:05 ` Eli Zaretskii
2022-09-06 13:18 ` Visuwesh
2022-09-07 6:18 ` YAMAMOTO Mitsuharu
2022-09-07 11:27 ` Eli Zaretskii
2022-09-08 6:06 ` Visuwesh
2022-09-09 15:00 ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-17 16:37 ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-17 17:00 ` Eli Zaretskii
2022-09-20 3:41 ` YAMAMOTO Mitsuharu [this message]
2022-09-20 11:07 ` Eli Zaretskii
2022-09-21 2:20 ` YAMAMOTO Mitsuharu
2022-09-21 2:25 ` YAMAMOTO Mitsuharu
2022-09-22 5:37 ` Eli Zaretskii
2022-09-25 7:18 ` YAMAMOTO Mitsuharu
2022-09-26 7:18 ` Eli Zaretskii
2022-09-27 0:29 ` YAMAMOTO Mitsuharu
2022-09-20 12:35 ` Rah Guzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-11 10:26 ` Visuwesh
2022-09-11 11:11 ` Visuwesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=wlzgeubtl7.wl-mituharu@math.s.chiba-u.ac.jp \
--to=mituharu@math.s.chiba-u.ac.jp \
--cc=50951@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
--cc=rahguzar@zohomail.eu \
--cc=visuweshm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).