Re: [9fans] Re: Thai Chicken

Re: [9fans] Re: Thai Chicken

[boyd, rounin]

> Am I on the right track here?

you may be able to type the char, but you need the glyph;
the glyphs being selected by font files.

[9fans] Re: Thai Chicken

[dbailey27]

Hm, I think I get this.

So, each font has to have a map file that can redirect
certain clusters of codes to certain clusters of characters
stored somewhere.

Thus, the unicode font, itself, may not have mappings
for a given set of codes, unless there is a defined map
to files that specify proper translation.

So, if I were to implement Thai support in my favorite
font (/lib/font/bit/lucida/unicode.7.font) I would need
to alter unicode.7.font to point to a file that contains
specific Thai encodings?

unicode.7.font
	map ASCII? -> internal?
	map Cyrillic -> /lib/font/bit/lucida/cyrillic.??.?
	map Thai -> external or undefined mapping

Am I on the right track here?

Don (north_)

Re: [9fans] Re: Thai Chicken

[dbailey27]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

Ah, yeah, I got it. As usual I skip reading man pages and
just try to understand the theory based on the files, themselves.
It's more fun that way.

I just read file(6) and it confirms what I suspected.

Don (north_)

[-- Attachment #2: Type: message/rfc822, Size: 2994 bytes --]

From: dbailey27@ameritech.net
To: 9fans@cse.psu.edu
Subject: [9fans] Re: Thai Chicken
Date: Mon, 23 Feb 2004 17:46:05 -0500
Message-ID: <d5095a9d9dfdb3ac914b9dd8dd855c8b@yourdomain.dom>

Hm, I think I get this.

So, each font has to have a map file that can redirect
certain clusters of codes to certain clusters of characters
stored somewhere.

Thus, the unicode font, itself, may not have mappings
for a given set of codes, unless there is a defined map
to files that specify proper translation.

So, if I were to implement Thai support in my favorite
font (/lib/font/bit/lucida/unicode.7.font) I would need
to alter unicode.7.font to point to a file that contains
specific Thai encodings?

unicode.7.font
	map ASCII? -> internal?
	map Cyrillic -> /lib/font/bit/lucida/cyrillic.??.?
	map Thai -> external or undefined mapping

Am I on the right track here?

Don (north_)

Re: [9fans] Re: Thai Chicken

[andrey mirtchovski]

> What I never understood was why there isn't a "if the character isn't found,
> then look in *this* font" entry.
>

"if the glyph isn't found substitute the 0x0 glyph (null glyph) for it"

Re: [9fans] Re: Thai Chicken

[Martin C.Atkins]

On Mon, 23 Feb 2004 17:46:05 -0500 dbailey27@ameritech.net wrote:
> Hm, I think I get this.

What I never understood was why there isn't a "if the character isn't found,
then look in *this* font" entry.

OK, this could recurse, etc horribly (and that would have to be
avoided somehow), but the advantage is that a single font could be
defined with all the Unicode characters, and made the default for the
other fonts. Then every font would be complete, and we wouldn't have
had this discussion!!!

Martin

--
Martin C. Atkins			martin@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] plan9 web server

[andrey mirtchovski]

> anyone else experienced similar problems?

can this be it:

	http://www.dslreports.com/shownews/39381

I haven't had any problems with bell-labs' site...

Re: [9fans] plan9 web server

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

It's ok from here.

[-- Attachment #2: Type: message/rfc822, Size: 2585 bytes --]

From: <vdharani@infernopark.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] plan9 web server
Date: Tue, 24 Feb 2004 03:05:41 -0500 (EST)
Message-ID: <33418.67.85.61.176.1077609941.squirrel@www.infernopark.com>


is plan9 webserver (plan9.bell-labs.com) doing fine? i have a feeling
something is wrong. for the past 3 or 4 days, i was not getting the pages
properly (off and on). sometimes, the main page didnt come up but i was
able to access some wiki pages.

anyone else experienced similar problems?

thanks
dharani

[9fans] plan9 web server

[vdharani]

is plan9 webserver (plan9.bell-labs.com) doing fine? i have a feeling
something is wrong. for the past 3 or 4 days, i was not getting the pages
properly (off and on). sometimes, the main page didnt come up but i was
able to access some wiki pages.

anyone else experienced similar problems?

thanks
dharani

Re: [9fans] plan9 web server

[boyd, rounin]

and here ...
--
MGRS 30U YC 01452 15834

Re: [9fans] plan9 web server

[vdharani]

>
>> anyone else experienced similar problems?
>
> can this be it:
>
> 	http://www.dslreports.com/shownews/39381
>
> I haven't had any problems with bell-labs' site...

dont know. not sure where is the problem. i am so close to the web server,
i can even hand deliver the packets :-). anyway, i will wait till morning.

