Version: (using KDE KDE 3.1.2) Installed from: RedHat RPMs Compiler: gcc 3.1.2 OS: Linux Line drawing characters can be output to the console via VT100 escape sequences or by using Unicode characters. There is often some variation in how well these characters line up with one another depending on which font you are using, so this may not be easy to test. There appears to be too much spacing between lines of text in Konsole, causing vertical lines drawn with these characters to be broken. These same lines are unbroken in KWrite or KWord, even using the same font. Even though there is variation from font to font, this gap is constant. I will attach a UTF-8 encoded text file which you can view in Konsole and KWrite to compare. Let me know if you would prefer to have one with VT escape sequences. Also: I understand there has been some work done in Konsole font display after KDE 3.1.2. If this appears fixed in CVS or 3.1.3, please mark this as resolved.
Created attachment 2057 [details] Test linedrawing file (UTF-8 encoding)
The file you uploaded joins fine in Konqueror for me. However, it does not in KWrite. That is, it's the complete opposite of your situation.
What version of KDE are you running? Also: Do you mean Konsole instead of Konqueror? This was filed as a Konsole bug--I have not done any testing in Konqueror at all.
Still happening with KDE 3.1.3, same symptoms.
Sorry, saying Konqueror was some non-sense of my part. I meant Konsole. Anyways, I've managed to reproduce your bug, but only if I'm using a TrueType font. When using a standard Type1 font, the line-drawing characters join perfectly, both in KWrite and Konsole. I'm guessing this has more to do with font metrics than with Konsole.
Interesting. I know there were recently some TrueType Konsole bugs (all fixed in 3.1.3 AFAIK). I'm not sure whether this bug is in the font or in Konsole, but Konsole does display characters differently than KWrite, using the same font. Since they are both creating fixed-width fonts from TrueTypes and coming up with different-looking results, I'd at least consider it an inconsistency. And I find KWrite's results more pleasing to look at, FWIW. I realize this is aesthetic more than anything. I'm just working down my list of items to make Konsole perfect. The fact I've gotten down to something so arcane says that it's pretty close.
A bug is always a bug. And even if this is just a minor issue, it might reveal something larger with font metrics. There are other bug reports relating to full- and half-width characters... Anyways, I'm using KDE from CVS as well as Qt 3.2. It's important to note that Qt 3.2 has had a big rework in the font handling classes, so the fix might be in there. I should also point out that Konsole and KWrite look the same for me when they are set for the same font. I can't be exactly sure if the problem is the font type (True Type, Type 1) or the font itself. I have, however, tested with the following fonts: - Fixed (Type 1): shows fine in both programs - Courier (Type 1 I think): shows fine in both programs - Luxi Mono, FreeMono (TrueType): shows broken in both programs I don't have any other monospaced TrueType fonts to test with.
*** Bug 63061 has been marked as a duplicate of this bug. ***
Okay, tested the attachment from comment#1 again in KDE 3.2, and got different results from 3.1.x. Now, in both KWrite and Konsole, linedrawing characters join horizontally, but not vertically. So at least the behavior is now consistent for me. However, I'd prefer linedrawing characters that join together (assuming the font isn't to blame). Here are some tests with various TrueType fonts: (free) Bitstream Vera Sans Mono - characters join horizontally, but do not quite join vertically (there's also a left/right positioning problem on verticals) (free) Luxi Mono - same as Bitstream Vera Sans Mono (nonfree) Lucida Console - characters join horizontally, there appears to be a larger vertical gap, and there also seems to be a positioning problem at the corners. Hope this helps.
*** Bug 77644 has been marked as a duplicate of this bug. ***
*** Bug 90117 has been marked as a duplicate of this bug. ***
*** Bug 50173 has been marked as a duplicate of this bug. ***
BR50173 suggests: Many terminal emulators, even plain old xterm, simulate line-drawing characters if not present in the used font. It would be more than nice if such a functionality would exist in konsole.
Rough patch at http://www.cs.cornell.edu/~maksim/patches/konsole-linechars.diff But I still need to re-check the table, fix some silliness in the comments, and have it reviewed by Zogje; but testing is appreciated from those who are building from sources
Would like to have the double-line versions as well and I would use the line-draw code unconditionally.
*** Bug 89459 has been marked as a duplicate of this bug. ***
Created attachment 9277 [details] Font source files
Created attachment 9278 [details] embedder
Created attachment 9279 [details] drawing code/konsole patch. OK, here is an implementation - it even tries to draw the heavy lines. The embedder run on the font source produces a header with a table encoding this stuff. The drawing stuff kind of sucks in a way, though, in that it doesn't attempt to scale at all. Though I think it does a passable job most of the time. I didn't do anything new konsole-integration-wise -- I would need help w/that. In particular, the issue of RTL and the drawTextFixed path is quite a bit scary.
CVS commit by waba: Don't rely on font for line-drawing. Patch by Maksim Orlovich BUG: 61637 A fontembedder.cpp 1.1 [no copyright] A linefont.h 1.1 [no copyright GENERATED FILE] A linefont.src 1.1 M +9 -1 Makefile.am 1.64 M +147 -6 TEWidget.cpp 1.220
*** Bug 57351 has been marked as a duplicate of this bug. ***