From: Peter Kirk (peterkirk@qaya.org)
Date: Thu Apr 01 2004 - 06:06:11 EST
On 31/03/2004 17:01, Mark Davis wrote:
> ...
>
>BTW, you have been mentioning the combining class; you can have combining marks
>in the PUA, but they have to have zero combining classes.
>
>
>
Thanks for the clarification. As I have argued elsewhere, zero combining
class should not be a problem. I am more interested in the default
ignorable property, which would allow PUA combining marks simply to
disappear if not supported in a particular font. More precisely, I was
thinking in terms of private variation selectors, which is where this
thread started. These should indeed be default ignorable; and the
private variant form of a already defined letter might be that letter
with a PUA diacritic.
The existence of such PUA variation selectors might help the CJK
situation, as it would allow users to define their own private variant
forms of a character which would default to the standard form when the
special font is not selected. This would ease the pressure to define
every possible variant shape as a code point or variation sequence.
> ...
>
>These are not whims of software vendors; they would be very expensive retrofits
>for essentially no benefit.
>
>
Thank you for speaking some sense to counter those who have told me to
go away and hack user definable properties into existing systems.
>
>
>>>...
>>>
>>>
>>That is why I (rather than Ernest) have discussed only rendering related
>>properties like bidi and default ignorable. I realise that there may be
>>other properties which need to be considered, but I am not yet sure
>>which these are.
>>
>>
>
>Those alone won't work. If you want stuff to render right, then you have to
>include *any* property that systems may use to affect display. You do want these
>characters to linebreak correctly, eh? That's why I said that a complete
>proposal would have to spell out all the properties would be considered, and
>give reasons for the inclusion/exclusions.
>
>
>
Good point. Well, at least properties like line breaking can be
overridden, at least to a large extent, e.g. by inserting ZWSP or
whatever after the character. RTL behaviour can probably be overridden
by using RLO...PDF. The properties we need to worry about are those
which cannot be overridden by simple sequences like these.
>>I sense that you prefer to change the default properties of existing PUA
>>characters rather than add new ones. Might it be sensible to adjust the
>>properties in one of the PUA planes but leave the other one untouched?
>>Has ANYONE actually defined characters in one or other of these planes,
>>and if so, which? It would make more sense to change the default
>>properties of a plane which no one is actually using.
>>
>>
>
>1. There is no way I would advocate adding even more PU characters; the number
>we have is wasteful as it is. (In hindsight, we shouldn't have gone beyond
>U+FFFFF in any event.)
>
>2. If you are going to make this proposal, I'd suggest using a small part of one
>plane, probably at the high end.
>
>
>
Thank you.
Peter
-- Peter Kirk peter@qaya.org (personal) peterkirk@qaya.org (work) http://www.qaya.org/
This archive was generated by hypermail 2.1.5 : Thu Apr 01 2004 - 06:42:58 EST