btw, is there a mirror site for the plan9 website? atleast wiki pages? i
disturbed my auth/cpu server and now i am not able to login from a
terminal. i remember i need to do something with /adm/keys but i need to
refer the wiki pages.

thanks
dharani

Re: [9fans] Re: Thai Chicken

[boyd, rounin]

> a font is just a textual list of subfont files, and any/all could include
references
> to subfonts supporting unicode.  quite a few do.  i'm not sure why some do
and
> some don't (in other words, i don't know what cost they are trying to
reduce).

my theory is that 'common' unicode blocks are there 'cos due to need.

how many thai 9fans have we got?

Re: [9fans] Re: Thai Chicken

[Martin C.Atkins]

On Mon, 23 Feb 2004 20:57:48 -0700 andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> wrote:
>...
>
> "if the glyph isn't found substitute the 0x0 glyph (null glyph) for it"
>

Yes, I know that! The point is that the 0x0 glyph doesn't display Thai
(or anything else, for that matter)!

Surely it would be better if every font contained a full Unicode set (without
any bloat/duplication)?

Martin

--
Martin C. Atkins			martin@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Re: Thai Chicken

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

a font is just a textual list of subfont files, and any/all could include references
to subfonts supporting unicode.  quite a few do.  i'm not sure why some do and
some don't (in other words, i don't know what cost they are trying to reduce).

