On Tue, 19 Mar 2013 01:19:00 +0100
Philippe Verdy wrote:
> It is the UCA that defines the concept of ignorable characters. And
> the DUCET ("Default" UCET) that makes characters ignorable by default,
> but this can still be tailored in specific collations).
>
> Where did you see another confusiv
It is the UCA that defines the concept of ignorable characters. And
the DUCET ("Default" UCET) that makes characters ignorable by default,
but this can still be tailored in specific collations).
Where did you see another confusive expression in TUS defining
"default ignorable" differently as being
On Mon, 18 Mar 2013 08:32:03 +0100
Philippe Verdy wrote:
> The "Default ignorable" property has nothing to do with rendering or
> being zero-width, it's just a matter of collation (comparing strings
> for similarity, for plain-text searches, or sorting them), it does not
> necesarily mean that th
2013/3/18 Kent Karlsson :
> It goes also for the Hangul filler characters, because they are there
> for syntactic reasons, and should not render whether you can support them
> properly or not.
There's an exception in editors (in edit mode) where these fillers may
be displayed distinctly (but this
First of all, are the fonts you are referring to able to at all handle
conjoining Jamo? If not, the question is moot.
Fonts that do not support conjoining Jamo, often show them as if they
were non-conjoining Jamo. But that is a bad idea, since the non-conjoining
Jamo have separate code points (for
>> i.e. , or , or -- should the
>> fillers be rendered as non-advancing?
>
> The renderer should create a single syllabic cluster by grouping the
> vowel filler with the previous consonnant, and grouping the leading
> consonnant filler with the following vowel. So there will be two
> clusters.
So
2013/3/18 Konstantin Ritt :
> Hi Philippe,
>
> thanks for your reply.
> I was confused by http://www.unicode.org/faq/unsup_char.html , which states
>> All default-ignorable characters should be rendered as completely invisible
>> (and non advancing, i.e. "zero width"), if not explicitly supported
Hi Philippe,
thanks for your reply.
I was confused by http://www.unicode.org/faq/unsup_char.html , which states
> All default-ignorable characters should be rendered as completely invisible
> (and non advancing, i.e. "zero width"), if not explicitly supported in
> rendering.
Do I understand corr
The "Default ignorable" property has nothing to do with rendering or
being zero-width, it's just a matter of collation (comparing strings
for similarity, for plain-text searches, or sorting them), it does not
necesarily mean that the character is zero-width (that's a rendering
property).
Character
Forgot to add the topis the first time, re-posting. Sorry for inconvenience.
Konstantin
2013/3/18 Konstantin Ritt :
> Hi list,
>
> The user reports Korean text rendering issue with any modern Hangul
> font when U+115F and U+1160 are handled like default_ignorable code
> points.
> [quote]With inp
10 matches
Mail list logo
