bugGNU Octave - Bugs: bug #43651, special character (diameter sign)...

 
 

bug #43651: special character (diameter sign) in plot produces warning or doesn't show up

Submitted by:  Hartmut <hardy>
Submitted on:  Thu 20 Nov 2014 10:00:23 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: 3.8.2Operating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 17 Oct 2017 02:37:14 PM UTC, comment #18:

I am actually advocating to avoid use of ghostscript.
Anyway on my system Symbol is google-croscore "SymbolNeu.ttf".

Inkscape uses cairo library for svg to pdf conversion, so converting symb.svg to pdf preserves the specified font (Symbola):

The file is attached.

Dmitri.

(file #42181)

Dmitri A. Sergatskov <dasergatskov>
Tue 17 Oct 2017 11:09:34 AM UTC, comment #17:

Ideally we should use the Symbol font so that printout and onscreen glyphs match. On my system, "fc-match -v Symbol" tels me the font files is a sym link to "/usr/share/fonts/type1/mathml/Symbol.pfb".

I used fontforge to inspect this file and I was not surprised to see that the glyphs we think are missing are actually present: that is why ghostscript is able to find them and put them in a png.

The problem is the mapping from a character to a glyph, and that is where I get lost. Let me take an example: "\alpha" is glyph #97 ("a") in a 1 byte Symbol character set (like the one used in postscript) and #945 in unicode.

There are additional information in font files to indicate which gliph correspond to what unicode or 1 byte character, but I still have to play with fontforge to understand this. At least what I already can say is that the unicode code for "Copyright" is not filled (it is -1 ataully) in my Symbol.pfb.

[1] http://www.alanwood.net/demos/symbol.html

Pantxo Diribarne <pantxo>
Project Member
Tue 17 Oct 2017 12:42:48 AM UTC, comment #16:

Attached are the svg output as well as its conversion to png
(inkscape symb.svg --export-png symb.png)

Dmitri.

(file #42177, file #42178)

Dmitri A. Sergatskov <dasergatskov>
Tue 17 Oct 2017 12:35:18 AM UTC, comment #15:

I do not have any problem with svg (which uses Symbola)
but printing to eps ignore font settings and uses "Helvetica"
(or whatever it resolved to on the machine).

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 17 Oct 2017 12:32:13 AM UTC, comment #14:

On my machine, FreeSerif complains about 4 symbols during printing so it too does not appear to be fully complete.

Symbola performs equally well as FreeSerif, that is, there are no complaints for onscreen rendering but 4 symbols have problems during printing.

On the other hand, Symbol is by far the worst as it complains about 11 glyphs when rendering onscreen.

If I use OpenSymbol I only get one glyph that is unhandled for both onscreen rendering and for printing.

Out of all that, its pretty hard to decide which is best. I don't mind switching to an alternative for Symbol, but which should it be?

Rik <rik5>
Project Administrator
Mon 16 Oct 2017 05:31:39 PM UTC, comment #13:

@Rik: indeed the script I attached was wrong and should have been like in omment #11. The reason I wanted to use FreeSerif instead of Symbol font is that on my system the Symbol font lacks some glyphs, at least the version fontonfig finds ("/usr/share/fonts/X11/Type1/Symbol.pfb"). The attached modified script plots all the TeX symbols in an svg file: 11 glyphs are missing in the symbol font in Octave and in Inkscape.

On the other hand ghostscript does have access to a full featured Symbol font so in theory it should be somewhere to be found.

(file #42165)

Pantxo Diribarne <pantxo>
Project Member
Sun 15 Oct 2017 11:30:57 PM UTC, comment #12:

There are Symbola fonts:

http://users.teilar.gr/~g1951d/

On Fedora they are in gdourious-symbola-fonts:

https://fedoraproject.org/wiki/Gdouros_Symbola

In case it matters -- the original Symbol fonts
are Serif fonts.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sun 15 Oct 2017 11:09:16 PM UTC, comment #11:

I changed the last bit of the script to

Since Matlab and gnuplot both switch to the Symbol font when rendering TeX, what is the advantage of switching to FreeSerif? Why shouldn't Octave just switch to Symbol font as well? Is there an OpenSymbol font that we could ship?

Rik <rik5>
Project Administrator
Sun 15 Oct 2017 10:53:46 PM UTC, comment #10:

Any reason why the bottom of the script prints the output twice?

Rik <rik5>
Project Administrator
Sun 15 Oct 2017 10:02:59 PM UTC, comment #9:

We now have the default ("*") sans serif font shipped with Octave. The chosen font is "FreeSans" which happens to contain the same characters as Ghostscript's replacement for Helvetica (urw base fonts) so that printout now look approximately like on-screen.

I would now advocate for using "FreeSerif" for TeX symbols:

  • All TeX symbols are defined
  • The symbols in this font (see svg output) look much like the Symbol font we have to use for eps output.
  • Again, mapping math characters to a single font is a common practice (libreoffice, matlab, latex, ...) and, this is a personal opinion, make labels more legible.

Please find attached a script in which I compiled all TeX symbols documented by Matlab, and plotted them to svg and eps.

(file #42162)

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Oct 2016 11:08:30 AM UTC, comment #8:

Most rich text editors (latex, libreoffice ...) use different fonts for (inline or not) math symbols.
I'd vote doing the same in Octave by choosing using a full featured font (ASANA?[1] Computer Modern? ...) that we would ship with Octave so that we are sure all symbols can be shown whatever the main text font is chosen by the user.
The example below leads to 2 different characters for the mu greek letter in Matlab (see screen shot attached), one for the utf8 character input and one for the tex input:

[1] https://en.wikipedia.org/wiki/Asana-Math

(file #38816)

Pantxo Diribarne <pantxo>
Project Member
Mon 29 Dec 2014 08:21:15 PM UTC, comment #7:

More debugging shows that for gnuplot the font name is always set to Symbol for any extended glyphs. This is consistent with the previous debugging that shows that Matlab and gnuplot do not use the text font for glyphs rendered through the TeX interpreter.

Rik <rik5>
Project Administrator
Mon 15 Dec 2014 05:31:08 AM UTC, comment #6:

Thanks for doing such careful debugging. I think you've discovered the root issue which is that FLTK adheres strictly to the user's stated font, while gnuplot and Matlab substitute a font specifically for symbols. They may also be running some sort of substitution for glyphs not found as well. I can tell because Octave is requesting the circle division slash glyph, and gnuplot is responding with the emptyset glyph which is a different.

Since gnuplot is going to ignore Octave anyways I don't see any point in checking on Octave's side whether the given font has the correct glyph. I believe you're right that the glyph warning can be eliminated when the toolkit is gnuplot.

On the broader issue of whether FLTK should follow gnuplot/Matlab and use a different font entirely for special symbols, I'm not certain how to proceed. One choice would be to try and use the default font, '*', for all symbols in the hope that the default has the largest number of glyphs of the available fonts. Otherwise, I'm not sure how to find the best font to use for symbols on a given platform.

Rik <rik5>
Project Administrator
Tue 09 Dec 2014 07:42:54 PM UTC, comment #5:
  • Concerning the (unnecessary) warning from gnuplot I do not like to argue. The resulting plot is fine nevertheless.

If we keep this aside, I do still see a big misbehavior of FLTK on this Win7 machine:

  • For the vast majority of the installed fonts (including the default font) NO special characters are displayed on screen. I took "\alpha" in the example below. So this misbehavior is not restricted to the rather exotic special character "\0".
  • On the very SAME Win7 machine (and therefore with the very same fonts installed) I do get properly displayed special characters with Matlab, as well as with the gnuplot engine of the same Octave installation.
  • note: This is even true on my Linux machine: gnuplot displays the "\alpha" and the "\0" with many many more different font names set, as the fltk frontend does.

Other observations, that might or might not be giving us a hint to the root cause here:

  • FLTK seems to take the special characters directly from the choosen font name. With Matlab and with the gnuplot engine of Octave this is NOT the case (see the attached screenshots). They seem to take the SPECIAL characters always from the same font, regardless of the specified font name. The specified font name is only taken for the letters and similar "normal" characters. (This is also the case under Linux: gnuplot gives me always the same "\alpha" on the screen, where as fltk gives my differently looking "\alpha"s, depending on the chosen font name. And for some fonts fltk does not give me any "\alpha" on screen, where gnuplot still does.)
  • Matlab as well as the Gnuplot engine probably take the font "Microsoft Sans Serif" as default font "" on this Win7 machine. This font is set as default font "MS Shell Dlg" via the Windows registry "HKLM/HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes". In contrast, fltk seems to use a different font as default font "". Maybe Arial. Have a look at the screenshots yourself.

I will attach 3 screenshots from the resulting plots in (1) Matlab, (2) Octave with gnuplot and (3) Octave with fltk respectively. They are all the result of the very same script, quoted below. I think you can follow my conclusions on the fltk misbehavior on the basis of those screenshots.

A last comment: This problematic Win7 PC is not some exotic Windows machine. It' a clean and fresh install of a standard PC in a big engineering company. The next couple of thousand PCs will look identical in this company...

(file #32627, file #32628, file #32629)

Hartmut <hardy>
Tue 02 Dec 2014 06:26:07 PM UTC, comment #4:

I checked the actual fontfiles using fontforge that I have installed on my computer and, indeed, the version of Arial and Cambria I have do not have an entry for 0x2298.

I set a breakpoint in the render code and checked the fontname just before it attempts to map the Unicode number to a glyph index. When it works, the font name is '*' which is the default font.

To find the default font I used

on a shell command line. I don't know if there is something similar for Windows or not, but that's the only way I could figure out what the default font was.

So far I think Octave is behaving correctly. The glyph doesn't exist so it issues a warning about it. Even when using gnuplot, the glyph doesn't exist but gnuplot seems to be substituting a character on its own.

Rik <rik5>
Project Administrator
Tue 02 Dec 2014 03:56:51 AM UTC, comment #3:

Using the default font '*' leaves it up to the operating system, and I don't know how to determine which font gets selected.

Within Octave, you can set a default on the root figure that will be respected later.

That is something you could put in your .octaverc if you find a font that you like and which generates the glyph for you.

When I try to use the Cambria font I still get a warning message and no printing of the correct glyph, but this is on a Linux install with the Microsoft TrueType fonts added--not a native Windows environment.

Rik <rik5>
Project Administrator
Thu 27 Nov 2014 08:33:06 PM UTC, comment #2:

I've tried a couple of things as suggested, and here is my current conclusion (more details below) for this one problematic Windows installation of Octave:

  • With FLTK as graphics toolkit, the default font does not contain several special characters, so there are not printed on screen (and a useful warning message is issued).
  • With FLTK and GNUPLOT as graphics toolkit, a (in this case useless) warning message is issued when printing those special characters, even when the on screen printing acutually DOES work properly.

Here are some details you wanted to know:

  • The GNUPLOT VERSION is "Version 4.4 patchlevel 3, last modified March 2011, System: MS-Windwos 32 bit". This seems to be included in the MXE Windows installation from mxeoctave.osuv.de.
  • I didn't find any way to find out the actual name of the DEFAULT FONT used by Octave, gnuplot or fltk. Can you give me a hint how I can get this information?
  • With GNUPLOT I tried some different font names like this:

The result was: The diamater sign always IS printed properly. The only problem with gnuplot is, that an unnecessary warning message is issued.

  • With FLTK I also tried some font names:

The result was: The diameter sign is NOT printed with many font names I have tried. A (some times different number of) warning messages are issued, which is appropriate in this case.

  • With FLTK I did find one font name that does work:

graphics_toolkit fltk
text (0.5,0.5, 'A \0 B', 'fontname', 'cambria')
-verbatim-
With this font (maybe there are other ones that do work, but I did try a couple of them) the diameter sign IS properly displayed on screen. But still the unecessary warning message is issued (like with Gnuplot).

As said at the beginning, I suspect this whole issue is "only" about a change in the default font name, that Octave tries to use. Can this happen? How do I find out which font name Octave is using as default font?

Hartmut <hardy>
Fri 21 Nov 2014 12:05:52 AM UTC, comment #1:

The FLTK toolkit has a TeX interpreter which only works for the onscreen display of special characters. There is a separate issue report filed about the wish to extend the TeX interpreter to printed characters.

As for gnuplot, it does work just fine for me on a Linux PC and for you on a different installation.

I would suggest starting by finding out which gnuplot version is being used. Another key is the font that is being used. You might try setting it to something you know exists on your computer and has the correct glyph (Unicode 2298 Circled Division Slash).

For example, I don't get an error if I use the default font for gnuplot. But, I do if I use a named font.

Rik <rik5>
Project Administrator
Thu 20 Nov 2014 10:00:23 PM UTC, original submission:

Here is a small script to show the behavior:

I get the behavior with the current Octave MXE compilation 3.8.2-3 for Windows (source: mxeoctave.osuv.de). I have one PC that throws this warning/error, another Windows installation of the very same Octave MXE version does not throw this warning/error. Under Linux (yet another different PC) I do not get the warning message either.

Here is what happens on my Windows machine that throws an error:

  • If I print the diameter sign in gnuplot, I get a warning message "warning: ft_render: skipping missing glyph for character '2298'". But the diameter sign is properly displayed in the plot window.
  • If I run the script, but change to fltk, then I get the very same warning message in my terminal window as with gnuplot. But additionally the diameter sign will NOT be printed in the plot window. (This is why I use the word "error" here.)

Because in general fltk is able to produce this latex symbol (diameter sign) in Octave 3.8.2 under Linux as well as under Windows, I report this as a bug. I also concluded, that it's not (only) a gnuplot problem

I suspect, that the wrong behavior is due to some specific setting of my Windows PC, let me know what information you need on this.

Hartmut <hardy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #42181:  symb.pdf added by dasergatskov (39KiB - application/pdf)
file #42177:  symb.png added by dasergatskov (30KiB - image/png)
file #42178:  symb.svg added by dasergatskov (51KiB - image/svg+xml)
file #42165:  symboltest.m added by pantxo (2KiB - text/x-objcsrc)
file #42162:  symboltest.m added by pantxo (2KiB - text/x-objcsrc)
file #38816:  mu.png added by pantxo (7KiB - image/png)
file #32627:  plot_matlab.jpg added by hardy (195KiB - image/jpeg)
file #32628:  plot_gnuplot.jpg added by hardy (189KiB - image/jpeg)
file #32629:  plot_fltk.jpg added by hardy (71KiB - image/jpeg)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by pantxo (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by hardy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 17 Oct 2017 02:37:14 PM UTCdasergatskovAttached File-=>Added symb.pdf, #42181
    Tue 17 Oct 2017 12:42:48 AM UTCdasergatskovAttached File-=>Added symb.png, #42177
      Attached File-=>Added symb.svg, #42178
    Mon 16 Oct 2017 05:31:39 PM UTCpantxoAttached File-=>Added symboltest.m, #42165
    Sun 15 Oct 2017 10:02:59 PM UTCpantxoAttached File-=>Added symboltest.m, #42162
    Wed 26 Oct 2016 11:08:30 AM UTCpantxoAttached File-=>Added mu.png, #38816
    Tue 30 Dec 2014 10:43:25 PM UTCrik5Dependencies-=>Depends on bugs #43907
    Mon 29 Dec 2014 08:21:15 PM UTCrik5StatusNone=>Confirmed
    Tue 09 Dec 2014 07:42:54 PM UTChardyAttached File-=>Added plot_matlab.jpg, #32627
      Attached File-=>Added plot_gnuplot.jpg, #32628
      Attached File-=>Added plot_fltk.jpg, #32629

    Back to the top


    Powered by Savane 3.1-cleanup1