media-fonts/unifont-1.0-r4 and media-fonts/unifont-1.0-r3 seem to use outdated unifont hexfiles for font creation. Outdatedness of sources is visible in braille blocks. see also http://unifoundry.com/unifont.html for braille errors (additions 2008-07-06 entry) I tried installing a newer version of the font, whichs works but for xterm. Font seems to have to be split in single and double width chars. I wasn't able to figure out, how to do that, especially how much the r4 path would 'interfere'. Upstream also seems to have changed: see http://unifoundry.com/unifont.html http://czyborra.com/ is down Reproducible: Always Steps to Reproduce: 1.emerge unifont 2.get any utf8 file with braille i.e: http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt 3.uxterm (with default fixed font) 4.less UTF-8-demo.txt 5.uxterm -fn "-*-unifont-*-*-*-*-*-*-*-*-*-*-iso10646-1" 6.less UTF-8-demo.txt 7.compare glyphs in math and braille sections of file 8.get http://unifoundry.com/unifont-5.1.20080820.ttf.gz (uptodate unifont) 9.view the file with new unifont version 10.compare glyphs in math and braille sections of file or compare with any other braille capable font Actual Results: glyphs shown differ Expected Results: should be the same
(In reply to comment #0) I just happened to see this bug report doing a Google search for another distribution. > Upstream also seems to have changed: see http://unifoundry.com/unifont.html > http://czyborra.com/ is down I run the unifoundry.com website, and yes, I am maintaining the font. If czyborra.com comes back up then that could become the central repository again, but for now unifoundry.com is. > media-fonts/unifont-1.0-r4 and media-fonts/unifont-1.0-r3 seem to use outdated > unifont hexfiles for font creation. > > Outdatedness of sources is visible in braille blocks. > see also http://unifoundry.com/unifont.html for braille errors (additions > 2008-07-06 entry) > > I tried installing a newer version of the font, whichs works but for xterm. > Font seems to have to be split in single and double width chars. I wasn't able > to figure out, how to do that, especially how much the r4 path would > 'interfere'. > You can split the BDF font into a half-width font and a full-width font with the "hex2bdf-split" script in the source package. There's also a man page for it in the source package. Gentoo's current source probably does much the same thing with the "hex2bdf" script. It is a Perl script; see if it accepts a "y" or "n" parameter (to split out half- or full-width glyphs). If it does, you can use it to split the font. I don't have a Gentoo distribution, so I can't check this myself right now. However, I considered splitting the BDF font to be deprecated for reasons mentioned below. The international editor Yudit needs an unsplit font file (and works just fine with it). For xterm use, I've been using the TrueType version with GNOME on GNU/Linux and non-GNU/Linux Unices. I didn't go into testing the BDF split versus non-split issue because I made my first package for Debian GNU/Linux, which now requires all BDF fonts to be converted to PCF with bdftopcf before installation. I have just added a link to the PCF version of the font on the webpage that you cite, http://unifoundry.com/unifont.html. Please try that instead of the BDF version and let me know if it works. The direct link to the PCF version is: http://unifoundry.com/unifont-5.1.20080820.pcf.gz The TrueType version is preferred over the PCF version. In addition to being scalable, the TrueType version handles all combining characters properly as zero-width glyphs. The PCF version doesn't do that, at least not now. If there are situations where the PCF font must be used instead of TrueType, I'll put effort into encoding zero-width combining characters in the PCF font as well. The BDF version never had that capability. > Reproducible: Always > > Steps to Reproduce: > 1.emerge unifont > 2.get any utf8 file with braille i.e: > http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt This is a cool test file! The large sigma in the mathematical summation has double-width upper and lower halves. It looks like UTF-8-demo.txt was written assuming that glyph would be half-width. That combination of half-width and full-width glyphs is an example of something that won't look right if you split the font into two halves depending upon width. That is why I consider that to be deprecated. The Block Elements (U+2580..U+259F) were half-width (8 pixels wide by 16 pixels tall) in the original unifont.hex. I changed them so they are all now double-width (16 pixels wide by 16 pixels tall). Since they are "block" elements and not "rectangle" elements, that seemed to be the intent of the Unicode Standard. The UTF-8-demo.txt file might have assumed that those glyphs were single-width, as with the summation sigma. If there is any indication that the Unicode Standard considers any of those glyphs to be half-width, let me know and I'll change them in the next release of the font. Another example where combining half-width and full-width glyphs is a necessity is the Halfwidth and Fullwidth Forms in Unicode (U+FF00..U+FFEF), designed for use with the Unified CJK ideographs. As their name indicates, they contain both half-width and full-width forms. The main CJK ideographs are all double-width. Thus font technology needs to handle both widths in the same font. > 3.uxterm (with default fixed font) > 4.less UTF-8-demo.txt > 5.uxterm -fn "-*-unifont-*-*-*-*-*-*-*-*-*-*-iso10646-1" > 6.less UTF-8-demo.txt > 7.compare glyphs in math and braille sections of file > 8.get http://unifoundry.com/unifont-5.1.20080820.ttf.gz (uptodate unifont) Yes, please use the 5.1.20080820 version, as you cite above. It contains numerous improvements as well as some corrections (such as the Braille Block that you mention, U+2800..U+28FF). > 9.view the file with new unifont version > 10.compare glyphs in math and braille sections of file > > or compare with any other braille capable font > Actual Results: > glyphs shown differ > > Expected Results: > should be the same Thank you for your interest in this font, and for an excellent and accurate bug description. I'd be happy to help sort out any problems with this font on Gentoo. I don't have a Gentoo system, but am willing to set one up if necessary. Paul Hardy unifoundry at no spam unifoundry.com
I should add one clarification about the TrueType font. It treats all combining marks as zero-width, meaning it superimposes the mark on the following glyph. To be brought in line with the Unicode Standard, it should be superimposed on the preceding glyph. It is my next step. I have to try to do it in a way that old and new versions of FontForge can handle, which will require some testing. I also didn't have time to do anything for combining marks in the BDF version (which is converted to the PCF version with bdftopcf) except to remove the dashed circles from the original unifont.bdf file. I might or might not add combining mark handling to the BDF version in the future, depending on the need. The big change in the latest version is that it contains a glyph for every visible code point in the Unicode 5.1 Basic Multilingual Plane. That was my first goal, before improving individual glyph handling (this is a work in progress). It was a huge effort. Now that first goal is accomplished, and I can work on things like fine-tuning combining mark positioning and then going beyond the Basic Multilingual Plane. Paul Hardy
I've uploaded a version of the TrueType version of this font that should handle Unicode combining marks properly. It can be downloaded at http://unifoundry.com/unifont-5.1.20080907.ttf.gz The Linux system I'm using is currently adding whitespace after a combining mark, but I am fairly certain that is a problem with the TrueType rendering engine under that X11 setup. The font doesn't render that way on XP, and I am certain that I have the advance width for combining marks set to zero in the TrueType font. Please use the 5.1.20080907 version and let me know if you have any problems with it. If you'd like, I can add a gentoo/ directory under pub/ on my website. Thanks again for your interest in this font! Paul Hardy
A HAPPY NEW YEAR in JST(+0900)!!! 5.1.20080914 in cvs now.
