using the symbol font in TeX plots

Community matplotlib-users
1

Thanks for the reminder. Sorry this fell through the cracks.

The reason this worked for me and not for you is that I had set (and later forgotten) font.sans-serif to the following:

   font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif

DejaVu Sans is the successor to Vera Sans that includes much larger Unicode coverage, including the Greek characters here. Vera Sans (at least the version shipped with matplotlib) does not include these characters.

It's an open question whether we want to ship the larger DejaVu fonts with matplotlib (and annoy the distro packagers even further who already dislike some of matplotlib's redundancy). A less disruptive change may be to change the rc defaults to put DejaVu in front of Vera, even though we don't ship DejaVu. This will help the majority of Linux users on modern distros (where DejaVu is almost always installed by default, I suspect), and still have our own Vera as a fallback (albeit with a more limited character set). Especially since DejaVu and Vera are basically the same font, and substituting one for the other would not change the appearance of plots, I think this a reasonably safe thing to do -- but I'd appreciate feedback in case I haven't thought through all the issues.

Mike

Gökhan Sever wrote:

···

On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom <mdroe@...86... > <mailto:mdroe@…86…>> wrote:

    On 01/28/2010 08:08 PM, Gökhan Sever wrote:

        #!/usr/bin/python
        # -*- coding: utf-8 -*-

        from pylab import *

        plot([1]*5)
        xlabel(u'μ = 50')
        ylabel(u'σ = 1.5')

        show()

    It works for me. Can you provide a screenshot and the output from
    matplotlib with "verbose.level : debug-annoying" in your matplotlibrc?

    Mike

Mike,

Attached are the outputs. Which font do you activated in your matplotlibrc? Currently non-active in mine.

--
Gökhan
------------------------------------------------------------------------

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

2

Thanks Mike. The Greek symbols become visible when I make the changes as you suggested. DejaVu Sans has been installed in my system (Fedora 12). We might put a note on the documentation stating to get wider Unicode coverage people could install additional fonts --DejaVu Sans being one of them instead of shipping the fonts with matplotlib.

With my working unicode example, now I have three ways to show u^-2 on labels. See the code at: http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py

Not heavy Latex users like me might find unicode fonts much easier to create their labels. Especially using units like #/cm^3.

There are so many nice looking symbols in the DejaVu Sans samples at http://dejavu.sf.net/samples/DejaVuSans.pdf
Is it possible in matplotlib to use those symbols as replacement for regular markers while plotting? I recall someone was asking about using Latex symbols as markers, but not sure about the fate of his question.

Thanks

···

On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom <mdroe@…920…6…> wrote:

Thanks for the reminder. Sorry this fell through the cracks.

The reason this worked for me and not for you is that I had set (and later forgotten) font.sans-serif to the following:

font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif

DejaVu Sans is the successor to Vera Sans that includes much larger Unicode coverage, including the Greek characters here. Vera Sans (at least the version shipped with matplotlib) does not include these characters.

It’s an open question whether we want to ship the larger DejaVu fonts with matplotlib (and annoy the distro packagers even further who already dislike some of matplotlib’s redundancy). A less disruptive change may be to change the rc defaults to put DejaVu in front of Vera, even though we don’t ship DejaVu. This will help the majority of Linux users on modern distros (where DejaVu is almost always installed by default, I suspect), and still have our own Vera as a fallback (albeit with a more limited character set). Especially since DejaVu and Vera are basically the same font, and substituting one for the other would not change the appearance of plots, I think this a reasonably safe thing to do – but I’d appreciate feedback in case I haven’t thought through all the issues.

Mike

Gökhan Sever wrote:

On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom <mdroe@…86… mailto:mdroe@...86...> wrote:

On 01/28/2010 08:08 PM, Gökhan Sever wrote:



    #!/usr/bin/python

    # -*- coding: utf-8 -*-



    from pylab import *



    plot([1]*5)

    xlabel(u'μ = 50')

    ylabel(u'σ = 1.5')



    show()



It works for me.  Can you provide a screenshot and the output from

matplotlib with "verbose.level : debug-annoying" in your matplotlibrc?



Mike

Mike,

