Re: RTL PUA?

On 19 Aug 2011, at 16:03, Shriramana Sharma wrote:

>> There is plenty of space. There would be no difficulty in assigning
>> some rows to a RTL PUA.
>
> It is not a question of availability of space. It is a question of principles.

Sure. People who are happy with LTR directionality have PUA code points they can use for whatever they want. People who need RTL directionality don't have that facility however.

>> Mucking about with the directionality of the existing PUA would be extremely unwise.
>
> ... which would mean that it is extremely unwise to change the BC of the existing PUA characters and defeat your purpose.

Thus I favour the addition of a RTL PUA. It needn't be large.

> That said, you don't mean to say that existing rendering engines actually take notice of the BC=L of these characters, do you? Again, if you wish for some PUA ranges to have their BC changed to R, it is necessary that such engines *don't* take notice of the BC of PUA characters.

In practice (and I also use PUA characters) they trot right along LTR just as I expect.

> In effect, changing the existing BC=L to ON is no worse than changing it to R.

That still won't get RTL functionality for undefined characters, which is a legitimate requirement.

>>> Conceivably certain closed user-groups could be using
>>> closed-distribution rendering engines which would support bidi and
>>> glyph reordering or such for PUA codepoints.
>>
>> Not everyone is a programmer and can devise a rendering engine. But
>> lots of people can make fonts that could support a RTL conscript or
>> some private Arabic characters.
>
> Heh -- you are a font expert and presumably can whip a font up at short notice. The same can't be said for others!

Lots more people can make a font than can devise a rendering engine.

> Others are programming experts and easily extend their rendering engine to a script in the PUA.

In reality, that doesn't happen. Conlangers and conscripters and academic linguists (who are pretty much the people who are concerned with this area) might stretch to font design, or get friends to help them, but

> Abilities are different. But if you have the need to support a particular RTL script in the PUA, just like you have to create an appropriate font, you should be ready to write programming for rendering support.

Only because the PUA is LTR-only. If there were an RTL PUA such a user would not be at such a *massive* disadvantage.

> Remember that for handling Indic-type scripts (involving reordering etc) in the PUA, support is needed from the rendering engine side anyway.

Irrelevant. The LTR part of PUA still works. And that support does not have to be inserted into the operating system: much can be done within the font.

> It may be difficult to do this for closed-source rendering engines, especially OpenType ones that place half the rendering logic in compiled code, but with OSS rendering engines, or using technologies like Graphite, you can achieve proper rendering for Indic scripts. I presume the same is extensible to RTL too.

I don't believe that your presumption is correct.

>>> In which case, the only change that needs to be done to affirm that
>>> the PUA can be used for both LTR and RTL scripts is to change the
>>> BC of all those characters to ON.
>>
>> I wouldn't support that.
>
> OK -- but I entreat you to look at the bigger picture by which allocating RTL ranges in the PUA would not solve the situation for unencoded Indic-style scripts.

Indic scripts have LTR directionality. They can use PUA and do whatever is needed for the *other* challenges inherent in Indic fonts. A private RTL script cannot use the PUA and have the same level of support.

Michael Everson * http://www.evertype.com/
Received on Fri Aug 19 2011 - 10:19:16 CDT