bugGNU Octave - Bugs: bug #49338, Error preventing the creation of...


bug #49338: Error preventing the creation of valid latex output with non-ascii chars under fltk

Submitted by:  None
Submitted on:  Thu 13 Oct 2016 07:21:36 PM UTC  
Category:  Plotting with OpenGL Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Wont Fix Assigned to:  None
Originator Name:  R.S.Carmenes Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  dev
Operating System:  GNU/Linux

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)

Tue 20 Aug 2019 08:20:03 AM UTC, comment #14: 

@Markus: Thanks for the review. I pushed the patch here:


I tested the patch with the original example and it works OOTB. But it looks like this works only because latex (pdftex in my tests) can translate those characters into simple accented characters ("í"->"\'{i}"). With Cyrillic characters, this is another story and one still has to edit the .tex file to include some relevant package that will handle russian (e.g. babel).

So I'd like to close this report as "Won't Fix" and let users tweak their .tex file as they needed (using e.g. "babel" with latex or "fontspec" with xetex/luatex ...)

Pantxo Diribarne <pantxo>
Project Member
Sun 21 Jul 2019 06:45:23 PM UTC, comment #13: 

Pantxo: Your proposed change looks good to me.

Markus Mützel <mmuetzel>
Project Member
Mon 10 Jun 2019 07:53:50 PM UTC, comment #12: 

I attached a patch that does the proposed change.

(file #47065)

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Mar 2019 07:45:54 PM UTC, comment #11: 

Working with encodings can get messy. IMHO, we should try to consistently use UTF-8 internally wherever possible and treat anything that deviates as a bug.

In that spirit I'd say: the resulting LaTeX file are expected to always be UTF-8 encoded. If they were not, that would be a separate bug.

Markus Mützel <mmuetzel>
Project Member
Sun 03 Mar 2019 06:27:45 PM UTC, comment #10: 

>> Will the LaTeX file written by Octave always be encoded in UTF-8?

We should ask to Markus, but I'd say yes. IIUC Octave now always uses utf8 as its internal string encoding and gl2ps prints those strings unchanged to the tex file.

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Mar 2019 06:21:39 PM UTC, comment #9: 

I guess the bottom line is it's possible any particular LaTeX engine may default to UTF-8 input, but for strict compatibility the file should contain '\usepackage[utf8]{inputenc}'. Reopening.

Will the LaTeX file written by Octave always be encoded in UTF-8?

Mike Miller <mtmiller>
Project Administrator
Sun 03 Mar 2019 06:05:01 PM UTC, comment #8: 

The tex files are the same: diff just tells me that I am closer to the end of this sunday than you, and that I use a dev version of gl2ps:

$diff -u ~/Téléchargements/test.tex /tmp/test.tex
--- "/home/pantxo/T\303\251l\303\251chargements/test.tex"        2019-03-03 18:58:31.507861381 +0100
+++ /tmp/test.tex        2019-03-03 18:46:37.966623025 +0100
@@ -4,9 +4,9 @@
% Title: gl2ps_renderer figure
-% Creator: GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
+% Creator: GL2PS 1.4.1, (C) 1999-2017 C. Geuzaine
% For: Octave
-% CreationDate: Sun Mar  3 09:10:32 2019
+% CreationDate: Sun Mar  3 18:46:37 2019

So maybe recent pdftex versions handles non ascii characters better than before?

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Mar 2019 05:57:46 PM UTC, comment #7: 

Interesting. Here are the test.tex and test.pdf on my system.

Using gl2ps 1.4.0 and pdfTeX 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian).

(file #46401, file #46402)

Mike Miller <mtmiller>
Project Administrator
Sun 03 Mar 2019 05:52:37 PM UTC, comment #6: 

@Mike: I ran the original example and pdflatex (pdfTeX 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian)) doesn't complain but still doesn't handle non ascci characters unless I add the appropriate \usepackage

graphics_toolkit fltk
title('Título de la gráfica')
system ("pdflatex test.tex")

See attached pdf file.

