From: Eli Zaretskii <eliz@gnu.org>
To: Khaled Hosny <dr.khaled.hosny@gmail.com>
Cc: behdad@behdad.org, far.nasiri.m@gmail.com, 33729@debbugs.gnu.org
Subject: bug#33729: 27.0.50; Partial glyphs not rendered for Gujarati with Harfbuzz enabled (renders fine using m17n)
Date: Sat, 29 Dec 2018 16:49:23 +0200 [thread overview]
Message-ID: <838t085qx8.fsf@gnu.org> (raw)
In-Reply-To: <20181224173723.GH6568@macbook.localdomain> (message from Khaled Hosny on Mon, 24 Dec 2018 19:37:23 +0200)
> Date: Mon, 24 Dec 2018 19:37:23 +0200
> From: Khaled Hosny <dr.khaled.hosny@gmail.com>
> Cc: rgm@gnu.org, far.nasiri.m@gmail.com, behdad@behdad.org,
> 33729@debbugs.gnu.org, kaushal.modi@gmail.com
>
> On Mon, Dec 24, 2018 at 06:10:49PM +0200, Eli Zaretskii wrote:
> > > Date: Mon, 24 Dec 2018 04:08:47 +0200
> > > From: Khaled Hosny <dr.khaled.hosny@gmail.com>
> > > Cc: rgm@gnu.org, far.nasiri.m@gmail.com, behdad@behdad.org,
> > > 33729@debbugs.gnu.org, kaushal.modi@gmail.com
> > >
> > > I think we are almost good now. There is only one serious FIXME left:
> > >
> > > /* FIXME: guess_segment_properties is BAD BAD BAD.
> > > * we need to get these properties with the LGSTRING. */
> > > #if 1
> > > hb_buffer_guess_segment_properties (hb_buffer);
> > > #else
> > > hb_buffer_set_direction (hb_buffer, XXX);
> > > hb_buffer_set_script (hb_buffer, XXX);
> > > hb_buffer_set_language (hb_buffer, XXX);
> > > #endif
> > >
> > > We need to know, for a given lgstring we are shaping:
> > > * Its direction (from applying bidi algorithm). Each lgstring we are
> > > shaping must be of a single direction.
> >
> > Communicating this to ftfont_shape_by_hb will need changes in a couple
> > of interfaces (the existing shaping engines didn't need this
> > information). I will work on this soon.
>
> Great.
Done. Please test. I made sure it compiles, but I couldn't actually
test the results, as I don't have access to a GNU/Linux system with
GUI display. So it could be that I misunderstood the Harfbuzz APIs,
as I was essentially flying blind, guided only by the Harfbuzz docs.
In particularly, I hope I understood correctly the way we should leave
to Harfbuzz guess the properties not explicitly provided by the Emacs
context, both for the direction of the text and its script.
> > > * Its script, possibly after applying something like:
> > > http://unicode.org/reports/tr24/#Common
> >
> > Per previous discussions, we decided to use the Harfbuzz built-in
> > methods for determining the script, since Emacs doesn't have this
> > information, and adding it will just do the same as Harfbuzz does,
> > i.e. find the first character whose script is not Common etc., using
> > the UCD database. I think it was you who suggested to use the
> > Harfbuzz built-ins in this case.
>
> The built-in HarfBuzz code is for getting the script for a given
> character, but resolving characters with Common script is left to the
> client. Suppose you have this string (upper case for RTL) ABC 123 DEF,
> what HarfBuzz sees during shaping is three separate chunks of text ABC,
> 123, DEF. The 123 part is all Common script characters and thus
> hb_buffer_guess_segment_properties won’t be able to guess anything (and
> based on the font and the script, this can cause rendering differences).
> Emacs will have to resolve the script of Common characters before
> applying bidi algorithm and pass that down to HarfBuzz.
See my followup questions about this. For now, I left this aspect to
HarfBuzz.
> > > * Its language, is Emacs allows setting text language (my understand is
> > > that it doesn’t). Some languages really need this for applying
> > > language-specfic features (Urdu digits, Serbian alternate glyphs, etc.).
> >
> > We don't currently have a language property for chunks of text, we
> > only have the current global language setting determined from the
> > locale (and there's a command to change that for Emacs, should the
> > user want it). This is not really appropriate for multilingual
> > buffers, but we will have to use that for now, and hope that in the
> > future, infrastructure will be added to allow more flexible
> > determination of the language of each run of text. (I see that
> > Harfbuzz already looks a the locale for its default language, but
> > since Emacs allows user control of this, however unlikely, I think
> > it's best to use the value Emacs uses.) I will work on this as well.
>
> Yes, better pass that from Emacs to HarfBuzz.
Done, but please see the FIXME I left behind. For testing purposes,
you can change the current language like this:
M-x set-locale-environment RET xx_YY.CODESET RET
For example:
M-x set-locale-environment RET sr_RS.UTF-8 RET
for the Cyrillic Serbian locale. This should change the value of
current-iso639-language to the symbol 'sr'.
Please tell if you encounter any difficulties with the code I added,
or if you need any further help.
Thanks.
next prev parent reply other threads:[~2018-12-29 14:49 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 20:20 bug#33729: 27.0.50; Partial glyphs not rendered for Gujarati with Harfbuzz enabled (renders fine using m17n) Kaushal Modi
2018-12-13 20:25 ` Kaushal Modi
2018-12-13 20:31 ` Khaled Hosny
2018-12-13 20:43 ` Kaushal Modi
2018-12-13 20:53 ` Khaled Hosny
2018-12-13 21:04 ` Kaushal Modi
2018-12-14 5:57 ` Eli Zaretskii
2018-12-14 7:48 ` Eli Zaretskii
2018-12-14 7:50 ` Khaled Hosny
2018-12-14 10:03 ` Eli Zaretskii
2018-12-14 11:03 ` Khaled Hosny
2018-12-14 13:42 ` Eli Zaretskii
2018-12-14 15:25 ` Eli Zaretskii
2018-12-17 0:30 ` Glenn Morris
2018-12-17 15:55 ` Eli Zaretskii
2018-12-20 18:58 ` Eli Zaretskii
2018-12-20 20:45 ` Behdad Esfahbod
2018-12-22 8:54 ` Khaled Hosny
2018-12-22 9:06 ` Khaled Hosny
2018-12-22 10:11 ` Eli Zaretskii
2018-12-22 15:15 ` Khaled Hosny
2018-12-22 15:27 ` Behdad Esfahbod
2018-12-22 15:42 ` Khaled Hosny
2018-12-22 15:42 ` Eli Zaretskii
2018-12-22 15:49 ` Khaled Hosny
2018-12-22 16:33 ` Eli Zaretskii
2018-12-22 19:38 ` Eli Zaretskii
2018-12-22 20:59 ` Khaled Hosny
2018-12-23 3:34 ` Eli Zaretskii
2018-12-23 13:51 ` Khaled Hosny
2018-12-23 16:00 ` Eli Zaretskii
2018-12-24 2:08 ` Khaled Hosny
2018-12-24 4:12 ` Kaushal Modi
2018-12-24 16:10 ` Eli Zaretskii
2018-12-24 17:37 ` Khaled Hosny
2018-12-24 18:07 ` Eli Zaretskii
2019-01-05 21:15 ` Khaled Hosny
2019-01-06 16:03 ` Eli Zaretskii
2019-01-27 17:12 ` Eli Zaretskii
2019-01-29 22:25 ` Khaled Hosny
2018-12-29 14:49 ` Eli Zaretskii [this message]
2019-01-05 20:53 ` Khaled Hosny
2019-01-05 21:04 ` Khaled Hosny
2019-01-06 17:54 ` Eli Zaretskii
2019-01-27 17:12 ` Eli Zaretskii
2019-01-29 22:33 ` Khaled Hosny
2019-01-06 15:50 ` Eli Zaretskii
2019-01-29 22:29 ` Khaled Hosny
2022-04-29 12:47 ` Lars Ingebrigtsen
2022-04-29 13:24 ` Eli Zaretskii
2019-01-27 17:09 ` Eli Zaretskii
2018-12-24 17:38 ` Benjamin Riefenstahl
2018-12-14 22:47 ` Khaled Hosny
2018-12-16 14:47 ` Benjamin Riefenstahl
2018-12-14 6:45 ` Paul Eggert
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=838t085qx8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=33729@debbugs.gnu.org \
--cc=behdad@behdad.org \
--cc=dr.khaled.hosny@gmail.com \
--cc=far.nasiri.m@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.