Please have a thorough look at
http://czyborra.com/unifont/
proposal for a GNU Unicode font
and share your comments about what must happen
before this can be released to the general public.
On 23 Jun 1998, Mark Crispin wrote:
> Newsgroups: netscape.public.mozilla.i18n
> Subject: re: About ISO-2022-CN and Mozilla
>
> It may be worthwhile to build a few CJK Unicode X (and perhaps
> MacOS) fonts, perhaps from the existing public domain CJK fonts.
On 23 Jul 1998, Markus Kuhn wrote:
> Newsgroups: comp.std.internat,comp.software.international,comp.fonts
> Subject: Re: Unicode reference fonts
>
> William Ehrich wrote:
> > Would it make sense for the code defining organizations also to
> > define a bit-mapped representation, at least as an example and
> > as a reality check?
Cheers
Roman
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/gnu-unifont
Free Web-based e-mail groups by eGroups.com
All I can say is "it's about time".
Yes, we badly need a basic and (reasonably) complete Unicode font. It doesn't
matter if it is ugly; that can be fixed at leisure.
What about the uni24.bdf font that came from Ho Yean Fee's group? She was
from the National University of Singapore, but then formed a separate compay.
I could probably find an address if I looked. I played with it a bit, but at
6MB it was too big for my X server to swallow... ;-)
Whatever you do, don't talk to Ohta Masataka (or similar cranks) about this
project. He'll come up with all sorts of reasons why it shouldn't be done,
and just waste everybody's time.
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/gnu-unifont
Free Web-based e-mail groups by eGroups.com
On Tue, 29 Sep 1998, Roman Czyborra wrote:
> Please have a thorough look at
>
> http://czyborra.com/unifont/
> proposal for a GNU Unicode font
>
> and share your comments about what must happen
> before this can be released to the general public.
Thank you for your efforts and keeping me informed about
your project. Let me begin with some comments and go
on to say a good news :-).
A couple of comments about your project web page:
> On the other hand, you can very well pretend to forget about the subtle
> difference between characters and glyphs and abuse Unicode as a
> one-to-one glyph numbering scheme. All Unicode characters have exactly
> one reference glyph in the Unicode book. Pasting these glyphs next to
> each other on horizontal lines just like you did with ASCII and
> ISO-8859-1 works for many languages, including most European languages,
> Ethiopic, Chinese, Japanese and Korean (CJK). Y
For Korean Hangul script, "one glyph-one code point" model doesn't
work as you think. Your assumption is valid if you wish to consider
only 11,172 pre-composed modern Hangul syllables in UAC00-UDxxx block.
However, that's only one of a few different ways of representing Hangul
which we're not so fond of, but which has been sort of forced upon
us(for several reasons including ease of implementation). A far more
ideal approach (I'm fully aware that your intention is NOT being ideal
and that your assumption is very useful for your limited purpose.
Therefore, this is just to dispell common misconception about Korean
Hangul scripts widely spread among non-Koreans) is use Hangul
Jamos(alphabets) enumerated in U1100-U11FF block and dynamically compose
glyphs for Hangul syllables made up of two,three or more Hangul Jamos.
In this respect, Korean Hangul is much more like most Indic scripts and
Thai script. Thus, the following statement of yours about Indic scripts
used in South(it's not Central) Asia(mostly Indian subcontinent) should
be noted to be the case of Korean Hangul scripts and to a lesser extent
Thai/Lao scripts.
> The native Central Asian languages from in and around India are
> currently the odd man out as nobody has publically numbered their many
> ligature glyphs yet. They will appear far from perfect with a bare
That's why Korean Hangul and Thai scripts are listed as target scripts
of X11 CTL.
> Others may hopefully find it more interesting to work on proofreading,
> optimizing and completing parts of the oriental [U+3000..U+FFFF] range.
> 20'902 - 18'174 = 2'728 Han ideographs are still missing, as well as the
> 11'172 - 2350 = 8'822 UHC precomposed Hangul syllables for which there
> does not seem to exist any free font yet.
"11,172-2,350 = 8,822 UHC" should read
"11,172-2,350 = 8,822 not covered by KS C 5601-1987 but convered
by KS X 1001(KS C 5601-1993) annex 3 and Unicode 2.0 or later", instead.
UHC has the same character repertoire as Unicode 2.0 and Johab encoding
defined in KS X 1001 annex 3, but its encoding has nothing to do with
standard(just a Microsoft's proprietary encoding), so refering to it
when talking about 8,822 precomposed Hangul syllable is not so good an idea
especially considering there ARE at least two standards including all of
them, Unicode 2.x(which has been adopted as KS X 1005) and KS X 1001
annex 3.
> Bitstream Cyberbit
> The most impressive Unicode font so far is Bitstream's cyberbit.ttf, a
> 13 MB serifed TrueType font covering all 20'902 Han ideographs besides
> basic Latin (no Vietnamese or IPA), Greek, Cyrillic, Arabic, Hebrew,
> Thai, and 1'153 of the Hangul syllables. It was released in 1997 for
> free download in the form of MS-DOS *.EXE archives from
> ftp.bitstream.com. You had to sign a license agreement restricting its
> use to a single copy. I am confused about the font's latest status.
Bitstream cyberbit, if my memory serves me right, includes a full set
of glyphs for 11,172(not 1,153) precomposed Hangul
syllables(UAC00-UD7A3). Besides, a self-extracting *.exe file can be
decompressed easily with Unix version of 'unzip'. If its license terms
permit, ttf2bdf would be the easiest way to get X11 BDF unicode
font(more or less complete).
Now, it's time for good news. Bitmapped glyphs for 11,172 pre-composed
Hangul in UCS-2 can be easily(with some Perl tinkering) made from
several different FREE sources. The reason it's not been done is those
who are most likely to do the chore(Linux and other free Unix users)
don't feel need for it. Why? Because there are a few alternatives to
huge X11 bitmap fonts : ttf support for X11 is widely available to
Korean Linux/FreeBSD users along with a couple of Korean truetype fonts
with 11,172 glyphs. In addition, an X11 font server for Linux that
presents several free scalable fonts used by the most popular Korean
word processor as X11 fonts to X11 application has been available about
a year.(For details, see http://pantheon.yale.edu/~jshin/faq/qa6.html
and references therein)
> 11'172 - 2350 = 8'822 UHC precomposed Hangul syllables for which there
> does not seem to exist any free font yet.
As I wrote above, there are some free fonts with all of 11,172
pre-composed Hangul syllables including several fonts distributed with
HLaTeX 0.98 although not in X11 BDF format. Anyway, here's one of a few
ways to get them in X11 BDF format as well as in your bitmap format.
Hanterm(Korean xterm) uses "Johab-encoded fonts" (made up of a few sets
of glyphs for Hangul jamos) to dynamically compose all modern (and a
subset of medivial) syllables. These fonts used by Hanterm available in
X11 BDF format can be converted to your format in UCS-2 encoding using
the Perl script enclosed below. I think it's much better to use bitmap
patterns generated with it than that produced out of Daewoo fonts
included in X11 distribution. Perhaps, johabm16.bdf or iyagi16.bdf would
be a good match for the rest of glyphs in your font.
Thank you again for your work,
Jungshik Shin
P.S. I may try to extract bitmap patterns from Postscript fonts used by
HLaTeX 0.98 sooner or later.
----------------------Cut-------------Here-------------------
#!/usr/bin/perl -w
# johab2ucs2.pl
# This script(working as filter) converts Hangul "Johab encoded fonts"
# with an unofficial XLFD name "-johab" in BDF format
# to UCS-2 encoded font in a format defined by
# Roman Czyborra <roman@...> at
# http://czyborra.com/unifont/
# 'hanterm304font.tar.gz contains about a dozen of
# "Johab-encoded" fonts. The package is available
# ftp://ftp.kaist.ac.kr/hangul/terminal/hanterm//hanterm304beta/fonts
# Please, note that this script only works with fonts whose
# XLFD name end with
#
# --16-160-75-75-c-160-johab-1
# (and whose file name in the package doesn't include 's' or 'sh' preceding
# '(m|g)16.bdf'. )
#
# There are four of them :
# johabg16.bdf,johabm16.bdf,johabp16.bdf,iyagi16.bdf.
#
# Fonts in the package with other XLFD names
# (johabs and johabsh) contain glyphs for about 5000 Hanjas and special symbols
# defined in KS C 5601-1987.
# Sep. 29, 1998
# Jungshik Shin <jshin@...>
# A more complete routine which not only covers
# *modern* pre-composed Hangul syllables in UAC00-UD7A3
# but also supports dynamic rendering of
# Hangul syllables(medivial as well as modern)
# using Hangul comibining Jamos at [U1100-U11FF]
# was made by Deog-tae Kim <dtkim@...>
# to be used in Java font-properties file.
# It's available at http://calab.kaist.ac.kr/~dtkim/java/
# Conversion routine from Hangul Jamo index to glyph index
# of Hangul "Johab-encoded" fonts as used by
# Hangul xterm, hanterm.
# The following routine is based on Hanterm by Song, Jaekyung
# available at ftp://ftp.kaist.ac.kr/hangul/terminal/hanterm
# The base font index for leading consonants
@lconBase= (
1, 11, 21, 31, 41, 51,
61, 71, 81, 91, 101, 111,
121, 131, 141, 151, 161, 171,
181
);
# The base font index for vowels
@vowBase = (
0,311,314,317,320,323, # (Fill), A, AE, YA, YAE, EO
326,329,332,335,339,343, # E, YEO, YE, O, WA, WAE
347,351,355,358,361,364, # OI, YO, U, WEO, WE, WI
367,370,374,378 # YU, EU, UI, I
);
# The base font index for trailing consonants
@tconBase = (
# modern trailing consonants (filler + 27)
0,
405, 409, 413, 417, 421,
425, 429, 433, 437, 441,
445, 459, 453, 457, 461,
465, 469, 473, 477, 481,
485, 489, 493, 497, 501,
505, 509
);
# The mapping from vowels to leading consonant type
# in absence of trailing consonant
@lconMap1 = (
0,0,0,0,0,0, # (Fill), A, AE, YA, YAE, EO
0,0,0,1,3,3, # E, YEO, YE, O, WA, WAE
3,1,2,4,4,4, # OI, YO, U, WEO, WE, WI
2,1,3,0 # YU, EU, UI, I
);
# The mapping from vowels to leading consonant type
# in presence of trailing consonant
@lconMap2 = (
5,5,5,5,5,5, # (Fill), A, AE, YA, YAE, EO
5,5,5,6,8,8, # E, YEO, YE, O, WA, WAE
8,6,7,9,9,9, # OI, YO, U, WEO, WE, WI
7,6,8,5 # YU, EU, UI, I
);
# vowel type ; 1 = o and its alikes, 0 = others
@vowType = (
0,0,0,0,0,0,
0,0,0,1,1,1,
1,1,0,0,0,0,
0,1,1,0
);
# The mapping from trailing consonants to vowel type
@tconType = (
0, 1, 1, 1, 2, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1
);
# The mapping from vowels to trailing consonant type
@tconMap = (
0, 0, 2, 0, 2, 1, # (Fill), A, AE, YA, YAE, EO
2, 1, 2, 3, 0, 0, # E, YEO, YE, O, WA, WAE
0, 3, 3, 1, 1, 1, # OI, YO, U, WEO, WE, WI
3, 3, 0, 1 # YU, EU, UI, I
);
# read in BITMAP patterns for Jamos from JOHAB-encoded BDF font file
# thru STDIN
$BITMAP=0;
while (<>) {
if (/^ENCODING\s+(\d+)/) { $i = $1; $jamo[$i]=""; }
elsif (/^BITMAP/) { $BITMAP=1; }
elsif (/^ENDCHAR/) { $BITMAP=0;
}
elsif ($BITMAP) {
y/a-f/A-F/;
s/\n$//;
$jamo[$i] = $jamo[$i] . $_;
}
}
for ( $j=0 ; $j < 11172 ; $j++ ) {
$init = int( $j / 21 / 28) ;
$medial = int($j / 28 ) % 21+1 ;
$final = $j % 28;
printf ("%04X: %64s\n", $j+0xAC00, &compose_hangul($init,$medial,$final));
}
sub compose_hangul
{
local($l,$m,$f) = @_;
@l_bit = unpack("a2" x 32, $jamo[&get_ind($l,$m,$f,1)]);
@m_bit = unpack("a2" x 32, $jamo[&get_ind($l,$m,$f,2)]);
@f_bit = unpack("a2" x 32, $jamo[&get_ind($l,$m,$f,3)]);
for ( $i = 0; $i < 32; $i++) {
$bit[$i]=sprintf("%02X",
hex($l_bit[$i]) | hex($m_bit[$i]) | hex($f_bit[$i]) );
}
return pack("a2" x 32, @bit );
}
sub get_ind
{
local($l,$m,$f,$wh) = @_;
# ($l >= 0 && $l < 19 && $m >=0 && $m < 21 && $f >=0 && $f < 28) or
# die ("$0: get_ind() : invalid Jamo index\n");
if ( $wh == 1 ) { # leading consonant index
return $lconBase[$l] +
($f > 0 ? $lconMap2[$m] : $lconMap1[$m] ) ;
}
elsif ( $wh == 2 ) { # medial vowel index
$ind = $vowBase[$m];
if ( $vowType[$m] == 1 ) {
# For vowels 'o' and alikes,
# Giyeok and Kieuk get special treatment
$ind += ( ($l==0 || $l == 15) ? 0 : 1)
+ ($f > 0 ? 2 : 0 );
}
else {
$ind+= $tconType[$f];
}
return $ind;
}
else {
return $tconBase[$f] + $tconMap[$m];
}
}
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/gnu-unifont
Free Web-based e-mail groups by eGroups.com
Instead of writing down the current situation of the
kernel keyboard/console drivers, I installed the xterm
from http://www.clark.net/pub/dickey/xterm/xterm.html
and the font from http://czyborra.com/unifont/
(I mean unifont.hex).
But there was no Tibetan in this font.
A first attempt (I made the 30 consonants) produces
0F40:000000007E2A2A4A4A02020202020000
0F41:000000007E5252525A46424040400000
0F42:000000007E4A4A4A6A1A0A0202020000
0F43:000000007E4A6A1A0A027E405C220400
0F44:000000007E4040407C02000000000000
0F45:000000007E10186422120C0000000000
0F46:000000007C1038545454280000000000
0F47:000000007E407E407C02000000000000
0F49:00000000304808182404040810000000
0F4A:000000007E02023E4240402010080000
0F4C:000000007E02023E4040404000000000
0F4E:000000007E1010385454484040400000
0F4F:000000007E40407C4202020408100000
0F50:000000007E42462A1222621A06020000
0F51:000000007E40407C0202020200000000
0F53:000000007E08081C2A2A120202020000
0F54:0000000072222222621A060202000000
0F55:00000000722222266A1A060202000000
0F56:000000007E222222621A060202000000
0F58:000000007A1212325A56220200000000
0F59:000000037E10186422120C0000000000
0F5A:000000037C1038545454280000000000
0F5B:000000037E407E407C02000000000000
0F5D:00000000225252121E121A0600000000
0F5E:000000003C44444E5555494131010000
0F5F:000000007E027E027E02000000000000
0F60:00000000384444580402000000000000
0F61:000000005A525A260202000000000000
0F62:000000007E10103C4202020000000000
0F63:00000000324A4A5A4602020000000000
0F64:000000000E12125E2212020200000000
0F66:0000000072524A4A6616020200000000
0F67:000000007E204C320204081000000000
0F68:000000005D5969555523030101000000
readable but ugly.
Are there Tibetan fonts already?
[Note: the above has no vowel signs, no digits,
no punctuation, ...]
Andries
Dear List-owner,
As of 01/11/2000, your eGroups email group, gnu-unifont@egroups.com,
is marked as inactive. Our records show that this group doesn't meet
minimum membership requirements or hasn't been used in the past 90
days.
IMPORTANT: If you wish to reactivate this group, you need to take
action as described in this message. If you do nothing, your group
will automatically be removed in 30 days, and all data deleted.
----------------------------------------------------------------------
eGroups Inactivity Policy
----------------------------------------------------------------------
eGroups email groups with 2 or fewer members *OR* no message activity
over a 90 day period are classified as inactive. This policy applies
to groups that are older than 90 days. When a group is classified (in
eGroups' sole discretion) as inactive, eGroups notifies by email the
list-owner. INACTIVE GROUPS HAVE 30 DAYS TO BECOME ACTIVE OR THE GROUP
AND ITS DATA, INCLUDING MESSAGE ARCHIVES, WILL BE PERMANENTLY REMOVED
FROM THE EGROUPS DATABASE.
Why do we do this?
In order to continue providing the Internet's best email groups,
eGroups periodically removes groups that appear to be inactive. Our
members appreciate browsing and joining groups that are active.
----------------------------------------------------------------------
What you need to do
----------------------------------------------------------------------
- If you want to reactivate your group
To reactivate your group, simply make use of our service. Try
inviting a few new members, or starting a fresh discussion topic.
It's easy, it's fun and it's free! We will not notify you when
your group is reactivated. To view your group, click here:
http://www.egroups.com/group/gnu-unifont/info.html
- If you want to delete your group
click here >
http://www.egroups.com/listman?method=display_policies&listname=gnu-unifont
If you are not using this group, you can delete it today by going
to the URL shown above and clicking the "Delete this group" button
on the bottom left-hand side of the page. You will need to sign in
as the list-owner of this group to access this page.
- What happens if you do nothing
If you do nothing, your group will be removed in 30 days. ALL
DATA, INCLUDING MESSAGE ARCHIVES, WILL BE PERMANENTLY DELETED. You
may receive a second notice shortly before your group is removed.
----------------------------------------------------------------------
For Customer Support
----------------------------------------------------------------------
If you have questions or comments about our service, please contact us
at support@egroups.com.
Thanks for using the eGroups service.
Hello!
As you might already know, since the gnu-unicode project has started,
there has been another big Unicode bitmap font creation project:
Together with a number of other volunteers, I have extended all the
public domain fonts "-misc-fixed-*" that xterm and many other X
applications use to become 16-bit Unicode fonts. The larger of these
font sizes now cover all the over 3000 characters that can be adequately
represented in a fixed-width font. These fonts are already shipping with
XFree86 3.9.17 and can be expected to become quickly widely installed on
all open source X systems once XFree86 4.0 is released (around 2000 March
I'd guess).
You can download these BDF fonts from
http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz
They are pretty complete and stable by now. There is also a collection
of Asian fonts on
http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts-asian.tar.gz
but this is in a very early stage and will need a lot of work. The fonts
found in there cover in fact so far only JISX208 and CP1252.
Check out the README files in the above distributions for lots of
interesting details information, as well as
http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
There is now a lot of activity going on to make Linux and associated
applications capable of using UTF-8 and the Unicode fonts. For details,
please read
http://www.cl.cam.ac.uk/~mgk25/unicode.html
and join the linux-utf8@... mailing list as described on that page.
Some things that I suggest could be done with the gnu-unifont are:
- The dotted circle should be removed from all combining characters.
With Robert Brady's latest patch (see above URL), xterm does now
support overstriking combining characters and if someone wants
to output a combining character with a dotted circle, the proper
way to do this is to precede the combining character with
U+25CC DOTTED CIRCLE as it is done in the *.repertoire-utf8
files in the above ucs-fonts.tar.gz package.
- The font should actually be split into two separate 8x16 and 16x16
fonts. It should be left to the application to choose, which
character is half-width and which is full-width, and it makes
sense to provide both options for many characters (especially if
JIS compatibility is desired by some applications and ISO 8859
compatibitily by others). Xterm needs for Unicode CJK support
a separate half-width nd full-width CharCell font. Currently,
gnu-unifont is a single proportional bi-with font that is
in its BFD incarnation mislabled as a CharCell font.
- It would be nice, if we could merge the 16x16 section (perhaps
padded to 18x18) with the Asian -misc-fixed-*-iso10646-1 package. For
political reasons, it would be helpful to drop the GPL license
and put the font under a BSD or MIT style license, or even
better let it just become completely public domain, just as the current
-misc-fixed-* fonts are already. (Some people in XFree86 have been
burnt in the past badly by the GPL, and the GPL is really nonsense
anyway for a pixel font, for which there is no notion of a
"source code" and a "compilation" step.)
- The -misc-fixed-*-iso10646-1 fonts contain already lots of
new Unicode 3.0 and UCS:2000 characters that are still missing
in unifont, and which should also be added.
In case Roman doesn't have the time any more to maintain the Unifont, I
would be happy to continue maintaining it as part of the
-misc-fixed-*-iso10646-1 fonts, provided the contributors can agree to a
sufficiently liberal licence. This would also ensure that the fonts can
ship together with all the major X distributions, including commercial
ones, such that they can become ubiquitously installed. How does that
sound?
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
[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
Send Email
