...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.
BTW, you have been mentioning the combining class; you can have combining marks in the PUA, but they have to have zero combining classes.
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.
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.
...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.
Thank you.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.
Peter
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
