matplotlib-devel Mailing List for matplotlib

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:

    Edin> Hi all, I have modified mathtext so it can use the fonts
    Edin> based on rcParams.  The new class is defined as follows:

    Edin> class MyUnicodeFonts(UnicodeFonts): prop =3D FontProperties()
    Edin> prop.set_family('serif') rmfile =3D fontManager.findfont(prop)

    Edin>     prop.set_family('fantasy') calfile =3D
    Edin> fontManager.findfont(prop)

    Edin>     prop.set_family('monospace') ttfile =3D
    Edin> fontManager.findfont(prop)

    Edin>     prop.set_family('serif') prop.set_style('italic') itfile
    Edin> =3D fontManager.findfont(prop) filenamesd =3D { 'rm' : rmfile,
    Edin> 'it' : itfile, 'cal' : calfile, 'tt' : ttfile,
    Edin>                 }

    Edin> Is this OK?

One downside of this approach is that it generates a lot of warnings
on every script because the calls like

    prop =3D FontProperties()
    prop.set_family('serif')
    rmfile =3D fontManager.findfont(prop)

are done on import of the mathtext module, rather than on class
initialization.  You might do something like

class MyUnicodeFonts(UnicodeFonts):
    _initialized =3D False
    def __init__(self):
        if not MyUnicodeFonts._initialized:
            prop =3D FontProperties()
            prop.set_family('serif')
            self.rmfile =3D fontManager.findfont(prop)

            prop.set_family('fantasy')
            self.calfile =3D fontManager.findfont(prop)

            prop.set_family('monospace')
            self.ttfile =3D fontManager.findfont(prop)

            prop.set_family('serif')
            prop.set_style('italic')
            self.itfile =3D fontManager.findfont(prop)
            self.filenamesd =3D { 'rm'  : self.rmfile,
                                'it'  : self.itfile,
                                'cal' : self.calfile,
                                'tt'  : self.ttfile,
                                }
            MyUnicodeFonts._initialized =3D True

This defers the initialization until it is needed, and importantly
prevents users (like me) from getting warnings on *every* matplotlib
script (regardless of whether I use mathtext), like

/usr/lib/python2.4/site-packages/matplotlib/font_manager.py:987:
UserWarning: Could not match fantasy, normal, normal.  Returning
/usr/lib/python2.4/site-packages/matplotlib/mpl-data/Vera.ttf
  warnings.warn('Could not match %s, %s, %s.  Returning %s' % (name,
  style, variant, self.defaultFont))
/usr/lib/python2.4/site-packages/matplotlib/font_manager.py:987:
UserWarning: Could not match serif, italic, normal.  Returning
/usr/lib/python2.4/site-packages/matplotlib/mpl-data/Vera.ttf
  warnings.warn('Could not match %s, %s, %s.  Returning %s' % (name,
  style, variant, self.defaultFont))


    Edin> Now all the backends can work with the new mathtext, and on
    Edin> all platforms, and I haven't introduced a single bug.=20

A bold claim -- are you willing to back that up, as Knuth does, with
an offer of a financial reward for any bugs found?

    Edin> this now be commited to the svn?

It is committed (svn revision 2535), with the changes I suggested
above.  I also added you as a developer, so you should get a fresh svn
developer checkout and you can commit directly.  Be sure to modify the
CHANGELOG and API_CHANGES with your commits.

As you may know, you should avoid naming things like MyClass.  So for
your next patch, how about making the proposed rc changes that will
allow the users to select bakoma or some other set of mathtext fonts,
and rename MyUnicodeFonts.

Also, please provide some example code showing how to use mathtext on
an arbitrary backend (non Agg, non PS).  Me thinks there may be a bit
more work yet to be done, but you are definitely on the right track.

    Edin> I was wondering if it could be added to the matplotlibrc a
    Edin> key-value pair like "mathtext.usebakoma :True" or something,
    Edin> so someone who wants to try out the new mathtext can easily
    Edin> do so?

This looks OK for testing purposes -- we may want something more
generic going forward.

    Edin> Also John, will I now begin to work on adding new
    Edin> features/TeX commands to mathtext?

Well, let's get the rc and backend configuration issues settled, and
also see if we can find a good set of free unicode fonts that are
superior to bakoma that we could ship.

Thanks!
JDH

Hi all,

I have modified mathtext so it can use the fonts based on rcParams.
The new class is defined as follows:

class MyUnicodeFonts(UnicodeFonts):
    prop = FontProperties()
    prop.set_family('serif')
    rmfile = fontManager.findfont(prop)

    prop.set_family('fantasy')
    calfile = fontManager.findfont(prop)

    prop.set_family('monospace')
    ttfile = fontManager.findfont(prop)

    prop.set_family('serif')
    prop.set_style('italic')
    itfile = fontManager.findfont(prop)
    filenamesd = { 'rm'  : rmfile,
                'it'  : itfile,
                'cal' : calfile,
                'tt'  : ttfile,
                }

Is this OK?

Now all the backends can work with the new mathtext, and on all
platforms, and I haven't introduced a single bug. Can this now be
commited to the svn?


I was wondering if it could be added to the matplotlibrc a key-value
pair like "mathtext.usebakoma :True" or something, so someone who
wants to try out the new mathtext can easily do so?

Also John, will I now begin to work on adding new features/TeX
commands to mathtext?

Thanks,
Edin

Hi Jim,

On Wednesday 31 May 2006 11:51, James Amundson wrote:
> Hello,
>
> I have ported the existing Qt(3) backend to Qt4. Qt4 is a substantial
> change from Qt3; the Python bindings for Qt have also changed
> substantially. Since the two versions of Qt are likely to coexist for at
> least a while, I think it makes sense to have a separate Qt4 backend.
>
> How do I go about contributing my Qt4 backend? I have three files:
> backend_qt4.py, backend_qt4agg.py  and embedding in qt4.py.

I finally got around to the qt4agg backend today, and finished porting the 
files you submitted to work with qt4. It seems to be functioning, so I 
checked it in to svn as of 2529. Thank you for contributing!

Darren

So now you can choose between the old BaKoMa fonts and any Unicode fonts.

Unfortunately, I managed to get the PS filesize for the BaKoMa fonts
to be even bigger (over 2 MB for mathtext_demo.py). Can you see the
changes to backend_ps.py I made John, and comment?

However, the filesize is 1+ MB with the Times New Roman italic fonts
(MS, Unicode aware).

The StandardPSFonts (afm) don't seem to work, and it's not because the
changes I made.