[-- Attachment #2: Type: message/rfc822, Size: 2853 bytes --]

From: Martin C.Atkins <martin@parvat.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: Thai Chicken
Date: Tue, 24 Feb 2004 15:05:53 +0530
Message-ID: <20040224150553.1dbff498.martin@parvat.com>

On Mon, 23 Feb 2004 20:57:48 -0700 andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> wrote:
>...
>
> "if the glyph isn't found substitute the 0x0 glyph (null glyph) for it"
>

Yes, I know that! The point is that the 0x0 glyph doesn't display Thai
(or anything else, for that matter)!

Surely it would be better if every font contained a full Unicode set (without
any bloat/duplication)?

Martin

--
Martin C. Atkins			martin@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Re: Thai Chicken

[Geoff Collyer]

Andrey undoubtedly has more complete fonts but I quickly cobbled these
font description files together and they're the only ones I use.  They
all cover up to 0x9fff as well as any of the standard .font files I
looked at and include a few extras like Hebrew.


# To unbundle, run this file
mkdir lib/font/bit/all
echo lib/font/bit/all/fixed.unicode.8.font
sed 's/^X//' >lib/font/bit/all/fixed.unicode.8.font <<'!'
14	11
0x0000	0x00FF	../pelm/latin1.8
0x0100	0x01f0	../lucida/EuroLatin.8.0
0x0250	0x02E9	../lucm/ipa.9
0x0370	0x03F5	../misc/greek.8
0x0300	0x03f2	../lucida/GenDiacrit.7.0
0x0401	0x04cc	../lucida/cyrillic.7.0
0x05b0	0x05f4	../lucida/Hebrew.7.0
0x2070	0x208E	../pelm/supsub.8
0x2000	0x20aa	../lucida/GenPunct.7.0
0x20ab	0x20ac	../pelm/currency.9
0x2100	0x21ea	../lucida/Letterlike.7.0
0x2200	0x22f1	../lucida/MathOps1.7.0
0x2300	0x232C	../misc/tech
0x2500	0x257F	../misc/chart
0x2400	0x2424	../lucida/control.7.0
0x2591	0x2593	../lucida/Altshades.7.0
0x2500	0x25ee	../lucida/FormBlock.7.0
0x25ef	0x25ff	../misc/geometric
0x2600	0x266F	../misc/ding
0x2700	0x27BF	../misc/zapf
0x3000 0x303f ../jis/jis3000.16
0x30a1 0x30fe ../jis/katakana.16
0x3041 0x309e ../jis/hiragana.16
0x4e00 0x4fff ../jis/jis4e00.16
0x5000 0x51ff ../jis/jis5000.16
0x5200 0x53ff ../jis/jis5200.16
0x5400 0x55ff ../jis/jis5400.16
0x5600 0x57ff ../jis/jis5600.16
0x5800 0x59ff ../jis/jis5800.16
0x5a00 0x5bff ../jis/jis5a00.16
0x5c00 0x5dff ../jis/jis5c00.16
0x5e00 0x5fff ../jis/jis5e00.16
0x6000 0x61ff ../jis/jis6000.16
0x6200 0x63ff ../jis/jis6200.16
0x6400 0x65ff ../jis/jis6400.16
0x6600 0x67ff ../jis/jis6600.16
0x6800 0x69ff ../jis/jis6800.16
0x6a00 0x6bff ../jis/jis6a00.16
0x6c00 0x6dff ../jis/jis6c00.16
0x6e00 0x6fff ../jis/jis6e00.16
0x7000 0x71ff ../jis/jis7000.16
0x7200 0x73ff ../jis/jis7200.16
0x7400 0x75ff ../jis/jis7400.16
0x7600 0x77ff ../jis/jis7600.16
0x7800 0x79ff ../jis/jis7800.16
0x7a00 0x7bff ../jis/jis7a00.16
0x7c00 0x7dff ../jis/jis7c00.16
0x7e00 0x7fff ../jis/jis7e00.16
0x8000 0x81ff ../jis/jis8000.16
0x8200 0x83ff ../jis/jis8200.16
0x8400 0x85ff ../jis/jis8400.16
0x8600 0x87ff ../jis/jis8600.16
0x8800 0x89ff ../jis/jis8800.16
0x8a00 0x8bff ../jis/jis8a00.16
0x8c00 0x8dff ../jis/jis8c00.16
0x8e00 0x8fff ../jis/jis8e00.16
0x9000 0x91ff ../jis/jis9000.16
0x9200 0x93ff ../jis/jis9200.16
0x9400 0x95ff ../jis/jis9400.16
0x9600 0x97ff ../jis/jis9600.16
0x9800 0x99ff ../jis/jis9800.16
0x9a00 0x9bff ../jis/jis9a00.16
0x9c00 0x9dff ../jis/jis9c00.16
0x9e00 0x9fff ../jis/jis9e00.16
0xfb1e	0xfb1e	../lucida/Althebrew.7.0
0xfee0	0xff5e	../pelm/latin1.9
0xfffd	0xfffd	../pelm/fffd.9
!
echo lib/font/bit/all/fixed.unicode.9.font
sed 's/^X//' >lib/font/bit/all/fixed.unicode.9.font <<'!'
18	14
0x0000	0x00FF	../pelm/latin1.9
0x0100	0x01f0	../lucida/EuroLatin.9.0
0x0250	0x02E9	../lucm/ipa.9
0x0370	0x03F5	../lucm/greek.9
0x0300	0x03f2	../lucida/GenDiacrit.7.0
0x0401	0x04cc	../lucida/cyrillic.7.0
0x05b0	0x05f4	../lucida/Hebrew.7.0
0x2070	0x208E	../pelm/supsub.9
0x2000	0x20aa	../lucida/GenPunct.7.0
0x20ab	0x20ac	../pelm/currency.9
0x2100	0x21ea	../lucida/Letterlike.7.0
0x2200	0x22f1	../lucida/MathOps1.7.0
0x2300	0x232C	../misc/tech
0x2500	0x257F	../misc/chart
0x2400	0x2424	../lucida/control.7.0
0x2591	0x2593	../lucida/Altshades.7.0
0x2500	0x25ee	../lucida/FormBlock.7.0
0x25ef	0x25ff	../misc/geometric
0x2600	0x266F	../misc/ding
0x2700	0x27BF	../misc/zapf
0x3000 0x303f ../jis/jis3000.16
0x30a1 0x30fe ../jis/katakana.16
0x3041 0x309e ../jis/hiragana.16
0x4e00 0x4fff ../jis/jis4e00.16
0x5000 0x51ff ../jis/jis5000.16
0x5200 0x53ff ../jis/jis5200.16
0x5400 0x55ff ../jis/jis5400.16
0x5600 0x57ff ../jis/jis5600.16
0x5800 0x59ff ../jis/jis5800.16
0x5a00 0x5bff ../jis/jis5a00.16
0x5c00 0x5dff ../jis/jis5c00.16
0x5e00 0x5fff ../jis/jis5e00.16
0x6000 0x61ff ../jis/jis6000.16
0x6200 0x63ff ../jis/jis6200.16
0x6400 0x65ff ../jis/jis6400.16
0x6600 0x67ff ../jis/jis6600.16
0x6800 0x69ff ../jis/jis6800.16
0x6a00 0x6bff ../jis/jis6a00.16
0x6c00 0x6dff ../jis/jis6c00.16
0x6e00 0x6fff ../jis/jis6e00.16
0x7000 0x71ff ../jis/jis7000.16
0x7200 0x73ff ../jis/jis7200.16
0x7400 0x75ff ../jis/jis7400.16
0x7600 0x77ff ../jis/jis7600.16
0x7800 0x79ff ../jis/jis7800.16
0x7a00 0x7bff ../jis/jis7a00.16
0x7c00 0x7dff ../jis/jis7c00.16
0x7e00 0x7fff ../jis/jis7e00.16
0x8000 0x81ff ../jis/jis8000.16
0x8200 0x83ff ../jis/jis8200.16
0x8400 0x85ff ../jis/jis8400.16
0x8600 0x87ff ../jis/jis8600.16
0x8800 0x89ff ../jis/jis8800.16
0x8a00 0x8bff ../jis/jis8a00.16
0x8c00 0x8dff ../jis/jis8c00.16
0x8e00 0x8fff ../jis/jis8e00.16
0x9000 0x91ff ../jis/jis9000.16
0x9200 0x93ff ../jis/jis9200.16
0x9400 0x95ff ../jis/jis9400.16
0x9600 0x97ff ../jis/jis9600.16
0x9800 0x99ff ../jis/jis9800.16
0x9a00 0x9bff ../jis/jis9a00.16
0x9c00 0x9dff ../jis/jis9c00.16
0x9e00 0x9fff ../jis/jis9e00.16
0xfb1e	0xfb1e	../lucida/Althebrew.7.0
0xfee0	0xff5e	../pelm/latin1.9
0xfffd	0xfffd	../pelm/fffd.9
!
echo lib/font/bit/all/var.unicode.8.font
sed 's/^X//' >lib/font/bit/all/var.unicode.8.font <<'!'
14	11
0x0000	0x00FF	../lucidasans/lsr.14
0x0100	0x01f0	../lucida/EuroLatin.8.0
0x0250	0x02e9	../lucida/Phonetic.7.0
0x0300	0x03f2	../lucida/GenDiacrit.7.0
0x03f3	0x03F5	../misc/greek.8
0x0401	0x04cc	../lucida/cyrillic.7.0
0x05b0	0x05f4	../lucida/Hebrew.7.0
0x2070	0x208E	../pelm/supsub.8
0x2000	0x20aa	../lucida/GenPunct.7.0
0x20ab	0x20ac	../pelm/currency.9
0x2100	0x21ea	../lucida/Letterlike.7.0
0x2200	0x22f1	../lucida/MathOps1.7.0
0x2300	0x232C	../misc/tech
0x2500	0x257F	../misc/chart
0x2400	0x2424	../lucida/control.7.0
0x2591	0x2593	../lucida/Altshades.7.0
0x2500	0x25ee	../lucida/FormBlock.7.0
0x25ef	0x25ff	../misc/geometric
0x2600	0x266F	../misc/ding
0x2700	0x27BF	../misc/zapf
0x3000 0x303f ../jis/jis3000.16
0x30a1 0x30fe ../jis/katakana.16
0x3041 0x309e ../jis/hiragana.16
0x4e00 0x4fff ../jis/jis4e00.16
0x5000 0x51ff ../jis/jis5000.16
0x5200 0x53ff ../jis/jis5200.16
0x5400 0x55ff ../jis/jis5400.16
0x5600 0x57ff ../jis/jis5600.16
0x5800 0x59ff ../jis/jis5800.16
0x5a00 0x5bff ../jis/jis5a00.16
0x5c00 0x5dff ../jis/jis5c00.16
0x5e00 0x5fff ../jis/jis5e00.16
0x6000 0x61ff ../jis/jis6000.16
0x6200 0x63ff ../jis/jis6200.16
0x6400 0x65ff ../jis/jis6400.16
0x6600 0x67ff ../jis/jis6600.16
0x6800 0x69ff ../jis/jis6800.16
0x6a00 0x6bff ../jis/jis6a00.16
0x6c00 0x6dff ../jis/jis6c00.16
0x6e00 0x6fff ../jis/jis6e00.16
0x7000 0x71ff ../jis/jis7000.16
0x7200 0x73ff ../jis/jis7200.16
0x7400 0x75ff ../jis/jis7400.16
0x7600 0x77ff ../jis/jis7600.16
0x7800 0x79ff ../jis/jis7800.16
0x7a00 0x7bff ../jis/jis7a00.16
0x7c00 0x7dff ../jis/jis7c00.16
0x7e00 0x7fff ../jis/jis7e00.16
0x8000 0x81ff ../jis/jis8000.16
0x8200 0x83ff ../jis/jis8200.16
0x8400 0x85ff ../jis/jis8400.16
0x8600 0x87ff ../jis/jis8600.16
0x8800 0x89ff ../jis/jis8800.16
0x8a00 0x8bff ../jis/jis8a00.16
0x8c00 0x8dff ../jis/jis8c00.16
0x8e00 0x8fff ../jis/jis8e00.16
0x9000 0x91ff ../jis/jis9000.16
0x9200 0x93ff ../jis/jis9200.16
0x9400 0x95ff ../jis/jis9400.16
0x9600 0x97ff ../jis/jis9600.16
0x9800 0x99ff ../jis/jis9800.16
0x9a00 0x9bff ../jis/jis9a00.16
0x9c00 0x9dff ../jis/jis9c00.16
0x9e00 0x9fff ../jis/jis9e00.16
0xfb1e	0xfb1e	../lucida/Althebrew.7.0
0xfee0	0xff5e	../pelm/latin1.9
0xfffd	0xfffd	../pelm/fffd.9
!
echo lib/font/bit/all/var.unicode.9.font
sed 's/^X//' >lib/font/bit/all/var.unicode.9.font <<'!'
18	14
0x0000	0x00FF	../lucidasans/lsr.18
0x0100	0x01f0	../lucida/EuroLatin.9.0
0x0250	0x02e9	../lucida/Phonetic.7.0
0x0300	0x03f2	../lucida/GenDiacrit.7.0
0x03f3	0x03F5	../lucm/greek.9
0x0401	0x04cc	../lucida/cyrillic.7.0
0x05b0	0x05f4	../lucida/Hebrew.7.0
0x2070	0x208E	../pelm/supsub.9
0x2000	0x20aa	../lucida/GenPunct.7.0
0x20ab	0x20ac	../pelm/currency.9
0x2100	0x21ea	../lucida/Letterlike.7.0
0x2200	0x22f1	../lucida/MathOps1.7.0
0x2300	0x232C	../misc/tech
0x2500	0x257F	../misc/chart
0x2400	0x2424	../lucida/control.7.0
0x2591	0x2593	../lucida/Altshades.7.0
0x2500	0x25ee	../lucida/FormBlock.7.0
0x25ef	0x25ff	../misc/geometric
0x2600	0x266F	../misc/ding
0x2700	0x27BF	../misc/zapf
0x3000 0x303f ../jis/jis3000.16
0x30a1 0x30fe ../jis/katakana.16
0x3041 0x309e ../jis/hiragana.16
0x4e00 0x4fff ../jis/jis4e00.16
0x5000 0x51ff ../jis/jis5000.16
0x5200 0x53ff ../jis/jis5200.16
0x5400 0x55ff ../jis/jis5400.16
0x5600 0x57ff ../jis/jis5600.16
0x5800 0x59ff ../jis/jis5800.16
0x5a00 0x5bff ../jis/jis5a00.16
0x5c00 0x5dff ../jis/jis5c00.16
0x5e00 0x5fff ../jis/jis5e00.16
0x6000 0x61ff ../jis/jis6000.16
0x6200 0x63ff ../jis/jis6200.16
0x6400 0x65ff ../jis/jis6400.16
0x6600 0x67ff ../jis/jis6600.16
0x6800 0x69ff ../jis/jis6800.16
0x6a00 0x6bff ../jis/jis6a00.16
0x6c00 0x6dff ../jis/jis6c00.16
0x6e00 0x6fff ../jis/jis6e00.16
0x7000 0x71ff ../jis/jis7000.16
0x7200 0x73ff ../jis/jis7200.16
0x7400 0x75ff ../jis/jis7400.16
0x7600 0x77ff ../jis/jis7600.16
0x7800 0x79ff ../jis/jis7800.16
0x7a00 0x7bff ../jis/jis7a00.16
0x7c00 0x7dff ../jis/jis7c00.16
0x7e00 0x7fff ../jis/jis7e00.16
0x8000 0x81ff ../jis/jis8000.16
0x8200 0x83ff ../jis/jis8200.16
0x8400 0x85ff ../jis/jis8400.16
0x8600 0x87ff ../jis/jis8600.16
0x8800 0x89ff ../jis/jis8800.16
0x8a00 0x8bff ../jis/jis8a00.16
0x8c00 0x8dff ../jis/jis8c00.16
0x8e00 0x8fff ../jis/jis8e00.16
0x9000 0x91ff ../jis/jis9000.16
0x9200 0x93ff ../jis/jis9200.16
0x9400 0x95ff ../jis/jis9400.16
0x9600 0x97ff ../jis/jis9600.16
0x9800 0x99ff ../jis/jis9800.16
0x9a00 0x9bff ../jis/jis9a00.16
0x9c00 0x9dff ../jis/jis9c00.16
0x9e00 0x9fff ../jis/jis9e00.16
0xfb1e	0xfb1e	../lucida/Althebrew.7.0
0xfee0	0xff5e	../pelm/latin1.9
0xfffd	0xfffd	../pelm/fffd.9
!

Re: [9fans] Re: Thai Chicken

[Chris Hollis-Locke]

I looked into this when thinking about doing a font server for Inferno.
The problem is that the remapping file really has to be hand written on a
face by face basis as there is no suitable font metric against which to
automatically decide on the mapping.  Faces of the same 'height' can vary in
rendered size dramatically - think Arial Vs. Dunhill - they just will not go
together.  This greatly complicates the way the draw device would have to
handle baselines and the sizing of its cached subfont image.  This also
skirts around the fact that the han unification area should have separate
renderings, an automatic mapping could end up being composed of renderings
specific to different locales.

Just my $0.02
Chris.

----- Original Message -----
From: "Martin C.Atkins" <martin@parvat.com>
To: <9fans@cse.psu.edu>
Sent: Tuesday, February 24, 2004 5:41 PM
Subject: Re: [9fans] Re: Thai Chicken


> On Mon, 23 Feb 2004 17:46:05 -0500 dbailey27@ameritech.net wrote:
> > Hm, I think I get this.
>
> What I never understood was why there isn't a "if the character isn't
found,
> then look in *this* font" entry.
>
> OK, this could recurse, etc horribly (and that would have to be
> avoided somehow), but the advantage is that a single font could be
> defined with all the Unicode characters, and made the default for the
> other fonts. Then every font would be complete, and we wouldn't have
> had this discussion!!!
>
> Martin
>
> --
> Martin C. Atkins martin@parvat.com
> Parvat Infotech Private Limited http://www.parvat.com{/,/martin}
>

Re: [9fans] Re: Thai Chicken

[Lucio De Re]

On Tue, Feb 24, 2004 at 11:04:13PM +1300, Chris Hollis-Locke wrote:
>
> I looked into this when thinking about doing a font server for Inferno.
> The problem is that the remapping file really has to be hand written on a
> face by face basis as there is no suitable font metric against which to
> automatically decide on the mapping.  Faces of the same 'height' can vary in
> rendered size dramatically - think Arial Vs. Dunhill - they just will not go
> together.  This greatly complicates the way the draw device would have to
> handle baselines and the sizing of its cached subfont image.  This also
> skirts around the fact that the han unification area should have separate
> renderings, an automatic mapping could end up being composed of renderings
> specific to different locales.
>
You'd think there'd be an English rendering of the above paragraph.  No
wonder I never could grasp the complexities of font management.

> Just my $0.02

I'm sure it's worth considerably more than that, but that is about as
much as I got out of it :-)

