matplotlib-devel Mailing List for matplotlib (Page 517)

John Hunter wrote:

>As mentioned, selecting charmap 0 is suppose to select a unicode
>character map, and apparently charmap 2 is such a map.  So you have
>\alpha in a bunch of different styles (plain, bold, italic, etc -- how
>to deal with all of this choice in the context of TeX/mathtext fonts
>like rm, it, tt etc is where some of the artistry referred to above
>comes in).  
>  
>
I would think the font_manager should be able to help you here, at least 
for the 'rm' and'it' styles.  The font_manager tries to provide such 
information with the .style attribute.  The 'tt' style is the big 
problem, since this requires a fixed width font. TTF fonts don't provide 
this information.  It must be known beforehand or somehow deduced by 
reading the widths of the characters, if one is to do this in the 
general sense.  The other option is to hardcode it into MPL.  You 
probably know this already, but thought I should mention it anyway.

 -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

John Hunter wrote:

> So some creative ways to handles these cases will have to be devised;
> a good start would be to google search
> 
>   tex unicode

Also

   tex mathml

since the MathML people have to deal with the same problem.

> and do a little reading to get the lay of the land.  There have been
> previous efforts at mapping characters between TeX and unicode, and
> I've worked on this before (see below).  Also, search the archives for
> any posts by Robert Kern on the issue of mathtext --- they are all
> filled with sage advice and wonderful links that you will never find
> even if you google for 1000 years.  Unfortunately, the sourceforge
> search engine is as sucky as their stats engine, so finding these
> posts may be difficult.

But Gmane is pretty good.

http://search.gmane.org/search.php?query=tex&email=kern&group=gmane.comp.python.matplotlib.general&sort=date

And couple useful tidbits that I sent privately:

"""There's some information here to go from various TeX font encodings 
to Unicode:
http://cvs.sourceforge.net/viewcvs.py/xdvi/xdvik/texk/xdvik/encodings.c?rev=1.13.2.14&view=markup

They claim some parts of it are GPLed from the catdvi project. I'm not 
sure if one can copyright this kind of information; how much creative 
choice is involved? But it might be worth asking the relevant 
individuals for permission.
"""

"""If you want to use the algorithms from _TeX: The Program_, I would 
suggest that you take a look at the publications of Luca Padovani, the 
implementor of GtkMathView. He describes how he uses, more or less, the 
TeX algorithms without the extra information provided by fonts designed 
for use in TeX.

MathML formatting with TeX rules, TeX fonts, and TeX quality
http://www.tug.org/TUGboat/Articles/tb24-1/padovani.pdf

PhD thesis: MathML Formatting
http://www.cs.unibo.it/~lpadovan/phd/main.pdf
"""

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> Let me make sure I understand this. If we map mathtext
    Darren> characters to unicode, and use freefont for now, will that
    Darren> help prepare MPL for STIX fonts? If there is an option
    Darren> available now that moves MPL in the direction of a
    Darren> permanent solution, then it seems like the decision is
    Darren> already made. 

What follows is a long post of getting unicode fonts to work with
mathtext, which is a very important goal.  But there is another goal
which is also important that may serve your thesis needs well: the
ability to farm out text handling to TeX/LaTeX, either for ps or png
using dvitopng.  

Now, on to the unicode question.

In principle we should be able to substitute any set of unicode fonts
with any other, since they will all use the same encoding.  Last time
I looked into replacing the bakoma fonts I spent a while looking at
the umbelleek fonts, but I came to the conclusion that they do not use
a unicode encoding, despite their author's later advocacy of unicode

  http://www.tug.org/TUGboat/Articles/tb19-3/tb60kinch.pdf

So I think freefont is a better path to pursue (I wasn't aware of
these until reading Baptiste's post); even though they are GPLd, they
will ease the path to integration with other unicode fontsets later

    Darren> Can we come up with some kind of a plan or
    Darren> design document for what steps we need to take? I will
    Darren> pick at it after work, if I understand what needs to be
    Darren> done.

I am happy to help, offer advice and pointers and so on, but there is
no definite set of steps I can lay out.  The person who has their
boots on wading through the mud will have to make many of these
decisions.  There is no 1-to-1 mapping between TeX symbols and
unicode.  Most unicode symbols (ancient cypriot) have no TeX
equivalent and many TeX symbols have no unicode equivalent (eg there
is no unicode symbol for each of \sqrt, \Sqrt, \SQRT)

So some creative ways to handles these cases will have to be devised;
a good start would be to google search

  tex unicode

and do a little reading to get the lay of the land.  There have been
previous efforts at mapping characters between TeX and unicode, and
I've worked on this before (see below).  Also, search the archives for
any posts by Robert Kern on the issue of mathtext --- they are all
filled with sage advice and wonderful links that you will never find
even if you google for 1000 years.  Unfortunately, the sourceforge
search engine is as sucky as their stats engine, so finding these
posts may be difficult.

    Darren> Now that the new formatter is complete, I have to find new
    Darren> ways to procrastinate. I will defend in August.

Hmm, in my experience, the having nothing to do is only the 2nd best
motivator for working on an open source project.  The best one, of
course, is having a dissertation you should be working on.  I'll try
and keep up with you :-)

