matplotlib-devel Mailing List for matplotlib

It seems there are error reports in the wild which may not be getting to=20
us here at matplotlib-devel. I'm forwarding one to our list. Does anyone=20
know the cause of the issue below? Can we fix it?

Gonzalo, I'm forwarding your emails to the matplotlib-devel list. If you=20
reply to us there and could be more specific about "get errors" someone=20
would be much better able to figure out what is going wrong.

-------- Original Message --------
Subject: 	Re: [Fann-general] pyfann+pylab
Date: 	Wed, 26 Apr 2006 18:27:03 +0200
From: 	Gonzalo A. de la Vega <gad...@ya...>
Reply-To: 	fan...@li...
To: 	fan...@li...
References: 	<444...@ya...>=20
<444...@fm...>



Thanks... I tried that before thou. I just found out, following some=20
tips on matplotlib archives, that the problem comes from localization. I=20
just run with English and runs fine (used Spanish before), but the=20
problem apparently comes for pylab (it may be only Fedora Core 5).

Michael R=F6ttger wrote:
> Hi Gonzalo,
>
> Gonzalo A. de la Vega schrieb:
>  =20
>> Working with pyfann I get errors when reading training data or nets fr=
om
>> files, but only if the pylab module (or part of it) has been imported.=
I
>> know pylab overloads some python operations, but I don't see how this
>> could affect pyfann. Any ideas?
>>    =20
>
> try to import both modules in separate namespaces, e.g.
>
>  import pylab as pl
>  import pyfann.libfann as fann
>
> and use it like
>
>  pl.plot(..)
>  ann =3D fann.neural_net()
>  ann.create_from_file(..)
>
> In this way I carried out a short test (matplotlib 0.85, pyfann2) and
> had no problems when reading a network with ann.create_from_file(..).
>
>  Michael
>
>  =20


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job ea=
sier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
_______________________________________________
Fann-general mailing list
Fan...@li...
https://lists.sourceforge.net/lists/listinfo/fann-general

Pepe SM wrote:
> I have uploaded a plot done with my code to the
> following  address:
> http://www.iaa.csic.es/~jsm/matplotlib/lfir-lradio.png

Thanks. It looks like your approach provides a subset of what mine does, 
with probably the benefit of better performance. Am I correct that for a 
given series, the markers are all the same, that is, they all point in 
the same direction and are the same length?

With my code, each data point gets a different direction (though they 
are all the same length -- maybe I should change that). You could set 
them to be all the same to get similar results to your approach.

This brings up another question: Could you have created a custom marker 
without having to patch the code, but rather using the existing API? If 
not, that would be a good feature to add.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hello Chris,

El Jueves, 27 de Abril de 2006 02:10, Christopher
Barker escribió:
> You might want to do something with a LineCollection
instead. TRy the
> enclosed code. Is that what you are looking for?
>

Yes, it is fine.

> I intend, some day, to clean this up and submit it
to MPL, but in the
> meantime, feel free to use or hack on it.
>
> By the way, do you have a sample of what your code
produces?
>

I have uploaded a plot done with my code to the
following  address:
http://www.iaa.csic.es/~jsm/matplotlib/lfir-lradio.png

Pepe.



		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com

I just changed the defaults on the mailing lists to member posting
only, so hopefully this will stop the spammers.

JDH

You might want to do something with a LineCollection instead. TRy the 
enclosed code. Is that what you are looking for?

I intend, some day, to clean this up and submit it to MPL, but in the 
meantime, feel free to use or hack on it.

By the way, do you have a sample of what your code produces?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Thank you Jared Wahlstrand and anyone else who has contributed to the svg 
backend. I'm making a poster with Inkscape, and had trouble importing some 
eps graphics, when I remembered that we have svg support. MPL kicks ass.

>>>>> "Tom" == Tom Denniston <tom...@al...> writes:
    Tom> I was able to work around the error simply by doing the
    Tom> obvious, making var = 0 if max(abs(vmin), abs(vmax)).  I
    Tom> think someone who understood the code better could probably
    Tom> come up with a better solution.

