bug#41005: problem with rendering Persian text in Emacs 27

[Pip Cet]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Pip Cet <pipcet@gmail.com>
>> Cc: valizadeh.ho@gmail.com,  41005@debbugs.gnu.org,  nicholasdrozd@gmail.com
>> Date: Thu, 04 Jun 2020 19:52:42 +0000
>> 
>> > As for script and language, for now adding them would just waste
>> > memory, since we don't yet have any meaningful support for
>> > buffer-local, let-alone paragraph-local, scripts and languages.  When
>> > we added HarfBuzz support, I considered adding some functionality to
>> > determine language and/or script from the codepoints, but decided that
>> > it made little sense, since HarfBuzz already does exactly that in
>> > hb_buffer_guess_segment_properties.  So I think we should add to the
>> > FIXME in hbfont.c the fact that when we do support those internally in
>> > Emacs, we should add these attributes to cached gstrings, but not yet
>> > actually add them for now.
>> 
>> We're going to have to change the lgstring structure, though, right?
>
> I think so.  We should probably add one more element to the vector in
> LGSTRING_HEADER, because the header is the hash key of the composition
> cache.

Do we have to maintain compatibility? If so, I suggest we change

[FONT-OBJECT CHAR ...]

to

[FONT-OBJECT [CHAR ...] DIRECTION], and use ARRAYP (AREF (..., 2)) to
decide whether the new format is in effect.  I actually thought about
suggesting the format be [FONT-OBJECT STRING DIRECTION], but that would
make debugging harder when pretty-printing the string in a failed
composition re-attempts that composition.

But of course it would be easier not to maintain compatibility, and then
we could order the elements any way we choose.

>> Could we maybe get away with just doing so once? My suggestion would be
>> to add a single field to gstrings which would currently be L2R or R2L
>> but might become an alist or something when we get around to adding
>> those features?
>
> We could add an element that would currently be a symbol or an
> integer, but could later become a vector of several elements.  Is that
> what you had in mind?

Yes, a vector was what I meant by "or something".

> (I think we should prefer vectors to lists in
> this case, because consing them is slightly faster, and the number of
> elements is known in advance and fixed.)

No argument there, though harfbuzz features, if we ever add them,
probably should be added as a list inside the vector. I'm talking about
things like "kern=0" passed to hb_feature_from_string, then to hb_shape,
to disable kerning.