++L

Re: [9fans] Re: Thai Chicken

[Rob Pike]

> Surely it would be better if every font contained a full Unicode set
> (without
> any bloat/duplication)?

without any bloat?  no chance.  unicode has gotten bloated lately.
linear B, anyone?

there are several reasons why the fonts aren't all full:

1) unicode keeps growing, so they can only be full temporarily.
2) it's easy to forget, but there were no unicode fonts when plan 9
adopted
    unicode.  bigelow and holmes made lucida sans unicode for us, and
that
    was the first - still partial, even today - unicode font.  in other
words, font
    coverage is spotty.
3) for many applications, you don't want the full set of fonts and
there is no
    need to pay the full memory footprint for them.
4) on slow lines, it can be very painful to cat a file by mistake that
has a lot
    of unusual characters, such as a binary file or a japanese file when
working
    in ascii.  try a drawterm across the country and run unicode
8000-B000 or
    something like that.

number 4 may be mitigated by improving networks, but in the early days
of plan 9 only the diehards ran with a relatively full font set.

-rob

Re: [9fans] plan9 web server

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 22 bytes --]

I'm checking this out.

[-- Attachment #2: Type: message/rfc822, Size: 2606 bytes --]

From: <vdharani@infernopark.com>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] plan9 web server
Date: Tue, 24 Feb 2004 19:34:56 -0500 (EST)
Message-ID: <7690.192.11.226.116.1077669296.squirrel@www.infernopark.com>


i tried to access this page:
http://plan9.bell-labs.com/wiki/plan9/plan_9_wiki

it says :

404 Not Found
....
Object not found.

however, http://plan9.bell-labs.com gives me the first page properly.

regards
dharani

> and here ...
> --
> MGRS 30U YC 01452 15834

Re: [9fans] plan9 web server

[vdharani]

i tried to access this page:
http://plan9.bell-labs.com/wiki/plan9/plan_9_wiki

it says :

404 Not Found
....
Object not found.

however, http://plan9.bell-labs.com gives me the first page properly.

regards
dharani

> and here ...
> --
> MGRS 30U YC 01452 15834

Re: [9fans] Re: Thai Chicken

[andrey mirtchovski]

> I'm just asking why there isn't a simpler way of managing the font (mapping)
> files, than all the effort that Geoff went to...

That one's very easy -- just buy the fonts you want..  Bitstream.com
has a whole bunch of complete Unicode TTF's which you can easily
convert to Plan 9.  You can even get a support package where any new
unicode glyphs will be sent to you immediately...

Getting complete unicode fonts for free is going to be, I believe,
significantly harder for some time still.  As Markus Kuhn puts it:
"this would be a very substantial project that I can't affort as a
hobby".  Same with .font files -- somebody needs to have the time and
desire to do it...


