> On 11 May 2015, at 21:25, Philippe Verdy wrote:
>
> Yes, but this does not mean that 0xFFF cannot be used as a (32-bit) code
> unit in "32-bit strings", even if it is not a valid code point with a valid
> scaar value in any legacy or standard version of UTF-32.
The reason I did it was t
On Mon, 11 May 2015 21:25:29 +0200
Philippe Verdy wrote:
> Once again, "code units" and "x-bit strings" are not bound to any
> Unicode or ISO/IEC 10646 or legacy RFC contraints related to the
> current standard UTFs or legacy (obsoleted) UTF's.
Who says they are?
I'm just saying that the concep
Yes, but this does not mean that 0xFFF cannot be used as a (32-bit)
code unit in "32-bit strings", even if it is not a valid code point with a
valid scaar value in any legacy or standard version of UTF-32.
The limitation to 0x7FF was certainly just there to avoid sign/unsigned
differences
> On 11 May 2015, at 19:44, Doug Ewell wrote:
>
> Hans Aberg wrote:
>
However I wonder what would be the effect of D80 in UTF-32: is
<0x> a valid "32-bit string" ?
>>>
>>> The value 0x cannot appear in a UTF-32 string. Therefore it
>>> cannot represent a unit of enco
Hans Aberg wrote:
>>> However I wonder what would be the effect of D80 in UTF-32: is
>>> <0x> a valid "32-bit string" ?
>>
>> The value 0x cannot appear in a UTF-32 string. Therefore it
>> cannot represent a unit of encoded text in a UTF-32 string.
>
> Even though the values with
When the update with Windows 10 info was posted, earlier sections for Windows
2000 / XP / XP SP2 were inadvertently deleted. Those have been restored.
From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Peter Constable
Sent: Friday, May 8, 2015 7:16 AM
To: unicode@unicode.org
Subject:
fyi, i have been developing a page
Notes on Mongolian variant forms
http://r12a.github.io/scripts/mongolian/variants
the page compares variant glyph shapes proposed in three documents,
and shows what shapes fonts actually produce.
i have been documenting changes at
http://lists.w3.org/Archives
7 matches
Mail list logo
