Bug 61637 - Line drawing characters do not join vertically
Summary: Line drawing characters do not join vertically
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Maksim Orlovich
: 50173 57351 63061 77644 89459 90117 (view as bug list)
Depends on:
Reported: 2003-07-24 21:52 UTC by Chelsea Buchanan & Keith Briscoe
Modified: 2013-05-14 11:56 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:

Test linedrawing file (UTF-8 encoding) (63 bytes, text/plain)
2003-07-24 21:52 UTC, Chelsea Buchanan & Keith Briscoe
Font source files (4.39 KB, text/plain)
2005-01-25 02:42 UTC, Maksim Orlovich
embedder (2.11 KB, text/x-c++src)
2005-01-25 02:43 UTC, Maksim Orlovich
drawing code/konsole patch. (5.21 KB, patch)
2005-01-25 02:50 UTC, Maksim Orlovich

Note You need to log in before you can comment on or make changes to this bug.
Description Chelsea Buchanan & Keith Briscoe 2003-07-24 21:52:01 UTC
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.
Comment 1 Chelsea Buchanan & Keith Briscoe 2003-07-24 21:52:56 UTC
Created attachment 2057 [details]
Test linedrawing file (UTF-8 encoding)
Comment 2 Thiago Macieira 2003-07-24 22:22:40 UTC
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. 
Comment 3 Chelsea Buchanan & Keith Briscoe 2003-07-26 20:20:39 UTC
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.
Comment 4 Chelsea Buchanan & Keith Briscoe 2003-08-08 06:43:31 UTC
Still happening with KDE 3.1.3, same symptoms.
Comment 5 Thiago Macieira 2003-08-08 11:25:12 UTC
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. 
Comment 6 Chelsea Buchanan & Keith Briscoe 2003-08-08 16:25:42 UTC
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.
Comment 7 Thiago Macieira 2003-08-08 16:47:20 UTC
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. 
Comment 8 Stephan Binner 2003-12-18 23:28:28 UTC
*** Bug 63061 has been marked as a duplicate of this bug. ***
Comment 9 Chelsea Buchanan & Keith Briscoe 2004-02-05 03:12:06 UTC
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.
Comment 10 Waldo Bastian 2005-01-24 19:14:04 UTC
*** Bug 77644 has been marked as a duplicate of this bug. ***
Comment 11 Waldo Bastian 2005-01-24 19:14:34 UTC
*** Bug 90117 has been marked as a duplicate of this bug. ***
Comment 12 Waldo Bastian 2005-01-24 19:16:04 UTC
*** Bug 50173 has been marked as a duplicate of this bug. ***
Comment 13 Waldo Bastian 2005-01-24 19:16:55 UTC
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.
Comment 14 Maksim Orlovich 2005-01-24 20:07:17 UTC
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
Comment 15 Waldo Bastian 2005-01-24 22:02:00 UTC
Would like to have the double-line versions as well and I would use the line-draw code unconditionally.
Comment 16 Maksim Orlovich 2005-01-24 23:51:19 UTC
*** Bug 89459 has been marked as a duplicate of this bug. ***
Comment 17 Maksim Orlovich 2005-01-25 02:42:52 UTC
Created attachment 9277 [details]
Font source files
Comment 18 Maksim Orlovich 2005-01-25 02:43:48 UTC
Created attachment 9278 [details]
Comment 19 Maksim Orlovich 2005-01-25 02:50:41 UTC
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

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
Comment 20 Waldo Bastian 2005-01-25 12:33:02 UTC
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

Comment 21 Maksim Orlovich 2005-01-25 18:53:18 UTC
*** Bug 57351 has been marked as a duplicate of this bug. ***
Comment 22 Christoph Feck 2013-05-14 11:56:49 UTC
*** Bug 90117 has been marked as a duplicate of this bug. ***