andrey

Re: [9fans] Re: Thai Chicken

[Martin C.Atkins]

On Tue, 24 Feb 2004 08:04:30 -0800 Rob Pike <rob@mightycheese.com> wrote:
> > Surely it would be better if every font contained a full Unicode set
> > (without
> > any bloat/duplication)?
>
> without any bloat?  no chance.  unicode has gotten bloated lately.
> linear B, anyone?

That seems to be the industry disease, bloat... :-(

> there are several reasons why the fonts aren't all full:
>
> 1) unicode keeps growing, so they can only be full temporarily.

Isn't that a good reason for keeping the knowledge about how to make a full
font in one place, rather than in every font file (if one wants every font
to be full)?

> 2) it's easy to forget, but there were no unicode fonts when plan 9
> adopted...

Indeed it is! Thanks for reminding me (I didn't know this detail of
the history - I knew Plan 9 was first with Unicode, but didn't know
lucida sans Unicode was "made for Plan 9" - could we use this as a
slogan, a la "intel inside"? :-)!

> 3) for many applications, you don't want the full set of fonts and
> there is no
>     need to pay the full memory footprint for them.

Sorry - why would you ever (except for your reason 4, below), not want
a full font? I thought the whole point of the nice font-file mapping format
was that one didn't need to pay the "full memory footprint" if you didn't
need all the characters. (I'm assuming the 'full memory footprint' of
the mapping file is acceptable!)