Attached are the outputs. Which font do you activated in your matplotlibrc? Currently non-active in mine.

–

Gökhan

–

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

–
Gökhan

3

SVN trunk has support for mathtext as symbol markers --

  plot(range(10), linestyle='None', marker=r'\\clubsuit')

We could support arbitrary (non-math) text, too, fairly easily. We just need to invent a syntax for it.

Mike

Gökhan Sever wrote:

···

Thanks Mike. The Greek symbols become visible when I make the changes as you suggested. DejaVu Sans has been installed in my system (Fedora 12). We might put a note on the documentation stating to get wider Unicode coverage people could install additional fonts --DejaVu Sans being one of them instead of shipping the fonts with matplotlib.

With my working unicode example, now I have three ways to show u^-2 on labels. See the code at: Google Code Archive - Long-term storage for Google Code Project Hosting.

Not heavy Latex users like me might find unicode fonts much easier to create their labels. Especially using units like #/cm^3.

There are so many nice looking symbols in the DejaVu Sans samples at http://dejavu.sf.net/samples/DejaVuSans.pdf
Is it possible in matplotlib to use those symbols as replacement for regular markers while plotting? I recall someone was asking about using Latex symbols as markers, but not sure about the fate of his question.

Thanks

On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom <mdroe@...86... > <mailto:mdroe@…86…>> wrote:

    Thanks for the reminder. Sorry this fell through the cracks.

    The reason this worked for me and not for you is that I had set
    (and later forgotten) font.sans-serif to the following:

     font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida
    Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde,
    sans-serif

    DejaVu Sans is the successor to Vera Sans that includes much
    larger Unicode coverage, including the Greek characters here.
     Vera Sans (at least the version shipped with matplotlib) does not
    include these characters.

    It's an open question whether we want to ship the larger DejaVu
    fonts with matplotlib (and annoy the distro packagers even further
    who already dislike some of matplotlib's redundancy). A less
    disruptive change may be to change the rc defaults to put DejaVu
    in front of Vera, even though we don't ship DejaVu. This will
    help the majority of Linux users on modern distros (where DejaVu
    is almost always installed by default, I suspect), and still have
    our own Vera as a fallback (albeit with a more limited character
    set). Especially since DejaVu and Vera are basically the same
    font, and substituting one for the other would not change the
    appearance of plots, I think this a reasonably safe thing to do --
    but I'd appreciate feedback in case I haven't thought through all
    the issues.

    Mike

    Gökhan Sever wrote:

        On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom > <mdroe@...86... <mailto:mdroe@…86…> > <mailto:mdroe@…86…>> wrote:

           On 01/28/2010 08:08 PM, Gökhan Sever wrote:

               #!/usr/bin/python
               # -*- coding: utf-8 -*-

               from pylab import *

               plot([1]*5)
               xlabel(u'μ = 50')
               ylabel(u'σ = 1.5')

               show()

           It works for me. Can you provide a screenshot and the
        output from
           matplotlib with "verbose.level : debug-annoying" in your
        matplotlibrc?

           Mike

        Mike,

        Attached are the outputs. Which font do you activated in your
        matplotlibrc? Currently non-active in mine.

        -- Gökhan
        ------------------------------------------------------------------------

    -- Michael Droettboom
    Science Software Branch
    Operations and Engineering Division
    Space Telescope Science Institute
    Operated by AURA for NASA

--
Gökhan

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

4

Thanks again. I didn’t know it was complete :slight_smile:

For the second idea you mean something as generic as plotting such markers?

plt.plot(range(10), linestyle=‘None’, marker=u’※ ')

···

On Fri, Feb 26, 2010 at 2:56 PM, Michael Droettboom <mdroe@…86…> wrote:

SVN trunk has support for mathtext as symbol markers –

plot(range(10), linestyle=‘None’, marker=r’\clubsuit')

We could support arbitrary (non-math) text, too, fairly easily. We just need to invent a syntax for it.

Mike

Gökhan Sever wrote:

Thanks Mike. The Greek symbols become visible when I make the changes as you suggested. DejaVu Sans has been installed in my system (Fedora 12). We might put a note on the documentation stating to get wider Unicode coverage people could install additional fonts --DejaVu Sans being one of them instead of shipping the fonts with matplotlib.

With my working unicode example, now I have three ways to show u^-2 on labels. See the code at: http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py

Not heavy Latex users like me might find unicode fonts much easier to create their labels. Especially using units like #/cm^3.

There are so many nice looking symbols in the DejaVu Sans samples at http://dejavu.sf.net/samples/DejaVuSans.pdf

Is it possible in matplotlib to use those symbols as replacement for regular markers while plotting? I recall someone was asking about using Latex symbols as markers, but not sure about the fate of his question.

Thanks

On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom <mdroe@…86… mailto:mdroe@...86...> wrote:

Thanks for the reminder.  Sorry this fell through the cracks.



The reason this worked for me and not for you is that I had set

(and later forgotten) font.sans-serif to the following:



 font.sans-serif     : DejaVu Sans, Bitstream Vera Sans, Lucida

Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde,

sans-serif



DejaVu Sans is the successor to Vera Sans that includes much

larger Unicode coverage, including the Greek characters here.

 Vera Sans (at least the version shipped with matplotlib) does not

include these characters.



It's an open question whether we want to ship the larger DejaVu

fonts with matplotlib (and annoy the distro packagers even further

who already dislike some of matplotlib's redundancy).  A less

disruptive change may be to change the rc defaults to put DejaVu

in front of Vera, even though we don't ship DejaVu.  This will

help the majority of Linux users on modern distros (where DejaVu

is almost always installed by default, I suspect), and still have

our own Vera as a fallback (albeit with a more limited character

set).  Especially since DejaVu and Vera are basically the same

font, and substituting one for the other would not change the

appearance of plots, I think this a reasonably safe thing to do --

but I'd appreciate feedback in case I haven't thought through all

the issues.



Mike



Gökhan Sever wrote:







    On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom > >  > >         <mdroe@...86... <mailto:mdroe@...86...> > > <mailto:mdroe@...86... <mailto:mdroe@...86...>>> wrote:



       On 01/28/2010 08:08 PM, Gökhan Sever wrote:



           #!/usr/bin/python

           # -*- coding: utf-8 -*-



           from pylab import *



           plot([1]*5)

           xlabel(u'μ = 50')

           ylabel(u'σ = 1.5')



           show()



       It works for me.  Can you provide a screenshot and the

    output from

       matplotlib with "verbose.level : debug-annoying" in your

    matplotlibrc?



       Mike





    Mike,



    Attached are the outputs. Which font do you activated in your

    matplotlibrc? Currently non-active in mine.





    --        Gökhan

    ------------------------------------------------------------------------





--    Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

–

Gökhan

–

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

–
Gökhan

5

Gökhan Sever wrote:

Thanks again. I didn't know it was complete :slight_smile:

For the second idea you mean something as generic as plotting such markers?

plt.plot(range(10), linestyle='None', marker=u'※ ')

Yes -- but it can't be quite this simple, since there is already a set of strings that have specific meanings for markers, and we wouldn't want to change that behavior. In order to use an arbitrary character or string, we'd need additional syntax to indicate that's what you want to do. For example:

plt.plot(range(10), linestyle='None', marker=u'(※)')

But I'm hoping someone can suggest a more obvious way to do it.

Mike

···

On Fri, Feb 26, 2010 at 2:56 PM, Michael Droettboom <mdroe@...86... > <mailto:mdroe@…86…>> wrote:

    SVN trunk has support for mathtext as symbol markers --

     plot(range(10), linestyle='None', marker=r'\\clubsuit')

    We could support arbitrary (non-math) text, too, fairly easily.
     We just need to invent a syntax for it.

    Mike

    Gökhan Sever wrote:

        Thanks Mike. The Greek symbols become visible when I make the
        changes as you suggested. DejaVu Sans has been installed in my
        system (Fedora 12). We might put a note on the documentation
        stating to get wider Unicode coverage people could install
        additional fonts --DejaVu Sans being one of them instead of
        shipping the fonts with matplotlib.

        With my working unicode example, now I have three ways to show
        u^-2 on labels. See the code at:
        Google Code Archive - Long-term storage for Google Code Project Hosting.

        Not heavy Latex users like me might find unicode fonts much
        easier to create their labels. Especially using units like #/cm^3.

        There are so many nice looking symbols in the DejaVu Sans
        samples at http://dejavu.sf.net/samples/DejaVuSans.pdf
        Is it possible in matplotlib to use those symbols as
        replacement for regular markers while plotting? I recall
        someone was asking about using Latex symbols as markers, but
        not sure about the fate of his question.

        Thanks

        On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom > <mdroe@...86... <mailto:mdroe@…86…> > <mailto:mdroe@…86…>> wrote:

           Thanks for the reminder. Sorry this fell through the cracks.

           The reason this worked for me and not for you is that I had set
           (and later forgotten) font.sans-serif to the following:

            font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida
           Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde,
           sans-serif

           DejaVu Sans is the successor to Vera Sans that includes much
           larger Unicode coverage, including the Greek characters here.
            Vera Sans (at least the version shipped with matplotlib)
        does not
           include these characters.

           It's an open question whether we want to ship the larger DejaVu
           fonts with matplotlib (and annoy the distro packagers even
        further
           who already dislike some of matplotlib's redundancy). A less
           disruptive change may be to change the rc defaults to put
        DejaVu
           in front of Vera, even though we don't ship DejaVu. This will
           help the majority of Linux users on modern distros (where
        DejaVu
           is almost always installed by default, I suspect), and
        still have
           our own Vera as a fallback (albeit with a more limited
        character
           set). Especially since DejaVu and Vera are basically the same
           font, and substituting one for the other would not change the
           appearance of plots, I think this a reasonably safe thing
        to do --
           but I'd appreciate feedback in case I haven't thought
        through all
           the issues.

           Mike

           Gökhan Sever wrote:

               On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom > <mdroe@...86... <mailto:mdroe@…86…> > <mailto:mdroe@…86…> > <mailto:mdroe@…86… > <mailto:mdroe@…86…>>> wrote:

                  On 01/28/2010 08:08 PM, Gökhan Sever wrote:

                      #!/usr/bin/python
                      # -*- coding: utf-8 -*-

                      from pylab import *

                      plot([1]*5)
                      xlabel(u'μ = 50')
                      ylabel(u'σ = 1.5')

                      show()

                  It works for me. Can you provide a screenshot and the
               output from
                  matplotlib with "verbose.level : debug-annoying" in your
               matplotlibrc?

                  Mike

               Mike,

               Attached are the outputs. Which font do you activated
        in your
               matplotlibrc? Currently non-active in mine.

               -- Gökhan
                      ------------------------------------------------------------------------

           -- Michael Droettboom
           Science Software Branch
           Operations and Engineering Division
           Space Telescope Science Institute
           Operated by AURA for NASA

        -- Gökhan

    -- Michael Droettboom
    Science Software Branch
    Operations and Engineering Division
    Space Telescope Science Institute
    Operated by AURA for NASA

--
Gökhan

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

6

Gökhan Sever wrote:
> For the second idea you mean something as generic as plotting such
> markers?
> plt.plot(range(10), linestyle='None', marker=u'※ ')

Yes -- but it can't be quite this simple, since there is already a set
of strings that have specific meanings for markers, and we wouldn't want
to change that behavior. In order to use an arbitrary character or
string, we'd need additional syntax to indicate that's what you want to
do.

Perhaps naively, I do not see why.
A small number of strings have predefined meanings.
Just keep documenting that and then test if the
provided string is in this set.
Otherwise, use the provided string.
This seems very nice.

If that is too implicit, then adding a markerstr keyword argument
seems the right way to go. It would override the marker argument,
and any string could be used, getting rid of the above problem.

Cheers,
Alan Isaac
(just a user)

···

On 3/1/2010 8:33 AM, Michael Droettboom wrote:

7

Alan G Isaac wrote:

Gökhan Sever wrote:
    

For the second idea you mean something as generic as plotting such
markers?
plt.plot(range(10), linestyle='None', marker=u'※ ')
      
Yes -- but it can't be quite this simple, since there is already a set
of strings that have specific meanings for markers, and we wouldn't want
to change that behavior. In order to use an arbitrary character or
string, we'd need additional syntax to indicate that's what you want to
do.
    
Perhaps naively, I do not see why.
A small number of strings have predefined meanings.
Just keep documenting that and then test if the
provided string is in this set.
Otherwise, use the provided string.
This seems very nice.

If that is too implicit, then adding a markerstr keyword argument
seems the right way to go. It would override the marker argument,
and any string could be used, getting rid of the above problem.

Cheers,
Alan Isaac
(just a user)
  

What if you want to use the letter 'o' as a marker? That to me seems like a potential source of confusion, as well as a little bit limiting. What would the escaping syntax be to use the letter 'o'?

As you suggest, adding an additional kwarg is also a way forward. In that case, though, I would suggest that providing both a marker and markerstr argument should raise an exception. Having implicit overriding rules can often lead to confusion.

One downside of the additional kwarg is that you occasionally see code like this:

markers = ['o', '.', 'h', 'x']
for data, marker in zip(datasets, markers):
    plot(data, marker=marker)

If one wanted to mix built-in with non-built-in markers that idiom would become much more complex. That's why I proposed sticking to a purely string representation -- I'm just not sure of the best or most obvious one.

Mike

···

On 3/1/2010 8:33 AM, Michael Droettboom wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

8

What if you want to use the letter 'o' as a marker? That to me seems

like a potential source of confusion, as well as a little bit limiting. What would the escaping syntax be to use the letter 'o'?

Maybe:
allow only unicode strings as string markers
and test with `is`::

>>> 'o' is 'o'
         True
>>> 'o' is u'o'
         False

Alan Isaac

···

On 3/1/2010 9:36 AM, Michael Droettboom wrote:

9

Alan G Isaac wrote:

Gökhan Sever wrote:

For the second idea you mean something as generic as plotting such

markers?

plt.plot(range(10), linestyle=‘None’, marker=u’※ ')

Yes – but it can’t be quite this simple, since there is already a set

of strings that have specific meanings for markers, and we wouldn’t want

to change that behavior. In order to use an arbitrary character or

string, we’d need additional syntax to indicate that’s what you want to

do.

Perhaps naively, I do not see why.

A small number of strings have predefined meanings.

Just keep documenting that and then test if the

provided string is in this set.

Otherwise, use the provided string.

This seems very nice.

If that is too implicit, then adding a markerstr keyword argument

seems the right way to go. It would override the marker argument,

and any string could be used, getting rid of the above problem.

Cheers,

Alan Isaac

(just a user)

What if you want to use the letter ‘o’ as a marker? That to me seems

like a potential source of confusion, as well as a little bit limiting.

What would the escaping syntax be to use the letter ‘o’?

As you suggest, adding an additional kwarg is also a way forward. In

that case, though, I would suggest that providing both a marker and

markerstr argument should raise an exception. Having implicit

overriding rules can often lead to confusion.

One downside of the additional kwarg is that you occasionally see code

like this:

markers = [‘o’, ‘.’, ‘h’, ‘x’]

for data, marker in zip(datasets, markers):

plot(data, marker=marker)

If one wanted to mix built-in with non-built-in markers that idiom would

become much more complex. That’s why I proposed sticking to a purely

string representation – I’m just not sure of the best or most obvious one.

To me it seems like having only one keyword “marker” is easier for the sake of simplicity as you have already demonstrated with an example. (Having one keyword to handle all special markers, unicode symbols and strings.) However probably this will need more coding to handle all the cases properly.

···

On Mon, Mar 1, 2010 at 8:36 AM, Michael Droettboom <mdroe@…878…86…> wrote:

On 3/1/2010 8:33 AM, Michael Droettboom wrote:

Mike

–

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

Download Intel® Parallel Studio Eval

Try the new software tools for yourself. Speed compiling, find bugs

proactively, and fine-tune applications for parallel performance.

See why Intel Parallel Studio got high marks during beta.

http://p.sf.net/sfu/intel-sw-dev

Matplotlib-users mailing list

Matplotlib-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users

–
Gökhan