L2/02-081
February 11, 2002
Comments on proposed �invisible� property
----- Original Message -----
From: "Kenneth Whistler" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Friday, February 08, 2002 15:16
Subject: Invisibility (was: Re: Agenda items from Apple)
Mark said:
> I want to clarify a bit.
> By "invisible" one could mean a lot of different things. For example:
I agree, but...
> a) has (normally) no visible glyph, and contributes no advance� width (DICP)
> b) has (normally) no visible glyph (DICP + Whitespace).
this is not quite complete.
> There are edge cases such as soft-hyphens, which normally are (a), but
> are visible at the end of a line.
>
> John suggests another: is zero width. This would be (DICP + Nonspacing
> Mark + Enclosing Mark). I wouldn't call this invisible, although it
> may be a useful set depending on the application Deborah has in mind.
Default_Ignorable_Code_Point
�� This includes all the format controls, the ISO controls (except
�� 0009..000D, 0085), the variation selectors, ranges of unassigned
�� code points we have designated for format controls, and surrogate
�� code points.
�� All of these should have no visible glyph, and should not contribute
�� to advance width.
200B ZERO WIDTH SPACE
�� Neither Default_Ignorable_Code_Point nor White_Space
�� This has no visible glyph, and does not contribute to advance width.
Hangul fillers
�� 115F HANGUL CHOSEONG FILLER
�� 1160 HANGUL JUNGSEONG FILLER
�� 3164 HANGUL FILLER
�� FFA0 HALFWIDTH HANGUL FILLER
�� These have no visible glyphs, and do not contribute to advance width.
White space layout controls (White_Space - Zs)
�� 0009..000D, 0085, 2028, 2029
� These have no visible glyph, but affect layout, may contribute to
� advance width, break lines, and so on.
Spaces (White_Space - Cc - Zl - Zp)
� These have no visible glyph, but have positive advance widths.
00AD SOFT HYPHEN
�� This has no visible glyph, except at line end, where it has a visible
�� glyph and has a positive advance width.
Taking the Hangul filler characters into account, I'd say that
Deborah has a reasonable case for "Invisible" not being an easily
derived property from what is already defined.
--Ken
[Please see L2/02-080 for proposal by Deborah and more comments by Mark Davis]