[Top][All Lists]

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

Re: Glyphs of Fonts for Special Characters in Octave Fail

From: stimits
Subject: Re: Glyphs of Fonts for Special Characters in Octave Fail
Date: Sun, 31 Dec 2017 22:29:49 +0000 (UTC)

An alternate question...can anyone using the symbolic package correctly see then entire sqrt (radical) symbol from:
symx x
If "yes", which version of octave (and what operating system or distribution are  you using) and which font is used in your terminal window was used?
I suppose a "no" answer with that same information would be useful. I'm wondering if there might be someone this works for, and if it does, what might be in common or different than my version.
----- Original Message -----
From: address@hidden
To: address@hidden
Sent: Tue, 26 Dec 2017 20:48:52 -0000 (UTC)
Subject: Glyphs of Fonts for Special Characters in Octave Fail
In the following I'm using both Octave 4.0.3 (Fedora Linux pre-packaged) and 4.3.0 (which I compiled, also on Fedora) with the same results. I also have added the symbolic package so I can see something like sqrt(x) instead of a decimal number. I'm going to describe a few things about fonts, and then ask if anyone knows of a reason why fonts don't work correctly for me, e.g., if maybe there is some setting I can tweak to get it working right. I don't see any bugs listed which exactly match this.
Background Comment: Every character set has a table of indices where characters are defined, and each character has a graphic image defined as well (the glyph). A character at a given index should have the same meaning regardless of font, but graphical image and typesetting will change (the glyph is why they look different). Older character sets only used the first seven bits, and originally characters after index 127 (decimal) had no representation (at least nothing "standard"). Along came the "curses" console mode pseudo graphical drawing library and character sets started showing up where the 8th bit began to have standardized glyphs for things like drawing boxes or line art on terminals without true graphics capability...good old ASCII art got some new tricks. Another example is the "tree" command on Linux to draw a tree of file and subdirectory's a very nice "tree-like" display of directory and subdirectory content using only a text-mode display and that 8th bit of the character set with standardized glyphs for line art. Octave benefits from those same glyph extensions.
My character set is UTF-8, with locale en_US. Not all fonts have the various extended glyphs, especially older fonts. My Linux console has several fonts able to use these drawing glyphs, e.g., what octave labels "monospace", as well as "liberation mono", and a host of others. Octave seems to be aware of system fonts and shows the same fonts as what I can select from various Linux terminals in the X11 GUI environment. Some people use a locale other than en_US, or perhaps even a different UTF-16 character set, but the method of dealing with mapping a glyph to a an index into a character set should be the same.
The octave command window is really a text console, but it does some nice things by using some of these drawing characters from the 8th bit, e.g., square roots (these symbols are characters you can copy and paste, not graphical images such as a .gif/.png.jpg/.svg image would be). If you have the symbolic package, then you'll see octave attempting to draw a square root symbol for something like this by utilizing those glyphs from 8-bit character sets:
syms x
Do these symbolic package prints look correct to anyone else here under Linux? For me I am missing parts of the square root symbol (and the part missing is inconsistent), but if I copy and paste these and echo them on a terminal or in an editor, they look correct. The index into the character set does the correct thing for drawing the square root symbol, but the glyphs are partly missing. It is as if sometimes the 8th bit is filtered out when rendering the glyph...but not always.
Changing fonts does not help, and I can verify many fonts which should match what my command line console shows are not showing glyphs from the 8th bit under octave even though the font has that glyph. Copy and paste verifies that other applications set to the font which is set in octave only displays incorrectly in octave, e.g., I can always copy from octave and paste it elsewhere and the square root/radical symbol shows up correctly outside of octave.
So I am interested in knowing if this is a known issue, or if for some weird reason this only happens to me (I'm new to using octave). I had this issue in the past when writing some docbook documents, but this was because I needed a font with the extended glyphs. Simply using the correct font fixed this issue. In the case of octave known correct glyphs are only partially working.

reply via email to

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