NB I'm advocating full fonts, not a full unicode subfont (that way
lies X11/Windows font madness)!

I'm just asking why there isn't a simpler way of managing the font (mapping)
files, than all the effort that Geoff went to... (Cutting and pasting is easy,
but updating them all when Unicode changes or new subfonts arrive is a pain.
I suppose scripts could generate Geoff's output from some meta description, but
that seems unnecessarily complex, why not just:
	$ mv one_of_geoffs_full_fonts default.8.font
and change the font-reading library to allow:
	$ cat some_font.8.font
	14	11	default.8.font
	0x0000	0x00FF	../pelm/latin1.8
so that some_font.8.font is a full font too?

Please, I'm not trying to make a row. I simply don't understand why this seemingly
obvious solution, apparently has problems I don't understand! Or is the 'problem'
simply that "no-one has got around to doing it yet" - which is fine!)

BTW: I don't see that Chris' arguments affect this, since I'm not proposing
mixing characters from Arial and Dunhill, but rather characters from Arial
and Katakana, Hebrew, etc.... But maybe I'm not "getting" this problem, either!

> 4) on slow lines, it can be very painful to cat a file by mistake that
> has a lot....

OK - I see that could be an issue, but one could still have a 'safe' font, for
such situations.

Martin

--
Martin C. Atkins			martin@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Re: Thai Chicken

[Chris Hollis-Locke]

----- Original Message -----
From: "Martin C.Atkins" <martin@parvat.com>
To: <9fans@cse.psu.edu>
Sent: Wednesday, February 25, 2004 6:52 PM
Subject: Re: [9fans] Re: Thai Chicken

...
> BTW: I don't see that Chris' arguments affect this, since I'm not
proposing
> mixing characters from Arial and Dunhill, but rather characters from Arial
> and Katakana, Hebrew, etc.... But maybe I'm not "getting" this problem,
either!
>

Just as there is more than one style of latin glyphs (Arial Vs Dunhill)
other language glyphs (Katakana, Hebrew etc.) can be presented in different
styles too.

If  you do want a Dunhill unicode font (heaven forbid!), what faces are you
going to choose to fill in the gaps?  What height should you choose?  The
stems on Dunhill mean that a simple height match will give very wide glyphs
for the non latin chars w.r.t the Dunhill glyphs..

Other attributes come into play too - consider a latin fixed width typeface,
if you pick up non-latin chars from a proportional-width font then your
lovely columnar output is messed up.

However, as usual, I was trying to solve everything.  A simple elegant
solution for 99% of the problem whips the arse of a complex solution to 100%
of the problem.  But I often forget this!

Chris.

Re: [9fans] Re: Thai Chicken

[Dave Lukes]

> What I never understood was why there isn't a "if the character isn't found,
> then look in *this* font" entry.

Danger, Will Robinson, Danger!  That way lies TrueType.

While I understand the frustration caused by lack of mappings
for the (types of) languages spoken by the majority of the world's
population, jumping in with a Q+D fix is not the answer.
If you try reading English text that is made up of varying fonts,
you will strain your brain, and while I suspect that this
may be less true with other language types,
it still doesn't sound like a good idea.

> OK, this could recurse, etc horribly (and that would have to be
> avoided somehow),

Fine words ...
So the algorithm for rendering a single character
in a known font becomes what, exactly ...?

What do you do if the other font is fundamentally different?
(size, baseline, aspect ratio ...).

>  but the advantage is that a single font could be
> defined with all the Unicode characters, and made the default for the
> other fonts.

