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: 	2006年4月26日 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 2006年4月24日, 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