Scripsit Tristan Miller:
>http://www.unicode.org/mail-arch/uni...-m12/0379.html
That page is password-protected. :(
It's pseudo-protection: the password is announced on the Unicode pages, and
it is "unicode".
>The bottom line is that no, you can't expect to be able to do such
things.
I suspected as much, but (except in the case of compatibility
equivalent characters) you haven't provided any normative reason for
this.
There is no normative reason, even for compatibility equivalent characters.
Programs are allowed to treat a precomposed character differently from its
decomposed form, though they should generally not be expected to do so.
Consider the display issue. A non-supporting (though conforming)
implementation can just ignore combining diacritic marks, showing a generic
glyph of unrepresentable character. A simplistic implementation effectively
just overprints the diacritic, as taken from a font, on the base character.
A better implementation takes into account the shape of the base character
and positions, for example, a diacritic on "O" differently from the same
diacritic on "o". An even better implementation additionally checks whether
the combination exists as a precomposed character (or just as a glyph in a
font) and uses it when possible, since a glyph designed by a font designer
should be expected to be as good as or better than a combination of glyphs
generated by software. This is the intended behavior - but not required.
Are you saying that this "bottom line" is simply an
implementation choice?
Yes, but not necessarily just a matter of lazyness. It might appear to be
simple to let diacritics to be colored separately, but then the effects
would depend on the use of precomposed forms (where no such coloring would
be applied). Moreover, treating colors in an ad hoc manner would not be that
natural, and letting _any_ font formatting apply to diacritics would open a
few cans of worms. For example, font size and weight changes might have
rather odd effects and would generally ruin the work of a sophisticated
algorithm that tries to place a diacritic optimally.
If you want to play with colored diacritics, you could use a spacing
diacritic (either as a separately coded character or as a no-break space
followed by a combining diacritic), which can be colored, and use some piece
of CSS to make it overprint the preceding character. This gets tricky of
course, and nasty - you would effectively imitate the simplistic
implementation of combining diacritics (as described above). There's no sure
way of getting even the horizontal position right, since there is no CSS
unit for the width of a character.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/ 