I hate to be language-ist here,
but that solution will probably work fairly well for
ideographic/pictographic languages for various reasons:
* there is probably a very limited set of fonts available
* Those few fonts available probably look surprisingly similar
  due to cultural, sociological and availability constraints.

>  Then every font would be complete,
Beg to differ: they would be complete in the same sense that
Frankenstein's monster was complete.

It's like sticking tractor tyres on a Skyline
(sorry: "fancy fast car" for non-petrol-heads),
and saying "Hey, it's a sports car that can plough fields",
when what we need is an LM-03 (sorry, non-petrolheads).

>  and we wouldn't have had this discussion!!!

Instead we'd be having the discussion about how many levels
of recursion to allow, what to do when that limit gets blown,
where do we put the permitted recursion level in the font header,
... ?

Cheers,
	Dave.

P.S. What Geoff Collyer said, too.

Re: [9fans] Re: Thai Chicken

[Lucio De Re]

On Wed, Feb 25, 2004 at 12:40:56PM +0000, Dave Lukes wrote:
>
> Danger, Will Robinson, Danger!  That way lies TrueType.
>
Why do I get this feeling that alphabets and fonts should be kept
distinct?

Alphabet soup, Thai chicken, TrueType Spaghetti, anyone?

++L

Re: [9fans] Re: Thai Chicken

[rog]

> Please, I'm not trying to make a row. I simply don't understand why this seemingly
> obvious solution, apparently has problems I don't understand! Or is the 'problem'
> simply that "no-one has got around to doing it yet" - which is fine!)

one "obvious" reason why this is a problem is that fonts don't
necessarily come in all sizes.  there's no point in my tiny 7 point
font dragging in chinese chars from a much larger font - either
they'll be truncated, or the tiny font will have a much larger height
than it should.

i guess that's an argument for on-demand rendering of scalable fonts,
but that's not a trivial problem, as chris found out...

i have to say i'd like to see a more standard convention for naming
fonts; i very rarely use other than the standard acme or rio fonts,
(although i'd sometimes like to) and the fact that fonts have no
consistent naming scheme doesn't really help.

just the act of grouping a load of consistent fonts in one place, as
chris did for charon, helps a lot:

	charon/(bold cw italic plain).(tiny small normal large vlarge).font

at least then i can remember where to find typefaces that more-or-less
go with one another, and have as large a coverage as is possible,
consistent with the font appearance.

Re: [9fans] Re: Thai Chicken

[boyd, rounin]

as Queen said in One Vision:

    Just gimme gimme gimme gimme
    Fried chicken

Re: [9fans] Re: Thai Chicken

[boyd, rounin]

> Instead we'd be having the discussion about how many levels
> of recursion to allow, what to do when that limit gets blown,
> where do we put the permitted recursion level in the font header,
> ... ?

we put it in a 'persistant object', err ... file ;)

Re: [9fans] Re: Thai Chicken

[Martin C.Atkins]

Sorry, I was out of the office for a couple of days...

On Wed, 25 Feb 2004 12:40:56 +0000 Dave Lukes <davel@anvil.com> wrote:
> > What I never understood was why there isn't a "if the character isn't found,
> > then look in *this* font" entry.
>
> Danger, Will Robinson, Danger!  That way lies TrueType.

Most of the arguments against my suggestion seem to fall into:

1) It will be difficult to find fonts that work well together

2) If badly configured, the consequences could be horrible

3) My suggestion is too hacky

4) Sometimes one doesn't need/want this

To address these in turn:
1) It will be difficult to find fonts that work well together:
Maybe. However, having characters "disappear" isn't too good either!
(unless one accidentally cat'ed a binary, in which case you don't really
care what the output looks like. In other cases, presumably the
characters were there for some purpose?)

2) If badly configured, the consequences could be horrible
This is true of just about everything in software (and elsewhere).
So don't configure it badly - at least you would have another option
to help with the configuration.

3) My suggestion is too hacky
Possibly: I was hoping that people could suggest better approaches
that would solve the problem, rather than just saying "Ugh, that's
horrible". For example, one could introduce a new layer in the font
files, with the first layer defining the font size, and a list of
second-layer files to be searched in order for glyphs. The second
layer would be much like the current font files, but without the font
size information, and the last layer would be the current sub-font
files. This would solve the "recursion" problem, and provide a common
font size across all the files, but was a more dramatic change than I
wanted to propose.

4) Sometimes one doesn't need/want this
So have some fonts that don't use the new mechanism! No-one is saying
that every font *has* to have a default, or that all fonts have to
have the *same* default. If this is *sometimes* useful, then is it
worth the costs? That is surely the trade-off that we, as engineers,
should be discussing? (The answer might well be "no", but surely
there is some balance of cost/benefits one way or the other?)

Martin

--
Martin C. Atkins			martin@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}