Included below is a hodge-podge of some stuff I drudged out of my
examples and test directories related to fonts, mathtext and unicode
-- collectively they provide the tools required to put all these
pieces together.  

The following is a script to parse a unicode -> text mapping found at
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/ -- grab the file TeX.txt
and run this script on it.  The code parses that file builds a
dictionary from TeX->unicode

items = []

for line in file('TeX.txt'):
    line = line.strip()
    if not line.find('\\\\'): continue
    vals = line.split('\t')
    for val in vals:
        tup = val.split(' ')
        if len(tup)!=2: continue
        code, sym = tup
        if not sym.startswith('\\'): continue
        items.append((sym, code))


for k,v in items:
    o = ord(v.decode('utf-8'))
    
    #print k,v,o, hex(o)
    print "    r'%s' : %d," % (k, o)


and generates output like

peds-pc311:~/python/mplsupport/test> python parse_tex.py 
    r'\alpha' : 945,
    r'\iota' : 953,
    r'\varrho' : 1009,
    r'\beta' : 946,
    r'\kappa' : 954,
    r'\sigma' : 963,

which you can use to create a dictionary mapping tex syms to unicode
indices.  You can save this dictionary as a _mathtext_data dict, for
use by the mathtext module.

The next task is to take a set of fonts and build a mapping from
unicode index to fontname, glyph index.  This will require some
mastery of ft2font.  Last time I was working on this I wrote
examples/font_indexing.py, mainly as a reminder to myself, on how to
use the module to extract the relevant information from font files,
character names, glyph indexes and character codes.  I now wish I had
added more comments <wink>.  You may want to try this example, read
over it, and make sure you understand what it is doing (add comments
as you learn and commit the updates to CVS).