One naming question.
Is it OK to change the name of the classes like: Fonts -> FontBundle
etc.? It's much more intuitive IMO.

I have created a patch against the SVN. You can try changes I made by
uncommenting the appropriate lines in the function
math_parse_s_ft2font_common in mathtext.py, and you can change the
MyUnicodeFonts class by adding your fonts.

Does anyone now what fonts does OpenOffice use for its math stuff? And AbiWord?

Feel free to comment

Have fun,
Edin

I noticed that Axes.errorbar() was being unnecessarily called by 
Axes.bar(), due to improper handling of when xerr and yerr are passed as 
None (the default). I don't think it was causing any bad behaviour, but 
here's the patch nevertheless.

Cheers,

Martin

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:

    Edin> I got the SVG backend to work properly. The PS backend seems
    Edin> to be very tightly integrated with the current
    Edin> implementation of the Fonts classes so I haven't realy
    Edin> digged into it yet.

    Edin> This patch only adds four new files for converting TeX/Type1
    Edin> <-> Unicode, and the modified mathtext.py file.

A couple of comments

  * can we put all the dictionaries and data into a single file
    (_mathtext_data).  I would rather not have a proliferation of
    support modules for mathtext


  * do we really need dictionaries for tex2uni and uni2tex.  Would it
    not be better to define tex2uni and then do

     uni2tex =3D dict([(v,k) for k,v in tex2uni.items()])

JDH

SSBnb3QgdGhlIFNWRyBiYWNrZW5kIHRvIHdvcmsgcHJvcGVybHkuIFRoZSBQUyBiYWNrZW5kIHNl
ZW1zIHRvIGJlCnZlcnkgdGlnaHRseSBpbnRlZ3JhdGVkIHdpdGggdGhlIGN1cnJlbnQgaW1wbGVt
ZW50YXRpb24gb2YgdGhlIEZvbnRzCmNsYXNzZXMgc28gSSBoYXZlbid0IHJlYWx5IGRpZ2dlZCBp
bnRvIGl0IHlldC4KClRoaXMgcGF0Y2ggb25seSBhZGRzIGZvdXIgbmV3IGZpbGVzIGZvciBjb252
ZXJ0aW5nIFRlWC9UeXBlMSA8LT4KVW5pY29kZSwgYW5kIHRoZSBtb2RpZmllZCBtYXRodGV4dC5w
eSBmaWxlLgoKRmVlbCBmcmVlIHRvIHNldHVwIHRoZSBjbGFzcyBNeVVuaWNvZGVGb250cyB3aXRo
IHlvdXIgVW5pY29kZSBtYXRoCmZvbnQocyksIGFuZCB0aGVuIHVuY29tbWVudCB0aGUgY29yZXNw
b25kaW5nIGxpbmVzIGluIHRoZQptYXRoX3BhcnNlX3NfZnQyZm9udF9jb21tb24gY2xhc3MgdG8g
YWN0dWFsbHkgZW5hYmxlIHRoZQpNeVVuaWNvZGVGb250cyBjbGFzcyB0byBkbyBzb21ldGhpbmcg
dXNlZnVsLgoKQ2hlZXJzCkVkaW4KCk9uIDYvMjYvMDYsIEVkaW4gU2Fsa292acSHIDxlZGluLnNh
bGtvdmljQGdtYWlsLmNvbT4gd3JvdGU6Cj4gQXQgbGFzdCwgc29tZSByZWFsIHByb2dyZXNzIQo+
Cj4gSSBkb24ndCBoYXZlIGEgZnJlc2ggU1ZOIGNvIGF0IGhvbWUgKGFuZCBJIGhhdmUgYSBkaWFs
IHVwKSwgYnV0Cj4gdG9tb3Jyb3cgbW9ybmluZyBJJ2xsIHNlbmQgYSBwYXRjaCBhZ2FpbnN0IHRo
ZSBTVk4uCj4KPiBJIGZpeGVkIGEgYml0IHRoZSBVbmljb2RlRm9udHMgY2xhc3Mgc28gbm93IHRo
ZSByYXN0ZXIgKEFnZykgYW5kIFNWRwo+IG91dHB1dHMgd29yay4gU1ZHIG5lZWRzIGEgbGl0dGxl
IG1vcmUgZml4aW5nLgo+Cj4gSSBiYXNpY2FseSBkZWZpbmVkIGEgbmV3IGNsYXNzLCBiYXNlZCBv
biB0aGUgQXJpYWwgVW5pY29kZSBNUyBmb250Lgo+IGNsYXNzIEFyaWFsVW5pY29kZUZvbnRzKFVu
aWNvZGVGb250cyk6Cj4gICAgIGJhc2VwYXRoID0gcidDOlxXSU5ET1dTXEZvbnRzJwo+ICAgICBm
YWNlZmlsZWRpY3QgPSB7ICdjYWwnIDogJ0tVTlNUTEVSLlRURicsCj4gICAgICAgICAgICAgICAg
ICdybScgIDogJ3RpbWVzLnR0ZicsCj4gICAgICAgICAgICAgICAgICd0dCcgIDogJ2NvdXIudHRm
JywKPiAgICAgICAgICAgICAgICAgJ2l0JyAgOiAnQVJJQUxVTkkuVFRGJywKPiAgICAgICAgICAg
ICAgICAgTm9uZSAgOiAnQVJJQUxVTkkuVFRGJywKPiAgICAgICAgICAgICAgICAgfQo+Cj4gLi4u
YW5kIGp1c3QgdGhhdCEgRXZlcnl0aGluZyBlbHNlIGlzIGluaGVyaXRlZCBmcm9tIHRoZSBVbmlj
b2RlRm9udHMgY2xhc3MuCj4KPiBUaGVuIEkgcmFuIHRoZSBtYXRodGV4dF9kZW1vLnB5LiBUaGUg
cmVzdWx0cyBhcmUgYXR0YWNoZWQuCj4KPiBPbiA2LzI1LzA2LCBFZGluIFNhbGtvdmnEhyA8ZWRp
bi5zYWxrb3ZpY0BnbWFpbC5jb20+IHdyb3RlOgo+ID4gVGhpcyBpcyBhIGxvbmcgb25lLgo+Cj4K

QXQgbGFzdCwgc29tZSByZWFsIHByb2dyZXNzIQoKSSBkb24ndCBoYXZlIGEgZnJlc2ggU1ZOIGNv
IGF0IGhvbWUgKGFuZCBJIGhhdmUgYSBkaWFsIHVwKSwgYnV0CnRvbW9ycm93IG1vcm5pbmcgSSds
bCBzZW5kIGEgcGF0Y2ggYWdhaW5zdCB0aGUgU1ZOLgoKSSBmaXhlZCBhIGJpdCB0aGUgVW5pY29k
ZUZvbnRzIGNsYXNzIHNvIG5vdyB0aGUgcmFzdGVyIChBZ2cpIGFuZCBTVkcKb3V0cHV0cyB3b3Jr
LiBTVkcgbmVlZHMgYSBsaXR0bGUgbW9yZSBmaXhpbmcuCgpJIGJhc2ljYWx5IGRlZmluZWQgYSBu
ZXcgY2xhc3MsIGJhc2VkIG9uIHRoZSBBcmlhbCBVbmljb2RlIE1TIGZvbnQuCmNsYXNzIEFyaWFs
VW5pY29kZUZvbnRzKFVuaWNvZGVGb250cyk6CiAgICBiYXNlcGF0aCA9IHInQzpcV0lORE9XU1xG
b250cycKICAgIGZhY2VmaWxlZGljdCA9IHsgJ2NhbCcgOiAnS1VOU1RMRVIuVFRGJywKICAgICAg
ICAgICAgICAgICdybScgIDogJ3RpbWVzLnR0ZicsCiAgICAgICAgICAgICAgICAndHQnICA6ICdj
b3VyLnR0ZicsCiAgICAgICAgICAgICAgICAnaXQnICA6ICdBUklBTFVOSS5UVEYnLAogICAgICAg
ICAgICAgICAgTm9uZSAgOiAnQVJJQUxVTkkuVFRGJywKICAgICAgICAgICAgICAgIH0KCi4uLmFu
ZCBqdXN0IHRoYXQhIEV2ZXJ5dGhpbmcgZWxzZSBpcyBpbmhlcml0ZWQgZnJvbSB0aGUgVW5pY29k
ZUZvbnRzIGNsYXNzLgoKVGhlbiBJIHJhbiB0aGUgbWF0aHRleHRfZGVtby5weS4gVGhlIHJlc3Vs
dHMgYXJlIGF0dGFjaGVkLgoKT24gNi8yNS8wNiwgRWRpbiBTYWxrb3ZpxIcgPGVkaW4uc2Fsa292
aWNAZ21haWwuY29tPiB3cm90ZToKPiBUaGlzIGlzIGEgbG9uZyBvbmUuCg==

This is a long one.

The problem with the last patch I submitted was a no brainer.
Instead of:
math_parse_s_ft2font_ps = math_parse_s_ft2font_common('PS')
should have been:
math_parse_s_ps = math_parse_s_ft2font_common('PS')

I am now in the process of creating a UnicodeFonts class, and a
derived BakomaUnicodeFonts, which is a hack to add "unicode support"
to the
Bakoma fonts. Is BakomaUnicodeFonts worth of implementing?

I must say that I had a lot of problems in reading/understanding the code
of the current Fonts classes, especially regarding the ambiguous usage
of the word "font". I also tried to make a common parent class in order to
abstract the common properties of the BakomaTrueTypeFonts and
BakomaPSFonts classes (something along the way of what I did with the
math_parse_s_ft2font_common class), but I hit the wall - there was a lot
of black magic under the hood, IMHO.

So I decided to make naming changes in the new Unicode aware classes,
and that's the purpose of writing this email before I got the new classes to
work. So please John, do comment on this, because I don't know whether
I'm breaking something, and whether the names are chosen appropriately.

The changes I made, make no effect on the current code - that is, everything
still works. I'm sending you a patch against the SVN tree. I also added
the automatically genarated tex2uni etc. files, and they are now incorporated
in the patch.

What should we do with the script that generates those file. Should I try to
integrate it into the setup/build process?

These are the new imports:

from matplotlib.tex2uni import tex2uni
from matplotlib.type12uni import type12uni

These are the new top-level functions I defined in mathtext:

def font_open(filename):
    ext = filename.rsplit('.',1)[1]
    if ext == 'afm':
        return AFM(filename)
    else:
        return FT2Font(filename)

def get_unicode_index(symbol):
    """get_unicode_index(symbol) -> integer

Return the integer index from the Unicode table of an Unicode symbol
"""
    try:# This will succeed if symbol is a single unicode char
        return ord(symbol)
    except TypeError:
        pass
    try:# Is symbol a TeX symbol (i.e. \alpha)
        return tex2uni[symbol]
    except KeyError:
        pass
    try:# Is symbol a Type1 name (i.e. degree)? If not raise error
        return type12uni[symbol]
    except KeyError:
        message = """'%(symbol)s' is not a valid Unicode character or
TeX/Type1 symbol"""%locals()
        raise ValueError, message

