On Fri, 19 Apr 2002, Tom Gewecke wrote:
I have added a couple more variations of the Unicode supplementary
characters example page, for utf-16 and utf-32.
I had the impression that it was not really practical to use web pages with
these encodings over the internet, because they do not
The latest docs I've seen indicate four hex chars in the uni names
for glyphs corresponding to BMP chars. What should be done for glyphs
corresponding to characters in the supplementary planes?
Will using five or six hex chars break any software¹ out in the wild?
Also, would setting up lig
This looks like a nice endorsement of SCSU:
:D
It saves 59% just as a charset,
and it saves almost 20% in a system with a real compression.
I am all for SCSU as a charset (after my tools can view it properly), but
that was not the use there. OTOH there is gzip encoding in HTTP 1.1 :)
Twenty-second International Unicode Conference (IUC22)
Unicode and the Web: Evolution or Revolution?
http://www.unicode.org/iuc/iuc22
September 9-13, 2002
San Jose, California
I have added a couple more variations of the Unicode supplementary
characters example page, for utf-16 and utf-32.
I am not sure if your UTF-16 and UTF-32 test pages really conform to the
HTML standard. The server states a content type of text/html without
charset information. From the content
At 13:31 4/19/2002, James H. Cloos Jr. wrote:
The latest docs I've seen indicate four hex chars in the uni names
for glyphs corresponding to BMP chars. What should be done for glyphs
corresponding to characters in the supplementary planes?
Adobe are supposed to have posted an update to
Philipp Reichmuth wrote:
I don't think it's fixed 27.5° in handwritten script, it varies quite
considerably, partly depending on how much text has to fit in the line
in calligraphy. In ordinary handwriting, the angle easily reaches 45°
or more.
I couldn't find any reference in books about
7 matches
Mail list logo