Many fonts have multiple character maps.  Normally the 0 charmap is
unicode if there is a unicode char map.  Let's look at the freefont
files and see how we can use the ft2font to find the font with \alpha
(should be at character code 945 from the results above).  Below is
some code I wrote to iterate over a list of ttf files and print the
character codes, glyph indices and character names contained in those
files.  I'm running this over all the fonts in the freefont dirs and
grepping for 945 and alpha to eliminate the noise

  test> python find_unicode_texsyms.py /usr/share/fonts/truetype/freefont/*.ttf|grep 945|grep alpha 

produces the following output

  FreeMonoBoldOblique.ttf 0 447 945 alpha
  FreeMonoBoldOblique.ttf 2 447 945 alpha
  FreeMonoBold.ttf 0 612 945 alpha
  FreeMonoBold.ttf 2 612 945 alpha
  FreeMonoOblique.ttf 0 651 945 alpha
  FreeMonoOblique.ttf 2 651 945 alpha
  FreeMono.ttf 0 679 945 alpha
  FreeMono.ttf 2 679 945 alpha
  FreeSansBoldOblique.ttf 0 394 945 alpha
  FreeSansBoldOblique.ttf 2 394 945 alpha
  FreeSansBold.ttf 0 438 945 alpha
  FreeSansBold.ttf 2 438 945 alpha
  FreeSansOblique.ttf 0 457 945 alpha
  FreeSansOblique.ttf 2 457 945 alpha
  FreeSans.ttf 0 570 945 alpha
  FreeSans.ttf 2 570 945 alpha
  FreeSerifBoldItalic.ttf 0 546 945 alpha
  FreeSerifBoldItalic.ttf 2 546 945 alpha
  FreeSerifBold.ttf 0 530 945 alpha
  FreeSerifBold.ttf 2 530 945 alpha
  FreeSerifItalic.ttf 0 527 945 alpha
  FreeSerifItalic.ttf 2 527 945 alpha
  FreeSerif.ttf 0 566 945 alpha
  FreeSerif.ttf 2 566 945 alpha

As mentioned, selecting charmap 0 is suppose to select a unicode
character map, and apparently charmap 2 is such a map.  So you have
\alpha in a bunch of different styles (plain, bold, italic, etc -- how
to deal with all of this choice in the context of TeX/mathtext fonts
like rm, it, tt etc is where some of the artistry referred to above
comes in).  

Below is the code that generated this output -- hopefully it will give
you some more insight into how to use ft2font [BTW, if you take this
on, it would be really helpful if right now you open a notes file and
start a tutorial to self about what you are learning.  I have to
relearn this stuff myself every time I work on it (and I wrote most of
the font code and the examples).  There is no better time to write
helpful documentation than when learning.  Someone may have to do this
again one day, and that someone may be you!]

import sys, os
from glob import glob
from matplotlib.font_manager import fontManager
from matplotlib.ft2font import FT2Font
from matplotlib.cbook import reverse_dict

for fname in sys.argv[1:]:

    #for fname in fontManager.ttffiles:
    font = FT2Font(fname)
    print 'loaded', fname, font.num_charmaps
    for i in range(font.num_charmaps):
        font.set_charmap(i)
        cmap = font.get_charmap()
        items = cmap.items()
        items.sort()
        fname = os.path.split(fname)[-1]
        for gind, code in items:
            name = font.get_glyph_name(gind)
            print fname, i, gind, code, name

 
OK, so now we have some mappings from TeX -> unicode and some idea of
how to map unicode symbols tofont names and glyph indices.  Another
tool which you can look at to understand font handling and glyph
rendering is in the mpl examples dir.  The following builds a standard
font table in a plot window

  examples> ./font_table_ttf.py /usr/share/fonts/truetype/freefont/FreeSans.ttf

This should be enough for tonight :-).  We can talk by phone tomorrow
if you think it would help, or you can post questions here.  It's good
to get some of this on record.  I've spent many hours working on this
problem, but have never had the time and stamina to see it through.
mathtext in matplotlib has a lot of promise but the current
implementation is not satisfactory.  Getting a good set of unicode
fonts working would be a significant step forward.

Thanks!
JDH

On Wednesday 04 May 2005 3:45 pm, John Hunter wrote:
>     >> To fix this one should get the kerning information from the
>     >> font, and do the kerning manually.  Have a look at dvips output
>     >> to get inspiration.
>
> We could go the route of embedding type1 fonts and using afm files for
> layout -- this wouldn't be too hard.  But our energy might be best
> served by converting the mathtext data tables to map text characters
> to unicode and then using a set of unicode fonts, using freefont for
> now (GPLd I think)
>
>  
> http://sourceforge.net/mailarchive/forum.php?thread_id=7090823&forum_id=361
>87
>
> and STIX fonts when they are done 

Let me make sure I understand this. If we map mathtext characters to unicode, 
and use freefont for now, will that help prepare MPL for STIX fonts? If there 
is an option available now that moves MPL in the direction of a permanent 
solution, then it seems like the decision is already made. Can we come up 
with some kind of a plan or design document for what steps we need to take? I 
will pick at it after work, if I understand what needs to be done.

> I realize you have a thesis to print, so hopefully we can figure out a
> smooth path to success soon!  When do you need to turn that thing in?

Now that the new formatter is complete, I have to find new ways to 
procrastinate. I will defend in August.

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:

    Marcin> On Wed, 4 May 2005, John Hunter wrote:
    >> I don't like the idea of making the label a string or None,
    >> because it leads to code that is difficult to maintain and may
    >> break existing code that relies on the label to be a string.  I
    >> would be amenable to using a sentinel string, such as
    >> '_nolegend_' or something like that.

    Marcin> Ok, it would also work well for me.

OK, could you resend a patch against CVS?

    Marcin> BTW when I was reading mpl docs I stopped for a while on
    Marcin> description of 'hold'. I'm not used to Matlab and didn't
    Marcin> understand what is "hold state".  (I found it out in
    Marcin> Matlab docs).


When hold is True, subsequent plot commands will be added to the
current axes.  When hold is False, the current axes and figure
will be cleared on the next plot command

There are many ways to manipulate the hold state.  You can call the
pylab (or Axes) "hold" function with a boolean.  You can pass hold as
a kwarg to a plot command to temporarily override the default.  And
you can set the default value in your rc file.

For example, suppose you have hold=False in rc.  Then every plot
command will clear the previous one.  But you may want to add a new
overplot

  plot([1,2,3])
  plot([2,4,6], hold=True)  # overplot

The default rc file that ships with matplotlib already has hold : True
be default (matlab is hold False by default).

You can query the hold state with ishold.


    Marcin> And if I could say what features I'm lacking most in MPL,
    Marcin> it would be: 1. plotting a function like in, say, gnuplot,
    Marcin> without using arange() 2. something like wxPython demo,
    Marcin> that contains all the examples


 1) Would definitely be nice -- we've talked about it.

 2) Have you seen the examples directory in the matplotlib src
    distribution, and is also available here
    http://matplotlib.sourceforge.net/matplotlib_examples_0.80.zip ?
    Or do you mean something else?


JDH

On Wed, 4 May 2005, John Hunter wrote:

> I don't like the idea of making the label a string or None, because it
> leads to code that is difficult to maintain and may break existing
> code that relies on the label to be a string.  I would be amenable to
> using a sentinel string, such as '_nolegend_' or something like that.

Ok, it would also work well for me. 

BTW when I was reading mpl docs I stopped for a while on description of 
'hold'. I'm not used to Matlab and didn't understand what is "hold state".
(I found it out in Matlab docs).

And if I could say what features I'm lacking most in MPL, it would be: 
1. plotting a function like in, say, gnuplot, without using arange()
2. something like wxPython demo, that contains all the examples

Thanks for your work,
Marcin

-- 
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr/

Sounds good.  I'll take a look at it tomorrow (Thursday).

Ted

At 02:48 PM 5/4/2005, John Hunter wrote:
> >>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
>
>     Fernando> With these changes and the corresponding ones to ipython
>     Fernando> (not in CVS yet, give me a day or two), it becomes
>     Fernando> possible to use ipython to interactively drive Qt
>     Fernando> applications, including matplotlib interactive plotting
>     Fernando> with the QtAgg backend.
>
>Hey guys thanks for working on this -- Ted and colleagues at JPL, if
>you haven't used ipython for interactive plotting with mpl, it is very
>nice, and I definitely recommend giving it a try when Fernando gets
>his changes in CVS.  Could you all look over this patch and make sure
>it doesn't conflict with anything your group is doing with the qt
>backend and if it looks good to you I'll merge it in.
>
>JDH
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.
>Get your fingers limbered up and give it your best shot. 4 great events, 4
>opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> With these changes and the corresponding ones to ipython
    Fernando> (not in CVS yet, give me a day or two), it becomes
    Fernando> possible to use ipython to interactively drive Qt
    Fernando> applications, including matplotlib interactive plotting
    Fernando> with the QtAgg backend.

Hey guys thanks for working on this -- Ted and colleagues at JPL, if
you haven't used ipython for interactive plotting with mpl, it is very
nice, and I definitely recommend giving it a try when Fernando gets
his changes in CVS.  Could you all look over this patch and make sure
it doesn't conflict with anything your group is doing with the qt
backend and if it looks good to you I'll merge it in.

JDH

Hi all,

Denis Rivi=E8re <nu...@fr...>, Yann Cointepas <ya...@sa...> and B=
enjamin=20
Thyreau <Be...@de...> recently worked on some enhancements to ip=
ython=20
to support Qt threading (like we do for GTK and WX).  In the process, the=
y=20
made some fixes to the Qt backend and sent me this, which I hope the powe=
rs=20
that be can take a look at and include before the CVS tree diverges too f=
ar.

With these changes and the corresponding ones to ipython (not in CVS yet,=
 give=20
me a day or two), it becomes possible to use ipython to interactively dri=
ve Qt=20
applications, including matplotlib interactive plotting with the QtAgg ba=
ckend.

Cheers,

f

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:


    Marcin> Proposition of the patch is attached.

OK, I've added this to my local tree and it will make it into CVS
before too long.  Those with an interest in tk, gtk, qt might want to
consider a similar patch to those backends.


    Marcin> BTW could you have a look at
    Marcin> http://sourceforge.net/mailarchive/forum.php?thread_id=7056275&forum_id=36187
    Marcin> Does it makes a sense?

Sorry I didn't respond earlier -- a combination of being out of the
country in combination with a hard-drive failure have left me in
catch-up mode.  Thanks for the reminder

I don't like the idea of making the label a string or None, because it
leads to code that is difficult to maintain and may break existing
code that relies on the label to be a string.  I would be amenable to
using a sentinel string, such as '_nolegend_' or something like that.

JDH

On Sun, 1 May 2005, John Hunter wrote:

>     Marcin> And last thing: what do you think about making toolbar2
>     Marcin> more hmm..  interactive(?), i mean disabled back/forward
>     Marcin> buttons whan there is no history, pressed pan/zoom buttons
>     Marcin> when in pan/zoom mode etc?  I don't know if I'll try to do
>     Marcin> it, but if someone would do it, would it be included in
>     Marcin> MPL?
> 
> Yes, this would be nice.  I think fltk already does this.  It's mainly

I haven't installed fltk, but had a look at code, and I think it does
toggled pan/zoom buttons, but not enabled/disabled back/forward.

> a matter of getting to this to work on each and every backend.  I
> think Steve and I both looked at this for gtk, but couldn't an easy
> way to do this.  Part of the problem, I think, is that mpl is using
> custom images for these buttons and it wasn't clear to me how to
> indicate "pressed" status with button relief, etc...  Patches gladly
> accepted.

Proposition of the patch is attached. 

BTW could you have a look at 
http://sourceforge.net/mailarchive/forum.php?thread_id=7056275&forum_id=36187
Does it makes a sense?

Marcin

-- 
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr/

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    >> To fix this one should get the kerning information from the
    >> font, and do the kerning manually.  Have a look at dvips output
    >> to get inspiration.

Now that we understand the problem, we have two options.

  * We can manually do the kerning in draw_text for the truetype
    fonts.  This won't be hard because we can just follow the example
    of draw_unicode with minor modifications.  This will be a little
    slower and make ps files a little bigger, but will look the best.

  * we can add a kwarg to font.get_width_height() to ignore kerning
    information, and backend ps can call
    font.get_width_height(kerning=False). 


    Darren> I also had a look at the dvips output, and get the general
    Darren> idea of how it handles layout. So let me ask, why does
    Darren> mathtext break with afm fonts? Is it inherent, or could
    Darren> mathtext.py (or backend_ps.py) be changed to cooperate
    Darren> with afm? From looking at the dvips output, a naive
    Darren> individual like myself might think it is pretty straight
    Darren> forward to render something like r'My test string
    Darren> $A=A_0e^(i\theta)$'.  (I'm not saying it would be easy to
    Darren> implement.)

    Darren> Dvips embeds four fonts to render my example string:
    Darren> CMMI7, CMR7, CMMI10, CMR10. Here is the output, I clipped
    Darren> the start of the file up to the end of the font defs:

I started working with AFM fonts in my initial implementation of
mathtext, but before I got too far Paul took on the task of porting
mathtext to PS and decided to embed the truetype fonts.  This has the
advantage of having your postscript figure and screen figure look
nearly identical and also just gives us a single point of maintenance
in the mathtext module.  But there are problems as well, as you've
noticed

  * the bakoma fonts suck in my opinion, some glyphs render poorly.
    Paul and I were never able to figure out how the vertical offsets
    in cmex worked, they have licensing problems

  * the use of bakoma fonts for mathtext and other fonts for the rest
    of the figure looks bad, and may be unacceptable for publication.
    One solution is to use cmr as your default font (set the rc param)
    but then see the problem above.


We could go the route of embedding type1 fonts and using afm files for
layout -- this wouldn't be too hard.  But our energy might be best
served by converting the mathtext data tables to map text characters
to unicode and then using a set of unicode fonts, using freefont for
now (GPLd I think)

  http://sourceforge.net/mailarchive/forum.php?thread_id=7090823&forum_id=36187

and STIX fonts when they are done http://www.stixfonts.org (which
should be just a few months according to their web site, but then
again their FAQ says "The STIX Fonts will not be completed until some
time in 2003" so we should be cautious....)

See also 

  http://www.mozilla.org/projects/mathml/fonts/


I realize you have a thesis to print, so hopefully we can figure out a
smooth path to success soon!  When do you need to turn that thing in?

JDH

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:
> Hi Darren,
>
> On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> > I assigned the PS bug to myself. If anyone has some insight, I could
> > definitely use it.
>
> Sorry, I do not have much time at the moment, but I remember
> something: the PostScript driver always got the horizontal text
> extents slightly wrong, because PostScript seems to not do kerning by
> itself.  It is a small effect, but visible.  This is especially
> visible when comparing strings like "AAAAA" and "AVAVAV".  Is this
> what you are seeing?
>
> To fix this one should get the kerning information from the font,
> and do the kerning manually.  Have a look at dvips output to get
> inspiration.

I just finished reading Adobe's Technical Note #5012: The Type 42 Font Format 
Specification. The only mention of kerning is on page 12, indicating that 
performance can be improved by including only those type 42 tables that are 
actually used by the TrueType rasterizer. It implies that kerning tables are 
not used.

I also had a look at the dvips output, and get the general idea of how it 
handles layout. So let me ask, why does mathtext break with afm fonts? Is it 
inherent, or could mathtext.py (or backend_ps.py) be changed to cooperate 
with afm? From looking at the dvips output, a naive individual like myself 
might think it is pretty straight forward to render something like 
r'My test string $A=A_0e^(i\theta)$'. 
(I'm not saying it would be easy to implement.)

Dvips embeds four fonts to render my example string: CMMI7, CMR7, CMMI10, 
CMR10. Here is the output, I clipped the start of the file up to the end of 
the font defs:

>%%EndFont 
>TeXDict begin 40258431 52099146 1000 600 600 (temp.dvi)
>@start /Fa 150[23 86[32 18[{}2 58.1154 /CMMI7 rf /Fb
>207[33 48[{}1 58.1154 /CMR7 rf /Fc 154[39 35[62 65[{}2
>83.022 /CMMI10 rf /Fd 134[44 4[32 33 33 3[46 4[23 1[42
>1[37 23[76 15[65 11[42 49[{}11 83.022 /CMR10 rf end
>%%EndProlog
>%%BeginSetup
>%%Feature: *Resolution 600dpi
>TeXDict begin
> end
>%%EndSetup
>%%Page: 1 1

I'm not sure what that first block is doing (yet), but here is the important 
part:

>TeXDict begin 1 0 bop 639 523 a Fd(My)28 b(test)g(string)f
>Fc(A)c Fd(=)g Fc(A)1420 535 y Fb(0)1457 523 y Fc(e)1496
>493 y Fa(i\022)1926 5255 y Fd(1)p eop end

Its essentially a group of moveto statements and font changes. It looks like 
the kerning support is sort of a hybrid, where you dont have to layout each 
glyph independently, but layout is done manually between groups of glyphs.

I guess I havent considered rendering in AGG.

Darren

Hi,

I have installed matplotlib-0.80 on WinXP and when I run a Python script 
that calls pylab.plot
several times after a while the program ends with the error message 
listed below. I inserted some print statements into backend_agg.py and 
text.py (code snippets see below). As far as I can see the problem is 
with the function xy_tup that returns (70.0555555556, -3509680569.77) 
when given the input (-0.030476944389471572, -0.012864052691159839).

My workaround is to set:

try:
    self._renderer.draw_text(font, int(x), int(y), gc)
except:
    pass

in backend_agg.py

Is there anything I can do instead to avoid this error message?

With kind regards

Rolf Wester

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

text.py

    def draw(self, renderer):
        ...
       
        bbox, info = self._get_layout(renderer)
->      print "draw ", info,
        for line, wh, x, y in info:
            x, y = self._transform.xy_tup((x, y))
->          print x,y," / ",
            #renderer.draw_arc(gc, (1,0,0),
            #                  x, y, 2, 2, 0.0, 360.0)

            if renderer.flipy():
                canvasw, canvash = renderer.get_canvas_width_height()
                y = canvash-y
->              print y, canvash
           
            renderer.draw_text(gc, x, y, line,
                               self._fontproperties, angle,
                               ismath=self.is_math_text())

------------------------------------------------
backend_agg.py:

    def draw_text(self, gc, x, y, s, prop, angle, ismath):
        """
        Render the text
        """
        if __debug__: verbose.report('RendererAgg.draw_text', 
'debug-annoying')

        if ismath:
            return self.draw_mathtext(gc, x, y, s, prop, angle)

        font = self._get_agg_font(prop)
        if font is None: return None
        if len(s)==1 and ord(s)>127:

            font.load_char(ord(s))
        else:
            font.set_text(s, angle)
        font.draw_glyphs_to_bitmap()
->     print font, int(x), int(y), gc
        self._renderer.draw_text(font, int(x), int(y), gc)

--------------------------------------------------------------
Shell

...

draw  [('0', (7.0, 10.0), -0.030476944389471572, -0.012864052691159839)] 
70.0555555556 -3509680569.77  /  3509681061.77 492.0
<FT2Font object at 0x0132DEAC> 70 3509681061 
<matplotlib.backend_bases.GraphicsContextBase instance at 0x1B340F80>

Traceback (most recent call last):
  File "E:\work\trumpf\kaustikopti6659mmAK2ma.py", line 238, in -toplevel-
    intensity_nf, intensity_ff = opt_resonator_online(GRIDLIST,  OELIST, 
outcoupler, SEQUENCELIST1, SEQUENCELIST2, no_fc, init_kind, nit, nav, 
verbose=verbose, plot = plot, genplot = gen_plot)
  File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_resonator.py", 
line 473, in opt_resonator_online
    if plot: genplot.plot_slice(fc_outcouple, ifigure = 2, clear = 
'yes', nr = 1, nc = 2, nf = 1, slice = 1, xlabel = '$r$',    i=0,  
ylabel = '$Intensity$', title =  '$nearfield$')
  File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_graphics.py", 
line 507, in plot_slice
    xlabel = xlabel, ylabel = ylabel, title =  title)
  File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_graphics.py", 
line 560, in plot_slice_matplotlib
    pylab.plot(x,xslice)
  File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\pylab.py", 
line 1900, in plot
    draw_if_interactive()
  File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 58, in draw_if_interactive
    figManager.show()
  File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 292, in show
    self.canvas.draw()
  File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 146, in draw
    FigureCanvasAgg.draw(self)
  File 
"D:\PROGLA~1\Python23\lib\site-packages\matplotlib\backends\backend_agg.py", 
line 312, in draw
    self.figure.draw(renderer)
  File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\figure.py", 
line 395, in draw
    for a in self.axes: a.draw(renderer)
  File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axes.py", line 
1362, in draw
    self.yaxis.draw(renderer)
  File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axis.py", line 
524, in draw
    tick.draw(renderer)
  File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axis.py", line 
141, in draw
    if self.label1On: self.label1.draw(renderer)
  File "D:\PROGLA~1\Python23\lib\site-packages\matplotlib\text.py", line 
332, in draw
    ismath=self.is_math_text())
  File 
"D:\PROGLA~1\Python23\lib\site-packages\matplotlib\backends\backend_agg.py", 
line 211, in draw_text
    self._renderer.draw_text(font, int(x), int(y), gc)
TypeError: CXX: type error.
 >>>

-- 
-------------------------------------
Rolf Wester
rol...@il...

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:
> Hi Darren,
>
> On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> > I assigned the PS bug to myself. If anyone has some insight, I could
> > definitely use it.
>
> Sorry, I do not have much time at the moment, but I remember
> something: the PostScript driver always got the horizontal text
> extents slightly wrong, because PostScript seems to not do kerning by
> itself.  It is a small effect, but visible.  This is especially
> visible when comparing strings like "AAAAA" and "AVAVAV".  Is this
> what you are seeing?
>
> To fix this one should get the kerning information from the font,
> and do the kerning manually.  Have a look at dvips output to get
> inspiration.

Hi Jochen,

Thanks for responding. I'll continue looking into this tomorrow. For now, I 
posted a new eps file in the sourceforge bugreport, which renders the 
suggested strings. You are right, the effect is especially visible when 
rendering 'AVAVAV'.

By the way, did you know MoonBuggy is in the gentoo package management tree?

-- 
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd...@co...

Hi Darren,

On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> I assigned the PS bug to myself. If anyone has some insight, I could=20
> definitely use it.
Sorry, I do not have much time at the moment, but I remember
something: the PostScript driver always got the horizontal text
extents slightly wrong, because PostScript seems to not do kerning by
itself.  It is a small effect, but visible.  This is especially
visible when comparing strings like "AAAAA" and "AVAVAV".  Is this
what you are seeing?

To fix this one should get the kerning information from the font,
and do the kerning manually.  Have a look at dvips output to get
inspiration.

All the best,
Jochen
--=20
http://seehuhn.de/

On May 3, 2005, at 6:11 PM, John Hunter wrote:

>>>>>> "Darren" == Darren Dale <dd...@co...> writes:
>     Darren> I'm amazed at the amount of effort required to handle
>     Darren> fonts properly.
>
> Deranged scientist in Chicago laughs maniacally....
>

It's not much appreciated that handling fonts well is one of the 
hardest aspects of any multiplatform plotting package (at least that's 
what I think).

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> If anyone can offer advice, I am a little desperate. Half
    Darren> of my plots are logscale, so I need to fix this in order
    Darren> to generate figures for my thesis.  Is there anywhere I
    Darren> can look to learn the basics of dealing with fonts at this
    Darren> level? Any recommendations on C++ crash courses?

I have an idea -- it may be that the freetype module and postscript
are handling kerning differently.  If for some reason freetype is
applying more kerning than the postscript machine you are rendering
with, then the bounding boxes will be smaller than the rendered ps
text.  Consider this example -- the only difference between the two
strings is that in the unicode version I lay out the text character by
character and manually do the kerning myself (since postscript doesn't
have unicode I do the layout glyph-by-glyph basis)

  import pylab as p
  p.text(1,2,'AVA', fontsize=80, bbox={'pad':0})
  p.text(1,1,u'AVA', fontsize=80, bbox={'pad':0})
  p.grid()
  p.axis([0,3,0,3])
  p.savefig('test.png')
  p.savefig('test.ps')
  p.show()


The important point is that only in the regular text is the bounding
box wrong, which supports my hunch that there are different levels of
kerning in the default ps text.  

Is the kerning information getting embedded?

Do some research on embedded truetype fonts and postscript kerning and
see if anything turns up.


We might consider using the unicode layout engine for *all* text as a
quick fix.  We would pay a performance cost to do this, and it might
break numerical superscripting temporarily....

    Darren> I'm amazed at the amount of effort required to handle
    Darren> fonts properly.

Deranged scientist in Chicago laughs maniacally....

JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I have a little more information. When I set ps.useafm
    Darren> =True in .matplotlibrc, eps output looks good, there is no
    Darren> mismatch between the bboxes and the text.  I'm guessing
    Darren> the bug may be in either backend_ps.encodeTTFasPS, or
    Darren> somewhere in ft2font.h. Unfortunately, I have zarro
    Darren> experience with C++, so I'm having a hard time
    Darren> interpretting ft2font.

    Darren> If anyone can offer advice, I am a little desperate. Half
    Darren> of my plots are logscale, so I need to fix this in order
    Darren> to generate figures for my thesis.  Is there anywhere I
    Darren> can look to learn the basics of dealing with fonts at this
    Darren> level? Any recommendations on C++ crash courses?

I don't think the bug is in ft2font for the simple reason that the
same ft2font code is being used to do the agg layout and the ps
layout (and agg is pretty close to right).  It could be that we are
not setting the dpi and fontsize in backend ps, it could be that we
are not setting some scale parameter when we embed the fonts in ps,
I'm not sure.  Did you get a chance to send a figure to the printer
yet?

JDH

On Monday 02 May 2005 4:03 pm, Darren Dale wrote:
> It looks like there is a bug in the text bounding boxes. It causes some
> problems in the postscript backend, where I noticed badly formatted
> logscale ticks. It looks like the bug exists in the AGG backend as well,
> although it is less noticeable there. I filed two bugs at the sf website,
> with images of bboxes that dont fit their associated text. You can also run
> the script below, but you will need a recent update of patches.py, John
> fixed a bug there today.

I have a little more information. When I set ps.useafm =True in .matplotlibrc, 
eps output looks good, there is no mismatch between the bboxes and the text. 
I'm guessing the bug may be in either backend_ps.encodeTTFasPS, or somewhere 
in ft2font.h. Unfortunately, I have zarro experience with C++, so I'm having 
a hard time interpretting ft2font.

If anyone can offer advice, I am a little desperate. Half of my plots are 
logscale, so I need to fix this in order to generate figures for my thesis. 
Is there anywhere I can look to learn the basics of dealing with fonts at 
this level? Any recommendations on C++ crash courses?

-- 
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd...@co...

>>>>> "Zelakiewicz," == Zelakiewicz, Scott (Research) <zel...@cr...> writes:

    Scott> I routinely plot fairly large datasets (~4million
    Scott> points) using imshow but on my machine this takes
    Scott> about 11 secs to complete.  I went through the code
    Scott> and made a couple of minor changes where the image
    Scott> data would get clipped by vmax and vmin only if the
    Scott> user supplied a vmax or vmin.  The clipping is
    Scott> unnecessary if the user does not supply these values
    Scott> since vmax and vmin default to the max and min in
    Scott> the image.  I also replaced two successive
    Scott> where(...) calls with a single clip(...) call and
    Scott> that seems to have helped a tiny bit as well.  This
    Scott> change has been tested on 0.80 compiled with
    Scott> Numeric, though I can't envision how this would
    Scott> break anything.  The profiler tells me that my plot
    Scott> time has decreased from 11.8 sec to 7.2 sec.  Hope
    Scott> this helps.

Thanks Scott -- this simple optimization should help a lot with common
use cases.  I've applied it in my local tree (hasn't made CVS yet
because there are other more significant changes I'm working on that I
can't commit yet).

Thanks!
JDH

Hi Everyone,

There is a new formatter in ticker.py called NewScalarFormatter. If you have 
scientific notation in your plots, you may like the results. If you would 
like to try it out, you need to change ScalarFormatter->OldScalarFormatter, 
and NewScalarFormatter->ScalarFormatter. It will then be the default for 
linear scale axes. I would appreciate feedback, it will hopefully become the 
default at some point.

Darren

It looks like there is a bug in the text bounding boxes. It causes some 
problems in the postscript backend, where I noticed badly formatted logscale 
ticks. It looks like the bug exists in the AGG backend as well, although it 
is less noticeable there. I filed two bugs at the sf website, with images of 
bboxes that dont fit their associated text. You can also run the script 
below, but you will need a recent update of patches.py, John fixed a bug 
there today.

I assigned the PS bug to myself. If anyone has some insight, I could 
definitely use it.

Darren

http://sourceforge.net/tracker/index.php?func=detail&aid=1177396&group_id=80706&atid=560720

from pylab import *

def addtext(props):
    text(0.5, 0.5, 'xx-small', props, fontsize='xx-small')
    text(1.5, 0.5, 'x-small', props, fontsize='x-small')
    text(2.5, 0.5, 'small', props, fontsize='small')
    text(3.5, 0.5, 'medium', props, fontsize='medium')
    text(4.5, 0.5, 'large', props, fontsize='large')
    yticks([0,.5,1])

# the text bounding box
bbox = {'fc':0.8, 'pad':0} 

figure(1,figsize=(5,2))
axes()
addtext({'ha':'center', 'va':'center', 'bbox':bbox})
xlim(0,5)
savefig('/home/darren/temp/bbox.eps')
savefig('/home/darren/temp/bbox.png')
show()

Matt Newville wrote:

> For my apps, I provide interactivity by binding left-click to
> 'report x,y coords', left-down-and-drag (ie, move more than a
> few pixels) to 'Zoom to Rectangle', and have right-click bring
> up a pop-up menu with 'zoom back 1 level', 'zoom back to full
> view', and 'save image', among other things.  That makes the

I'll think about it, perhaps its a better solution. With 3 buttons
and 1 wheel most of actions can be easily accessed.

> I do think it would be possible to come up with yet another
> binding mode (toolbar, toolbar2, ... no_toolbar, or toolbar0??),
> where the above behavior was provided.  I don't know if that
> would be considered generally useful or not.

Probably it will be useful for me.

Marcin

--=20
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr

John Hunter wrote:
>
> What do you mean by updating plot -- calling a plot command?  Calling

Yes

> "plot" and related functions does autoscale the axes -- is this the
> problem you are referring to?

Yes, that was the problem.

> It might be useful to add and
> autoscale=3DFalse option, much in the way we have a hold=3DTrue|False
> option, to the plot command, so one could issue a plot command w/o
> changing the current view lim.
>

Yes, but I would also like to allow user explicitly autoscale, ie. show
whole plot when when pressing home (or another) button.
So I don't want to change the current view lim when calling plot command,
but I want to know what the new data lims are, to be able to use it later=
.

Marcin

--=20
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr