Keith Packard wrote on 2002-02-02 20:56 UTC: > Instead, I'd like to suggest that we create a separate tool that can > transcode the fonts not already available in a Unicode version into Unicode > for use by all Freetype based applications.
I have already one written in Perl that converts non-Unicode BDF fonts into ISO10646-1 encoded BDF fonts. I'd be happy to bring it into releasable shape once I have a bit more time, though I'd rather like to see such tools only be used in the hands of experts, as some amount of checking and tweaking on the output can lead to significant better BDF files. > One important question is whether XFree86 currently contains fonts with > glyphs not covered by Unicode; As far as I can tell, as of Unicode 3.2 and UCS:2002 the answer is: no. For the pedant: There might be a hand full of very obscure glyphs in two ancient DEC fonts that cover the DEC technical set (possibly ment to be components for large summation signs), but hardly anyone understands what they really are and chances are good that they were never used by anyone. They are not in Unicode 3.2, because Frank da Cruz (Kermit author, who got the other missing VT100 graphical and technical symbols into Unicode 3.2) didn't understand what they might have been good for. There are also some 7-segment digits in the C0 area of some of the Schumacher clean fonts, but again I don't think anyone ever used these. There was some email exchange between myself, Frank da Cruz and Ken Whistler (Unicode Technical Committee) on the large summartion sign components and whether to add it to Unicode 3.2, but we stopped discussing it when we found that one of the old HP Laserjet sets also had such characters, but shaped in a way incompatible with the DEC technical set. It also became unclear, to which degree this could be unified with existing box drawing glyphs. Adding both would have generated an awful clutter of obscure and completely useless symbols in everyone's opionion, so we dropped it. There is of course the cursor font, which is not covered by Unicode, because it contains mouse cursor shapes, not anything related to text. I would say, this is clearly out of the scope of Xft. Even if there should be non-Unicode characters left, they are likely to be so obscure that nobody ever will want to really use them and in any case they could be mapped on Unicode private use positions easily. In other words, you won't loose anything if you restrict the API to Unicode. If you want to provide access to all *-dec-dectech glyphs, Frank or I will cook up a mapping table that will contain probabaly three private use characters for - \ , / - and \ / which you can than have officially santioned by whoever at your current employer still remembers the days when the shop was still called DEC and produced "thin clients" with awfully many glyph slots to fill. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
