Glyphs of Fonts for Special Characters in Octave Fail

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Glyphs of Fonts for Special Characters in Octave Fail

stimits
Hi,
 
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 content...it'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
1/sqrt(x)
sqrt(1/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.
 
Thanks!

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Glyphs of Fonts for Special Characters in Octave Fail

stimits
An alternate question...can anyone using the symbolic package correctly see then entire sqrt (radical) symbol from:
symx x
sqrt(x)
sqrt(1/x)
1/sqrt(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: [hidden email]
To: [hidden email]
Sent: Tue, 26 Dec 2017 20:48:52 -0000 (UTC)
Subject: Glyphs of Fonts for Special Characters in Octave Fail
Hi,
 
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 content...it'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
1/sqrt(x)
sqrt(1/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.
 
Thanks!

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Glyphs of Fonts for Special Characters in Octave Fail

Eric-262
In reply to this post by stimits
On 12/31/2017 03:29 PM, [hidden email] wrote:

> An alternate question...can anyone using the symbolic package correctly
> see then entire sqrt (radical) symbol from:
> symx x
> sqrt(x)
> sqrt(1/x)
> 1/sqrt(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.

I am running GNU Octave, version 4.0.0 on Ubuntu 16.04.

Here is what my command window looks like if I follow from above
(substituting symx to syms :-) ) and copying and pasting into the email
body.

 >> pkg load symbolic
 >> symx x
error: 'symx' undefined near line 1 column 1
 >> syms x
OctSymPy v2.2.4: this is free software without warranty, see source.
Initializing communication with SymPy using a popen2() pipe.
Some output from the Python subprocess (pid 3694) might appear next.
Python 2.7.12 (default, Nov 20 2017, 18:23:56)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> >>>
OctSymPy: Communication established.  SymPy v0.7.6.1.
 >> sqrt(x)
ans = (sym)

     ___
   ╲╱ x

 >> sqrt(1/x)
ans = (sym)

       ___
      ╱ 1
     ╱  ─
   ╲╱   x

 >> 1/sqrt(x)
ans = (sym)

     1
   ─────
     ___
   ╲╱ x

 >>

This is different that what my command window actually looks like.  I
attached a screen shot of what that looks like and you can see that the
radical symbol only shows the horizontal portion and not the complete
symbol.  I am not sure why it shows up differently from a copy and paste.


Regards,

Eric

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave

Screenshot from 2017-12-31 15-40-22.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Glyphs of Fonts for Special Characters in Octave Fail

stimits
Btw, sorry about my top-posting, it's what my web mail does...otherwise quotes get mixed up....also my typo of "symx x" which should be "syms x":
syms x
sqrt(x)
sqrt(1/x)
1/sqrt(x)
 
Yes, this is what I am talking about...copy and paste shows the character is there (the numeric value), but the display is incorrect in octave (the parts which are extended character set glyphs). It isn't an issue with the operating system per se since pasting into a new window of another application set to the same (or even different) font works.
 
I am using Fedora, this extends then to Ubuntu. Anyone else able to reproduce this on any different system, e.g., a Windows user? Or other Linux distributions? Does anyone see the command window display correctly for the radical?
 
Note: Octave is using the correct character, whoever developed the character rendering code may be different from development of the symbolic package since many numeric calculations do not require rendering an extended character...I guess what I am wondering is if this displayed correctly for whoever built the symbolic package...if so, then I am wondering if developers saw this work correctly by virtue of running on Windows?
 
Can anyone with Windows octave/symbolic who can verify? Does symbolic display correctly for anyone on any o/s?
 
----- Original Message -----
From: eric <[hidden email]>
To: [hidden email]
Sent: Sun, 31 Dec 2017 22:45:06 -0000 (UTC)
Subject: Re: Glyphs of Fonts for Special Characters in Octave Fail
On 12/31/2017 03:29 PM, [hidden email] wrote:

> An alternate question...can anyone using the symbolic package correctly
> see then entire sqrt (radical) symbol from:
> symx x
> sqrt(x)
> sqrt(1/x)
> 1/sqrt(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.
I am running GNU Octave, version 4.0.0 on Ubuntu 16.04.
Here is what my command window looks like if I follow from above
(substituting symx to syms :-) ) and copying and pasting into the email
body.
>> pkg load symbolic
>> symx x
error: 'symx' undefined near line 1 column 1
>> syms x
OctSymPy v2.2.4: this is free software without warranty, see source.
Initializing communication with SymPy using a popen2() pipe.
Some output from the Python subprocess (pid 3694) might appear next.
Python 2.7.12 (default, Nov 20 2017, 18:23:56)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> >>>
OctSymPy: Communication established. SymPy v0.7.6.1.
>> sqrt(x)
ans = (sym)
___
╲╱ x
>> sqrt(1/x)
ans = (sym)
___
╱ 1
╱ ─
╲╱ x
>> 1/sqrt(x)
ans = (sym)
1
─────
___
╲╱ x
>>
This is different that what my command window actually looks like. I
attached a screen shot of what that looks like and you can see that the
radical symbol only shows the horizontal portion and not the complete
symbol. I am not sure why it shows up differently from a copy and paste.

Regards,
Eric

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave