
12

Dear Octave maintainers,
I am considering the implementation of the "latex interpreter"
functionality in octave based on a combination of Qt+Mathjax.
The idea is from this post
https://forum.qt.io/topic/36457/qtmathjaxbeautifulmathtypesettinginqtapps.
Please let me know your oppinion if such an approach would be feasible
and desirable.
Best regards
George
____________________________________________
Dr. Georgios Apostolopoulos
Fusion Technology Group
INRASTES / NCSR "Demokritos"
15310 Agia Paraskevi Attikis,
Greece
tel: +302106503731 / 3749 (lab)
fax: +302106545496
email: [hidden email]
web: http://ipta.demokritos.gr/ftg/


George,
Improving the TeX/LaTeX handling in Octave is certainly
a needed project. But, a few points:
1. It would be good to look at the current implementation
which allows embedding LaTeX in label strings and
allows postediting of the LaTeX before generating the PDF.
This has restrictions, and is not as simple as might be nice,
but it works. Using this path there is little need for Mathjax
since LaTeX is available.
2. The use of Mathjax + Qt would more be for generation of
other formats such as html, EPUB, etc. Mathjax is as far
as I have experienced the best path for getting wellformatted
math into files other than TeX/LaTeX.
3. An end goal could be the implementation of "Octave" notebooks.
i.e. allow a text mode with Octave and supporting things like
Mathjax embedded. This would allow a text (i.e. TeX) source to
instantiate Octave results inline.
These are just suggestions. You are welcome to join in the
Octave project and help out as you see best.
Michael


Am 11. Januar 2016 17:26:20 MEZ, schrieb Michael Godfrey < [hidden email]>:
>George,
>
>Improving the TeX/LaTeX handling in Octave is certainly
>a needed project. But, a few points:
>
>1. It would be good to look at the current implementation
> which allows embedding LaTeX in label strings and
> allows postediting of the LaTeX before generating the PDF.
> This has restrictions, and is not as simple as might be nice,
> but it works. Using this path there is little need for Mathjax
> since LaTeX is available.
>
>2. The use of Mathjax + Qt would more be for generation of
> other formats such as html, EPUB, etc. Mathjax is as far
> as I have experienced the best path for getting wellformatted
> math into files other than TeX/LaTeX.
>
>3. An end goal could be the implementation of "Octave" notebooks.
> i.e. allow a text mode with Octave and supporting things like
> Mathjax embedded. This would allow a text (i.e. TeX) source to
> instantiate Octave results inline.
>
>These are just suggestions. You are welcome to join in the
>Octave project and help out as you see best.
>
>Michael
What is the best practice to insert math in TexInfo documentation? I haven't found a good solution yet.
1. You could use math mode if output format is tex and ASCII art formulas otherwise. This is currently done in Octave manual. The big disadvantage is that the TexInfo document is not independent of the output format and you have to write each formula twice. Also this looks poor in HTML output.
2. You could typeset formulas with Unicode characters. I do this in a package's documentation. The advantage is that you have only one input for all output formats. This approach works for simple formulas only, the result looks a little less good in tex and much better in plaintext+HTML. Coding the formulas is a little bit more complicated and is more likely to contain errors (e.g. if you forget to use non breaking spaces). Output of the help command looks strange in Windows, which does not support UTF8 at the moment.
3. Use the @math macro. Downside is that plaintext+HTML contain tex syntax. You can probably fix the HTML with MathJax, but the plaintext output will still contain tex code.
Is it possible to input formulas only once and make them look good in all output formats?
Oliver


On 01/11/2016 05:14 PM, Oliver Heimlich wrote:
> Is it possible to input formulas only once and make them look good in all output formats?
>
> Oliver
This is possible, but it is a lot of hard work. To see what can be done
take a look at:
www.feynmanlectures.caltech.edu
This renders well in all "standard" ebook formats, including Kindle!!
Michael


