Proposal for BiDi in terminal emulators

[Egmont Koblinger via Unicode]

Hi,

On Thu, Jan 31, 2019 at 4:14 PM Eli Zaretskii <eliz at gnu.org> wrote:>

> I suggest that you show the result to someone who does read Arabic.

I contacted one guy who is pretty knowledgeable in Arabic scripts, as
well as terminal emulation, I sent out an early unpublished version of
the proposal to him, but unfortunately he was busy and didn't have the
chance to respond. Let this thread be one where we invite Arabic folks
to comment :)

> Small changes can be very unpleasant to the eyes of an Arabic reader.

I can easily imagine that!

I can assure you, seeing õ instead of ő in my native language is
extremely unpleasant to my eyes. Depending on the font you're using,
you may not even have spotted any difference.

But could someone argue for example that seeing an "i" and "w" equally
wide is unpleasant to their eyes? Where do we draw the lines of what's
an acceptable compromise on a platform that has technical limitations
(fixed grid) to begin with? We really need input from Arabic folks to
answer this.

I'm also wondering: how unpleasant it is if a letter is cut in half
(e.g. overflows at the edge of the text editor), and is shaped not
according to the entire word but according to the visible part? I took
it from the CSS specification that the desired behavior is to shape it
according to the entire word, but I honestly don't know how acceptable
or how unpleasant the other approach is.

> You could do that, but it will require a lot of non-trivial processing
> from the applications.  Text-mode applications don't want any complex
> tinkering, they want just to write their text and be done.  The more
> overhead you add to that simple task, the less probable it is that
> applications will support such a terminal.

I agree with your overall observation, but I'm not sure how much it
applies to this context.

Text-mode applications have to run the BiDi algorithm. The one I
picked can also do shaping (well, the pretty limited one, using
presentation forms). Shouldn't any BiDi algorithm also provide methods
for shaping that produce some output that can be easily sent to the
terminals? Shouldn't we push for them?

As far as I imagine the ideal solution, doing this part of shaping
shouldn't be any harder for apps than doing BiDi, basically all they
would need to do is hook up to existing API methods.

Of course, given the current APIs, it's probably really not this simple.


cheers,
egmont