(file #46400)

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Mar 2019 05:17:25 PM UTC, comment #5: 

On my Debian system, running in the en-US.UTF-8 locale, the original example now works for me with Octave 5. The output .tex file contains the correct UTF-8 characters, and pdflatex produces the correct pdf with no errors or warnings. I do not need to insert any '\usepackage' directives into the file.

If there are still cases where this doesn't work, please comment and this can be reopened.

Mike Miller <mtmiller>
Project Administrator
Sun 03 Mar 2019 07:06:37 AM UTC, comment #4: 

Version 4.2.0 is deprecated and no longer supported.  Please try with the latest stable release which is 5.1.0.  The problem is likely to have been fixed.

Rik <rik5>
Project Administrator
Fri 14 Oct 2016 04:10:27 PM UTC, comment #3: 

Just another idea that may be simpler and cleaner: relying on an external user-configured file jusl like gnuplot does, containing the correct latex heading. If present, gnuplot uses the folowing file:


For example, in my setup, this file contains simply:

%% A configuration file for the epslatex terminal by Harald Harders.
%% This file is part of Gnuplot.
%% End of file `gnuplot.cfg'.

Maybe octave could use that same file too, so that the right encoding for fltk would be set at the same time as for gnuplot?

Fri 14 Oct 2016 03:49:42 PM UTC, comment #2: 

Yes, you are right. I'm using Linux, but have it configured to use latin1 for my convenience, hence, hardcoding \usepackage[T1]{fontenc} was right for me but won't be for others. I did no realise that fact.

In the case of graphics_toolkit gnuplot, it is gnuplot that take care of selecting the right char encoding through a system-wide or user-wide gnulot configuration file. However, with fltk, it is octave which is taking care of creating the latex file itself, so I supose that octave should also take care of creating the right latex headings depending on the encoding being set on the current computer. A naïve implementation could consist in making print.m to check the current LANG environment variable before issuing the latex headings ...

Fri 14 Oct 2016 01:32:57 PM UTC, comment #1: 


Thanks for your bug report. I can reproduce the bug (whatever the version of gl2ps between 1.3.8 an current dev) and your solution produces a compile ready .tex file but the output pdf is still wrong. One has to specify the encoding through "\usepackage[opt]{inputenc}": "opt" being "utf8" for me on linux but probably "latin1" on some other systems like Windows. Now how to decide what encoding the target system is using?

Pantxo Diribarne <pantxo>
Project Member
Thu 13 Oct 2016 07:21:36 PM UTC, original submission:  

Hello, this is a bug report regarding the printing of plots with texts containing non-ascii chars. I am providing what I believe is a valid the solution too.

The latex file created under the graphics_toolkit fltk will not compile when the plot contains non-ascii chars.


graphics_toolkit fltk
title('Título de la gráfica')

(the string in the title command contains two latin-1 chars; I believe the same problem would be the same with other encodings).

Executing pdflatex test.tex will fail, complaining at the non-ascii chars.This is due to the absence of the following in the generated latex file:


together with the inability to pass the non-ascii chars to the latex file.

A third error in the file prevents from getting a valid latex file with recent GL2PS.

Patching print.m with the attached file will solve the problem (first change incorporates the missing heading, the second one makes print.m able to read non-ascii chars, and the third removes the line that seems incompatible with recent versions of GL2PS).



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

Attach Files:

Attached Files
file #47065:  tex_utf8.patch added by pantxo (1KiB - text/x-patch)
file #46401:  test.tex added by mtmiller (2KiB - text/x-tex)
file #46402:  test.pdf added by mtmiller (22KiB - application/pdf)
file #46400:  test.pdf added by pantxo (24KiB - application/pdf)
file #38721:  latin1-fltk.patch added by None (2KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

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

    Only project members can vote.




    Follow 19 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-10-29 pantxo Open/ClosedOpen => Closed
    2019-08-20 pantxo StatusPatch Submitted => Wont Fix
    2019-06-10 pantxo Attached File- => Added tex_utf8.patch, #47065
        StatusConfirmed => Patch Submitted
    2019-03-03 mtmiller CategoryPlotting => Plotting with OpenGL
        Severity3 - Normal => 1 - Wish
        Item GroupIncorrect Result => Feature Request
        StatusFixed => Confirmed
        Open/ClosedClosed => Open
        Release4.2.0 => dev
    2019-03-03 mtmiller Attached File- => Added test.tex, #46401
        Attached File- => Added test.pdf, #46402
    2019-03-03 pantxo Attached File- => Added test.pdf, #46400
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 => -
    2019-03-03 mtmiller StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2016-11-17 mtmiller Release4.2.0-rc2 => 4.2.0
    2016-10-14 pantxo StatusNone => Confirmed
    2016-10-13 None Attached File- => Added latin1-fltk.patch, #38721

    Back to the top

    Powered by Savane 3.6