Hey Tom, this bug is already fixed in matplotlib svn.  Thanks for the
report.

JDH

The following code in matplotlib.ticker has a bug:

730     def scale_range(vmin, vmax, n =3D 1, threshold=3D100):
731         dv =3D abs(vmax - vmin)
732         meanv =3D 0.5*(vmax+vmin)
733 B->     var =3D dv/max(abs(vmin), abs(vmax))
734         if var < 1e-12:
735             return 1.0, 0.0
736         if abs(meanv)/dv < threshold:
737             offset =3D 0
738         elif meanv > 0:

When both dmin and dmax are 0 it results in 0 division.  I have been
unable to write a snippet of code to reproduce the problem
unfortunately.

I was able to work around the error simply by doing the obvious,
making var =3D 0 if max(abs(vmin), abs(vmax)).  I think someone who
understood the code better could probably come up with a better
solution.

--Tom

Hello,

This is my first message to the mailing list. I send a
patch to plot arrows as markers. I hope someone find
it usefull.

I needed to plot arrows as markers and I did not find
how to do it easily. Finally I changed some of the
source code (axes.py and lines.py) to do this.

To plot an arrow you have to write an 'a' plus a
number which defines the direction of the arrow. The
directions are the same that the ones in the numerical
keyboard, i.e., if you want to plot a green arrow
pointing to the left-bottom you will have to write the
string 'ga1' or 'a1g'.

I send the files for the version 0.82 of matplotlib (I
can not run properly the version 0.87 by now because I
have problems with colours and the axes(??!)). Here
are the diff outputs for the two files:

--- axes.py 2005-08-04 20:19:57.000000000 +0200
+++ axes_original.py  2005-06-15 20:50:44.000000000
+0200
@@ -89,30 +89,6 @@
     if fmt.find('-.')>=0:
         linestyle = '-.'
         fmt = fmt.replace('-.', '')
-    if fmt.find('a1')>=0:
-        marker = 'a1'
-        fmt = fmt.replace('a1', '')
-    if fmt.find('a2')>=0:
-        marker = 'a2'
-        fmt = fmt.replace('a2', '')
-    if fmt.find('a3')>=0:
-        marker = 'a3'
-        fmt = fmt.replace('a3', '')
-    if fmt.find('a4')>=0:
-        marker = 'a4'
-        fmt = fmt.replace('a4', '')
-    if fmt.find('a6')>=0:
-        marker = 'a6'
-        fmt = fmt.replace('a6', '')
-    if fmt.find('a7')>=0:
-        marker = 'a7'
-        fmt = fmt.replace('a7', '')
-    if fmt.find('a8')>=0:
-        marker = 'a8'
-        fmt = fmt.replace('a8', '')
-    if fmt.find('a9')>=0:
-        marker = 'a9'
-        fmt = fmt.replace('a9', '')

     chars = [c for c in fmt]



