Tue 01 Dec 2015 08:58:45 AM UTC, comment #9:
Ok, tested on a clean user account and underscores seem fine. I re-read the thread: it seems the slashes that make up unicode-art sqrts never worked.
So in summary, this bug is still valid, and to me seems unchanged since 3.8.1.
|
Fri 27 Nov 2015 10:09:14 PM UTC, comment #8:
Hmm, if anything its worse! On Octave 4.0.0, sqrt signs (the slashes) are completely missing. Come to notice it, so are plain ol' underscores (so some low ascii problems).
I've tested with a couple different fonts, but not yet tested on a clean user account.
I've upgraded my OS (Fedora 23 now) since I originally filed this.
|
Wed 25 Nov 2015 09:38:46 PM UTC, comment #7:
This bug is 1.5 years old and filed against the GUI in 3.8.1. So much has changed since then, is this report still relevant or can it be closed?
|
Fri 18 Apr 2014 12:56:43 PM UTC, comment #6:
Changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/5fb180e37d7c
fixes the issue for some fonts. For other fonts (like Inconsolata) the issue still shows up. However, the incorrect result for those fonts can also be seen in other applications when pasting the text there (e.g. geany or gedit).
The gui terminal does not show the beginning of the square root whereas the result in the gnome terminal is correct.
|
Fri 18 Apr 2014 06:12:21 AM UTC, comment #5:
Hmmm, at least my browser (Firefox 28) also has a small problem with the e of exp(x).
But OTOH, the sqrt looks much better here than in my terminals (or Octave GUI).
So perhaps we don't think we need perfection here, just to do better than in my original screenshots.
I read somewhere (can probably find a reference if needed) but I think perfect alignment is not really possible when using certain types of hinting. But at least with monospace fonts, I'd expect errors of no large than 1/3 pixel.
My guess is the exp(x) term is a font-substitution issue, given that I see it in Firefox, Emacs and Konsole. But the other alignment problems are not apparent in those software.
|
Fri 18 Apr 2014 06:03:47 AM UTC, comment #4:
Yes I tried different fonts, see gui_bad2.png in the original set.
I've attached the samples. all are utf-8 except unicode_align3.m which is the strings converted to double so is just ascii.
I'll try to paste into a verbatim block too:
(file #31199, file #31200, file #31201)
|
Thu 17 Apr 2014 10:03:11 PM UTC, comment #3:
That was my first thought too, if memory serves me right bug #37187 was related to fractional offsets from moving the cursor back over already entered text.
Colin, can you post one of your examples in text form or attach as an m-file in UTF-8 so someone can load it and reproduce in Octave on our end? That would help in determining if this bug is reproducible and whether it's related to this other font spacing bug.
Also have you tried different fonts? I know you say this font aligns perfectly in gnome-terminal and not in konsole, what about other fixed-width fonts?
|
Thu 17 Apr 2014 09:47:23 PM UTC, comment #2:
This issue seems related to bug #37187. I am going to add a patch for it within the next days.
|
Thu 17 Apr 2014 03:59:48 PM UTC, comment #1:
I installed Konsole, and it also looks a bit poor.
Perhaps its just QT in general? Looks a bit look not our fault, but still, I wonder if there is a workaround?
(I'd quite to enable this unicode output by default the octsympy symbolic package.)
(file #31198)
|
Thu 17 Apr 2014 03:54:16 PM UTC, original submission:
Drawing boxes with unicode that look fine when running in Gnome-Terminal, have minor (several pixel) alignment problems in the new GUI.
I'll attach some screenshots.
|