And finally, these are the new classes:
====
class UnicodeFonts(Fonts):
    """An abstract base class for handling Unicode fonts.

Specific terminology:
 * fontface: an FT2Font object, corresponding to a facename
 * facename: a string that defines the (type)face's name - 'rm', 'it' etc.
 * filename: a string that is used for generating a fontface object
 * symbol*: a single Unicode character or a TeX command,
    or to be precise, a TeX symbol command like \alpha (but not \frac) or
    even a Type1/PS name
 * filenamesdict: a dict that maps the face's name to the filename:
    filenamesdict = { 'cal' : 'fontnamecal.ext',
                  'rm'  : 'fontnamerm.ext',
                  'tt'  : 'fontnamett.ext',
                  'it'  : 'fontnameit.ext',
                  None  : 'fontnamesmth.ext'}
    filenamesdict should be declared as a class atribute
 * glyphdict: a dict used for caching of glyph specific data
 * fontsdict: a dict of facename -> fontface pairs
 * charmaps: a dict of facename -> charmap pairs
 * glyphmaps: a dict of facename -> glyphmap pairs. A glyphmap is an
    inverted charmap
 * output: a string in ['BMP','SVG','PS'], coresponding to the backends
 * index: Fontfile specific index of a glyph/char. Taken from a charmap.

"""

    # The path to the dir with the fontfiles
    basepath = get_data_path()

    def __init__(self, output='BMP'):
        if output:
            self.output = output
        # dict self.glyphdict[key] = facename, metrics, glyph, offset
        self.glyphdict = {}

        self.fontsdict = dict(
            [ (facename, font_open(os.path.join(self.basepath,
                filenamesdict[facename]))) for facename in
                                                self.facenames])
        # a dict of glyphindex -> charcode pairs
        self.charmaps = dict(
            [ (facename, self.fontsdict[facename].get_charmap())\
                for facename in self.facenames])
        # a dict of charcode -> glyphindex pairs
        self.glyphmaps = {}
        for facename in self.facenames:
            charmap = self.charmaps[facename]
            self.glyphmaps[facename] = dict([(charcode, glyphind)
                for glyphind, charcode in charmap.items()])
        for fontface in self.fontsdict.values():
            fontface.clear()
        if self.output == 'SVG':
            # a list of "glyphs" we need to render this thing in SVG
            self.svg_glyphs=[]

    def set_canvas_size(self, w, h, pswriter=None):
        'Dimension the drawing canvas; may be a noop'
        # self.width = int(w)
        # self.height = int(h)
        # I don't know why this was different than the PS version
        self.width = w
        self.height = h
        if pswriter:
            self.pswriter = pswriter
        else:
            for fontface in self.fontsdict.values():
                fontface.set_bitmap_size(int(w), int(h))

    def render(self, ox, oy, facename, symbol, fontsize, dpi):
        filename = self.filenamesdict[facename]
        metrics, glyph, offset = self._get_info(facename, symbol, fontsize,
                                                                dpi)
        index = self._get_unicode_index(symbol)
        if self.output == 'SVG':
            oy += offset - 512/2048.*10.
            self.svg_glyphs.append((filename, fontsize, index, ox, oy,
                                                            metrics))
        elif self.output == 'PS':
            # This should be changed to check for math mode or smth.
            #if filename == 'cmex10.ttf':
            #    oy += offset - 512/2048.*10.
            psfontname = self.fontsdict[facename].postscript_name
            ps = """/%(psfontname)s findfont
%(fontsize)s scalefont
setfont
%(ox)f %(oy)f moveto
/%(glyphname)s glyphshow
""" % locals()
            self.pswriter.write(ps)
        else: # BMP
            fontface = self.fontsdict[facename]
            fontface.draw_glyph_to_bitmap(
            int(ox),  int(self.height - oy - metrics.ymax), glyph)

    def get_metrics(self, facename, symbol, fontsize, dpi):
        metrics, glyph, offset  = \
                self._get_info(facename, symbol, fontsize, dpi)
        return metrics

    def _get_unicode_index(self, symbol):
        return get_unicode_index(symbol)

    # Methods that must be overridden
    def _get_info(self, facename, symbol, fontsize, dpi):
        raise NotImplementedError('Derived must override')


class BakomaUnicodeFonts(UnicodeFonts):
    """A class that simulates Unicode support in the BaKoMa fonts"""

    filenamesdict = { 'cal' : 'cmsy10.ttf',
                'rm'  : 'cmr10.ttf',
                'tt'  : 'cmtt10.ttf',
                'it'  : 'cmmi10.ttf',
                }

    def _get_info(self, facename, symbol, fontsize, dpi):
        'load the facename, metrics and glyph'
        #print hex(index), symbol, filename, facename
        key = facename, symbol, fontsize, dpi
        tup = self.glyphdict.get(key)
        if tup is not None:
            return tup

        filename = self.fontmap[facename]
        # This is black magic to me (Edin)
        if self.output == 'PS':
            if filename not in bakoma_fonts:
                bakoma_fonts.append(filename)
        fontface = self.fontsdict[facename]
        fontface.set_size(fontsize, dpi)
        head  = fontface.get_sfnt_table('head')
        index = self._get_index(symbol)
        glyph = fontface.load_char(index)
        xmin, ymin, xmax, ymax = [val/64.0 for val in glyph.bbox]
        # This is black magic to me (Edin)
        if filename == 'cmex10.ttf':
            if self.output == 'PS':
                offset = -(head['yMin']+512)/head['unitsPerEm']*10.
            else:
                offset =  glyph.height/64.0/2 + 256.0/64.0*dpi/72.0
        else:
            offset = 0.
        metrics = Bunch(
            advance  = glyph.linearHoriAdvance/65536.0,
            height   = glyph.height/64.0,
            width    = glyph.width/64.0,
            xmin = xmin,
            xmax = xmax,
            ymin = ymin+offset,
            ymax = ymax+offset,
            )
        self.glyphdict[key] = metrics, glyph, offset
        return self.glyphdict[key]

    # We override the UnicodeFonts method
    def _get_unicode_index(self, symbol):
        pass
====

Cheers,
Edin

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John Hunter wrote:
>     >>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>     >>
>     Eric> they will not be transparent.  If you need transparent
>     Eric> masked regions, then try pcolor instead of imshow.  Pcolor
>     Eric> plots nothing at all in masked cells.  Pcolormesh, on the
>     Eric> other hand, is like imshow in plotting the assigned bad
>     Eric> color and in using a single alpha for everything.
>     >>  I'm confused about the comments about alpha not working on
>     >> imshow -- can you elaborate.  On the agg backend at least, the
>     >> alpha channel is respected in imshow, eg
>     >> examples/layer_images.py.  Is there a reason it does not (or
>     >> should not) work in the masked example?
> 
>     Eric> John,
> 
>     Eric> I don't know why it doesn't work; I know only that in my
>     Eric> example, it doesn't work as I perhaps naively think it
>     Eric> should.  My interpretation of alpha is that if alpha is zero
>     Eric> in any colored region, and if nothing else is drawn on top,
>     Eric> then the background should show through; that is, the r,g,b
>     Eric> values in the r,g,b,a tuple for a region should have no
>     Eric> effect if a is zero.  If you uncomment
>     Eric> #cmap.set_bad((1,1,1,0) in my example, you will find that
>     Eric> the masked region is white; and if you change the rgb part
>     Eric> of that tuple, it takes on that color, regardless of alpha.

My confusion here was that cmap.set_bad() ignores the alpha part of the 
color spec; you have to set alpha explicitly with a kwarg.  Maybe I will 
fix this some time.  But, read on...

> 
> I'm not sure what is going on in your example, but this test case
> shows that the alpha channel is respected.  I made a red RGBA array
> and set the alpha channel for the center to be transparent and it
> behaves as expected: you can see the line through the transparent
> region of the rectangle and the axes bgcolor shows through.  I had to
> make a small change to svn to make this work because the image wasn't
> respecting the zorder (revision 2495).  So the bug you are
> experiencing is likely to be in the front-end code.


You are partly right; alpha works fine with imshow.  But there is a 
problem in a backend, specifically the agg draw_quad_mesh and/or 
DrawQaudMesh methods.  This is where I originally ran into the problem, 
and the attached script illustrates it.  The figure on-screen has 
erratic and incorrect behavior in the central rectangle of the second 
subplot, for which alpha is zero.  Note what happens when you resize the 
window.  The ps backend, using the backend_bases code for the quad mesh, 
works correctly, now that I fixed it--two of the vertices in each quad 
were originally reversed.

It seems that DrawQuadMesh is trying to go straight to a low-level agg 
function, and in the process something is being lost when alpha is zero, 
or any value less than 1; in the example, you can change the alpha to 
0.5, for example, and you will still see the behavior when you resize 
the window.

I'm stumped.

Eric

Look what happened to my beautiful code :(

'''A script for seemlesly copying the data from the stix-tbl.ascii*
file to a set
of python dicts. Dicts are then saved to .py coresponding files, for
later retrieval.
Currently used table file:
http://www.ams.org/STIX/bnb/stix-tbl.ascii-2005-09-24

'''

tablefilename = 'stix-tbl.ascii-2005-09-24'
dictnames = ['uni2type1', 'type12uni', 'uni2tex', 'tex2uni']
dicts = {}
# initialize the dicts
for name in dictnames:
    dicts[name] = {}

for line in file(tablefilename):
    if line[:2]!=' 0': continue
    uninum = int(line[2:6].strip().lower(), 16)
    type1name = line[12:37].strip()
    texname = line[83:110].strip()
    if type1name:
        dicts['uni2type1'][uninum] = type1name
        dicts['type12uni'][type1name] = uninum
    if texname:
        dicts['uni2tex'][uninum] = texname
        dicts['tex2uni'][texname] = uninum

template = '''# Automatically generated file.
# Don't edit this file. Edit _mathtext_manual_data.py instead

%(name)s = {%(pairs)s
}
try:
    from _mathtext_manual_data import _%(name)s
    %(name)s.update(_%(name)s)
except (TypeError, SyntaxError): # Just these exceptions should be raised
    raise
except: # All other exceptions should be silent. Even ImportError
    pass
'''

# automatically generating .py module files, used by importers
for name in ('uni2type1', 'uni2tex'):
    pairs = ''
    for key, value in dicts[name].items():
        value = value.replace("'","\\'")
        value = value.replace('"','\\"')
        pair = "%(key)i : r'%(value)s',\n"%(locals())
        pairs += pair
    file(name + '.py','w').write(template%{'name':name, 'pairs':pairs})

for name in ('type12uni', 'tex2uni'):
    pairs = ''
    for key, value in dicts[name].items():
        key = key.replace("'","\\'")
        key = key.replace('"','\\"')
        pair = "r'%(key)s' : %(value)i,\n"%(locals())
        pairs += pair
    file(name + '.py','w').write(template%{'name':name, 'pairs':pairs})

# An example
from uni2tex import uni2tex
from  uni2type1 import uni2type1

unichar = u'\u00d7'
uninum = ord(unichar)
print uni2tex[uninum]
print uni2type1[uninum]

VGhhbmtzIEpvaG4gYW5kIEZlcm5hbmRvLAoKWW91J3JlIHJpZ2h0LiBJJ2xsIGNoYW5nZSB0aGUg
c2NyaXB0cyB0byBnZW5lcmF0ZSBwdXJlIFB5dGhvbiBtb2R1bGVzLApidXQgSSdsbCBsZWF2ZSB0
aGUgIm1hbnVhbCIgbW9kdWxlLgoKQXMgZm9yIFVuaWNvZGUsIEkgZnVsbHkgdW5kZXJzdGFuZCB3
aGF0IHlvdSBtZWFuIEpvaG4sIGFuZCBJJ20gcGxhbmluZwp0byB0cnkgdG8gZ2V0IG1hdGh0ZXh0
IHRvIHdvcmsgd2l0aCB0aGUgZm9udHMgSSBtZW50aW9uZWQgdG8geW91IGEKd2hpbGUgYWdvOgpo
dHRwOi8vY2Fub3B1cy5pYWNwLmR2by5ydS9+cGFub3YvY20tdW5pY29kZS8KCmFsdGhvdWdoIHRo
ZXkgZG9uJ3QgaGF2ZSBhbG1vc3QgYW55IHB1cmUgbWF0aCBjaGFyYWN0ZXJzIChsaWtlCmludGVn
cmFsIGV0Yy4pLCBidXQgYXQgbGVhc3QgdGhleSdsbCBiZSB1c2VmdWxsIGZvciB0ZXN0aW5nIHRo
ZQptb2R1bGUuIFRoZXkgaGF2ZSBzb21lIHZlcnkgZXhvdGljIGNoYXJhY3RlcnMuIFRoZSBtYWlu
dGFpbmVyIHNhaWQKdGhhdCwgaWYgSSAob3IgYW55Ym9keSkgd2FudCB0bywgSSBjYW4gc2VuZCBo
aW0gcGF0Y2hlcyBmb3IgdGhlIG1hdGgKc3ltYm9scyAobm90IGZvciB0aGlzIFNvQyA6KS4KCkVk
aW4KCk9uIDYvMjMvMDYsIEZlcm5hbmRvIFBlcmV6IDxmcGVyZXoubmV0QGdtYWlsLmNvbT4gd3Jv
dGU6Cj4gT24gNi8yMy8wNiwgSm9obiBIdW50ZXIgPGpkaHVudGVyQGFjZS5ic2QudWNoaWNhZ28u
ZWR1PiB3cm90ZToKPiA+ID4+Pj4+ICJFZGluIiA9PSBFZGluIFNhbGtvdmnCpyA8ZWRpbi5zYWxr
b3ZpY0BnbWFpbC5jb20+IHdyaXRlczoKPiA+ICAgICBFZGluPiBUaGUgcmVhc29uIHdoeSBJIHVz
ZWQgcGlja2xlIC0gZnJvbSB0aGUgUHl0aG9uIGRvY3M6ID09PT09Cj4gPgo+ID4gSSBoYXZlIGhh
ZCBiYWQgZXhwZXJpZW5jZXMgaW4gdGhlIHBhc3Qgd2l0aCBwaWNrbGUgZmlsZXMgY3JlYXRlZCB3
aXRoCj4gPiBvbmUgdmVyc2lvbiB0aGF0IGRvbid0IGxvYWQgd2l0aCBhbm90aGVyLiAgSSBkb24n
dCBrbm93IGlmIHRoYXQgaXMgYQo+ID4gY29tbW9uIHByb2JsZW0gb3IgaWYgb3RoZXJzIGhhdmUg
ZXhwZXJpZW5jZWQgaXQsIGJ1dCBpdCBoYXMgbWFkZSBtZQo+ID4gd2FyeSBvZiB0aGVtIGZvciBt
cGwsIHdoZXJlIHdlIHdvcmsgYWNyb3NzIHBsYXRmb3JtcyBhbmQgcHl0aG9uCj4gPiB2ZXJzaW9u
cy4gIE1heWJlIHRoaXMgY29uY2VybiBpcyB1bmZvdW5kZWQuICBJIHN0aWxsIGRvIG5vdCB1bmRl
cnN0YW5kCj4gPiB3aGF0IHRoZSBkb3duc2lkZSBpcyBvZiBzaW1wbHkgY3JlYXRpbmcgYSBkaWN0
aW9uYXJ5IGluIGEgcHl0aG9uCj4gPiBtb2R1bGUgYXMgd2UgZG8gd2l0aCBsYXRleF90b19iYWtv
bWEuCj4KPiBUaGUgbW9zdCBjb21tb24gd2F5IHBpY2tsZSBicmVha3MgaXMgd2hlbiB5b3UgcGlj
a2xlIGFuIGluc3RhbmNlIGFuZAo+IGxhdGVyIG1vZGlmeSB0aGUgY2xhc3MgaXQgYmVsb25ncyB0
byBzdWNoIHRoYXQgc29tZSBhdHRyaWJ1dGUKPiBkaXNhcHBlYXJzIG9yIGlzIHJlbmFtZWQuICBT
aW5jZSBwaWNrbGluZyB3b3JrcyBieSAgJ2Z1bGx5IHF1YWxpZmllZAo+IG5hbWUnLCBtZWFuaW5n
IHRoYXQgaXQgb25seSBzYXZlcyB0aGUgbmFtZSBvZiB0aGUgY2xhc3MgYW5kIHRoZQo+IGluc3Rh
bmNlIGRhdGEsIGJ1dCBpdCBkb2Vzbid0IGFjdHVhbGx5IHNhdmUgdGhlIG9yaWdpbmFsIGNsYXNz
LCBpbgo+IHRoaXMgc2NlbmFyaW8gdGhlIHBpY2tsZSBjYW4ndCBiZSB1bnBpY2tsZWQgc2luY2Ug
IHRoZXJlIGFyZQo+IGF0dHJpYnV0ZXMgdGhhdCB0aGUgbmV3IGNsYXNzIGRvZXNuJ3QgaGF2ZSBh
bnltb3JlLgo+Cj4gSWYgeW91IGFyZSBzdHJpY3RseSBwaWNrbGluZyBkYXRhIGluIG9uZSBvZiB0
aGUgYnVpbHRpbiBweXRob24gdHlwZXMsCj4geW91IGFyZSAvcHJvYmFibHkvIE9LLCBhcyBJIGRv
bid0IHNlZSBweXRob24gcmVtb3ZpbmcgYXR0cmlidXRlcyBmcm9tCj4gZGljdHMsIGFuZCB0aGUg
YnVpbHRpbiBkYXRhIHR5cGVzIGRvbid0IHJlYWxseSBoYXZlIGFueSBzcGVjaWFsCj4gaW5zdGFu
Y2UgYXR0cmlidXRlcyB3aXRoIG11Y2ggbWV0YWRhdGEgdGhhdCBjYW4gY2hhbmdlLgo+Cj4gQnV0
IGl0J3Mgc3RpbGwgdHJ1ZSB0aGF0IHRoZXJlJ3MgYSB3aW5kb3cgZm9yIHByb2JsZW1zIHdpdGgg
cGlja2xlCj4gdGhhdCBzaW1wbHkgaXNuJ3QgdGhlcmUgd2l0aCBhIHB1cmUgYXV0by1nZW5lcmF0
ZWQgc291cmNlIG1vZHVsZS4gIEFuZAo+IHRoZSBzcGVlZCBhcmd1bWVudCBpcywgSSB0aGluayBt
b290OiB3aGVuIHlvdSBpbXBvcnQgc29tZXRoaW5nLCBweXRob24KPiBtYXJzaGFscyB0aGUgc291
cmNlIGludG8gYmluYXJ5IGJ5dGVjb2RlIHVzaW5nIHNvbWV0aGluZyB3aGljaCBJIHRoaW5rCj4g
aXMgcXVpdGUgc2ltaWxhciB0byBjUGlja2xlLCBhbmQgcHJvYmFibHkganVzdCBhcyBmYXN0IChp
ZiBub3QgZmFzdGVyLAo+IHNpbmNlIG1hcnNoYWwgaXMgc2ltcGxlciB0aGFuIHBpY2tsZSkuICBJ
J20gbm90IDEwMCUgc3VyZSBvbiB0aGUKPiBkZXRhaWxzIG9mIGJ5dGVjb2RlIG1hcnNoYWxsaW5n
LCBzbyBwbGVhc2UgY29ycmVjdCBtZSBpZiB0aGlzIHBhcnQgaXMKPiB3cm9uZy4KPgo+IEhUSCwK
Pgo+IGYKPgo=

In the Non-PostScript font classes in mathtext.py the set_canvas_size is
def set_canvas_size(self, w, h):
    'Dimension the drawing canvas; may be a noop'
    self.width = int(w)
    self.height = int(h)
    for font in self.fonts.values():
        font.set_bitmap_size(int(w), int(h))

While in the PS class:
    def set_canvas_size(self, w, h, pswriter):
        'Dimension the drawing canvas; may be a noop'
        self.width  = w
        self.height = h
        self.pswriter = pswriter

Why is the float converted to int in the first case, and not in the second?

>>>>> "Martin" == Martin Spacek <sc...@ms...> writes:

    Martin> Whoops. Forgot to include the patches for CHANGELOG and
    Martin> API_CHANGES. I updated barh_demo.py as well, and tested
    Martin> the rest of the bar demos. Here's the combined patch
    Martin> against 2515.

    Martin> Sorry for the hassle, I'm a bit new at this.

OK, great.  They are in 2516.

Thanks!
JDH

Whoops. Forgot to include the patches for CHANGELOG and API_CHANGES. I 
updated barh_demo.py as well, and tested the rest of the bar demos. 
Here's the combined patch against 2515.

Sorry for the hassle, I'm a bit new at this.

Cheers,

Martin

John Hunter wrote:
>>>>>> "Martin" == Martin Spacek <sc...@ms...> writes:
> 
>     Martin> Ah, I was just working off the axes.py file from
>     Martin> viewcvs. I've checked out now from /trunk/matplotlib/
>     Martin> (using tortoise svn). Hopefully this new patch file will
>     Martin> work.
> 
> Making progress - I was able to apply this and check it in, but I only
> got a patch for axes.py (no CHANGELOG, API_CHANGES, modified examples,
> etc).  Also, examples/barh_demo.py is now broken after application of
> this partial patch).  Could you get a fresh checkout from svn
> (revision 2515) and see what is missing and then provide an updated
> patch?
> 
> Thanks!
> JDH

>>>>> "Martin" == Martin Spacek <sc...@ms...> writes:

    Martin> Ah, I was just working off the axes.py file from
    Martin> viewcvs. I've checked out now from /trunk/matplotlib/
    Martin> (using tortoise svn). Hopefully this new patch file will
    Martin> work.

Making progress - I was able to apply this and check it in, but I only
got a patch for axes.py (no CHANGELOG, API_CHANGES, modified examples,
etc).  Also, examples/barh_demo.py is now broken after application of
this partial patch).  Could you get a fresh checkout from svn
(revision 2515) and see what is missing and then provide an updated
patch?

Thanks!
JDH

John Hunter wrote:
 > I can live with that -- did you test your work with the table_demo?

I just tried table_demo, looks good, bars are nicely centered (had to 
set my rcparams axes.hold to True to get all four colours of bars).

> I'm having trouble applying your patch because of the way the file
> names are coded.  If somebody knows the magic patch command to make it
> go through, please commit it.  Otherwise, Martin, can you make a patch
> with svn diff from the mpl root dir (the one that setup.py lives in)?

Ah, I was just working off the axes.py file from viewcvs. I've checked 
out now from /trunk/matplotlib/ (using tortoise svn). Hopefully this new 
patch file will work.

Cheers,

Martin

On 6/23/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
>     Edin> The reason why I used pickle - from the Python docs: =3D=3D=3D=
=3D=3D
>
> I have had bad experiences in the past with pickle files created with
> one version that don't load with another.  I don't know if that is a
> common problem or if others have experienced it, but it has made me
> wary of them for mpl, where we work across platforms and python
> versions.  Maybe this concern is unfounded.  I still do not understand
> what the downside is of simply creating a dictionary in a python
> module as we do with latex_to_bakoma.

