From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <6b8e7586eaf104fda388c17f4e43391b@quanstro.net>
Date: Thu, 18 May 2006 23:43:34 -0500
From: quanstro@quanstro.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] strangely typed functions in standard library
In-Reply-To: <775b8d190605180221l79cf7214m7116dfe7567af85d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 51e851d6-ead1-11e9-9d60-3106f5b1d025

of course, how an array of Runes is stored is a different issue from how =
a
Rune argument is passed on the stack (or in a register).=20

don't consider this advocacy, but what would break if runes were expanded
to 32 bits?  i think that font handling would need some limits changed,
chartorune and runetochar would need to be modified and some enum
constants in libc.h would need to be changed.  this seems to me to be sma=
ll
potatoes in comparison to dealing with issues lurking within the basic pl=
ane
like character composition.

rob has suggested passing uncomposed characters to libdraw and handling
the problem there.  but there's one problem with that.  how do you stick
a nonspacing horn onto an arbitrary letter?  how do you put a grave accen=
t
on top of that?  (transliterations of cryllic to the roman alphabet use s=
ome=20
double- and triple- accented letters which do not exist in precombined fo=
rm
within unicode.)

i modified p9p libdraw at one point to draw combining characters.  (i.e. =
compose
a zero-width character on top of the previous character.) the results
were not legible.  a+diaresis may have been marginal buit A + " was mud.

this is really annoying.  characters should not combine.  the character-c=
omposition
algorithims of tex+metafont shouldn't come hidden within a character set.=
 =20

(well that's my 2=C2=A2, anyway.  maybe somebody has an idea on how to ma=
nage these
issues.)

- erik

p.s. how would you do this? =20

> i'd like to map them to RFat ... something unassigned in
> 0xFF.. space.

the problem is that there's not enough free space in the basic plane. and=
 as usual=20
with these things invention is the mother of all necessity.


On Thu May 18 04:22:47 CDT 2006, bruce.ellis@gmail.com wrote:
> 32 bit unicode is not Rune friendly ... i hope Runes don't
> get fatter.  it will break many things.  rob has had something
> to say about this, do a search on the list.
>=20
> i'd like to map them to RFat ... something unassigned in
> 0xFF.. space.
>=20
> use them at your peril.
>=20
> brucee
>=20
> On 5/18/06, erik quanstrom <quanstro@quanstro.net> wrote:
> > while this is true, i believe that the real reason for this is that
> > on a >=3D32-bit machine, an ushort can just be declared
> > to be a long by the compiler whereas the compiler must emit
> > instructions to convert a long to an unsigned short.
> >
> > - erik
> >
> > On Tue May 16 10:10:37 CDT 2006, 0xef967c36@gmail.com wrote:
> > > On 5/16/06, Matt Stewart <rotaerk1@gmail.com> wrote:
> > > > The following functions are described as accepting a Rune, but in=
stead
> > > > the parameters are of type long.  Why?
> > > >
> > > > int runelen(long);
> > > > char *utfrune(char *, long);
> > > > char *utfrrune(char *, long);
> > >
> > > full unicode is 32 bit, even if plan9 (afaik)
> > > supports only characters in the BMP.
> >
>=20