From: Asmus Freytag (firstname.lastname@example.org)
Date: Mon Sep 07 2009 - 18:28:43 CDT
On 9/7/2009 3:07 PM, verdy_p wrote:
> "Asmus Freytag"
>> The second is the radical solution: reclassify every single
>> character from Mc to Lo where there isn't any compelling
>> reason (in rendering or processing) to consider that
>> character actually "combining" in function, not just in name.
>> The advantage of this approach is that it would be very
>> visible and direct. Treating an "Lo" character by using the
>> support for graphically combining characters in a
>> renderer is obviously wrong, so you might expect a
>> pressure on *all* implementations to get that corrected.
>> The downside, of course, is that it's impossible to predict
>> what uses the gc=Mc classification has been put to by
>> actual implementations, outside of simple rendering issues.
>> You are correct in calling such an approach destabilizing,
>> no matter how appealing it would be, otherwise. For
>> the same reason, UTC is correct to continue to be
>> consistent with past practice in assigning Mc to any new
>> characters that are analogues to existing Mc characters.
> This solution would be much too radical.
Thanks for agreeing with me on this.
> But the main problem you'll have is that it would change how many other uses,...
> My opinion is that this radical change is absolutely not needed. The standard just needs to say that gc=Mc
> characters should be treated like gc=Lo for rendering, ...
And having a character behave like an "Lo" does not preclude ligation
and a number of other context-dependent rendering behavior appropriate
for the character and the script. The biggest difference is that it
doesn't imply that a base character, or worse, a specific base
character, is required to be present.
The latter assumptions built into some rendering engines, is what
started this whole discussion.
This archive was generated by hypermail 2.1.5 : Mon Sep 07 2009 - 18:31:11 CDT