The most common way pickle breaks is when you pickle an instance and
later modify the class it belongs to such that some attribute
disappears or is renamed.  Since pickling works by  'fully qualified
name', meaning that it only saves the name of the class and the
instance data, but it doesn't actually save the original class, in
this scenario the pickle can't be unpickled since  there are
attributes that the new class doesn't have anymore.

If you are strictly pickling data in one of the builtin python types,
you are /probably/ OK, as I don't see python removing attributes from
dicts, and the builtin data types don't really have any special
instance attributes with much metadata that can change.

But it's still true that there's a window for problems with pickle
that simply isn't there with a pure auto-generated source module.  And
the speed argument is, I think moot: when you import something, python
marshals the source into binary bytecode using something which I think
is quite similar to cPickle, and probably just as fast (if not faster,
since marshal is simpler than pickle).  I'm not 100% sure on the
details of bytecode marshalling, so please correct me if this part is
wrong.

HTH,

f

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:

    Edin> I thought that the idea was to allow users to write unicode
    Edin> strings directly in TeX (OK, this isn't much of an excuse

No, this is not the reason.  Someone may want to do that one day so it
is good to keep the possibility in the back of your mind.  The point
of this work is to decouple mathtext from the bakoma fonts.  Right now
the mathtext data has a hard mapping from texnames->bakoma glyph info.
By setting up the encoding from texnames->unicode, then with a little
more work we can use any set of fonts that provide the unicode names.
Once we jettison bakoma, we can get nicer glyphs and kerning with a
decent set of fonts.  Once we have that, we can work on the layout
algorithms.

JDH

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
    Edin> The reason why I used pickle - from the Python docs: =3D=3D=3D=3D=
=3D

I have had bad experiences in the past with pickle files created with
one version that don't load with another.  I don't know if that is a
common problem or if others have experienced it, but it has made me
wary of them for mpl, where we work across platforms and python
versions.  Maybe this concern is unfounded.  I still do not understand
what the downside is of simply creating a dictionary in a python
module as we do with latex_to_bakoma.

JDH

>>>>> "Martin" == Martin Spacek <sc...@ms...> writes:

    Martin> I suppose I'm a bit jaded towards edges because I tend to
    Martin> make histograms and not bar graphs, but we can have it
    Martin> both ways.

I can live with that -- did you test your work with the table_demo?

    Martin> Sure. Here they are against their latest rev (2508 for
    Martin> both). Never done logs before, hope they're alright. What
    Martin> do you mean by "the rest"?

"the rest", meaning the work you had already done.

I'm having trouble applying your patch because of the way the file
names are coded.  If somebody knows the magic patch command to make it
go through, please commit it.  Otherwise, Martin, can you make a patch
with svn diff from the mpl root dir (the one that setup.py lives in)?

Thanks,
JDH

On 6/22/06, John Hunter <jdh...@ac...> wrote:
> Since you asked :-)
>
> I may not have mentioned this but the style conventions for mpl code
> are
>
>   functions : lower or lower_score_separated
>   variables and attributes : lower or lowerUpper
>   classes : Upper or MixedUpper

OK

> Also, I am not too fond of the dict of dicts -- why not use variable
> names?

I used a dict of dicts because this allowed me to generate separate
picle files (for each one of the dicts in the top-level dict) and
anything else (see the final script) by their coresponding top-level
dict name. I thought it was better, for practical/speed reasons, to
have separate pickle files, for every dict.

>     for line in file(fname):
>         if line[:2]!=' 0': continue # using continue avoids unneccesary indent

Thanks for the tip!

>         uninum = line[2:6].strip().lower()
>         type1name = line[12:37].strip()
>         texname = line[83:110].strip()
>
>         uninum = int(uninum, 16)

I thought that the idea was to allow users to write unicode strings
directly in TeX (OK, this isn't much of an excuse :). That's why I
used the eval approach, to get the dict keys (or values) to be unicode
strings. I'm also aware that indexing by ints is faster, and that the
underlying FT2 functions work with ints... OK, I'm now convinced that
your approach is better :)

