"Steve White" <[EMAIL PROTECTED]> writes: > Hi, Joe! > > Thanks for the comments, and thanks A LOT for the test case (can I > put it on the web page?)
Please feel free to do so. For information: it is derived from Markus Kuhn's UTF-8-demo.txt, plus some stuff of my own. Basically, I packed the most interesting portions of UTF-8-demo.txt into 30 lines and 130 columns so that I could compare terminal fonts side by side. I also added a bunch of characters I personally like to use. I suppose I have some copyright interest in it (although so does Marcus Kuhn), so I hereby license everyone in the world to use it as they see fit. > It seems to me that you have three main complaints: > > 1) You disapprove of the increased line spacing (explained in the release > notes) > You have two applications of a certain spacing that don't work > with the increased spacing The word “disapprove” misses the point. Taking 2 extra pixels vertically per line is a complete show-stopper for me. If the font wastes space like that, it does not matter how nice the font is otherwise. An important point: It is not completely clear how applications are supposed to decide how much vertical space to allocate per line when using a font. Part of the blame here may be with xterm. I've previously (I think about 2 years ago) communicated with the xterm maintainer and also the DejaVu team about this, and they seemed to think it was unclear how things are supposed to work regarding vertical spacing. However, other fonts work much more nicely with xterm, so it is clearly possible to get the nice behavior. > 2) Combining accents don't work as you expect Not only do combining accents not work as I expect, they are currently completely broken and do not work as anyone should expect. Or at least they are completely broken in xterm. Since all other fonts that support combining accents that I can test right now work with xterm (e.g., DejaVu Sans Mono, Lucida Sans Typewriter, CMU Typewriter Text), I think it is safe to conclude that something is quite wrong inside FreeMono.ttf. > 3) You don't like the new glyphs for the curly quotes It is not that I dislike the new glyphs, but rather that I *really* *like* the old glyphs. The old glyphs are *extremely* *clear* and unambiguous, especially at small font sizes. I also think the old glyphs are good looking, but my main concern was readability. > I would encourage you to submit individual bug reports on these. That > way, you can track the progress of changes, and interact with the > developers (me, at this time). Sadly, my time is vastly overcommitted, so this message is likely the last you will hear from me. > (Try to be as descriptive, and avoid emotional remarks such as > "screwed up". It will get things done faster.) Taking 16.5% more space vertically and also breaking line drawings is awful. The phrase “screwed up” is a greatly toned down version of my true thoughts. I'm sorry if it makes you less than happy. I have no intention to offend. Maintaining freefont is a big job and I am delighted to see what you have accomplished in your brief time doing it. > I don't have complete answers to all your complaints, but I have > looked at your test case. > > Concerning (1): Line spacing is a big problem in this family, due to > character ranges whose glyphs are very high and low. Furthermore, the > standards (to the best of my understanding), are rather weak on the > point of line spacing (as opposed to font height, etc.) What I have > done represents a compromise, that vastly improves the behaviour of > the fonts for most purposes, but screws up certain applications. > > On the other hand, I see your problem, and intend to do something about it. I'm delighted to hear this. Here are some ideas: • Document a way (if there is one) that users can tell applications to use this font with a smaller vertical line spacing. • Provide a way to get a version of the font which lies about its vertical space or which omits the very tall glyphs, so that lines will take less vertical space. > Frankly, I wasn't aiming for xterm use. I was primarly looking at > text editors, web browsers, and word processors. I did test it in > xterm, but never even thought about line- and shape-drawing > applications. I have the same issue in text editors: the number of lines that can be displayed is crucial. > Complaint (2) may be a case of me completely failing to understand how > combining characters are supposed to work in a monospace font. I was > hoping to achieve glyphs that appeared over the preceding one, and > took up no space themselves. But I never got it to work (and I > thought the old version wasn't working either). I'm not sure in precisely which version of FreeMono.ttf combining accents stopped working. > I'll have another look at this, with your examples. > > With regard to (3), the old glyphs were incorrect, and made the font > useless for many of its stated purposes. > See bug#18300, https://savannah.gnu.org/bugs/index.php?18300 Arrgh, that bug report contains bad news for me. So the left double quote mark is _required_ to have this shape?!?! That sucks. They should have made a separate Unicode character for the German right double quote mark. I suppose the only way I will be able to get decent behavior will be to switch exclusively to using DOUBLE HIGH-REVERSED-9 QUOTATION MARK for English and abandon LEFT DOUBLE QUOTATION MARK forever. But that will only work for text I write myself; the text I get from others will have the poor display. This sucks. Arrgh. (Not your fault! My complaint is with Unicode.) > I based my glyphs on the comma, which is consistent with Uncode. Is > the comma also ugly? In fact, it seems that alternate names for the characters in the standard are DOUBLE TURNED COMMA QUOTATION MARK and DOUBLE COMMA QUOTATION MARK, so you are (unfortunately in my opinion!) correct. ☹ :-( > If you can make suggestions for better glyphs, I would be glad to > entertain them. No, it seems the problem is with the standard. It would be nice if there was some way that people like me could select the nice glyphs and not get the standard glyphs. > You went on to talk about hinting and anti-aliasing. This is not so > much a font issue. The font can turn these processes off > (accidentally), but there is little a font developer can do about it. Actually, the solution is probably to do the hinting by hand. The problem is that this is very labor intensive and requires extremely specialized expertise from the person doing the hinting. The reason why proprietary commercial fonts have nice hinting for all their characters is that they pay people to do this kind of drudge work. > They depend very heavily on the algorithms used by the various > releases of the various graphics packages of the various operating > systems. The newer FontForge does a better job of auto-hinting than > previous versions; this may be part of the change you see. I can only hope that autohinting will get better. However, I suspect that some characters will always need to be hinted by hand. -- With my best regards, Joe > Cheers! > > > > On Wed, Apr 2, 2008 at 6:40 PM, Joe Wells <[EMAIL PROTECTED]> wrote: >> To compare the latest FreeMono.ttf with earlier versions, I have run >> the command >> >> xterm -title FreeMono-8 -geometry 130x32+0+0 -fa FreeMono-8 +fbx -e sh -c >> "echo ${ESC}%GFreeMono-8; head -n 30 UTF-8-font-test-sample.txt; sleep 99999" >> >> with the versions of FreeMono.ttf of 2008-03-24 (latest release) and >> 2003-06-24 (five years ago). (The variable ESC holds a string of >> length 1 whose sole character is the escape character.) >> >> I was running on a LCD with (I believe) rgb subpixel order with >> subpixel aliasing turned on. >> >> Screenshots are attached below, as is the sample text file I used. >> >> Here are some quick observations: >> >> • More characters are included. Hurray! >> >> • Hinting is a bit nicer in the latest fonts. I can see many >> individual characters (like I, N, 1, 4, etc.) that have better >> subpixel aliasing and come out looking black instead of colored. >> >> I'm pleased to see this progress and I think the maintainers deserve >> congratulations. >> >> • There are still plenty of characters that get bad subpixel aliasing >> and therefore show up with colored fringes. Examples include ℝ, ░, >> ⊪, etc. I guess there is lots of work to do here with hinting. >> (Can the autohinter handle these decently?) >> >> • The vertical spacing is screwed up (at least in xterm). This causes >> two problems: >> >> ‣ Each line takes up too much vertical space, so fewer lines can be >> displayed, which is a big problem on short screens. >> >> ‣ Characters that are supposed to combine vertically like "⎪" >> (U+23AA, CURLY BRACKET EXTENSION) have gaps between them. >> >> This problem does not occur in the font as of 5 years ago, as you >> can see for yourself in the screenshot. (I think the problems in >> the older screenshot are caused by xterm drawing the line-drawing >> characters instead of using what is in the font.) >> >> By itself, this is a big enough reason to keep using the old font. >> The number of lines that will fit on a screen is a primary criteria >> used when selecting a font for terminal windows, and the ability to >> display line drawings correctly is also very significant. For the >> same reason, I have previously refused to upgrade to FreeFont.ttf >> versions of 2003-10-08 and 2006-01-26. Due to this problem, right >> now upgrading would actually be a downgrade. >> >> • The older glyphs for the quote characters (i.e., ', ", ", ') are >> much nicer for a screen font. It would be nice to be able to get >> the old glyphs somehow. >> >> • Something awful is happening with combining accents. You can see in >> the screenshot in the test line "STARGΛ̊TE SG-1, a = v̇ = r̈, a⃑ ⊥ b⃑" >> that the combining accents (when they are drawn at all) are all >> positioned one character cell to the left of where they should be. >> This was working in the font as of 5 years ago, so presumably this >> is a bug introduced since then. >> >> For what it is worth, I am running Ubuntu 6.06 LTS ("Dapper Drake") >> and I think all packages involved in this test are the latest >> available for Ubuntu 6.06. >> >> I hope this report is helpful. >> >> Joe Wells >> -- Heriot-Watt University is a Scottish charity registered under charity number SC000278
