unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Cc: rahguzar@zohomail.eu, larsi@gnus.org, 50951@debbugs.gnu.org,
	visuweshm@gmail.com
Subject: bug#50951: 28.0.50; Urdu text is not displayed correctly
Date: Thu, 22 Sep 2022 08:37:24 +0300	[thread overview]
Message-ID: <83h710t1ez.fsf@gnu.org> (raw)
In-Reply-To: <wlleqd31tl.wl-mituharu@math.s.chiba-u.ac.jp> (message from YAMAMOTO Mitsuharu on Wed, 21 Sep 2022 11:20:54 +0900)

> Date: Wed, 21 Sep 2022 11:20:54 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: rahguzar@zohomail.eu,
> 	visuweshm@gmail.com,
> 	larsi@gnus.org,
> 	50951@debbugs.gnu.org
> 
> > If the problem is rounding, I think we should do this adjustment only
> > when the last glyph has a non-zero width that was rounded to zero, no?
> > Otherwise, we are inventing adjustments out of thin air, which could
> > adversely affect the displayed result, I think?
> > 
> > Or maybe we should have a variable that controls this heuristic?
> > 
> > Bottom line: I'm uneasy with messing with the grapheme cluster data
> > without some sound basis.  We delegate this job to a text-shaping
> > engine for a reason.  But if there is a sound basis for this
> > adjustment, could you please elaborate on it?
> > 
> > Thanks.
> 
> IIUC, the only "unsound" case is that the width of a grapheme cluster
> is exactly 0 before rounding.  I think such a case is quite rare.  And
> even for such a case, Emacs needs to put at least extra 1 pixel to
> move the cursor to the position of the grapheme cluster.  So the
> adjustment made by the patch is minimum and necessary.
> 
> The current (unpatched) master may put multiple pixels (space width of
> the font as in Line 32433 above), and moreover the corresponding
> glyphs are not displayed.  If we keep this behavior for the "unsound"
> case, the result would be much more apart from the optimal.

Can you please point me to the place(s) in our code where this
rounding takes place?

Also, I asked whether you could elaborate on the rationale for
adjusting the zero width to be 1 pixel, and I don't think you answered
that particular question.  What you are saying (AFAIU) is that
heuristically the results of using this adjustment are better, at
least in this case.  I don't argue with that, but I wonder whether
there's some rationale for this that isn't just heuristics?  IOW, do
you know how come hb-view doesn't have this problem? what do we do
that produces the zero width where hb-view doesn't?

Thanks.





  parent reply	other threads:[~2022-09-22  5:37 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
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 [this message]
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=83h710t1ez.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=50951@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=mituharu@math.s.chiba-u.ac.jp \
    --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).