On 11.01.2016 18:28, Michael Godfrey wrote:
>
>
> On 01/11/2016 05:14 PM, Oliver Heimlich wrote:
>> Is it possible to input formulas only once and make them look good in
>> all output formats?
>>
>> Oliver
> This is possible, but it is a lot of hard work. To see what can be done
> take a look at:
> www.feynmanlectures.caltech.edu
>
> This renders well in all "standard" ebook formats, including Kindle!!
This is not TexInfo, is it?
Also I disagree: This does not render well in my browser. The MathJax
numbers use a different font with a different weight compared to the
surrounding text, which looks very bad.
Oliver


On 01/11/2016 05:52 PM, Oliver Heimlich wrote:
> Also I disagree: This does not render well in my browser. The MathJax
> numbers use a different font with a different weight compared to the
> surrounding text, which looks very bad.
>
> Oliver
What browser are you using? On what system?


> On Jan 11, 2016, at 10:09 AM, Michael Godfrey < [hidden email]> wrote:
>
>
>
> On 01/11/2016 05:52 PM, Oliver Heimlich wrote:
>> Also I disagree: This does not render well in my browser. The MathJax
>> numbers use a different font with a different weight compared to the
>> surrounding text, which looks very bad.
>>
>> Oliver
> What browser are you using? On what system?
>
>
MathJax looks bad in Google Chrome on OSX unless I right click and go choose Math SettingsMath Renderer and select SVG as the renderer. The HTMLCSS, Common HTML (which was the default), and Fast HTML all look really bad for me.
My test equations was:
$\dot{x}(t) = A(t) x(t) + B(t) u(t) \\ y(t) = C(t) x(t)$
In the poor cases, the dot for the derivative was too low and smashed into the x and the spacing for dependent variables and spacing between equation components seemed “off” compared to vanilla pdflatex. After choosing the SVG renderer, I couldn’t see a difference between the LaTeX output from LaTeXit! and from MathJax
John S.


On 11.01.2016 19:15, John Swensen wrote:
>
>> On Jan 11, 2016, at 10:09 AM, Michael Godfrey < [hidden email]> wrote:
>>
>>
>>
>> On 01/11/2016 05:52 PM, Oliver Heimlich wrote:
>>> Also I disagree: This does not render well in my browser. The MathJax
>>> numbers use a different font with a different weight compared to the
>>> surrounding text, which looks very bad.
>>>
>>> Oliver
>> What browser are you using? On what system?
>>
>>
>
> MathJax looks bad in Google Chrome on OSX unless I right click and go choose Math SettingsMath Renderer and select SVG as the renderer. The HTMLCSS, Common HTML (which was the default), and Fast HTML all look really bad for me.
>
> My test equations was:
> $\dot{x}(t) = A(t) x(t) + B(t) u(t) \\ y(t) = C(t) x(t)$
>
> In the poor cases, the dot for the derivative was too low and smashed into the x and the spacing for dependent variables and spacing between equation components seemed “off” compared to vanilla pdflatex. After choosing the SVG renderer, I couldn’t see a difference between the LaTeX output from LaTeXit! and from MathJax
>
> John S.
>
I have checked Iceweasel on GNU/Linux, Chrome on Android, and Opera on
Windows. All have the problem that the MathJax font doesn't match the
surrounding text and the font weight is too high. In Chrome on Android
the different font weights are not as bad, but still visible. Switching
to SVG didn't help me—just produced antialiasing artifacts.
Then I tried w3m. The fonts weight differences are gone ;) However, the
tex code became visible (that is the same problem that you have with
TexInfo and @math in nontex output).
Oliver

Administrator

