pyx-user — PyX user

[Pyx-user] Re: Problems building PyX 3.0.1 under Windows with VC++ 6.0

[Joerg L. <jo...@us...>]

Hello Bent André,

On 10.04.03, Bent Andre wrote:
> First of all; sorry about sending this mail to your private address, was
> unsure whereelse to send it.

No problem, but just for you information, there is also a PyX user
mailing list on SourceForge pyx...@li....
For archiving purposes, we should move this to this list.

> My name is Bent André Solheim, and I am trying to build PyX 0.3.1 under
> Windows 2000 using Python 2.2 Visual C++ 6.0.


> First of all, let me say that I have had troubles get a working copy of
> kpathsea with kpathsea.lib and the headerfiles, but I currently have all
> the files required to build the library on my system, collected from
> different sources; the headerfiles comes from the teTex distribution
> that comes with CygWin, the kpathsea.lib comes from a binary
> distribution of some latex-tools. So the combination of these may cause
> the problem... But the error message that comes when I try to build is
> this;

I also wonder whether your Python 2.2 (compiled with Visual C++ 6.0) is
compatible is compatible with the libraries from cygwin (which are
presumably compiled with gcc). I would suggest using either MikTeX 
or a CygWin version of Python.

> I was wondering how you guys build the library under Windows, and if you
> had any guidelines for how I should do it; including where to get a
> working copy of the kpathsea-library and which compiler works best.

I think, we have never built these modules under Windows (André W.,
please correct me, if I'm wrong). In fact, we have tried to ensure
that PyX also works without them, if 
- you your kpsewhich works correctly (which then replaces the
  _pykpathsea module)
- and you don't mind having all glyps of a font included (this happens,
  if you haven't compiled the t1strip module)

> Hope you can help me with this problem, as your library is really
> interesting and usefull (I buildt it without problems on my Linux at
> work), and I would really like to use it on my Windows Laptop aswell...

Let's try to get it work.

        Jörg

[Pyx-user] Announcement: PyX 0.3 released

[Andre W. <and...@ph...>]

Hi,

we're pround to announce the release of PyX 0.3. Find a list of
changes below and do not miss our new webpage available at
http://pyx.sourceforge.net/

Enjoy,


Jörg Lehmann, André Wobst



0.3 (2003/03/31)
  - examples
    - new easy to use example generation (will hopefully lead to nice examples)
  - unit box:
    - new module for handling of convex polygons (taken out of the graph module)
  - unit helper:
    - new module containing a collection of helper functions (taken out of the graph module)
    - moved the attrlist into helper -- as plain functions; attrlist becomes obsolete
  - text module:
    - new module: a new and preferable integration of TeX/LaTeX
  - t1strip module:
    - strip glyphs from pfa/pfb-fonts
    - there is a C implementation taken from pdftex
    - fallback solution via an external program (pfb2pfa)
  - pykpathsea module:
    - (partial) C binding to libkpathsea
    - fallback solution via an external program (kpsewhich)
  - graph module:
    - removed some code duplication (various axis painters)
    - use text module instead of the obsolete tex module
    - allow for tailing zeros of automatic generated labels
    - allow for missing data in bar graphs -> skipmissing parameter
    - remove the support for variables given as keyword arguments in data constructor
    - use context instead of extern for extern variables and functions
    - graph keys; titles in data/function/etc.
  - unit module:
    - new classes for visual and width lengths, aliases for user length (u_pt = pt)
    - all length classes have now by default a quantifier 1 (instead of 0), such that,
      for instance, 5*unit.t_cm() == unit.t_cm(5)
    - default_unit now has to be set via unit.set. For instance: unit.set(defaultunit="m").
    - convert_to is now an internal function, which moreover does not longer accept tuples or lists
  - bbox module:
    - new class _bbox (the former bbox) which accepts points in the constructor. This is used
      for internal purposes.
    - the bbox constructor now accepts user lengths in the constructor.
    - new methods height, width, top, bottom, left, right
    - ll & ur ???, what about ul and lr -> ugly!
    - enlarge (was enhance) now allows selective enlargement to the left, bottom, right and top
    - output HiResBoundingBox
    - never reduce bbox upon output
    - defered TODOs:
      __iadd__ and inplace enlarge, transform,...
  - epsfile module:
    - new constructor signature, more in line with rest of PyX:
      epsfile(x, y, filename, **additional_args)
  - data module:
    - removed additional column support in addcolumn; removed _addcolumn
    - line reduction for datafile like the every parameter in gnuplot
  - canvas module:
    - new way of PS prolog generation that writes only necessary parts
    - added support for patterns
    - canvas.insert() now supports arguments
    - bbox of canvas can be specified in writetofile command explicitely
    - writetofile does not return self anymore
    - arrow template now uses intersection with circle to get size right
      (as per a suggestion by Michael Schindler)
  - mathtree module:
    - added abs function
    - changed the handling of extern functions and all variables
  - color module:
    - gradient renamed to palette
  - numerous bugfixes:
    - problem with sizefile on windows (tex module)
    - allow for strings in graphxy's width and height; allow for width only (graph module)
    - disable rating for labelattrs equals None (graph module)
    - defaultstyle selection, when a list of data is provided to the plot function (graph module)
    - traverse when adding functions as arguments of operators (mathtree module)
    - allow for extern functions in addcolumn (data module)
    - just one common place for the version number
    - fix incorrect exception name MathError (path module)
    - prevent double return of intersections for closed sub paths
    - ...


-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

Re: [Pyx-user] join line segments in graph

[Andre W. <and...@ph...>]

Hi,

On 17.03.03, Joerg Lehmann wrote:
> On 17.03.03, Gert Ingold wrote:
> > how about a round join?
> +1

IMHO the only possibilities are a miterlimit with 90 degrees (+0)
or a round join (+1) -> I've just done the round join in cvs head.

André

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

Re: [Pyx-user] join line segments in graph

[Joerg L. <jo...@us...>]

On 17.03.03, Gert Ingold wrote:
> how about a round join? This would at least make sense if data points are
> thought of being represented by small circles. In addition, there will be
> no overshooting so that even without symbols the visual impression is
> correct.
+1

Greetings,

        Jörg

Re: [Pyx-user] join line segments in graph

[Gert I. <Ger...@Ph...>]

On Mon, Mar 17, 2003 at 08:37:45AM +0100, Andre Wobst wrote:
Hi André,

> Your observation is correct. The overshooting arises from the default
> stroke attributes linecap.butt + miterlimit.lessthan11deg. These are,
> by the way, the postscript defaults. Right now you may set these
> stroke attributes manually (using the lineattrs attribute of
> graph.line (or graph.symbol)). You're right, that PyXs default, having
> only an interator for the linestyle, is not a good solution. Instead
> your problem should be addressed adequately by better default
> attributes. Expect a change of these defaults for lineattrs soon. BTW:
> What do would you suggest to be the right combination of attributes?

how about a round join? This would at least make sense if data points are
thought of being represented by small circles. In addition, there will be
no overshooting so that even without symbols the visual impression is
correct.

Best regards,
Gert

-- 
 Gert-Ludwig Ingold               |                                  
 Institut fuer Physik             | email: In...@Ph...
 Universitaet Augsburg            | Phone: +49-821-598-3234
 D-86135 Augsburg                 | Fax  : +49-821-598-3222
 Germany                          |                                  

WWW homepage: http://www.physik.uni-augsburg.de/theo1/ingold

Re: [Pyx-user] join line segments in graph

[Andre W. <and...@ph...>]

Hi Gert,

On 14.03.03, Gert Ingold wrote:
> it seems that the default way in which PyX joins line segments
> connecting datapoints in a graph may lead to overshooting if two
> adjacent line segments enclose a very small angle. In order to give
> the correct visual impression of a function, the lines should IMHO
> never go beyond the datapoints. What do you think about this issue?

Your observation is correct. The overshooting arises from the default
stroke attributes linecap.butt + miterlimit.lessthan11deg. These are,
by the way, the postscript defaults. Right now you may set these
stroke attributes manually (using the lineattrs attribute of
graph.line (or graph.symbol)). You're right, that PyXs default, having
only an interator for the linestyle, is not a good solution. Instead
your problem should be addressed adequately by better default
attributes. Expect a change of these defaults for lineattrs soon. BTW:
What do would you suggest to be the right combination of attributes?

André

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

[Pyx-user] join line segments in graph

[Gert I. <Ger...@Ph...>]

Hi PyX developers,

it seems that the default way in which PyX joins line segments connecting
datapoints in a graph may lead to overshooting if two adjacent line
segments enclose a very small angle. In order to give the correct visual
impression of a function, the lines should IMHO never go beyond the datapoints.
What do you think about this issue?

Best regards,
Gert

-- 
 Gert-Ludwig Ingold               |                                  
 Institut fuer Physik             | email: In...@Ph...
 Universitaet Augsburg            | Phone: +49-821-598-3234
 D-86135 Augsburg                 | Fax  : +49-821-598-3222
 Germany                          |                                  

WWW homepage: http://www.physik.uni-augsburg.de/theo1/ingold

Re: [Pyx-user] How to plot only parts of a dataset

[Andre W. <and...@Ph...>]

Hi Andreas,

On 18.02.03, Andreas Hoffmann wrote:
> I wanted to plot something like
> 
>  .../\/\.../\/\..../\/\
>  in red  in blue  in red
>  .../\/\.../\/\..../\/\
>  in blue  in red  in blue
>  .../\/\.../\/\..../\/\
>  in red  in blue  in red
> 
> So several columns plotted against the first and each column
> partly in red and partly in blue according to some criteria.
> I did not find a way to plot only parts of a dataset.
> 
> Rearranging the dataset would result in multiple listings of
> parts of the first column, is this necessary?

As far as I see, I do not see a better solution right now. But
creating of another column, which holds only part of the data, isn't
that difficult. Unfortunately, there are two ugly bugs in pyx 0.2,
which prevent the following example to run nicely. The patches are
quick and straight forward:

    Index: graph.py
    ===================================================================
    RCS file: /cvsroot/pyx/pyx/pyx/graph.py,v
    retrieving revision 1.120.2.2
    diff -r1.120.2.2 graph.py
    2220c2220
    <         if (height is not None) and (width is None):
    ---
    >         elif (height is not None) and (width is None):
    Index: data.py
    ===================================================================
    RCS file: /cvsroot/pyx/pyx/pyx/data.py,v
    retrieving revision 1.3
    diff -r1.3 data.py
    74c74
    <         tree = self.parser.parse(expression)
    ---
    >         tree = self.parser.parse(expression, extern=self.extern)

It's really easy to fix it by hand right now. (They are checked into
the cvs head, of course).

