[Sorry if you receive this multiple times; it just means that you are on
all the right mailing lists ... ;-]
Here is some important news for anyone interested in text processing
and character sets:
The new edition of the Unicode standard
The Unicode Consortium: The Unicode Standard, Version 3.0,
Addison-Wesley Developers Press, 2000, 1070 p., with CD-ROM,
ISBN 0-201-61633-5, ~50 USD.
http://www.unicode.org/unicode/uni2book/u2.html
has just been published. You can ordered it now in your favourite
local or online book shop.
If you find yourself involved with fonts, character set conversion, file
formats, text processing and rendering tools, i18n, etc., then the
Unicode 3.0 book is definitely a reference that you want to have on your
desk. Unicode (ISO 10646) is the Universal Character Set that is
expected to replace in the not too far future all other ASCII
extensions. Most other character sets are today already defined in terms
of the ISO 10646 code positions of their characters.
Lots of updated background information on the progressing introduction of
Unicode/UTF-8 on POSIX/GNU/Linux systems is available on
http://www.cl.cam.ac.uk/~mgk25/unicode.html
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Hi,
I found your page regarding Unicode BDF fonts and thought you might be
interested in my new program, "txtbdf2ps". Its home page is
http://www.linuxstart.com/~winitzki/txtbdf2ps.html and it's a perl
script that can take a text file in either 8-bit ASCII or UTF-8, take a
BDF font file, and produce compact Postscript output that can be printed
on most printers. (The BDF font is embedded as a set of bitmaps while
the Postscript font machinery is hacked to accept more than 256
characters.) I would be interested to hear what you think about it.
Right now the latest development version supports Unicode input although
it is limited to the first 65535 characters.
Regards,
--
Serge
I've been working on Cherokee for the Unifont. Here's a
prelimenary version of the first three rows.
13A0:00000000782422222222222224780000
13A1:00000000784442447850484444430000
13A2:000000007F4908080808080808080000
13A3:000000001C0814122151515155560000
13A4:000000003048484B494E484848300000
13A5:000000000008080008080808083E0000
13A6:000000003C424240207F0442423C0000
13A7:000000001C02725252526242423C0000
13A8:000000007020222A3E20202020700000
13A9:000000004242424242261A02023C0000
13AA:0000000018242442427E424242420000
13AB:000000001F0404040404044444380000
13AC:000000007E4040407C404040407E0000
13AD:0000000010101010507E521414180000
13AE:000000003C220272223C202020200000
13AF:000000000E111111111F111155770000
13B0:000000007C1010121E121010107C0000
13B1:000000007E4240404040404040400000
13B2:000000001824242424185B595A240000
13B3:000000005252524A5A5A666642420000
13B4:00000000040A0A083844444444380000
13B5:000000003C4242524C40404040400000
13B6:000000003C424240484C4A4244380000
13B7:00000000424266665A5A424242420000
13B8:000000003864620242725E0202020000
13B9:00000000180A15207C541414141C0000
13BA:00000000324A4A4A4E4E4A4A4A320000
13BB:00000000424242427E42424242420000
13BC:000000003810384402020242423C0000
13BD:000000004742424242261A02723C0000
13BE:000000003C424242427E4242423C0000
13BF:000000002078202020202027221E0000
13C0:000000003C424240404E4242463A0000
13C1:00000000304848484444444242470000
13C2:00000040404040405C62424242420000
13C3:000000007E42020408102040427E0000
13C4:000000001C22720272221E0202020000
13C5:00000000304848484A4F484848300000
13C6:000000007F49080808080808497F0000
13C7:000000000C1202424A4A4A4A4A340000
13C8:00000000245A4A162848484848300000
13C9:00000000672524242828282828100000
13CA:000000004141414149555151512E0000
13CB:000000003C4240403C404046423C0000
13CC:0000000077222222223E2222221C0000
13CD:000000000609090909011D6959660000
13CE:00000000040C142444447E0404040000
13CF:0000000070202020203C2222227C0000
I think I may be overusing the right edge a little bit. Unfortunetly,
Cherokee relys on fine differences too much (compare U13B3 against
U13D4, or U13A1 against U13D2) and has some pretty complex glyphs
(U13B9, U13CD, U13A3). Anyway, while I am going to have a native
Cherokee reader look over them, I'd appreciate comments from the
computer/typographical perspective.
--
David Starner - dstarner98@...
Finger dvdeug@... for more information.
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
-- Dr. Burchard, math professor at OSU
13D0:000000001C0808080B5D6808081C0000
13D1:00000000724D7127407C4242423C0000
13D2:000000007844424478504844444E0000
13D3:000000007020202020202022221C0000
13D4:00000000555555495959656543410000
13D5:000000003C424F40201F0442423C0000
13D6:000000007E50101010101013110E0000
13D7:000000000702020202060A1222470000
13D8:000000007F42020202060A1222470000
13D9:00000000414141222222141408080000
13DA:000000003C424240300C0242423C0000
13DB:00000000364962504848484828100000
13DC:00000000182418242255555555220000
13DD:000000001824404040404042427E0000
13DE:000000004040404040404042427E0000
13DF:000000003C42424040404042423C0000
13E0:000000000722527F12121212120C0000
13E1:00000000245A595B1824242424180000
13E2:000000007C4242427C40404040400000
13E3:000000003C42474040464642423C0000
13E4:000000007B5112121414141818100000
13E5:00000040404040434D74444444440000
13E6:00000000424448506060504844420000
13E7:00000000070202021E224242221C0000
13E8:0000000030484A454040454A48300000
13E9:0000000038444C4C40404E44443B0000
13EA:00000000225555535131115955620000
13EB:000000003C424272525E4242423C0000
13EC:000000002255515161414141221C0000
13ED:00000000081412120A06026264380000
13EE:000000003C464640407C4242423C0000
13EF:0000000006090101015D49492A140000
13F0:000000001C2222223C222262322C0000
13F1:000000001C081C222242424A524C0000
13F2:0000003C424240405C62424242420000
13F3:0000000030484A4540405C4848300000
13F4:000000007C4242427C424242427C0000
There may be some minor errata when I have a native reader look over them,
but this is pretty much it. If Marcus Kuhn is reading this, I license it
under the XFree license as well as the GNU GPL so it can be used included
in the fonts that come with XFree86, if anyone cares to do so.
--
David Starner - dstarner98@...
Finger dvdeug@... for more information.
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
-- Dr. Burchard, math professor at OSU
Any one here?
I was poking around for a quick script to get a list of missing glyphs,
and came up with a nice two line method, assuming you have Unidata.txt.
(1) awk 'BEGIN {FS=";"} {print $1}' < UnicodeData.txt > ud.txt
(2) cut -c1-4 unifont.hex | diff -u - ud.txt | grep ^+ | cut -c2-5
It's not terribly accurate - there's some extraneous stuff in the
Unidata.txt file and Unidata.txt doesn't have the Han glyphs. That
aside, wc claims there's about 5000 glyphs undone. To preserve
bandwith, I won't post the list here.
--
David Starner - dstarner98@...
http/ftp: x8b4e53cd.dhcp.okstate.edu
"A dynamic character with an ability to survive certain death and
a questionable death scene leaving no corpse? Face it, we'll never
see her again." - Sluggy Freelance
Here's the first 6 characters from that list of missing characters,
Capital Hwair and Wynn, Yogh (large and small) and OU (large and small.)
(Let me note that we here at OSU firmly object to the inclusion of OU
in Unicode without the corresponding addition of OSU.)
01F6:000000004848484878484A4A4A4E0000
01F7:000000005C6242424448506040404000
021C:000000003C4242020C340202023C0000
021D:0000000000003C42020C32020C300000
0222:00000000244242423C424242423C0000
0223:00000000284444443844444444380000
--
David Starner - dstarner98@...
http/ftp: x8b4e53cd.dhcp.okstate.edu
"A dynamic character with an ability to survive certain death and
a questionable death scene leaving no corpse? Face it, we'll never
see her again." - Sluggy Freelance
David Starner wrote:
> Any one here?
Hi, I am here, silent. I hope we are not the only two people...
> I was poking around for a quick script to get a list of
> missing glyphs,
> and came up with a nice two line method, assuming you have
> Unidata.txt.
>
> (1) awk 'BEGIN {FS=";"} {print $1}' < UnicodeData.txt > ud.txt
> (2) cut -c1-4 unifont.hex | diff -u - ud.txt | grep ^+ | cut -c2-5
>
> It's not terribly accurate - there's some extraneous stuff in the
> Unidata.txt file and Unidata.txt doesn't have the Han glyphs. That
> aside, wc claims there's about 5000 glyphs undone. To preserve
> bandwith, I won't post the list here.
I don't have awk or those nice Unix commands.
Is the list so big? What about posting it zipped? Or, even better, asking
Roman Czyborra to publish it on his home page?
As (of course) no glyph can be used, it would be great to find the way of
adding Unicode names to each line.
_ Marco
Marco.Cimarosti@... wrote on 2000-06-27 10:54 UTC:
> As (of course) no glyph can be used, it would be great to find the way of
> adding Unicode names to each line.
Many of the missing glyphs (especially the stuff added with Unicode 3.0)
have been in the XFree86 4.0 -misc-fixed-*-iso10646-1 fonts on
http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
now for quite some time, and you can simply use today xterm -u8 on any
recent Linux distribution to display them.
Comfortable tools for checking the coverage of fonts have also been around
for quite some time. For example, you can convert everything to BDF and
then simply run it through the uniset Perl script in
http://www.cl.cam.ac.uk/~mgk25/download/uniset.tar.gz
This can output compact range lists in the CEN-MES format, detailed
lists with character names as text or HTML and optionally also with the
UTF-8 code, HTML NCR or HTML code chart image of the glyph. It not only
allows you to find missing glyphs, but also provides general set
arithmetic on Unicode subsets in order to generate easily target
repertoires for font projects.
Simply trying to fill the "entire repertoire" of Unicode 3.0 is a bit
naive, because Unicode encodes characters, but fonts would have to
encode glyphs instead. That is the same for the European and Far East
scripts, but for the Indic scripts, this makes a substantial difference!
You can't simply implement Devanagari etc. by copying the glyphs in the
Unicode 3.0 book onto the corresponding character positions. What the
GNU unifont file format (as well as BDF :-( ) lacks at the moment is a
way to assign a ligature glyph to a *sequence* of Unicode characters.
This would be necessary to start filling the Indic ranges in a sensible
way.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
(Is the CC neseccary? Is someone listening on the other side?)
This is the A w/ Ring and Angstrom sign, which are canonical-equivalent
characters. Because any Unicode conformant system must treat them the
same, it's a little surprising that they don't have the same glyph.
00C5:1824180018242442427E424242420000
212B:000018242418003C4242427E42420000
Looking at those two characters, it looks like 221B should have 00C5's
glyph, as it is much nicer and looks closer to what I've seen before as
the glyph for the Angstrom sign.
--
David Starner - dstarner98@...
http/ftp: x8b4e53cd.dhcp.okstate.edu
"A dynamic character with an ability to survive certain death and
a questionable death scene leaving no corpse? Face it, we'll never
see her again." - Sluggy Freelance
On Wed, Jun 28, 2000 at 09:31:39AM +0100, Markus Kuhn wrote:
> Many of the missing glyphs (especially the stuff added with Unicode 3.0)
> have been in the XFree86 4.0 -misc-fixed-*-iso10646-1 fonts on
>
> http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
>
> now for quite some time, and you can simply use today xterm -u8 on any
> recent Linux distribution to display them.
Actually not. Even Debian Woody (basically the latest CVS version) doesn't
have an xterm that accepts -u8.
> You can't simply implement Devanagari etc. by copying the glyphs in the
> Unicode 3.0 book onto the corresponding character positions. What the
> GNU unifont file format (as well as BDF :-( ) lacks at the moment is a
> way to assign a ligature glyph to a *sequence* of Unicode characters.
> This would be necessary to start filling the Indic ranges in a sensible
> way.
So, say, 0030+0305:0000FF00182442424242424224180000? That's trivial. The
big problems are that nothing uses the unifont file format now - it's only
translated into bdf. I don't know of any open source programs that would
handle that right now, either. Maybe when I'm digging around in the internals
of Yudit in my copous free time, I'll to add hexfont file reading and ligature
glyph handling.
--
David Starner - dstarner98@...
http/ftp: x8b4e53cd.dhcp.okstate.edu
It was starting to rain on the night that they cried forever,
It was blinding with snow on the night that they screamed goodbye.
- Dio, "Rock and Roll Children"
Sorry if I am repeating something already said, but I have some difficulty
following the discussion in gnu-unifont. Either part of the discussion is
done privately, or it is on other lists, or I am loosing some postings.
David Starner (quoting Markus Kuhn):
> > You can't simply implement Devanagari etc. by copying the
> glyphs in the
> > Unicode 3.0 book onto the corresponding character
> positions. What the
> > GNU unifont file format (as well as BDF :-( ) lacks at the
> moment is a
> > way to assign a ligature glyph to a *sequence* of Unicode
> characters.
> [...]
> So, say, 0030+0305:0000FF00182442424242424224180000? That's
> trivial.
> [...]
((( Well, not so trivial if you want it to remain compatible with
applications handling 16-bit codes only, and this includes BDF fonts. This
would require mapping an extended code like "0030+0305" to a 16-bit value,
that should be allocated somewhere in the 64K code space (e.g. in the
Private Use Area). )))
Apart ligatures, another feature is needed to implement complex scripts: the
ability to specify a context, both for ligatures and for single characters.
I imagine an optional field at the end of the code, with syntax like:
"[" contextId "]"
The "easy" example is with cursive scripts (Arabic, Syriac, Mongolian),
where you need, e.g.:
# SYRIAC LETTER MIM (nominal, isolated, medial, and final forms)
0721:0123456789ABCDEF0123456789ABCDEF
0721[cursiveIni]:0123456789ABCDEF0123456789ABCDEF
0721[cursiveMed]:0123456789ABCDEF0123456789ABCDEF
0721[cursiveFin]:0123456789ABCDEF0123456789ABCDEF
Of course, the rendering engine must know each script's shaping rules, and
the repertoire of glyphs available in the font, in order to load the
appropriate forms depending on the surrounding characters.
But also Indic ligatures need contextual shaping. E.g., a Devanagari "dead
consonant" (consonant+virama) displays as a "half consonant" glyph only if
another consonant follows the virama, otherwise (e.g. at the end of a word),
it uses the two regular glyphs for the consonant and the combining virama,
So:
# DEVANAGARI LETTER MA (half form)
092E+094D[indicHalf]:0123456789ABCDEF0123456789ABCDEF
Talking about combining accents reminds me of another extension that I deem
necessary. The 2-widths approach of unifont is a great idea, but it is not
enough for complex characters.
In an attempt to extend unifont's "quasi-monospaced" philosophy to deal with
complex scripts, I would suggest the following set of widths:
w) 16 px: "wide" (already in unifont)
m) 8 px: "medium width" (already in unifont)
n) 4 px: "narrow" (for some Indic matras and Indic half consonants)
z) 0 px: "zero width" (for combining accents, etc.)
But how to extend the simple and beloved unifont syntax to specify types (n)
and (z)?
I would suggest to add an *optional* field after the bitmap, to specify a
couple of measures. This "metrics" field could have this syntax:
":" <decimal left gut> "," <decimal width>
E.g., a combining acute would be specified as follows:
0301:00040810000000000000000000000000:8,0
Meaning that the 8-bit glyph will overlay to the glyph on the *left* hand
side, and that its advance is null.
An Arabic fathah (an "a" vowel sign) would look very similar, but with
differ metrics specifying that it has to overlay over the *right* hand
glyph:
0301:00040810000000000000000000000000:0,0
This also allows to specify *spacing* glyphs which have "guts" on the sides,
that must overlay on surrounding letters (similar beasts are needed for
Indic scripts).
See these two (admittedly stupid) examples: an "f" whose "curl" extends to
the right over the next letter, and a "j" whose tail extends on the left
under the previous letter:
0066:0000000000000FFF1000100010007C0010001000100010001000100000000000:0,8
006A:000000000000000400040000000C00040004000400040004000400040008FFF0:8,8
This feature can readily be mapped to BDF fonts generated from unifont, and
it is not so hard to implement -- but it opens the road to a minimal (but
viable) implementation of complex scripts.
Of course, all existing 8 and 16 bit glyphs that do not have the new
"metrics" field would implicitly use default values (respectively ":0,8" and
":0,16").
To preserve backward compatibility, such extensions could even remain out of
the original "unifont.hex". Imagine having a "unifontX.hex", using the new
syntax and containing only the *delta* glyphs that need to be added or
substituted to the main unifont.
_ Marco
I apologize if this is mangled - I'm sending from the web form
at www.egroups.com, and I'm not sure how it will come out. I won't
be reading personal mail for a couple weeks, but will probably be
reading the list archives.
--- In gnu-unifont@egroups.com, Marco.Cimarosti@i... wrote:
> Sorry if I am repeating something already said, but I have some
difficulty
> following the discussion in gnu-unifont. Either part of the
discussion is
> done privately, or it is on other lists, or I am loosing some
postings.
You can check on www.egroups.com, but I think you've got
everything so far.
> ((( Well, not so trivial if you want it to remain compatible with
> applications handling 16-bit codes only, and this includes BDF
fonts. This
> would require mapping an extended code like "0030+0305" to a 16-bit
value,
> that should be allocated somewhere in the 64K code space (e.g. in
the
> Private Use Area). )))
True. The addition to the Unifont is trivial, the extensions are
not so trivial. But adding to the Private Use Area is useless unless
there is someway to tell the clients how they are mapped to the
ligatures, which really needs a change to BDF or at least some
consensus so it's not only the Unifont that writes the ligature pair
data to name.lig_data. I was thinking about hacking support for the
hex format (w/ ligatures) into Yudit. So far the only Unix font
type that I know that supports features like this is OpenType, which
is only in Freetype 2 and I believe doesn't supports bitmap fonts.
It would be an interesting challenge to create an OpenType font from
Unifont that looks exactly like it at the right level.
> Apart ligatures, another feature is needed to implement complex
scripts: the
> ability to specify a context, both for ligatures and for single
characters.
Personally, I think this requires too much intellegence from a client
to be appropriate for Unifont. It's supposed to cover everything at
a basic level that a lot of stuff can handle.
> Talking about combining accents reminds me of another extension
that I deem
> necessary. The 2-widths approach of unifont is a great idea, but it
is not
> enough for complex characters.
Ouch. Recently there was a complaint about that "feature" of Unifont.
It certainly does ugly things to xterm - I've taken to using a Unifont
that has been stripped of all fullwidth characters for xterm. If
there are to be more widths, then let's change the Unifont to be a
proportional font, instead of claiming to be a monospaced font.
--
David Starner - dstarner98@...
LET THE WHOLE INTERNET SEE YOUR BUSINESS OR PRODUCT!
Are you tired of searching for a stable bulk friendly ISP.... Stop searching!
We are your one-stop Bulk mail experts. With all services under one roof. We
have the A-Z of the bulk emailing business.
Services that we offer:
* Bulk Emailing Service
Promote your web site by mass emailing. We can break our 85 million plus
database by country, state, or by target. Our lists are updated daily and washed
twice a week.
MASS MAILING PRICES (All Prices include emails)
500,000 EMAILS.............................. $375.00
750,000 EMAILS.............................. $562.00
1,200,000 EMAILS ........................... $720.00
1,600,000 EMAILS............................ $960.00
3,000,000 EMAILS........................... $1500.00
3,000,000 + EMAILS PLEASE CALL FOR QUOTE
Order by 12 pm PST mailed that night. We mail 7 days per week.
*Bulletproof Dial-up Account - 56K V.90
For all you "do it your selfer's" Promote your site with reliable dial up
service 7 days a week 24HRs a day. Stop wasting time and energy burning through
ISPs. Triple the number of emails you are sending. 24 hr Set-up.
Dial - up pricing
30 days of service $500.00 (unlimited use) one time set-up of $300.00
* Bulletproof Web Hosting
Promote your web site as much as you want without the worries of it getting shut
down because of spam complaints. Our operation centers are protected by Central
Intelligence Agency level security that delivers safety-proof reliability. For
this reason we are ranked the first largest Bulk Friendly Internet Service
Provider in the world.
Bulletproof Hosting Prices
30 days Hosting $600.00 and a one time Set-up of $200.00
24 hr Set-up
*Targeted Email Lists
Quotes available upon request
For more information and to get started please call us at:
1 (323) 874-4647 .
If you would like to be removed , please email: webmaster@... with the word
"Remove" in the subject line. We apologize for any inconvenience.
CABLE TV DE-SCRAMBLER
Build Your Own Cable De-scrambler for less than $17. There are only 7 Simple
steps to follow, and all the parts (parts number list provided) can be easily
found at your local electronics store.
We Send You:
¨ E-Z To follow Assembly Instructions.
¨ E-Z To read Original Drawings.
¨ The Parts List.
Frequently Asked Questions--CABLE TV DE-SCRAMBLER
Q: Will the de-scrambler work on Fiber, TCI, Jarrod and
Satellite systems?
A: The answer is YES.
Q: Do I need a converter box?
A: This plan works with or without a converter box. Specific
Instructions are included in the plan for each.
Q: Can the de-scrambler be detected?
A: No, the signal de-scrambles right at the box and does not
Move back thorough the line.
Q: Do I have to alter my existing cable system, television or
VCR?
A: The answer is no.
Q: Does this work everywhere across the country?
A: Yes, every where in the USA plus England, Brazil, and
Other countries.
Q: When I order, when will I get my stuff?
A: We mail out all orders within 48 hours of receiving it.
To get the instruction plans, the easy to follow diagram, and parts list. Just
send $17, (Cash ,Check or Money Order.) and you will receive your Cable
De-scrambler Plans right away.
You get the complete package all for just $17 (Shipping and Handling included),
CA residents please add sales Tax (8.25%)
Send your orders to: SMA
1300 N. Cahuenga Blvd STE#292
Hollywood, CA 90028
PRINT YOUR:
NAME______________________________________________
ADDRESS___________________________________________
CITY/STATE/ZIP____________________________________
PHONE NUMBER______________________________________
E-MAIL ADDRESS____________________________________
Thank you for your interest.
(DISCLAIMER pleases notes: This information is being provided for educational
purposes only. The information itself is legal, while the usage of such
information may be illegal. We do not advocate unauthorized use or theft of
cable services. If in doubt check your local laws and act accordingly.)
To be removed from our future mailing please email webmaster911@... with
the word remove in the subject line
On Thursday 20 July 2000 06:03 pm, David Starner wrote:
> On Wed, Jun 28, 2000 at 09:31:39AM +0100, Markus Kuhn wrote:
> > You can't simply implement Devanagari etc. by copying the glyphs in the
> > Unicode 3.0 book onto the corresponding character positions. What the
> > GNU unifont file format (as well as BDF :-( ) lacks at the moment is a
> > way to assign a ligature glyph to a *sequence* of Unicode characters.
> > This would be necessary to start filling the Indic ranges in a sensible
> > way.
>
> So, say, 0030+0305:0000FF00182442424242424224180000? That's trivial. The
> big problems are that nothing uses the unifont file format now - it's only
> translated into bdf. I don't know of any open source programs that would
> handle that right now, either. Maybe when I'm digging around in the
> internals of Yudit in my copous free time, I'll to add hexfont file reading
> and ligature glyph handling.
http://www.wholehog.fsnet.co.uk/robert/indic/fonts.html has a design for
ligatures in BDF, so if someone wants to implement that in the Unifont
utilities, ligatures could be added to GNU Unifont. Any objections to the
above format for Unifont's ligatures? The only problem is that it will need
to be automatically mapped to a private use point. If we don't want to add
that much intellegence to the Unifont, we can do it by direct reference to
private use points; i.e 0030+0305:E000.
David Starner - dstarner98@...
I´m planning to use the GNU Unifont in an embedded system I am
developing. The plan is for the device to be able to handle all
characters for the Japanese market.
I notice that the CJK Ideographs fill the 16x16 bitmap i.e. there is
no empty row of pixels at the bottom or on the side.
Does anybody know if it is possible to use the Unifont ideographs
using a 16x16 cell with no additional space or do I need to allocate
a 17x17 cell for the double width characters?
This would probably mean that I would have to allocate a 8x17 cell
for the western characters.
Are you still actively working on the GNU Unifont? I've done some more
characters for the GNU Unifont (cf. http://dvdeug.dhis.org/unicode.html ),
but I'd like to some deeper stuff too (like add 'ligature' characters
like those nessecary for Lakota and Lithuanian, and cleaner seperation
of the widths), and you don't appear to be on gnu-unifont@egroups.com
anymore. If you aren't working on it anymore, would you mind if I formed
a Sourceforge project for it?
Also, what's the license on the GNU Unifont? A lot of people seem to
believe that it's GPL, but the webpage doesn't really say anything about
it. The Debian package has this in it:
All of my works you find here are freeware. You may freely copy, use, quote,
modify or redistribute them as long as you properly attribute my contribution
and have given a quick thought about whether Roman might perhaps be interested
to read what you did with his stuff. Horizontal rules don't apply.
which isn't the clearest of licenses, but works. (What the heck does
"Horizontal rules don't apply" mean?)
--
David Starner - dstarner98@...
http://dvdeug.dhis.org
"(You see, the best way to solve a problem is to rigorously define it in
terms of other people's problems and then run away quickly.)"
-- Roland McGrath <frob@...>
Dear David:
> Are you still actively working on the GNU Unifont?
I am actively filing everything in my unifont mail folder in Status:
TODO and actively procrastinating the needed work because the days
still are too short for all the creative deeds I consider necessary.
More urgent political needs at http://egroups.de/messages/bine-news
and http://taz.de/ and their restricted work environments (the glibc
and RPM upgrade cycle breaking all stability of cross-version
compatibility pisses me off!) have been handicapping me. I have
gotten used to working online and neglecting my lovely slow offline
notebook with the unifont master files at home. Sorry about that.
> I've done some more characters for the GNU Unifont (cf.
> http://dvdeug.dhis.org/unicode.html ),
Thank you. You mean http://dvdeug.dhis.org/unifont.html
> but I'd like to some deeper stuff too (like add 'ligature'
> characters like those nessecary for Lakota and Lithuanian, and
> cleaner seperation of the widths), and you don't appear to be on
> gnu-unifont@egroups.com anymore. If you aren't working on it
> anymore, would you mind if I formed a Sourceforge project for it?
Not at all, I would love to learn more about Sourceforge.
But does Sourceforge work reliably enough? I couldn't get past
http://sourceforge.net/account/verify.php?confirm_hash=331ca3cd3e7ffb728d35bf60c\
8511172
which throws me in an endless password fill-out loop.
I am listed in http://www.egroups.com/members/gnu-unifont but have
been misbehaving as read-only.
I as a postgraduate am currently following the very innovative open
source seminar http://user.cs.tu-berlin.de/~tron/oss/ to find some
better motivation and project organization.
Last but not least http://eva-marbach.net/ is currently relocating our
virtual server http://czyborra.com/unifont/ from 209.204.208.78 to
ssh-less 207.106.23.6 and I hope to be able to move it on to a
self-administered 217.13.203.149 at http://neuralcenter.de/ in 2001.
> Also, what's the license on the GNU Unifont? A lot of people seem
> to believe that it's GPL, but the webpage doesn't really say
> anything about it. The Debian package has this in it: All of my
> works you find here are freeware. You may freely copy, use, quote,
> modify or redistribute them as long as you properly attribute my
> contribution and have given a quick thought about whether Roman
> might perhaps be interested to read what you did with his stuff.
> Horizontal rules don't apply.
That was the http://czyborra.com/#freeware license quoted.
> which isn't the clearest of licenses, but works. (What the heck
> does "Horizontal rules don't apply" mean?)
Take it as a pun. It means that just like the GNU intlfonts for leim
my GNU unifont is not GPLed but absolutely free and friendly because
that seemed to cause the least hassles for me. I have not had any
reason to regret that.
Cheers
Roman
Hi,
I'm experimenting with unifont as a solution
for Unicode text display in OpenGL applications.
I'd like to clarify the license for unifont...
Is it GNU or GPL?
Cheers,
Nigel Stewart
--
Nigel Stewart (nigels@...)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Hello.
I am one of the administrators of /efont/ -- The Electronic Font Open
Laboratory -- in Japan.
* http://openlab.ring.gr.jp/efont/
(currently Japanese Mailing List only)
I am very interested in unifont. But the license of unifont seems
unclear. So I began to make yet another unicode bitmap fonts which
include bitmaps whose copyright is clear only. And I want to merge your
copyrighted bitmaps if possible.
* http://openlab.ring.gr.jp/efont/unicode/
(currently written in Japanese)
Would you please tell me which characters in unifont are YOUR
copyrighted works? And please tell me the license of them (anyone can
use, copy, modify and distribute for any purpose without fee? copyright
notice and permission notice needed?).
Regards,
Kazuhiko <kazuhiko@...>
Hello,
My name is Joshua Hadley; I work for Agfa Monotype Corporation. I came
across your 'unifont' page, and wanted to add some information, for whatever
it's worth: There are at least 2 "full Unicode" fonts available. Not under
GPL, I'm afraid, but available nonetheless.
The first font is Arial Unicode MS, which encodes at least one glyph for
every defined Unicode codepoint (there are many more glyphs than characters
in the font because of extensive OpenType Layout tables). We created this
font exclusively for Microsoft, and they currently distribute it with their
Office 2000 product. Coverage is Unicode 2.1, format is OpenType (TrueType).
Another font which we currently have available for license is "Andale". The
coverage is Unicode 3.0, and there is currently only a one-to-one
character-to-glyph mapping. The format is also OpenType, however there are
no OpenType layout tables at this time.
I hope this information will enhance your documentaion about fonts and
Unicode.
Kind regards,
Joshua Hadley
Agfa Monotype Corporation
http://www.agfamonotype.com
Deary Mr. Roman Czyborra,
I'm currently working on multilingualization of a text-based browser.
Mainly for debuggin purpose of it, I have been seeking for complete
Unicode font set these few weeks, and have found your great work, GNU
Unicode font. Thanks a lot for keeping such beautiful font set
publicly available.
Attached below is a patch to your hex2bdf to utilize your
unifont.hex.gz with xterm-146 (UTF-8 ready version of xterm). For
this version of xterm, one must specify separate font sets for double
width characters and for signle ones width in such a way that bounding
box of fonts for former have double width of that for latter. So I
needed to modify hex2bdf so that it generates two type of bdf files.
With best regards,
--
SUTO, Kiyokazu <suto@...>
http://pub.ks-and-ks.ne.jp/pgp-public-key.html
Hi,
Do you have fonts available for Chinese (encoding GB2312-80, 13000,
18040)?
thanks,
Frederic
--
=========================================================================
Hong Feng/President & CEO
RON's Datacom Co., Ltd.
Email: fred@... http://www.rons.net.cn
=========================================================================
Hi!
I am designing a bitmap font compressor for the use of your great font
Unifont. I am implementing it so that Unifont can be used in embedded
systems with a small memory footprint. My aim is to have a direct access
to each glyph while maximizing the compression ratio.
You could use it as an alternate way to distribute your font Unifont. I am
currently working on the "Unifont renderer" which can render
antialiased compressed Unifont glyphs at any size.
Here are my first results about lossless compression of your whole Unifont
font:
* As a reference, gzip achieves 418676 bytes (12.0 bytes/glyph) (excluding
Hangul and Braille glyphs because the renderer can compute them on the
fly). Of course no direct access is possible so the font must be
decompressed before it can be used.
* My current compression code reaches 336559 bytes (9.7 bytes/glyph) while
direct access is preserved because the font is compressed by independent
chunks of 256 glyphs.
* It is possible to go as low as 300000 bytes (8.6 bytes/glyph) but it
uses more memory to decompress it and direct access cannot be achieved.
Will you interested by supporting such a project, for example by citing it
on your page ? Of course, the full source code of the encoder and the
renderer will be available under the GPL licence. Are you aware of similar
other projects ?
regards,
Fabrice Bellard.
Hello Roman.
Attached is "Ideographic description characters" range for your Unifont
project.
They occupy 2ff0-2fff range in basic plane. I have also seen them in
oriental dictionaries.
Hi Roman.
I would like to contribute a couple of scripts for your gnu unicode font
project. Is it still alive, BTW?
Attached file n1643.hex is Klingon script for plane 1. It is not in standard
yet and there are very small chances it ever will be.
u13A0.hex is cherockee letters for basic plane. They are already in Unicode.
Andrew Nikitin.
Mr. Czyborra,
I don't understand what you mean by "Chinese or Taiwanese legibility" at
http://czyborra.com/unifont/ . If you mean Traditional and Simplified
Chinese, then I would understand. However, Traditional Chinese (the
character format in use in Taiwan and to a large extent, Hong Kong) is not
a "Taiwan" phenomenon. Simplified Chinese (the one in use on mainland
.. aka communist China) is a communist phenomenon - it was created to make
it easier for peasents to learn reading/writing skills.
Let me put it this way .. simplified Chinese is like English's
"phonics" system (see 'Hooked on Phonics' in US TV advertisement).
Slow connection on my end (packet drops and extremely bad lag .. in the
seconds) prevents me to elaborate further. This is ment as constructive
criticism - if tone is "bad", its my frustration of the slow connection
seaping through.
---
Best regards,
Benjamin Tsai
tsaib@...
PGP Key: http://www.taiwanonline.org/tsaib/pgpkey.asc
Send Email