In reply to this post by George Apostolopoulos
On 01/11/2016 07:06 AM, George Apostolopoulos wrote:
> Dear Octave maintainers,
>
> I am considering the implementation of the "latex interpreter"
> functionality in octave based on a combination of Qt+Mathjax.
>
> The idea is from this post
> https://forum.qt.io/topic/36457/qtmathjaxbeautifulmathtypesettingin> qtapps.
>
> Please let me know your oppinion if such an approach would be feasible
> and desirable.
What's the goal? Complete support for arbitrarily complex LaTeX? Where
is LaTeX input expected to be found? Only in graphics labels or
somewhere else?
jwe


In reply to this post by George Apostolopoulos
George Apostolopoulos wrote
Dear Octave maintainers,
I am considering the implementation of the "latex interpreter"
functionality in octave based on a combination of Qt+Mathjax.
The idea is from this post
https://forum.qt.io/topic/36457/qtmathjaxbeautifulmathtypesettinginqtapps.
Please let me know your oppinion if such an approach would be feasible
and desirable.
Best regards
George
____________________________________________
Dr. Georgios Apostolopoulos
Fusion Technology Group
INRASTES / NCSR "Demokritos"
15310 Agia Paraskevi Attikis,
Greece
tel: +302106503731 / 3749 (lab)
fax: +302106545496
email: [hidden email]web: http://ipta.demokritos.gr/ftg/
Hi Georgios,
AFAICS the library you mention makes use of the svg ouput of Mathjax so lets assume you'll end up having to deal with svg paths (*not characters anymore*, see [1]).
The Qt toolkit is mostly a container for an opengl scene, *not* a QPainter that would have the hability to handle directly the svg output of Mathjax. For text rendering we currently use two approaches:
* onscreen: we build text strings using our own tex parser and freetype and we render them as pixmaps to include them in the opengl scene.
* printing: we use the very basic text capabilities of gl2ps.
Turning the svg to pixels for onscreen rendering of latex strings would probably do the trick. Now for printing we would have to make svg our primary output format (instead of eps), include Mathjax svg output directly into the output file using gl2psSpecial, convert to eps using e.g. librsvg and then use our current tool chain to convert to the desired format.
The major drawbacks in the above approach is that you'll end up with *non selectable* text strings in e.g. pdf printout (characters are now paths) and we would need to add a conversion step. The advantage is that we don't need to to have latex installed to have latex typesetting in our printout contrary to what has been tried in a GSOC a few years ago.
This is my two cents.
Pantxo
[1] https://github.com/nathancarter/qtmathjax/blob/master/screenshot.png


Thank you all for your constructive comments.
My motivation for this is actually to use octave for creating figures
for publications in scientific journals. Up to now I have used matlab to
generate eps files using the latex interpreter for axis titles and graph
labels.
I have reviewed octave's latex+ps combination which is very interesting.
However, apart from the added processing steps, I am missing the
possibility to create a single, selfcontained eps file for one figure.
This is required when sending a manuscript to publishers.
So, my specifications for this project would be:
 use latex code in figure annotations (axis titles, legends, text
labels etc)
 rendering of latex on screen in the graph window
 good quality printing of a figure to eps/pdf