>     pickle.dump((uni2type1, type12uni, uni2tex, tex2uni), file('unitex.pcl','w'))
>
>     # An example
>     unichar = int('00d7', 16)
>     print uni2tex.get(unichar)
>     print uni2type1.get(unichar)
>
> Also, I am a little hesitant to use pickle files for the final
> mapping.  I suggest you write a script that generates the python code
> contains the dictionaries you need (that is how much of _mathext_data
> was generated.

The reason why I used pickle - from the Python docs:
=====
Strings can easily be written to and read from a file. Numbers take a
bit more effort, since the read() method only returns strings, which
will have to be passed to a function like int(), which takes a string
like '123' and returns its numeric value 123. However, when you want
to save more complex data types like lists, dictionaries, or class
instances, things get a lot more complicated.

Rather than have users be constantly writing and debugging code to
save complicated data types, Python provides a standard module called
pickle. This is an amazing module that can take almost any Python
object (even some forms of Python code!), and convert it to a string
representation; this process is called pickling. Reconstructing the
object from the string representation is called unpickling. Between
pickling and unpickling, the string representing the object may have
been stored in a file or data, or sent over a network connection to
some distant machine.
=====
So I thought that pickling was the obvious way to go. And, of course,
unpickling with cPickle is very fast. I also think that no human being
should change the automaticaly generated dicts. Rather, we should put
a separate python file (i.e. _mathtext_manual_data.py) where anybody
who wants to manually override the automaticaly generated values, or
add new (key, value) pairs can do so.

The idea:

_mathtext_manual_data.py:
=======
uni2text = {key1:value1, key2:value2}
tex2uni = {}
uni2type1 = {}
type12uni = {}

uni2tex.py:
=======
from cPickle import load

uni2tex = load(open('uni2tex.cpl'))
try:
    import _mathtext_manual_data
    uni2tex.update(_mathtext_manual_data.uni2tex)
except (TypeError, SyntaxError): # Just these exceptions should be raised
    raise
except: # All other exceptions should be silent
    pass
=====

Finally, I added lines for automatically generating pretty much
everything that can be automatically generated

stix-tbl2py.py
=======
'''A script for seemlesly copying the data from the stix-tbl.ascii*
file to a set
of python dicts. Dicts are then pickled to coresponding files, for
later retrieval.
Currently used table file:
http://www.ams.org/STIX/bnb/stix-tbl.ascii-2005-09-24
'''

import pickle

tablefilename = 'stix-tbl.ascii-2005-09-24'
dictnames = ['uni2type1', 'type12uni', 'uni2tex', 'tex2uni']
dicts = {}
# initialize the dicts
for name in dictnames:
    dicts[name] = {}

for line in file(tablefilename):
    if line[:2]!=' 0': continue
    uninum = int(line[2:6].strip().lower(), 16)
    type1name = line[12:37].strip()
    texname = line[83:110].strip()
    if type1name:
        dicts['uni2type1'][uninum] = type1name
        dicts['type12uni'][type1name] = uninum
    if texname:
        dicts['uni2tex'][uninum] = texname
        dicts['tex2uni'][texname] = uninum

template = '''# Automatically generated file.
from cPickle import load

%(name)s = load(open('%(name)s.pcl'))
try:
    import _mathtext_manual_data
    %(name)s.update(_mathtext_manual_data.%(name)s)
except (TypeError, SyntaxError): # Just these exceptions should be raised
    raise
except: # All other exceptions should be silent
    pass
'''

# pickling the dicts to corresponding .pcl files
# automatically generating .py module files, used by importers
for name in dictnames:
    pickle.dump(dicts[name], open(name + '.pcl','w'))
    file(name + '.py','w').write(template%{'name':name})

# An example
from uni2tex import uni2tex
from  uni2type1 import uni2type1

unichar = u'\u00d7'
uninum = ord(unichar)
print uni2tex[uninum]
print uni2type1[uninum]

Cheers,
Edin

Hi John,

John Hunter wrote:
> Most people prefer the center aligning behavior, at least those who
> complained on the list about bar, so when I wrote barh I adopted
> this.  I tried to fix bar in the process, but ended up running into
> some bugs when I tested John Gill's table demo, and so left it as edge
> aligned and haven't revisited it since.  So my weak preference would
> be to have the two functions consistent and center aligned, but he who
> does the work usually gets the biggest vote.  Maybe others can chime
> in.

I suppose I'm a bit jaded towards edges because I tend to make 
histograms and not bar graphs, but we can have it both ways.

Here's patch5 (now against the latest axes.py rev 2508). It has 
everything in patch4, plus a keyword arg 'align' that lets you choose 
between aligning the bars according to their edges (left for vertical 
bars, bottom for horizontal bars) or their centers. The default is 
align='edge' for both bar() and barh(). Perhaps that should be changed 
to 'center' if most people prefer it that way. Also, the 'horizontal' 
boolean arg in patch4 has been renamed to 'orientation' and is now a 
string: either 'vertical' or 'horizontal', consistent with hist(). I 
also added the align arg to hist(), which just passes it on to bar() or 
barh().

> I was following the convention that the x arg goes first and the y
> second, but I'm not wed to this. 

In barh(), Matlab does indeed order the args x, y, but interprets them 
as y, x (ie, position, value), which actually makes sense to me.

> Perhaps you could patch the CHANGELOG and
> API_CHANGES file along with the rest which explains the changes.

Sure. Here they are against their latest rev (2508 for both). Never done 
logs before, hope they're alright. What do you mean by "the rest"?

Cheers,

Martin

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> Where breakage will occur is any place in user code that
>     Eric> expects the collection segments or vertices to be lists of
>     Eric> tuples and tries to append to the list, for example.  I
>     Eric> don't know of any way to make the move towards use of arrays
>     Eric> without this problem cropping up; I hope it is considered
>     Eric> tolerable.
> 
> If I'm understanding you correctly:  Users who create the collection
> themselves with the list of xy tuples approach can still modify their
> lists, eg with append, and not have breakage (I actually use this
> feature).  But users who are getting collections back from code like
> contour will get the non-modifiable array version.
> 
> 

John,

Yes, that is the way it is supposed to work.  The collection stores and 
  uses whichever form it is given.  This can work because the XY array 
is very similar to the [(x,y), (x,y)...] form; both are single objects, 
and they behave the same when one says, "for xy in XY:", or if one calls 
the array constructor with either as an argument.

Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Where breakage will occur is any place in user code that
    Eric> expects the collection segments or vertices to be lists of
    Eric> tuples and tries to append to the list, for example.  I
    Eric> don't know of any way to make the move towards use of arrays
    Eric> without this problem cropping up; I hope it is considered
    Eric> tolerable.

If I'm understanding you correctly:  Users who create the collection
themselves with the list of xy tuples approach can still modify their
lists, eg with append, and not have breakage (I actually use this
feature).  But users who are getting collections back from code like
contour will get the non-modifiable array version.