Fix for ylabel title in example tex_unicode_demo.py

[pa-hobe]

The example is about using Unicode characters with TeX. However, the example uses a raw string type for the Unicode escape sequence:

plt.ylabel(r'\textit{Velocity (\u00B0/sec)}', fontsize=16)

That means that the escape sequence appears literally instead of the degree sign.
Proposed fix is a normal string with doubling of the backslash for the TeX macro
\textit:

plt.ylabel('\\textit{Velocity (\u00B0/sec)}', fontsize=16)

[Kojoley]

Is the bug in the example and not in the other place?

http://matplotlib.org/1.4.3/examples/pylab_examples/tex_unicode_demo.html

http://matplotlib.org/1.5.0/examples/pylab_examples/tex_unicode_demo.html

[dopplershift]

Apparently, there's a separate bug where the gallery image is chopped.

[pa-hobe]

@Kojoley This bug report is referring to the label for the y axis, where \u00B0 is not interpreted as Unicode escape sequence in the Python string. Instead it goes as raw form to the TeX file, where \u is interpreted as LaTeX macro, creating an accent to the following letter, the digit 0.

[Kojoley]

I have posted a rendered image of this example with matplotlib v1.4.3 and it looks right to me. That's why I think it is not a bug in the example, but in matplotlib itself.

[pa-hobe]

@Kojoley The bug report was made with matplotlib v1.5.1. But I get the same wrong image with matplotlib v1.4.3.

Tested with Python distribution Anaconda, environment test, created by

conda -create test python=3.5 matplotlib=1.4.3 spyder

Who is responsible for parsing the Unicode escape sequence \u00B0?
As far as I have understood the documentation, the conversion to the Unicode
character belongs to the Python layer, where the non-raw string is parsed and
the string will now contain the degree symbol. (Alternatively, the symbol could
have directly been written in the source.)

The temporary file for TeX contains the degree symbol in encoding UTF-8,
but not the macro \u followed by 00B0. Then the Unicode symbol is set
depending on the TeX configuration (package ucs for 8-bit engines or
Unicode engines XeTeX or LuaTeX).

The bug of the example is, that the escape sequence is put in a raw string (r'')
and TeX sees the escape sequence of the Python language and not the Unicode
symbol.

[tacaswell]

TLDR: this is the correct fix. Can you also remove the line-break \ in the title (replace it with implicit string concatenation) please?

---

@hoiqs your analysis seems correct, which leads to the question of how did the 1.4.3 docs come out right, which lead me down a fun rabbit hole.

It looks like I built the 1.4.3 docs 2015-02-16 but I can not sort out how to get the version of latex (or python) I used out of the files.

If I re-run this from 1.4.3 on my current system with 3.5 I get

This is what is getting handed off to latex (pulled from ~/.cache/matplotlib/tex.cache/01e1a4b38d10aa0dce7c667a9bc1e28b.tex)

\documentclass{article}
\usepackage{type1cm}
\renewcommand{\rmdefault}{pnc}
\usepackage{helvet}
\usepackage{courier}
\usepackage{textcomp}
\usepackage{ucs}
\usepackage[utf8x]{inputenc}

\usepackage[papersize={72in,72in},body={70in,70in},margin={1in,1in}]{geometry}
\pagestyle{empty}
\begin{document}
\fontsize{16.000000}{20.000000}{\sffamily \textit{Velocity (\u00B0/sec)}}
\end{document}

However, if I run mpl 1.5.1 with python2.7

\documentclass{article}
\usepackage{type1cm}
\renewcommand{\rmdefault}{pnc}
\usepackage{helvet}
\usepackage{courier}
\usepackage{textcomp}
\usepackage{ucs}
\usepackage[utf8x]{inputenc}

\usepackage[papersize={72in,72in},body={70in,70in},margin={1in,1in}]{geometry}
\pagestyle{empty}
\begin{document}
\fontsize{16.000000}{20.000000}{\sffamily \textit{Velocity (°/sec)}}
\end{document}

Note that the title is back on one line, the degree symbol is fixed, and it appears an unicode in the tex file.

---

So note:

22:30 $ python2
Python 2.7.12 (default, Jun 28 2016, 08:31:05) 
[GCC 6.1.1 20160602] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> r'\textit{Velocity (\u00B0/sec)}'
'\\textit{Velocity (\\u00B0/sec)}'
>>> '\\textit{Velocity (\u00B0/sec)}'
'\\textit{Velocity (\\u00B0/sec)}'
>>> from __future__ import unicode_literals
>>> r'\textit{Velocity (\u00B0/sec)}'
u'\\textit{Velocity (\xb0/sec)}'
>>> '\\textit{Velocity (\u00B0/sec)}'
u'\\textit{Velocity (\xb0/sec)}'
>>> 

vs

22:29 $ python
Python 3.5.2 (default, Jun 28 2016, 08:46:01) 
[GCC 6.1.1 20160602] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> r'\textit{Velocity (\u00B0/sec)}'
'\\textit{Velocity (\\u00B0/sec)}'
>>> '\\textit{Velocity (\u00B0/sec)}'
'\\textit{Velocity (°/sec)}'
>>> 

Tracing back the history of this line it went through a bunch of different ways of specifying that it was a unicode string. This is the documented behavior https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals

[tacaswell]

Turns out we have this documented in our dev guide: http://matplotlib.org/devel/portable_code.html#the-dreaded-u-escapes

[pa-hobe]

@tacaswell Thanks for your analysis, indeed the example works with Python 2.7, where the raw string interprets the \u sequences because of the implicit u because of the imported unicode_literals. A behavior, which is no longer present in Python 3.

As requested I have changed the line break in the title following the line break in tex_demo.py.
Also I changed the double quotes to single quotes to follow the quote symbol of the other strings.

[tacaswell]

backported to v1.5.2-doc as 7074991

[tacaswell]

@hoiqs Thanks!