For the implementation the Qt graphics capabilities can be used.
It is true what Panxto writes, that mathjax will convert latex to an svg
image. However, Qt can render the svg through the QSvgRenderer class
( http://doc.qt.io/qt4.8/qsvgrenderer.html) which is able to draw on a
QGLWidget. Thus, the rest of the toolchain would remain intact (gl2ps
etc) Of course, this will only be possible when using the qt
graphics_toolkit in octave.
Maybe a test of qt+mathjax+openGL+gl2ps would be in order to see if all
this is possible.


George Apostolopoulos wrote
For the implementation the Qt graphics capabilities can be used.
It is true what Panxto writes, that mathjax will convert latex to an svg
image. However, Qt can render the svg through the QSvgRenderer class
( http://doc.qt.io/qt4.8/qsvgrenderer.html) which is able to draw on a
QGLWidget. Thus, the rest of the toolchain would remain intact (gl2ps
etc) Of course, this will only be possible when using the qt
graphics_toolkit in octave.
Maybe a test of qt+mathjax+openGL+gl2ps would be in order to see if all
this is possible.
Do you have references on how does Qt handle svg > opengl? Does it rasterize the svg image prior to rendering it in the opengl scene or does it somehow actually draw the svg path? The latter would be interesting (even though, again, its is not text anymore) and would probably work with gl2ps, while the former will probably produce poor quality rasterized text.
Pantxo


In reply to this post by George Apostolopoulos
On 01/12/2016 11:58 AM, George Apostolopoulos wrote:
> For the implementation the Qt graphics capabilities can be used.
> It is true what Panxto writes, that mathjax will convert latex to an svg
> image. However, Qt can render the svg through the QSvgRenderer class
> ( http://doc.qt.io/qt4.8/qsvgrenderer.html) which is able to draw on a
> QGLWidget. Thus, the rest of the toolchain would remain intact (gl2ps
> etc) Of course, this will only be possible when using the qt
> graphics_toolkit in octave.
>
> Maybe a test of qt+mathjax+openGL+gl2ps would be in order to see if all
> this is possible.
This seems to be a good plan. There is an intention to "merge"
the fltk and qt toolkits in any case, so there is no problem,
I think, in implementing this in the qt toolkit. The
qt+mathjax+openGL+gl2ps test would be a good start.
Michael


In reply to this post by George Apostolopoulos
On 01/12/2016 05:58 AM, George Apostolopoulos wrote:
> Thank you all for your constructive comments.
>
> My motivation for this is actually to use octave for creating figures
> for publications in scientific journals. Up to now I have used matlab to
> generate eps files using the latex interpreter for axis titles and graph
> labels.
>
> I have reviewed octave's latex+ps combination which is very interesting.
> However, apart from the added processing steps, I am missing the
> possibility to create a single, selfcontained eps file for one figure.
> This is required when sending a manuscript to publishers.
Generally, the approach to this in the past was to use latex to generate
the EPS file indirectly. It worked rather well with gnuplot as the
graphics engine, but the capability was lost in 4.0, I think.
The way it works(ed) well was to use gnuplot's PS+latex standalone mode,
compile in LaTeX, then use dvips to create a nice mixture of PostScript
with LaTeX fonts in an EPS file. Something like:
graphics_toolkit('gnuplot');
plot([1:50]);
h = xlabel('$\sum_{x=0}^{N}$');
print('myplot.tex', 'depslatexstandalone');
Then at the command line, run latex:
latex myplot
dvips myplot o myplot.eps E
gv myplot.eps
The label should turn out being compiled in latex, with the desired
summation, having the font similar to the rest of latex. If the $...$
isn't compiled in math mode, one might need to try different things with
setting the interpreter of h. The end result looked nice.
What the state of things is now or going forward, don't know.
Dan


In reply to this post by George Apostolopoulos
On 01/12/2016 11:58 AM, George Apostolopoulos wrote:
> I have reviewed octave's latex+ps combination which is very interesting.
> However, apart from the added processing steps, I am missing the
> possibility to create a single, selfcontained eps file for one figure.
> This is required when sending a manuscript to publishers.
I am a bit surprised by this. I cannot remember a publisher requiring
eps. As far as I know the publishers take PDF or as needed jpeg.
This is generally in the scientific literature, or even IEEE, for example.
For various reasons PS and EPS seem to be on the way out. But, if there
is still a need they should be supported.
In any case, thanks for taking an interest in this. Anything that you
can do will surely be helpful.
Best,
Michael


Michael Godfrey wrote
On 01/12/2016 11:58 AM, George Apostolopoulos wrote:
> I have reviewed octave's latex+ps combination which is very interesting.
> However, apart from the added processing steps, I am missing the
> possibility to create a single, selfcontained eps file for one figure.
> This is required when sending a manuscript to publishers.
I am a bit surprised by this. I cannot remember a publisher requiring
eps. As far as I know the publishers take PDF or as needed jpeg.
This is generally in the scientific literature, or even IEEE, for example.
For various reasons PS and EPS seem to be on the way out. But, if there
is still a need they should be supported.
In any case, thanks for taking an interest in this. Anything that you
can do will surely be helpful.
Best,
Michael
@Michael: in physics at least, there are still many important publishers that prefer eps (e.g. [1, 2]) figure format.
@George: you can produce a standalone eps file using latex and dvips, e.g.;
plot (1:10)
print depsstandalone foo.tex
system ("latex foo.tex; dvips foo.dvi o foo.eps")
But I still think not having to rely on latex being installed to support latex interpreter would be great! Looking forward to hearing from your tests.
Pantxo
[1] IOP : http://publishing.aip.org/authors/preparinggraphics[2] APS (physical review letters and others): http://journals.aps.org/authors/tipsauthorsphysicalreviewphysicalreviewletters


On 01/13/2016 09:36 AM, Pantxo wrote:
> @Michael: in physics at least, there are still many important publishers
> that prefer eps (e.g. [1, 2]) figure format.
I have been aware of this, but of course they then do the
EPS to PDF conversion for you. This does sometimes introduce
problems (right now I think that some of the recent problems with
epstopdf have been fixed) but this is still an unnecessary step.
One reason that they do this is that they prefer to do the composition
and layout for you. Other Journals provide their "style guides"
so that you can produce the "final" .tex or .pdf from your LaTeX
source including whatever figures you have. Many of the technical
book publishers, such as Cambridge and MIT, accept PDF for book
publication. I and others much prefer this. It is pretty annoying,
as has happened to quite often, to find that the publisher has edited the
provided .tex files and introduced typos. It is an important step
forward that those problems can be eliminated.
But, you are right that EPS will still be around for a while.
Michael


On Wed, 20160113 at 01:36 0800, Pantxo wrote:
> Michael Godfrey wrote
> > On 01/12/2016 11:58 AM, George Apostolopoulos wrote:
> >> I have reviewed octave's latex+ps combination which is very interesting.
> >> However, apart from the added processing steps, I am missing the
> >> possibility to create a single, selfcontained eps file for one figure.
> >> This is required when sending a manuscript to publishers.
> > I am a bit surprised by this. I cannot remember a publisher requiring
> > eps. As far as I know the publishers take PDF or as needed jpeg.
> > This is generally in the scientific literature, or even IEEE, for example.
> > For various reasons PS and EPS seem to be on the way out. But, if there
> > is still a need they should be supported.
> >
> > In any case, thanks for taking an interest in this. Anything that you
> > can do will surely be helpful.
> >
> > Best,
> > Michael
>
> @Michael: in physics at least, there are still many important publishers
> that prefer eps (e.g. [1, 2]) figure format.
>
> @George: you can produce a standalone eps file using latex and dvips, e.g.;
> plot (1:10)
> print depsstandalone foo.tex
> system ("latex foo.tex; dvips foo.dvi o foo.eps")
>
> But I still think not having to rely on latex being installed to support
> latex interpreter would be great! Looking forward to hearing from your
> tests.
>
> Pantxo
>
> [1] IOP : http://publishing.aip.org/authors/preparinggraphics> [2] APS (physical review letters and others):
> http://journals.aps.org/authors/tipsauthorsphysicalreviewphysicalreviewletters>
>
>
>
> 
> View this message in context: http://octave.1599824.n4.nabble.com/LatexinterpreterviaMathjaxQttp4674346p4674370.html> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>
I finally found the time to put together a test of Qt + OpenGL + file
output. The results are not encouraging ....
1) The rendering of svg/mathjax on the QGLWidget is not satisfactory. It
appears to be rasterized.
2) The gl2ps file output does not contain any of the graphics produced
by Qt painter on the widget. See attached screenshot.
You can view the test project on https://github.com/gapost/qgl2psAny ideas are welcome.
George

12
