octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI font and cursor location


From: Michael Goffioul
Subject: Re: GUI font and cursor location
Date: Sun, 29 Jul 2012 22:38:41 +0100

On Sun, Jul 29, 2012 at 5:46 PM, Mike Miller <address@hidden> wrote:
On Sun, Jul 29, 2012 at 9:36 AM, Michael Goffioul wrote:
> On Sun, Jul 29, 2012 at 2:27 PM, Mike Miller <address@hidden> wrote:
>>
>> I am willing to do some more testing to help reproduce this and narrow
>> it down also.
>>
>> Here's how I just reproduced it with qterminal alone. This is on Debian
>> wheezy.
>>     git clone https://code.google.com/p/qterminal/
>>     cd qterminal
>>     git checkout -b testing 186cf39
>>     qmake
>>     make
>>     ./qterminal/qterminal
>>
>> The problem is evident to me this way. I changed the font family to
>> test various monospace fonts, and the size to make it more obvious.
>>
>> Here's how I changed the font to test this:
>>
>> diff --git a/qterminal/main.cpp b/qterminal/main.cpp
>> index e45a623..bd16bb2 100644
>> --- a/qterminal/main.cpp
>> +++ b/qterminal/main.cpp
>> @@ -29,6 +29,7 @@ int main(int argc, char *argv[])
>>      QMainWindow *mainWindow = new QMainWindow();
>>
>>      QTerminal *terminal = new QTerminal();
>> +    terminal->setTerminalFont(QFont("Courier", 16));
>>
>>      mainWindow->setCentralWidget(terminal);
>>      mainWindow->resize(600, 400);
>>
>> I tested with the following monospace fonts I have available: Courier,
>> Droid Sans Mono, FreeMono, Inconsolata, Liberation Mono, and Ubuntu
>> Mono.
>
>
> Thanks. Do all these fonts show the problem?

Yes, same problem with all the above fonts.

Also worth pointing out that the further the cursor moves to the left,
the spacing follows the cursor but the offset gets smaller, like it's
padding more for however many characters have filled up the line.

Can you reproduce this on your end?

No. I have tried exactly the same as you, using your git commands to retrieve qterminal sources, compile and adapt main.cpp to change the font as you did. I installed the following fonts:
- liberation-mono-fonts-1.07.2 (for Liberation Mono)
- levien-inconsolata-fonts-1.01 (for Inconsolata)
- gnu-free-mono-fonts-20100919 (for FreeMono)
- google-droid-sans-mono-fonts-20100409 (for Droid Sans Mono)

All fonts were displayed correctly in qterminal, except FreeMono. The latter displays the problem as reported by Doug, but this one is a special case, because it does not display correctly in other programs, like gedit (using FreeMono 16 and typing a line of '1', then a line of 'm', characters were completely misaligned). I'm inclined to think the font is buggy, and not really monospace. Using a QFontMetrics object to compute the width of 'm' and '1', you get different values, but that should not happen for a monospace font (the other explanation is that both Qt font engine and Pango are buggy, but I tend to think this is quite unlikely).

Now, about the issue of the space appearing in a string when moving the cursor, this is due to incorrect font metrics and the way a line is rendered. When a line containing the cursor is rendered, it happens more or less like:
1. render characters until the cursor
2. render the cursor
3. render characters after the cursor
Steps 1 and 3 are typically achieved by calling a single text rendering function with all characters to be rendered, as a string. Because the terminal widget assumes a monospace font, at step 3 it starts rendering the string at an horizontal offset computed as N*_fontWidth, where N is the number of chars rendered at step 1. But if the font is not monospace, the width of the string rendered at step 1 won't be exactly N*_fontWidth, and you will see a gap (or an overlap). The higher N, the bigger the gap, that's why the gap decreases when you move the cursor close to the beginning of the line. But as long as the font is monospace, a string of N characters should be exactly N*_fontWidth wide.

What is weird is that you guys are observing the issue for any monospace font. Mike, could you add further debug lines in TerminalView.cpp to check what's the value of _fontWidth and fw, as well as 'fm.width("m")', when you use the Inconsolata font as shown in your screenshot.

I'm not against Doug's patch, actually it should be completely transparent when you use a monospace font (as _fontWidth will be an integer value anyway). But I'm naively thinking: Konsole's code is probably more than 10 years old (and I've been using it since KDE-1.X series), if there was such a gross error in font metrics computation (like using double instead of int), don't you think the KDE developers would have caught it a long time ago?

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]