Now you can write:

    from pyx import *
    
    def step(x, a):
        if a > 0:
            return x
    
    c = canvas.canvas()
    t = c.insert(tex.tex())
    g = c.insert(graph.graphxy(t, width = 10))
    df = data.datafile("example.dat", extern={"step": step})
    df.addcolumn("y1a=step(y1, x-1)")
    df.addcolumn("y1b=step(y1, 1-x)")
    df.addcolumn("y2a=step(y2, x-1)")
    df.addcolumn("y2b=step(y2, 1-x)")
    g.plot(graph.data(df, x=1, y="y1a"), graph.line(color.rgb.red))
    g.plot(graph.data(df, x=1, y="y1b"), graph.line(color.rgb.blue))
    g.plot(graph.data(df, x=1, y="y2a"), graph.line(color.rgb.red))
    g.plot(graph.data(df, x=1, y="y2b"), graph.line(color.rgb.blue))
    g.finish()
    c.writetofile("example")

What is done is to make a step function available in the addcolumn
method by calling an external function (by the way, variables
(e.g. constants) can be made available within the mathematical
expressions the same way). You find a datafile enclosed, where you can
run this example against. (As long as this user list isn't big, I do
not bear in mind the mail size too much.) It might be better to
overlap the values ranges to prevent drawing of gaps --- I suppose,
this can't be done better.

Hope that helps,

André

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

[Pyx-user] How to plot only parts of a dataset

[Andreas H. <and...@un...>]

Hi,

I wanted to plot something like

 .../\/\.../\/\..../\/\
 in red  in blue  in red
 .../\/\.../\/\..../\/\
 in blue  in red  in blue
 .../\/\.../\/\..../\/\
 in red  in blue  in red

So several columns plotted against the first and each column
partly in red and partly in blue according to some criteria.
I did not find a way to plot only parts of a dataset.

Rearranging the dataset would result in multiple listings of
parts of the first column, is this necessary?

Greetings, Andreas

[Pyx-user] Announcement: PyX 0.2 released

[Andre W. <And...@Ph...>]

Hi,

we're pround to announce the release of PyX 0.2. Find a list of
changes below.


Jörg Lehmann, André Wobst



0.2 (2003/01/17):
  - unit module:
    - allow division of length by numbers
  - trafo module:
    - new transformation: slant
    - renamed all trafo methods to use the participle (i.e translate->translated)
    - the name of all trafo subclasses are verbs (i.e. translation->translate)
  - graph module:
    - mark class renamed to symbol
    - (text-)box distance measurement
    - moved axis partitioning to axis and axis painter
    - automatic axis partitioning (now officially: general cleanup, distance measurement, documentation)
    - splitaxis
    - baraxis, baraxispainter, and bar style
  - data module:
    - previously named datafile module
    - class "_datafile" renamed to class "data"
    - class sectionfile added
    - testsuite
  - mathtree module:
    - extern variables and functions (support in graph.function, graph.paramfunction and data.data)
    - testsuite
  - text module:
    - deferred to Version 0.3
    - running TeX "on the fly" is basically implemented
  - numerous bugfixes:
    - transformation bug (#624068, trafo module)
    - canvas transformations (canvas module???)
    - textbox alignment (graph module)
    - return linewidth upon calculation with linewidths (unit module)
    - allow column number variables with several digits
    - ...
  - british and american spellings (color module, graph module)
  - small logo modifications

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/