--- lines.py        2005-08-04 20:19:57.000000000
+0200
+++ lines_original.py   2005-06-15 00:21:21.000000000
+0200
@@ -27,8 +27,7 @@
 lineStyles  = {'-':1, '--':1, '-.':1, ':':1,
'steps':1, 'None':1}
 lineMarkers =    {'.':1, ',':1, 'o':1, '^':1, 'v':1,
'<':1, '>':1, 's':1,
                   '+':1, 'x':1, 'd':1, 'D':1, '|':1,
'_':1, 'h':1, 'H':1,
-                  'p':1, '1':1, '2':1, '3':1, '4':1,
'a1':1, 'a2':1,
-                  'a3':1, 'a4':1, 'a6':1, 'a7':1,
'a8':1, 'a9':1,
+                  'p':1, '1':1, '2':1, '3':1, '4':1,
                   TICKLEFT:1,
                   TICKRIGHT:1,
                   TICKUP:1,
@@ -109,14 +108,6 @@
         '2'  : '_draw_tri_up',
         '3'  : '_draw_tri_left',
         '4'  : '_draw_tri_right',
-        'a1'  : '_draw_arrow_left_down',
-        'a2'  : '_draw_arrow_down',
-        'a3'  : '_draw_arrow_right_down',
-        'a4'  : '_draw_arrow_left',
-        'a6'  : '_draw_arrow_right',
-        'a7'  : '_draw_arrow_left_up',
-        'a8'  : '_draw_arrow_up',
-        'a9'  : '_draw_arrow_right_up',
         's'  : '_draw_square',
         'p'  : '_draw_pentagon',
         'h'  : '_draw_hexagon1',
@@ -1136,139 +1127,6 @@
                 renderer.draw_line(gc, x-offset,
y-offset, x+offset, y+offset)
                 renderer.draw_line(gc, x-offset,
y+offset, x+offset, y-offset)

-#Empiezan mis 8 flechas
-
-    def _draw_arrow_down(self, renderer, gc, xt, yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(0, +offset)
-            path.line_to(0, -offset)
-            path.line_to(-offset, 0)
-            path.move_to(+offset, 0)
-            path.line_to(0, -offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x, y+offset,
x, y-offset)
-                renderer.draw_line(gc, x, y-offset,
x+offset, y)
-                renderer.draw_line(gc, x, y-offset,
x-offset, y)
-
-    def _draw_arrow_left_down(self, renderer, gc, xt,
yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(+offset, +offset)
-            path.line_to(-offset, -offset)
-            path.line_to(-offset, 0)
-            path.move_to(0, -offset)
-            path.line_to(-offset, -offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x+offset,
y+offset, x-offset, y-offset)
-                renderer.draw_line(gc, x-offset,
y-offset, x-offset, y)
-                renderer.draw_line(gc, x-offset,
y-offset, x, y-offset)
-
-    def _draw_arrow_right_down(self, renderer, gc,
xt, yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(-offset, +offset)
-            path.line_to(+offset, -offset)
-            path.line_to(+offset, 0)
-            path.move_to(0, -offset)
-            path.line_to(+offset, -offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x-offset,
y+offset, x+offset, y-offset)
-                renderer.draw_line(gc, x+offset,
y-offset, x+offset, y)
-                renderer.draw_line(gc, x+offset,
y-offset, x, y-offset)
-
-    def _draw_arrow_left(self, renderer, gc, xt, yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(+offset,0)
-            path.line_to(-offset,0)
-            path.line_to(0,+offset)
-            path.move_to(-offset, 0)
-            path.line_to(0, -offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x+offset, y,
x-offset, y)
-                renderer.draw_line(gc, x-offset, y,
x, y+offset)
-                renderer.draw_line(gc, x-offset, y,
x, y-offset)
-
-    def _draw_arrow_right(self, renderer, gc, xt,
yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(-offset,0)
-            path.line_to(+offset,0)
-            path.line_to(0,+offset)
-            path.move_to(+offset, 0)
-            path.line_to(0, -offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x+offset, y,
x-offset, y)
-                renderer.draw_line(gc, x+offset, y,
x, y+offset)
-                renderer.draw_line(gc, x+offset, y,
x, y-offset)
-
-    def _draw_arrow_left_up(self, renderer, gc, xt,
yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(+offset, -offset)
-            path.line_to(-offset, +offset)
-            path.line_to(-offset, 0)
-            path.move_to(0, +offset)
-            path.line_to(-offset, +offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x-offset,
y+offset, x+offset, y-offset)
-                renderer.draw_line(gc, x-offset,
y+offset, x, y+offset)
-                renderer.draw_line(gc, x-offset,
y+offset, x-offset, y)
-
-    def _draw_arrow_up(self, renderer, gc, xt, yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(0, -offset)
-            path.line_to(0, +offset)
-            path.line_to(-offset, 0)
-            path.move_to(+offset, 0)
-            path.line_to(0, +offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x, y+offset,
x, y-offset)
-                renderer.draw_line(gc, x, y+offset,
x+offset, y)
-                renderer.draw_line(gc, x, y+offset,
x-offset, y)
-
-    def _draw_arrow_right_up(self, renderer, gc, xt,
yt):
-        offset =
0.5*renderer.points_to_pixels(self._markersize)
-        if self._newstyle:
-            path = agg.path_storage()
-            path.move_to(-offset, -offset)
-            path.line_to(+offset, +offset)
-            path.line_to(+offset, 0)
-            path.move_to(0, +offset)
-            path.line_to(+offset, +offset)
-            renderer.draw_markers(gc, path, None, xt,
yt, self._transform)
-        else:
-            for (x,y) in zip(xt, yt):
-                renderer.draw_line(gc, x+offset,
y+offset, x-offset, y-offset)
-                renderer.draw_line(gc, x+offset,
y+offset, x+offset, y)
-                renderer.draw_line(gc, x+offset,
y+offset, x, y+offset)
-
-#Terminan mis 8 flechas
-
-
     def update_from(self, other):
         'copy properties from other to self'
         Artist.update_from(self, other)


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

I think it would not be difficult to do something
similar for the last version. The shape of the arrows
can be improved to look better. This patch is only an
idea, the problem is to add new non-standard marker
names, if anyone knows a smart way of doing this it
would be apreciated. That's all.

Thank you for your fabulous module.
Pepe.



		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com

Jouni K Seppanen <jk...@ik...> writes:

> It apparently has to be font.load_char(ch, LOAD_NO_SCALE), or at least
> that produces width values that look similar to those in files saved
> by Preview.app. But acroread still complains...

It seems that I can stop the complaining by forcing the /LastChar
entry in the Font dictionary to be 255 instead of 258. The characters
(in at least Bitstream Vera Sans) mysteriously seem to be numbered
from 3 to 258, so I guess this must be some sort of an encoding issue. 
Does this ring a bell to anyone?

-- 
Jouni

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> John Hunter <jdh...@ac...> writes:
    >> You shouldn't need to with the ft2font extension code, because
    >> it uses pycxx which has support for kwarg handling.  Eg in the
    >> _image.cpp src
    >> 
    >> Py::Object resize(const Py::Tuple& args, const Py::Dict&
    >> kwargs);
    Jouni>  [...]
    >> args.verify_length(2);
    >> 
    >> int norm = 1; if ( kwargs.hasKey("norm") ) norm = Py::Int(
    >> kwargs["norm"] );

    Jouni> This seems to mean that the function cannot be called using
    Jouni> the normal Python convention:

    >>>> img.resize(10,10,1)
    Jouni>   Traceback (most recent call last): File "<stdin>", line
    Jouni> 1, in ?  IndexError: Unexpected SeqBase<T> length.

The reason it raises is because I told it too :-)

  args.verify_length(2);

if you want normal python symantics, you could to something something
like (untested, freestyle code)

  int norm(0);
  if (args.length()==3)
      norm = Py::Int( args[2] );
  elif ( kwargs.hasKey("norm") ) 
    norm = Py::Int( kwargs["norm"] );

    Jouni> Instead you have to do img.resize(10,10,norm=1). This is
    Jouni> handled transparently by PyArg_ParseTupleAndKeywords: if
    Jouni> you set the format string to "ii|ii" and list the names of
    Jouni> all parameters as keywords, you automatically get the
    Jouni> normal Python convention where the last two args are
    Jouni> optional and all args are specifiable with their names.

    Jouni> But I guess this is not so important in extension code that
    Jouni> only gets called by matplotlib internals and not end users,
    Jouni> so I changed load_char to use the pycxx convention.

I do think it is useful in the pycxx extension code to stick where
possible to the cxx idioms -- for the most part the code is cleaner to
reads and helps with reference counting, etc....  You can check the
docs at 

  http://cxx.sourceforge.net/PyCXX.html

there may be a cleaner way to handle kwargs than what I suggested.

JDH

John Hunter <jdh...@ac...> writes:

> You shouldn't need to with the ft2font extension code, because it uses
> pycxx which has support for kwarg handling.  Eg in the _image.cpp src
>
>   Py::Object resize(const Py::Tuple& args, const Py::Dict& kwargs);
 [...]
>   args.verify_length(2);
>
>   int norm = 1;
>   if ( kwargs.hasKey("norm") ) norm = Py::Int( kwargs["norm"] );

This seems to mean that the function cannot be called using the normal
Python convention:

  >>> img.resize(10,10,1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  IndexError: Unexpected SeqBase<T> length.

Instead you have to do img.resize(10,10,norm=1). This is handled
transparently by PyArg_ParseTupleAndKeywords: if you set the format
string to "ii|ii" and list the names of all parameters as keywords,
you automatically get the normal Python convention where the last two
args are optional and all args are specifiable with their names.

But I guess this is not so important in extension code that only gets
called by matplotlib internals and not end users, so I changed
load_char to use the pycxx convention.

-- 
Jouni

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> I hacked the load_char method to accept a "flags" keyword
    Jouni> parameter. I hope I didn't break anything; is it safe to
    Jouni> use PyArg_ParseTupleAndKeywords with the C++ interface?

You shouldn't need to with the ft2font extension code, because it uses
pycxx which has support for kwarg handling.  Eg in the _image.cpp src

  Py::Object resize(const Py::Tuple& args, const Py::Dict& kwargs);

Py::Object
Image::resize(const Py::Tuple& args, const Py::Dict& kwargs) {
  _VERBOSE("Image::resize");

  args.verify_length(2);

  int norm = 1;
  if ( kwargs.hasKey("norm") ) norm = Py::Int( kwargs["norm"] );

  double radius = 4.0;
  if ( kwargs.hasKey("radius") ) radius = Py::Float( kwargs["radius"] );
  //snip snip snip
}

so you can easily add kwarg handling by changing the declaration to
accept a Py::Dict and then use the object with dictionary like
semantics.  In the init_type function, you'll need to declare your
method as a kwarg method, eg


  add_keyword_method( "resize", &Image::resize, Image::resize__doc__);

JDH

Jouni K Seppanen <jk...@ik...> writes:

> what looks like a bigger problem is how to get the /Widths array
> required by PDF. I've tried both the width and horiAdvance
> properties of font.load_char(ch), and in either case Acrobat Reader
> tells me the array is invalid.

It apparently has to be font.load_char(ch, LOAD_NO_SCALE), or at least
that produces width values that look similar to those in files saved
by Preview.app. But acroread still complains...

I hacked the load_char method to accept a "flags" keyword 
parameter. I hope I didn't break anything; is it safe to use
PyArg_ParseTupleAndKeywords with the C++ interface?

-- 
Jouni

[This discussion somehow wandered onto matplotlib-user. I'm bringing it back 
over to the dev list.]

On Monday 24 April 2006 16:30, Alan G Isaac wrote:
> On Mon, 24 Apr 2006, Christopher Barker apparently wrote:
> > I think it might use dvips or something to do that. rather than
> > reading and rendering the DVI itself.
>
> That is not my understanding,
> which however is limited.

PyX does read dvi files. I'll bet they ported dvitype to do so (PyX 
distributes a script called dvitype.py.)

> PS I have tried to reopen the discussion with the PyX
> developers.  I'll post any useful outcomes.

Their webpage states that they would consider relicensing, but when I talked 
to them, they were unwilling to release under a BSD-compatible license. 
However, we dont need all of PyX to be relicensed, and I did not make that 
clear to the PyX authors. If they would consider relicensing a subset of 
their code, it would be extremely helpful.

On Monday 24 April 2006 10:48, Jouni K Seppanen wrote:
> Darren Dale <dd...@co...> writes:
> > The basic approach is to extract the font layout information from the
> > dvi files. LaTeX could be the only dependency.
>
> Great! Another possibly useful reference is
>
> http://www.tug.org/tex-archive/dviware/driv-standard/level-0/dvistd0.pdf
>
> and the documents in driv-standard/papers. dvi is apparently pretty
> difficult to parse, as you have to implement a bytecode interpreter to
> keep track of the state.

Thanks Jouni, I was not aware of this document. There are some other packages 
in dviware that could serve as useful examples, like dvitops (there are a lot 
of GPL'd packages too, like dvisvgm and dvipdfmx. Too bad.)

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

> The basic approach is to extract the font layout information from the 
> dvi files. LaTeX could be the only dependency.

Great! Another possibly useful reference is

http://www.tug.org/tex-archive/dviware/driv-standard/level-0/dvistd0.pdf

and the documents in driv-standard/papers. dvi is apparently pretty
difficult to parse, as you have to implement a bytecode interpreter to
keep track of the state.

-- 
Jouni

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

    Darren> I also discovered that xdvi is OSS compliant, and have
    Darren> started studying that source code as well. I only started
    Darren> writing code to read the dvi information, but I post here
    Darren> to allow people to comment if they are so inclined, and to
    Darren> share the dvitype example with anyone who is interested. I
    Darren> have compiled the tex file, converted it to pdf, and
    Darren> posted the result at
    Darren> http://staff.chess.cornell.edu/~dale/matplotlib/dvitype.pdf.

This is very good stuff Darren -- it would be really nice to have a
python interface to dvi files under a BSD compatible license.
matplotlib sitting on top of my two favorite runtimes: python and TeX.

I think it is a shame that a lot tools built on top of TeX (web2c,
pyx, ...) have a more restrictive license than TeX itself, so this
would be a very useful piece of code.

JDH

Thanks for doing this Darren.  Keep up the good work!

On 4/24/06, Darren Dale <dd...@co...> wrote:
> This weekend I took the first small step towards improving usetex and
> eliminating the need for PSFrag and dependencies like ghostscript. This i=
s
> necessary in order to provide usetex support accross backends (like pdf a=
nd
> svg). The basic approach is to extract the font layout information from t=
he
> dvi files. LaTeX could be the only dependency.
>
> Wikipedia has an article about the dvi specification:
> http://en.wikipedia.org/wiki/DVI_file_format, which has a link to a reall=
y
> useful file called dvitype.web. This file contains the full dvi specifica=
tion
> and can be converted into a plain tex file using weave:
> http://www.ctan.org/tex-archive/systems/knuth/texware/dvitype.web
>
> dvitype.web also contains a well documented pascal program illustrating h=
ow to
> read dvi files correctly and convert them into symbolic form. It was mean=
t as
> a guide to programmers developing dvi-related software. It includes a sec=
tion
> on extracting the necessary information from tfm files, and other issues
> related to fonts.
>
> I also discovered that xdvi is OSS compliant, and have started studying t=
hat
> source code as well. I only started writing code to read the dvi informat=
ion,
> but I post here to allow people to comment if they are so inclined, and t=
o
> share the dvitype example with anyone who is interested. I have compiled =
the
> tex file, converted it to pdf, and posted the result at
> http://staff.chess.cornell.edu/~dale/matplotlib/dvitype.pdf.
>
> Darren
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

This weekend I took the first small step towards improving usetex and 
eliminating the need for PSFrag and dependencies like ghostscript. This is 
necessary in order to provide usetex support accross backends (like pdf and 
svg). The basic approach is to extract the font layout information from the 
dvi files. LaTeX could be the only dependency.

Wikipedia has an article about the dvi specification: 
http://en.wikipedia.org/wiki/DVI_file_format, which has a link to a really 
useful file called dvitype.web. This file contains the full dvi specification 
and can be converted into a plain tex file using weave: 
http://www.ctan.org/tex-archive/systems/knuth/texware/dvitype.web

dvitype.web also contains a well documented pascal program illustrating how to 
read dvi files correctly and convert them into symbolic form. It was meant as 
a guide to programmers developing dvi-related software. It includes a section 
on extracting the necessary information from tfm files, and other issues 
related to fonts. 

I also discovered that xdvi is OSS compliant, and have started studying that 
source code as well. I only started writing code to read the dvi information, 
but I post here to allow people to comment if they are so inclined, and to 
share the dvitype example with anyone who is interested. I have compiled the 
tex file, converted it to pdf, and posted the result at 
http://staff.chess.cornell.edu/~dale/matplotlib/dvitype.pdf. 

Darren

The "What's new" webpage at
http://matplotlib.sourceforge.net/whats_new.html starts with
matplotlib 0.83 - but the latest download is 0.87.2

Has the change to svn caused this?

Chris

I hacked some more on the PDF backend, and now it embeds TrueType
fonts. The positioning is still a bit off, but what looks like a
bigger problem is how to get the /Widths array required by PDF. I've
tried both the width and horiAdvance properties of font.load_char(ch),
and in either case Acrobat Reader tells me the array is invalid. 
Opening the file in Mac OS X's Preview, adding an annotation and then
saving the file changes the array to something acroread does not
complain about (and it also subsets the font). It doesn't look like
it's a simple scaling problem, since the ratio of correct width to
either of my guesses is not constant.

Any ideas?

-- 
Jouni

Hi All,

I have a problem plotting text on a graph that's been rotated using an 
Affine transform. I think I can demonstrate the cause of the problem 
with the following code snippet.

###
from matplotlib.transforms import Affine, Value

a = Affine(Value(1), Value(1), Value(-1), Value(1), Value(0), Value(0))

xy = (123, 456)
print a.inverse_xy_tup(a.xy_tup(xy))
###

Result is not 123, 456 as I expect but -456, 456.

I think the problem is in _transform.cpp. This patch (from HEAD revision 
in SVN) gives the correct result.

1704,1705c1704,1705
<     _ibval = scale*_cval;
<     _icval = -scale*_bval;
---
 >     _ibval = -scale*_bval;
 >     _icval = -scale*_cval;

Thanks,
Alan

On Friday 21 April 2006 14:24, Darren Dale wrote:
> On Friday 21 April 2006 08:35, Ralf Gommers wrote:
> > Hi everyone,
> >
> > I upgraded from version 87.2 to svn (on linux) two days ago, and I
> > noticed that the output to posscript files has changed. The relevant rc
> > settings are:
> >
> > text.usetex         : True
> > ps.papersize      : A4
> > ps.useafm         : True    # use of afm fonts, results in small files
> > ps.usedistiller   : ghostscript
> >
> > The results for a typical picture with both 87.2 and svn are attached.
> > I'm guessing that _svn is the correct behavior since the papersize is A4
> > here, as specified in the rc. But when I use ps2eps the 87.2 version
> > comes out correct and the svn version does not. I tried ps.papersize:
> > auto as well, but then the eps file is only half the graph.
>
> It looks like ghostscript is not calculating the bounding box properly when
> it distills your file. I have done a lot of testing and havent seen this
> problem. Try replacing the bounding box code on line 1179 in backend_ps
> with this:
>
> if ext=='.eps': print >>fh, "%%%%BoundingBox: %d %d %d %d" % bbox
>
> That might help things a little. Note, if your figure runs off the
> postscript page, conversion to eps may result in a clipped image. It's
> better to ask mpl to make an eps file in the first place.
>
> Darren

Thanks for the quick reply Darren.

Generating .eps files has never worked for me, I think I tried this with 0.86 
and 0.87.2 as well. In the script I changed the extension from ps to eps, 
this gives an error. I get the same error with the very simple script:

from scipy import *
from pylab import *

n=100
x=arange(n)
y=rand(n)
figure(1)
clf()
plot(x, y)
savefig('test.eps')
show()


Could replacing the code on line 1179 in backend_ps as you suggested solve 
this?
The traceback of the above script:

exceptions.ValueError                                Traceback (most recent 
call last)

/home/rgommers/data/python/test.py
      8 clf()
      9 plot(x, y)
---> 10 savefig('test.eps')
     11 show()
     12

/usr/lib/python2.3/site-packages/matplotlib/pylab.py in savefig(*args, 
**kwargs)
    800 def savefig(*args, **kwargs):
    801     fig = gcf()
--> 802     return fig.savefig(*args, **kwargs)
    803 if Figure.savefig.__doc__ is not None:
    804     savefig.__doc__ = _shift_string(Figure.savefig.__doc__)

/usr/lib/python2.3/site-packages/matplotlib/figure.py in savefig(self, *args, 
**kwargs)
    656                 kwargs[key] = rcParams['savefig.%s'%key]
    657
--> 658         self.canvas.print_figure(*args, **kwargs)
    659
    660     def colorbar(self, mappable,  cax=None,

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
print_figure(self, outfile, dpi, facecolor, edgecolor, orientation, 
papertype)
    995             # Let's keep the usetex stuff seperate from the generic 
postscript
    996             self._print_figure_tex(outfile, dpi, facecolor, edgecolor,
--> 997                                    orientation, papertype)
    998         else:
    999             if  isinstance(outfile, file):

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
_print_figure_tex(self, outfile, dpi, facecolor, edgecolor, orientation, 
papertype)
   1223
   1224         if rcParams['ps.usedistiller'] == 'ghostscript':
-> 1225             gs_distill(tmpfile, ext=='.eps', ptype=papertype, 
bbox=bbox)
   1226         elif rcParams['ps.usedistiller'] == 'xpdf':
   1227             xpdf_distill(tmpfile, ext=='.eps', ptype=papertype, 
bbox=bbox)

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
gs_distill(tmpfile, eps, ptype, bbox)
   1329     shutil.move(outputfile, tmpfile)
   1330     if eps:
-> 1331         pstoeps(tmpfile, bbox)
   1332
   1333

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
pstoeps(tmpfile, bbox)
   1418     Convert the postscript to encapsulated postscript.
   1419     """
-> 1420     bbox_info = get_bbox(tmpfile, bbox)
   1421
   1422     epsfile = tmpfile + '.eps'

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
get_bbox(tmpfile, bbox)
   1393 ##    bbox_info = stderr.read()
   1394     verbose.report(bbox_info, 'helpful')
-> 1395     l, b, r, t = [float(i) for i in bbox_info.split()[-4:]]
   1396
   1397     # this is a hack to deal with the fact that ghostscript does not 
return the

ValueError: invalid literal for float(): cidfmap
WARNING: Failure executing file: <test.py>


Cheers,
Ralf

On Friday 21 April 2006 08:35, Ralf Gommers wrote:
> Hi everyone,
>
> I upgraded from version 87.2 to svn (on linux) two days ago, and I noticed
> that the output to posscript files has changed. The relevant rc settings
> are:
>
> text.usetex         : True
> ps.papersize      : A4
> ps.useafm         : True    # use of afm fonts, results in small files
> ps.usedistiller   : ghostscript
>
> The results for a typical picture with both 87.2 and svn are attached. I'm
> guessing that _svn is the correct behavior since the papersize is A4 here,
> as specified in the rc. But when I use ps2eps the 87.2 version comes out
> correct and the svn version does not. I tried ps.papersize: auto as well,
> but then the eps file is only half the graph.

It looks like ghostscript is not calculating the bounding box properly when it 
distills your file. I have done a lot of testing and havent seen this 
problem. Try replacing the bounding box code on line 1179 in backend_ps with 
this:

if ext=='.eps': print >>fh, "%%%%BoundingBox: %d %d %d %d" % bbox

That might help things a little. Note, if your figure runs off the postscript 
page, conversion to eps may result in a clipped image. It's better to ask mpl 
to make an eps file in the first place.

Darren