I'm sorry for all the crossposts - I should have specified lists to reply
to. This pair is good, so long as we're talking about both the Unifont and X
fonts. Remember to cut it back if it gets too specific to one group.

Also, my apologies for the CRLF problems with the unifont. My Unix box
doesn't talk to my modem right, so it got ran through windows, and something
evidently decided to mess with it along the way. There has been a working
version at the same location for the last 10 hours.

From: Markus Kuhn <[EMAIL PROTECTED]>
> I strongly recommend that you follow the practice we established in
> XFree86 for the -misc-fixed-*-iso10646 fonts and split up GNU Unifont into
> two separate charcell font files, one 8x16 and one 16x16.

The hex file shouldn't have to be split - we can do two widths in the same
file. However, we have enough work just keeping up Unicode without worrying
about making double width copies of every character. If someone wants double
width characters, they're going to need to make them.

I agree with Kuhn about Yudit - if it wants biwidth fonts, it should make
fontsets.

> I doubt whether the
> Devanagari in GNU Unifont is of any practical use whatsoever at the
> moment.

It can't be worse than nothing. It at least shows you have Devanagari.

> The hex source format and tools for Unifont should definitely be extended
> to allow a glyph to be assigned to several sequences of UCS characters,
> not just as currently to one single UCS character per glyph.

Okay. I'll see about getting that done. The biggest problems is only Pango
cares about BDF annotations as of yet, and BDF is the only format we convert
to.

(See http://www.wholehog.fsnet.co.uk/robert/indic/fonts.html for the BDF
ligature hacks.)

> You can also implement combining characters are precomposed ligatures of a
> base character and one or more combining characters. This is a good idea
> for those base/accent combinations, where simple overstriking leads to
> unpleasant results.

Any one have a list of important Latin/Cryllic/Greek characters that can't
be handled with precomposed characters alone? I'm probably going to include
the Lakota characters as a start . . .

> To make them readable, programs have to add 1-2 empty pixel rows between
> the glyphs. But this breaks up box drawing chartacters. Therefore, in the
> -misc-fixed-* font project, we went for 9x18 and 18x18 as the format of

That's a non-sequitor. You can have an empty pixel row in 8x16/16x16, too.
We just don't happen to have one.

From: Bruno Haible <[EMAIL PROTECTED]>
> Btw, what is the license of the unifont? Is it suitable for inclusion
> in XFree86?

License was included:

License:
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.

It's about equivelent to the XFree86 license. If you can convince Roman to
give us a nice clear XFree86 license, I'd be greatly appreciative . . .

--
David Starner - [EMAIL PROTECTED], [EMAIL PROTECTED]

-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/

Reply via email to