pyx-devel — PyX development

[PyX-devel] [PATCH] allow Lipshitz bounds on function plots

[Michael J G. <mic...@us...>]

Depending on the number of points, PyX may or may not catch
singularities such as that of 1/x at 0. This may lead to spurious
vertical lines.

Introduce an extra parameter "lipshitz" to graph.data.function(). It
defaults to off. When specified and when two subsequent graph points
produce a slope larger in abosulte value than "lipshitz", an extra
"None" value is aded to the points produced by graph.data.function().
This makes graph.style.line() cut the plot between these two points.

This also catches discontinuities.

Signed-off-by: Michael J Gruber <mic...@us...>
---
This is just a first attempt/request for discussion.
One may argue whether one should put the "None" in between two points,
or replace a value by "None" rather than introducing an additional one
(but which one do you replace - left, right, both?).

The method is inspired by Alan's remarks.

 pyx/graph/data.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/pyx/graph/data.py b/pyx/graph/data.py
index 4e99951..e9c1c29 100644
--- a/pyx/graph/data.py
+++ b/pyx/graph/data.py
@@ -501,7 +501,7 @@ class function(_data):
     assignmentpattern = re.compile(r"\s*([a-z_][a-z0-9_]*)\s*\(\s*([a-z_][a-z0-9_]*)\s*\)\s*=", re.IGNORECASE)
 
     def __init__(self, expression, title=_notitle, min=None, max=None,
-                 points=100, context={}):
+                 points=100, context={}, lipshitz=0):
 
         if title is _notitle:
             self.title = expression
@@ -522,6 +522,7 @@ class function(_data):
         self.expression = compile(expression.strip(), __file__, "eval")
         self.columns = {}
         self.columnnames = [self.xname, self.yname]
+        self.lipshitz = lipshitz
 
     def dynamiccolumns(self, graph, axisnames):
         dynamiccolumns = {self.xname: [], self.yname: []}
@@ -550,6 +551,9 @@ class function(_data):
                 y = eval(self.expression, _mathglobals, self.context)
             except (ArithmeticError, ValueError):
                 y = None
+            if i and self.lipshitz > 0 and y is not None and abs(y - dynamiccolumns[self.yname][-1]) > self.lipshitz * abs(x - dynamiccolumns[self.xname][-2]):
+                dynamiccolumns[self.yname].append(None)
+                dynamiccolumns[self.xname].append(x)
             dynamiccolumns[self.yname].append(y)
         return dynamiccolumns
 
-- 
2.7.0.97.g592a2c5

[PyX-devel] Update gallery/arrows to python 3.0

[Michael J G. <mic...@fa...>]

Hi there,

I have no idea how to submit patches for the gallery now that it has
moved. In any case, gallery/arrows relied on the old behaviour rounding
int/int to an int: The line

x = lambda k: int(k)/11

needs to read

x = lambda k: int(k/11)

now (for py 3 or py2 with division from future), or else the vertical
lines are skewed:

http://nbviewer.ipython.org/urls/sf.net/p/pyx/gallery/arrows/attachment/arrows.ipynb

Michael

Re: [PyX-devel] [PATCH] do not shift grids when shifting axes

[André W. <wo...@us...>]

Dear Michael,

thanks for your patch, I queue the issue for fixing in the next release. We will probably do it differently, though. I have another report here (maybe it is some internal communication), that we want the grid to "live" on a separate layer altogether. For example on a bar graph you might want to have the axis on top of the data but the grid below the data (the bars in this case). This is rather common. At the moment we cannot easily do that, we should completely separate the grid from the axis (make it a separate "first-level" layer), which will probably make a fix to the issue you came up with much easier to fix ...

Best,


André

Am 02.12.2015 um 12:21 schrieb Michael J Gruber <mic...@us...>:

> "?axisat" allow shifting the axes to other locations, e.g. the quite
> common case of having the axes go through 0. This is implemented by
> shifting all axis layers, which includes the grid layer, so that it gets
> placed outside of the graph.
> 
> Omit the grid layer when shifting around axis layers so that the grid
> remains in place.
> 
> Signed-off-by: Michael J Gruber <mic...@us...>
> ---
> 
> Notes:
> The patch is against r3425, sorry for not being on py 3 yet.
> 
> Simple reproducer:
> 
> from pyx import *
> 
> gridpainter = graph.axis.painter.regular(gridattrs=[])
> gridaxis = graph.axis.linear(painter=gridpainter)
> g=graph.graphxy(width=6, x=gridaxis, y=gridaxis, xaxisat=0, yaxisat=0)
> g.plot(graph.data.function("y(x)=x*x", min=-1, max=1))
> g.writePDFfile()
> 
> pyx/graph/graph.py | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/pyx/graph/graph.py b/pyx/graph/graph.py
> index 5584530..9e3c558 100644
> --- a/pyx/graph/graph.py
> +++ b/pyx/graph/graph.py
> @@ -535,7 +535,10 @@ class graphxy(graph):
>             t = trafo.translate_pt(0, self.ypos_pt + v*self.height_pt - axis.positioner.y1_pt)
>         c = canvas.canvas()
>         for layer, subcanvas in axis.canvas.layers.items():
> -            c.layer(layer).insert(subcanvas, [t])
> +            if layer == 'grid':
> +                c.layer(layer).insert(subcanvas)
> +            else:
> +                c.layer(layer).insert(subcanvas, [t])
>         assert len(axis.canvas.layers) == len(axis.canvas.items), str(axis.canvas.items)
>         axis.canvas = c
> 
> -- 
> 2.6.3.507.gca54332
> 
> 
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] [PATCH] do not shift grids when shifting axes

[Michael J G. <mic...@us...>]

"?axisat" allow shifting the axes to other locations, e.g. the quite
common case of having the axes go through 0. This is implemented by
shifting all axis layers, which includes the grid layer, so that it gets
placed outside of the graph.

Omit the grid layer when shifting around axis layers so that the grid
remains in place.

Signed-off-by: Michael J Gruber <mic...@us...>
---

Notes:
The patch is against r3425, sorry for not being on py 3 yet.

Simple reproducer:

from pyx import *

gridpainter = graph.axis.painter.regular(gridattrs=[])
gridaxis = graph.axis.linear(painter=gridpainter)
g=graph.graphxy(width=6, x=gridaxis, y=gridaxis, xaxisat=0, yaxisat=0)
g.plot(graph.data.function("y(x)=x*x", min=-1, max=1))
g.writePDFfile()

 pyx/graph/graph.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/pyx/graph/graph.py b/pyx/graph/graph.py
index 5584530..9e3c558 100644
--- a/pyx/graph/graph.py
+++ b/pyx/graph/graph.py
@@ -535,7 +535,10 @@ class graphxy(graph):
             t = trafo.translate_pt(0, self.ypos_pt + v*self.height_pt - axis.positioner.y1_pt)
         c = canvas.canvas()
         for layer, subcanvas in axis.canvas.layers.items():
-            c.layer(layer).insert(subcanvas, [t])
+            if layer == 'grid':
+                c.layer(layer).insert(subcanvas)
+            else:
+                c.layer(layer).insert(subcanvas, [t])
         assert len(axis.canvas.layers) == len(axis.canvas.items), str(axis.canvas.items)
         axis.canvas = c
 
-- 
2.6.3.507.gca54332

Re: [PyX-devel] ANN: PyX 0.14 released

[Michael J G. <mic...@fa...>]

André Wobst venit, vidit, dixit 03.11.2015 00:20:
> Hi,
> 
> We've just released PyX 0.14.1. Starting from this release PyX is distributed at PyPI (see https://pypi.python.org/pypi), as pip will stop working with external hosted files in the near future (see https://www.python.org/dev/peps/pep-0470/). When installing via pip, no "--allow-external PyX" is needed anymore. Note that we completely stopped to distribute PyX on sourceforge. We also removed all file downloads and instead provide the previous releases on PyPI as well.
> 
> A very few bugs have also been fixed. See the full changelog below.
> 
> Happy PyXing,
> 
> 
> Jörg and André
> 
> 
> -------------
> 
> 0.14.1 (2015/11/02):
>   - distribution:
>     - upload to PyPI (including old releases)
>     - remove old releases from sourceforge
>   - text module:
>     - fix load_def message parser (reported by Mico Filós)
>   - normpath:
>     - fix intersect with empty normsubpaths (bug #62, thanks to Florent Hivert)

Tag pyx_0_14_1 was misplaced, by the way. (pyx/pyx vs. pyx)

Tag pyx_0_14 was the only one without mishap in a long time...

Maybe svn users don't care. (git-svn refetches the whole history because
of the different root dir - it's a different tree after all.)

Michael

[PyX-devel] ANN: PyX 0.14 released

[André W. <wo...@us...>]

Hi,

We've just released PyX 0.14.1. Starting from this release PyX is distributed at PyPI (see https://pypi.python.org/pypi), as pip will stop working with external hosted files in the near future (see https://www.python.org/dev/peps/pep-0470/). When installing via pip, no "--allow-external PyX" is needed anymore. Note that we completely stopped to distribute PyX on sourceforge. We also removed all file downloads and instead provide the previous releases on PyPI as well.

A very few bugs have also been fixed. See the full changelog below.

Happy PyXing,


Jörg and André


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

0.14.1 (2015/11/02):
  - distribution:
    - upload to PyPI (including old releases)
    - remove old releases from sourceforge
  - text module:
    - fix load_def message parser (reported by Mico Filós)
  - normpath:
    - fix intersect with empty normsubpaths (bug #62, thanks to Florent Hivert)

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] ANN: PyX 0.14 released

[André W. <wo...@us...>]

Hi all,

We're prod to to announce the release of PyX 0.14. This version adds SVG (Scaleable Vector Graphics) as an output format to PyX. SVG can also be read to include it unchanged to into the SVG output. In addition, even though with quite some limitations, SVG can be read, parsed, and then represented on the PyX graphics level. Here it can be modified and output not just to SVG, but also to the other output formats. Various improvements and bug fixes complete this release.

Happy PyXing,


Jörg and André



List of changes
===============

0.14 (2015/04/30):
  - new svgwriter module:
    - complete SVG output
    - SVG font output disabled by default due to missing support by
      most browsers, fallback by rendering fonts as paths
  - new svgfile module:
    - SVG reader
    - unparsed mode: embedd svg in other svg
    - parsed mode: supports reading paths (including styles,
      tranformations, etc.) into a PyX canvas
  - bitmap module:
    - using bytes in image type conversions and channel extraction
  - color module:
    - fix grey class
    - fix rgb css binary issue and short code index error
  - epsfile module:
    - fix parsing of bounding box
  - text module:
    - no end of pages test when no dvi is created at all
    - add chroot config option needed to use a chrooted TeX installation
  - graph module:
    - add xy12axesat feature to graphxyz
  - canvas module:
    - fix clipping and transformation applied together
    - provide _repr_svg_ in canvas for use by IPython
    - new constructor argument ipython_bboxenlarge
  - deco module:
    - remove shortcut for ornaments only to not skip global styles

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] [SPAM] Re: Strange behaviour of linkedaxis + manualticks + parter.autolinear

[Arnd B. <arn...@we...>]

Hi,

just in case it is of any help/relevance: I can reproduce the
problem with pyx.__version__ 0.12.1.

Best, Arnd

On Fri, 9 Jan 2015, Michael SCHINDLER wrote:

> Hello André,
>
> I found a strange behaviour of the axis partitioning, when combining
> it with manual ticks and a divisor. The x2-axis (which is
> automatically linked to x) has a tick at 10pi instead of a tick at pi.
> See the joint example.
>
> It would be great if you could see to it...
>
> Best,
>  Michael
>
>

[PyX-devel] Strange behaviour of linkedaxis + manualticks + parter.autolinear

[Michael S. <m-s...@us...>]

Hello André,

I found a strange behaviour of the axis partitioning, when combining
it with manual ticks and a divisor. The x2-axis (which is
automatically linked to x) has a tick at 10pi instead of a tick at pi.
See the joint example.

It would be great if you could see to it...

Best,
  Michael

Re: [PyX-devel] graph.data.points and iterables

[André W. <wo...@us...>]

Gert,

Thank you for the suggestion. You're right, and we should probably rethink the data handling. It is rather old code, and its design probably predates the Python 2.2 release, where iterators have been introduced. At least it was working on older Python versions for many years. I'm making myself a note and we can probably address this in one of the next releases.

Best,


André

Am 06.01.2014 um 09:19 schrieb Gert Ingold <ger...@ph...>:

> Dear André and Jörg,
> 
> first of all a happy (and productive;-) new year!
> 
> I just started to make my first plots with PyX 0.13 and came across
> the following problem. In graph.data.points I frequently use something
> like zip(xvals, yvals) where xvals would be e.g. a Numpy linspace and
> yvals is evaluated by applying Numpy functions to xvals. With Python 2 
> this
> works fine because zip produces a list. However, in Python 3, zip 
> produces an
> iterable which is not compatible with graph.data.points requiring an 
> object
> with a len-method. I am wondering whether it would make sense to 
> rewrite
> graph.data.points in such a way that it accepts iterables. It seems 
> that
> this would be more Python3-like. What do you think?
> 
> Best regards,
> Gert
> 
> -- 
> Gert-Ludwig Ingold      email: Ger...@Ph...
> Institut für Physik     Phone: +49-821-598-3234
> Universität Augsburg    Fax: +49-821-598-3222
> D-86135 Augsburg        WWW: www.physik.uni-augsburg.de/theo1/ingold
> Germany                 PGP: 86FF5A93, key available from homepage
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] graph.data.points and iterables

[Gert I. <ger...@ph...>]

Dear André and Jörg,

first of all a happy (and productive;-) new year!

I just started to make my first plots with PyX 0.13 and came across
the following problem. In graph.data.points I frequently use something
like zip(xvals, yvals) where xvals would be e.g. a Numpy linspace and
yvals is evaluated by applying Numpy functions to xvals. With Python 2 
this
works fine because zip produces a list. However, in Python 3, zip 
produces an
iterable which is not compatible with graph.data.points requiring an 
object
with a len-method. I am wondering whether it would make sense to 
rewrite
graph.data.points in such a way that it accepts iterables. It seems 
that
this would be more Python3-like. What do you think?

Best regards,
Gert

-- 
Gert-Ludwig Ingold      email: Ger...@Ph...
Institut für Physik     Phone: +49-821-598-3234
Universität Augsburg    Fax: +49-821-598-3222
D-86135 Augsburg        WWW: www.physik.uni-augsburg.de/theo1/ingold
Germany                 PGP: 86FF5A93, key available from homepage

[PyX-devel] ANN: PyX 0.13 released

[André W. <wo...@us...>]

Hi all,

We're prod to to announce the release of PyX 0.13. In this release PyX has been ported to Python 3. It now requires Python 3.2 and above, Python 2 is not supported by this release anymore. If you need to use Python 2, please use one of the previous releases.

Along with the port to Python 3 a major modernization of the text module was done, including some new documentation (based on Sphinx autodoc). We also added a sphinx theme to make the manual and the FAQ look like the PyX website.

The normpath now removes cusps by splitting normcurves as necessary. Thus there are no points on a normpath anymore, where no tangent, curvature, transformation, etc. are defined. The only discontinuities left are at the parameter values a switch from one path element to the next occurs (which is fine). Michael Schindler contributed some major improvements on the parallel deformer.

We also improved the usability within IPython and provide IPython notebook files for the examples. In fact, the gallery has completely removed from the subversion repository and is now a wiki on the sourceforge website featuring IPython notebooks as well. You are welcome to contribute to this resource [*].

Various improvements and fixes complete the release. Please find the full changelog below.

Happy PyXing,


Jörg and André


[*] At the moment I have troubles enabling this wiki for all sourceforge users. I have already opened a ticket to get the issue resolved.



List of changes
===============

0.13 (2013/12/20):
  - Requires at least Python 3.2
  - The gallery has been moved to https://sourceforge.net/p/pyx/gallery/, which
    is a wiki. Contributions are welcome.
  - filelocator module:
    - cygwin LaTeX with windows python patch (thanks to Sybren A. Stüvel)
  - graph styles:
    - fix numerical instability of line clippings
    - remove errorbar range checks, as they fail on a reverse axis, which is
      correct (reported by Néstor Espinoza)
  - path module:
    - fix internal name clash when generating a normpath from an empty path
      (reported by Brendon Higgins)
  - normpath module:
    - several stability and precision improvements and bugfixes
    - cusp removal at normpath construction (and getting rid of invalid
      results for curvature, rotation, tangent, and trafo methods)
    - remove curveradius methods as they are invalid for straigt paths
  - deco module:
    - apply text trafos to each character in curvedtext (reported by Hans L)
    - properly apply all textattrs in curvedtext (for example colors or scalings)
  - canvas module:
    - layer method takes layer names above or below (instead of an instance),
      also reorders layer accordingly when layer is already existing
    - remove the before and after arguments of insert
    - handle trafo and clip separately in constructor and write methods
    - allow for one clipping instance only
    - optimize graphics state stack usage
  - dvi/dvifile module:
    - change special handling for transformations and colors to use subcanvases
    - apply transformations to markers
  - trafos and styles are no longer canvasitems
  - style module:
    - fillrules are now fillstyles and handled within the PS/PDF context
  - text module:
    - new texenc setting
    - major code reorganization and documentation revision (now using autodoc)
  - font/afmfile module:
    - parse more AFM files, also some with common inconsistencies (thanks to
      Markus Schwienbacher for reporting these issues)
  - color module:
    - functiongradient has been split into functiongradient_rgb, etc. and
      the function parameters are now passed directly
    - lineargradient has been removed for factory functions lineargradient_rgb, etc.
      that provide linear gradients between colors of a particular color model
  - bitmap module:
    - fix jpegimage for progressive jpeg files (thanks to Michael Schindler)
  - pyxrc:
    - use APPDATA environment variable to locate the pyxrc on windows
    - tex, latex, kpsewhich, and locate executables are now customizable in the pyxrc
  - on the package level:
    - add pyxinfo to enable output of some useful information
  - manual:
    - PyX theme and various sphinx tweaks

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX and Python 3

[André W. <wo...@us...>]

Hi PyX developers,
(and PyX users, as some of our users probably work on the svn trunk as well),

I just moved the Python 2 PyX tree (the trunk) to:

  svn://svn.code.sf.net/p/pyx/code/branches/py2

The new trunk now is the Python 3 branch.

If you update your existing checkout with the repository url

  svn://svn.code.sf.net/p/pyx/code/trunk

without switching the repository url by an svn switch command,
you will now get the Python 3 version of PyX.

Happy PyXing,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX and Python 3

[Alan G I. <ai...@am...>]

On 7/14/2013 4:26 PM, André Wobst wrote:
> The surrogate escape error handling allows us the take
> Postscript code as ASCII, and if a file contains some non
> ASCII data (for example in comments or in strings, like
> a textual font name (we're not interested and just need to
> copy into the output)), it does not break. Another very
> helpful thing is, that you can use regular expressions
> both on strings and on bytes, either by using strings or
> bytes in the pattern to be matched.



Thank you for the interesting details.

Cheers,
Alan

Re: [PyX-devel] PyX and Python 3

[André W. <wo...@us...>]

Hi Alan,

Am 14.07.2013 um 22:01 schrieb Joerg Lehmann:
>> It would be great to have your thoughts on what you ran
>> into in the conversion process as true limits on the
>> practice of coding for Python 2.7 with an eye on using
>> the 2to3 tool to produce Python 3 code.
> 
> I cannot really comment on this because we did not try this. In
> retrospect, I would expect it to be possible to obtain a Python 2.7
> based version that would allow an automatic porting to Python 3. But
> given our limited resources we realy wanted to minimize the effort - and
> thought it to be more important, in the long run, to have a Python 3
> based version of PyX at all.


Jörg is right, we don't have experience in that. But it might still be interesting to you to learn about some of the major troubles we faced when switching to Python 3:

First of all I guess it really depends on the code base and the problems you're solving. In PyX we had (amongst others) two major problems to fix. First there where cyclic imports, which magically happened to work in Python 2 but needed to be resolved in Python 3. Secondly, PyX does reads and writes files, and we cannot assume a certain encoding for this. For example, when reading a Type 1 font, it contains both Postscript code (which is mostly ASCII), but also binary data (glyph programs in a special, very compact binary language). In addition, part of the file is encoded and encrypted at first ... you need to do this using bytes. On the other hand, the postscript code we write is ASCII (with minor exceptions), and in order to write something like "0.123 4.567 moveto" into the output, you have to use strings (formatting a number as a "string" can be done by creating strings only, not for bytes). In the end we needed to decide where to decode and encode the bytes and the strings. We hope to have found a proper solution, which happens to be more explicit and thus does for the better in the end. I still like the more explicit handling of encoded and decoded data, and fortunately, there are some very nice features available in Python. The surrogate escape error handling allows us the take Postscript code as ASCII, and if a file contains some non ASCII data (for example in comments or in strings, like a textual font name (we're not interested and just need to copy into the output)), it does not break. Another very helpful thing is, that you can use regular expressions both on strings and on bytes, either by using strings or bytes in the pattern to be matched. All this helped us a lot.

We decided to convert the PyX code by 2to3 and then resolve all the issues one by one. It would have been *way* more work to fix the original code and improve the translation step. In the end of the day we still have a working solution for Python 2, but the future is Python 3 only. Given our limited resources, this is the best we can offer. For our users the message should be rather clear: PyX is alive! You can use PyX 0.12 on Python 2.7 down to Python 2.3. And if you want to go for Python 3 in the future, just join our new releases to come.

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] PyX and Python 3

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

Alan,

On 14.07.13, Alan G Isaac wrote:
> On 7/14/2013 8:27 AM, Joerg Lehmann wrote:
> > Note that the next PyX release, which be plan to make in autumn, will
> > require at least Python 3.3! The alternative of supporting Python 2.7
> > and Python 3.3 in parallel is too cumbersome
> 
> 
> It would be great to have your thoughts on what you ran
> into in the conversion process as true limits on the
> practice of coding for Python 2.7 with an eye on using
> the 2to3 tool to produce Python 3 code.

I cannot really comment on this because we did not try this. In
retrospect, I would expect it to be possible to obtain a Python 2.7
based version that would allow an automatic porting to Python 3. But
given our limited resources we realy wanted to minimize the effort - and
thought it to be more important, in the long run, to have a Python 3
based version of PyX at all.

Cheers,

        Jörg

Re: [PyX-devel] PyX and Python 3

[Alan G I. <ai...@am...>]

On 7/14/2013 8:27 AM, Joerg Lehmann wrote:
> Note that the next PyX release, which be plan to make in autumn, will
> require at least Python 3.3! The alternative of supporting Python 2.7
> and Python 3.3 in parallel is too cumbersome


It would be great to have your thoughts on what you ran
into in the conversion process as true limits on the
practice of coding for Python 2.7 with an eye on using
the 2to3 tool to produce Python 3 code.

Thanks for PyX.

Alan

Re: [PyX-devel] PyX and Python 3

[David B. <dav...@ci...>]

Thanks for your continued work on PyX! Much appreciated.

Cheers
David
On Jul 14, 2013 2:12 PM, "Joerg Lehmann" <jo...@us...>
wrote:

> Dear PyX users,
>
> We just finished a couple of days of hacking on porting PyX to
> Python 3.3. The results of this effort are available in a separate
> branch, which you can checkout from
>
>    svn://svn.code.sf.net/p/pyx/code/branches/py3k
>
> All of our tests and examples (with one small exception) run, but there
> will for sure be corner cases we have not covered. So if you're
> interested in a PyX version compatible with Python 3, give it a try and
> report problems and bugs.
>
> Note that the next PyX release, which be plan to make in autumn, will
> require at least Python 3.3! The alternative of supporting Python 2.7
> and Python 3.3 in parallel is too cumbersome for us and we believe
> anyway that it is about time to move forward. For all who cannot
> follow us (yet), the current 0.12.1 release of PyX should work well for
> the next years.
>
> Cheers,
>
>         André and Jörg
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
>

[PyX-devel] PyX and Python 3

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

Dear PyX users,

We just finished a couple of days of hacking on porting PyX to
Python 3.3. The results of this effort are available in a separate
branch, which you can checkout from

   svn://svn.code.sf.net/p/pyx/code/branches/py3k

All of our tests and examples (with one small exception) run, but there
will for sure be corner cases we have not covered. So if you're
interested in a PyX version compatible with Python 3, give it a try and
report problems and bugs.

Note that the next PyX release, which be plan to make in autumn, will
require at least Python 3.3! The alternative of supporting Python 2.7
and Python 3.3 in parallel is too cumbersome for us and we believe
anyway that it is about time to move forward. For all who cannot
follow us (yet), the current 0.12.1 release of PyX should work well for
the next years.

Cheers,

        André and Jörg

Re: [PyX-devel] [pyx:support-requests] #3 pdf/eps from surface plot crashing on Mac OS 10.6

[André W. <wo...@us...>]

Michael,

Am 04.02.2013 um 09:51 schrieb Michael J Gruber:
> On Linux /Fedora 18 with python 2.7, recent TeXlive) I get these warnings
> 
> Warning: empty file.
> Warning: empty file.
> GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
> code = -1
> GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
> code = -1
> GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
> code = -1
> GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
> code = -1
> GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
> code = -1
> GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
> code = -1
> 
> and two output files which display fine, although they just look like
> the grayscale version of density(...), and in fact it looks the same
> when I just remove the gradient from the line above (rather than
> replacing density by surface). I don't get the empty file warnings for
> density(). I have no clue where in the source they come from.
> 
> Michael


This is funny. I'm running ghostscript 9.06 here as well, and it doesn't show this behavior. I'm on OS X 10.7 and ghostscript is installed by homebrew here (http://mxcl.github.com/homebrew/), so essentially it is self-compiled. I'm not using the X11 output, though, as it is not compiled into my version of ghostscript. Instead, I used the png16m device for my test here, and it works flawlessly both on the EPS and the PDF file with the surface style.

Best,


André

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] [pyx:support-requests] #3 pdf/eps from surface plot crashing on Mac OS 10.6

[Michael J G. <mic...@us...>]

Jorge Leitão venit, vidit, dixit 31.01.2013 17:18:
> ------------------------------------------------------------------------
> 
> *[support-requests:#3]
> <http://sourceforge.net/p/pyx/support-requests/3/> pdf/eps from surface
> plot crashing on Mac OS 10.6*
> 
> *Status:* open
> *Created:* Thu Jan 31, 2013 04:18 PM UTC by Jorge Leitão
> *Last Updated:* Thu Jan 31, 2013 04:18 PM UTC
> *Owner:* nobody
> 
> In the example of density plot
> <http://pyx.sourceforge.net/examples/graphstyles/density.html>, I tried
> to use "surface plot" instead of "density plot",
> 
> |
> g = graph.graphxy(height=8, width=8,
> x=graph.axis.linear(min=re_min, max=re_max, title=r"$\Re(c)$"),
> y=graph.axis.linear(min=im_min, max=im_max, title=r'$\Im(c)$'))
> g.plot(graph.data.points(d, x=1, y=2, color=3, title="iterations"),
> [graph.style.surface()]) # <<-- I changed this line|
> 
> g.writeEPSfile()
> g.writePDFfile()
> 
> Interestingly, I cannot open any of the files (EPS or PDF) using Mac OS
> 10.6: it crashes either the Finder or the Preview.
> 
> I have no clue why this is happening. Can anyone reproduce this behavior
> on a Linux/Windows machine to confirm it is a problem of the OS?

On Linux /Fedora 18 with python 2.7, recent TeXlive) I get these warnings

Warning: empty file.
Warning: empty file.
GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
code = -1
GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
code = -1
GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
code = -1
GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
code = -1
GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
code = -1
GPL Ghostscript 9.06: Error: Font Renderer Plugin ( FreeType ) return
code = -1

and two output files which display fine, although they just look like
the grayscale version of density(...), and in fact it looks the same
when I just remove the gradient from the line above (rather than
replacing density by surface). I don't get the empty file warnings for
density(). I have no clue where in the source they come from.

Michael

Re: [PyX-devel] [pyx:bugs] #59 bug on creating plots with iterable data

[Michael J G. <mic...@us...>]

> I've read the manual over and over and I found it not so clear. In page 44,
> 
> "The class symbol provides some symbol functions as member variables, namely:"
> 
> could be:
> 
> "The class symbol provides some pre-defined symbols functions as member variables which can be used as argument of symbol in graph.style.symbol(), namely:"
> 
> because:
> 1. they are not really functions, but rather att.changelist's (the module graph.style is the one who has the private functions) of the symbol.
> 2. It already suggests the reader how they are to be used.
> 
> Other important point is that if I want to create a custom symbol, it is non-trivial to see that it has to be of type att.changelist...
> 
> Anyway, maybe I'm being too picky about this, but I'm also trying to do an effort to push this project forward: I'm confident it has a lot of potential, and not so many people (at least in my community) is aware of it.
> 
> I'm would like to contribute to pyx; is there any guide for contributions for pyx? I saw the road map but it is quite "broad"... Do you accept patches, diffs, commits? I don't use svn for quite a while, but I contributed to some open-source projects before...


Hi Jorge,

yes, the documentation definitely could benefit from contributions. It's
mostly written in "German English" and from a developer's perspective. A
"pure user's view" could help a lot.

Also, I agree with you that PyX deserves more attention. I've impressed
many people with PyX output already, but we need to get more users.
Though it's frustrating when people ask you more about the software than
the research on the poster ;)

I'm not one of the core PyX developers, but from my experience here:
Patches (svn or git) are always welcome on the devel list, though there
are periods of lesser activity, so don't expect rapid responses.

There is also an unofficial git-svn mirror of the official svn tree at

https://github.com/mjg/PyX-svn

which I ususually keep up-to-date. (My own additions are separated out
at https://github.com/mjg/PyX; shame on github for not allowing me to
fork my own repo.)

This mirror is a straight git-svn conversion, the only exceptions being:

- I don't push out the "tag branches" which git-svn creates; rather, I
create proper annotated tags from those tagging commits with the same
commit message, tagger etc.

- In the case of botched tags (wrong root for the tree), I turn the
"layout fix commits" such as 3339 into merge commits between the botched
and the correct history, so that nothing is lost. Git's diff machinery
is then clever enough to detect the diff against the botched tree as a
move. Since these commits are in the "tag branches" they are not pushed out.

I could also push out these tag branches, of course, in case they are
useful for someone or are considered to make that mirror more complete.

Cheers
Michael

Re: [PyX-devel] [pyx:bugs] #59 bug on creating plots with iterable data

[Michael J G. <mic...@us...>]

Jorge Leitão venit, vidit, dixit 28.01.2013 11:41:
> ------------------------------------------------------------------------
> 
> *[bugs:#59] <http://sourceforge.net/p/pyx/bugs/59/> bug on creating
> plots with iterable data*
> 
> *Status:* open
> *Created:* Mon Jan 28, 2013 10:41 AM UTC by Jorge Leitão
> *Last Updated:* Mon Jan 28, 2013 10:41 AM UTC
> *Owner:* nobody
> 
> When using styles on a graph.plot with data as an iterable data, an
> error raised.
> 
> Minimal example:
> |
> from pyx import *|
> 
> g = graph.graphxy(width=8)
> 
> g.plot([graph.data.function("y(x)=exp(x)"),graph.data.function("y(x)=x**3")]
> <http://sourceforge.net/../graph.data.function("y(x)=exp(x)"),graph.data.function("y(x)=x**3")>,
> styles=[graph.style.symbol.changecircle]
> <http://sourceforge.net/../graph.style.symbol.changecircle>)
> 
> I will try to complete this ticket with more details when I have more time.

graph.style.symbol.changecircle is a symbol function, not a graph plot
style. You can use it as the symbol parameter of graph.style.symbol.

Michael

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3308] trunk/pyx/pyx/graph/style.py

[André W. <wo...@us...>]

Dear Jörg,

as far as I can see, Michael used a checkout with the old repository url here, the one we had before the Allura move. It is kind of unfortunate, that this repository url is still functional, but at a first sight I haven't seen an option to get rid of it.

Best,


André


Am 14.12.2012 um 21:40 schrieb Joerg Lehmann:

> Hi Michael,
> 
> I am rather confused about some of the changes below. See there.
> Btw, your changes also do not seem to be in SVN? At least, they
> do not appear when I update my checkout.
> 
> Cheers,
> 
>        Jörg
> 
> On 14.12.12, m-s...@us... wrote:
>> Revision: 3308
>>          http://pyx.svn.sourceforge.net/pyx/?rev=3308&view=rev
>> Author:   m-schindler
>> Date:     2012-12-14 14:27:47 +0000 (Fri, 14 Dec 2012)
>> Log Message:
>> -----------
>> fixed some little bugs in the density style of graphs
>> 
>> Modified Paths:
>> --------------
>>    trunk/pyx/pyx/graph/style.py
>> 
>> Modified: trunk/pyx/pyx/graph/style.py
>> ===================================================================
>> --- trunk/pyx/pyx/graph/style.py	2012-10-16 00:04:20 UTC (rev 3307)
>> +++ trunk/pyx/pyx/graph/style.py	2012-12-14 14:27:47 UTC (rev 3308)
>> @@ -162,7 +162,7 @@
>>         return self.gradient.getcolor(vc)
>> 
>>     def donedrawpoints(self, privatedata, sharedata, graph):
>> -        if self.keygraph is _autokeygraph:
>> +        if self.keygraph is not None:
>>             graph.layer("key").insert(privatedata.keygraph, [graph.autokeygraphtrafo(privatedata.keygraph)])
>> 
>> 
>> @@ -1976,23 +1976,23 @@
>>                     if v1 is None:
>>                         privatedata.vfixed[i] = v2
>>                     elif abs(v1-v2) > self.epsilon:
>> -                        raise ValueError("data must be in a plane for the bitmap style")
>> +                        raise ValueError("data must be in a plane for the density style")
>> 
>>     def donedrawpoints(self, privatedata, sharedata, graph):
>>         privatedata.keygraph.doaxes()
>> 
>>         values1 = pycompat.sorted(sharedata.values1.keys())
>>         values2 = pycompat.sorted(sharedata.values2.keys())
>> -        def equidistant(values):
>> +        def check_equidistant(values):
>>             l = len(values) - 1
>>             if l < 1:
>> -                raise ValueError("several data points required by the bitmap style in each dimension")
>> +                raise ValueError("several data points required by the density style in each dimension")
>>             range = values[-1] - values[0]
>>             for i, value in enumerate(values):
>>                 if abs(value - values[0] - i * range / l) > self.epsilon:
>> -                    raise ValueError("data must be equidistant for the bitmap style")
>> -        equidistant(values1)
>> -        equidistant(values2)
>> +                    raise ValueError("data must be equidistant for the density style")
>> +        check_equidistant(values1)
>> +        check_equidistant(values2)
>>         needalpha = False
>>         for value2 in values2:
>>             for value1 in values1:
>> @@ -2024,7 +2024,11 @@
>>                 if not available:
>>                     data.write(empty)
>>                     continue
>> -                c = privatedata.colors[value1][value2]
>> +                try:
>> +                    c = privatedata.colors[value1][value2]
>> +                except KeyError:
>> +                    data.write(empty)
>> +                    continue
>>                 c = self.color(privatedata, c)
>>                 if needalpha:
>>                     data.write(chr(255))
>> @@ -2049,7 +2053,7 @@
>>         privatedata.vfixed[sharedata.index2] = values2[0]-v2enlargement
>>         vx4, vy4 = t.inverse().apply_pt(*graph.vpos_pt(*privatedata.vfixed))
>>         if abs(vx4 - 1) > self.epsilon or abs(vy4 - 1) > self.epsilon:
>> -            raise ValueError("invalid graph layout for bitmap style (bitmap positioning by affine transformation failed)")
>> +            raise ValueError("invalid graph layout for density style (bitmap positioning by affine transformation failed)")
>> 
>>         p = path.path()
>>         privatedata.vfixed[sharedata.index1] = 0
>> @@ -2116,13 +2120,19 @@
> 
> The following things had already been fixed (in a simpler way) by André
> in the brown pager bug changesets 3331 and 3332. Your changeset seems
> to be refering to an older revision!?
> 
>>                 "/DeviceRGB": "RGB",
>>                 "/DeviceCMYK": "CMYK"}[self.gradient.getcolor(0).colorspacestring()]
>>         data = cStringIO.StringIO()
>> -        for i in builtinrange(self.resolution):
>> -            c = self.gradient.getcolor(i*1.0/self.resolution)
>> -            data.write(c.to8bitstring())
>> -        i = bitmap.image(self.resolution, 1, mode, data.getvalue())
>> +        if graph.flipped:
>> +            for i in builtinrange(self.resolution):
>> +                c = self.gradient.getcolor(i*1.0/self.resolution)
>> +                data.write(c.to8bitstring())
>> +            i = bitmap.image(self.resolution, 1, mode, data.getvalue())
>> +        else:
>> +            for i in builtinrange(self.resolution):
>> +                c = self.gradient.getcolor(1.0-i*1.0/self.resolution)
>> +                data.write(c.to8bitstring())
>> +            i = bitmap.image(1, self.resolution, mode, data.getvalue())
>> 
>> -        llx_pt, lly_pt = graph.vpos_pt(0-0.5/(self.resolution-1))
>> -        urx_pt, ury_pt = graph.vpos_pt(1+0.5/(self.resolution-1))
>> +        llx_pt, lly_pt = graph.vpos_pt(0)
>> +        urx_pt, ury_pt = graph.vpos_pt(1)
>>         if graph.direction == "horizontal":
>>             lly_pt -= 0.5*graph.height_pt
>>             ury_pt += 0.5*graph.height_pt
>> @@ -2132,7 +2142,7 @@
>> 
>>         t = trafo.trafo_pt(((0, urx_pt-llx_pt), (ury_pt-lly_pt, 0)), (llx_pt, lly_pt))
>> 
>> -        c = canvas.canvas([canvas.clip(path.rect_pt(llx_pt, lly_pt, urx_pt, ury_pt))])
>> +        c = canvas.canvas([canvas.clip(path.rect_pt(llx_pt, lly_pt, urx_pt-llx_pt, ury_pt-lly_pt))])
>>         b = bitmap.bitmap_trafo(t, i)
>>         c.insert(b)
>>         graph.layer("filldata").insert(c)
>> 
>> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
>> 
>> 
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> PyX-checkins mailing list
>> PyX...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyx-checkins
>> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> PyX-checkins mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-checkins

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3308] trunk/pyx/pyx/graph/style.py

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

Hi Michael,

I am rather confused about some of the changes below. See there.
Btw, your changes also do not seem to be in SVN? At least, they
do not appear when I update my checkout.

Cheers,

        Jörg

On 14.12.12, m-s...@us... wrote:
> Revision: 3308
>           http://pyx.svn.sourceforge.net/pyx/?rev=3308&view=rev
> Author:   m-schindler
> Date:     2012-12-14 14:27:47 +0000 (Fri, 14 Dec 2012)
> Log Message:
> -----------
> fixed some little bugs in the density style of graphs
> 
> Modified Paths:
> --------------
>     trunk/pyx/pyx/graph/style.py
> 
> Modified: trunk/pyx/pyx/graph/style.py
> ===================================================================
> --- trunk/pyx/pyx/graph/style.py	2012-10-16 00:04:20 UTC (rev 3307)
> +++ trunk/pyx/pyx/graph/style.py	2012-12-14 14:27:47 UTC (rev 3308)
> @@ -162,7 +162,7 @@
>          return self.gradient.getcolor(vc)
>  
>      def donedrawpoints(self, privatedata, sharedata, graph):
> -        if self.keygraph is _autokeygraph:
> +        if self.keygraph is not None:
>              graph.layer("key").insert(privatedata.keygraph, [graph.autokeygraphtrafo(privatedata.keygraph)])
>  
>  
> @@ -1976,23 +1976,23 @@
>                      if v1 is None:
>                          privatedata.vfixed[i] = v2
>                      elif abs(v1-v2) > self.epsilon:
> -                        raise ValueError("data must be in a plane for the bitmap style")
> +                        raise ValueError("data must be in a plane for the density style")
>  
>      def donedrawpoints(self, privatedata, sharedata, graph):
>          privatedata.keygraph.doaxes()
>  
>          values1 = pycompat.sorted(sharedata.values1.keys())
>          values2 = pycompat.sorted(sharedata.values2.keys())
> -        def equidistant(values):
> +        def check_equidistant(values):
>              l = len(values) - 1
>              if l < 1:
> -                raise ValueError("several data points required by the bitmap style in each dimension")
> +                raise ValueError("several data points required by the density style in each dimension")
>              range = values[-1] - values[0]
>              for i, value in enumerate(values):
>                  if abs(value - values[0] - i * range / l) > self.epsilon:
> -                    raise ValueError("data must be equidistant for the bitmap style")
> -        equidistant(values1)
> -        equidistant(values2)
> +                    raise ValueError("data must be equidistant for the density style")
> +        check_equidistant(values1)
> +        check_equidistant(values2)
>          needalpha = False
>          for value2 in values2:
>              for value1 in values1:
> @@ -2024,7 +2024,11 @@
>                  if not available:
>                      data.write(empty)
>                      continue
> -                c = privatedata.colors[value1][value2]
> +                try:
> +                    c = privatedata.colors[value1][value2]
> +                except KeyError:
> +                    data.write(empty)
> +                    continue
>                  c = self.color(privatedata, c)
>                  if needalpha:
>                      data.write(chr(255))
> @@ -2049,7 +2053,7 @@
>          privatedata.vfixed[sharedata.index2] = values2[0]-v2enlargement
>          vx4, vy4 = t.inverse().apply_pt(*graph.vpos_pt(*privatedata.vfixed))
>          if abs(vx4 - 1) > self.epsilon or abs(vy4 - 1) > self.epsilon:
> -            raise ValueError("invalid graph layout for bitmap style (bitmap positioning by affine transformation failed)")
> +            raise ValueError("invalid graph layout for density style (bitmap positioning by affine transformation failed)")
>  
>          p = path.path()
>          privatedata.vfixed[sharedata.index1] = 0
> @@ -2116,13 +2120,19 @@

The following things had already been fixed (in a simpler way) by André
in the brown pager bug changesets 3331 and 3332. Your changeset seems
to be refering to an older revision!?

>                  "/DeviceRGB": "RGB",
>                  "/DeviceCMYK": "CMYK"}[self.gradient.getcolor(0).colorspacestring()]
>          data = cStringIO.StringIO()
> -        for i in builtinrange(self.resolution):
> -            c = self.gradient.getcolor(i*1.0/self.resolution)
> -            data.write(c.to8bitstring())
> -        i = bitmap.image(self.resolution, 1, mode, data.getvalue())
> +        if graph.flipped:
> +            for i in builtinrange(self.resolution):
> +                c = self.gradient.getcolor(i*1.0/self.resolution)
> +                data.write(c.to8bitstring())
> +            i = bitmap.image(self.resolution, 1, mode, data.getvalue())
> +        else:
> +            for i in builtinrange(self.resolution):
> +                c = self.gradient.getcolor(1.0-i*1.0/self.resolution)
> +                data.write(c.to8bitstring())
> +            i = bitmap.image(1, self.resolution, mode, data.getvalue())
>  
> -        llx_pt, lly_pt = graph.vpos_pt(0-0.5/(self.resolution-1))
> -        urx_pt, ury_pt = graph.vpos_pt(1+0.5/(self.resolution-1))
> +        llx_pt, lly_pt = graph.vpos_pt(0)
> +        urx_pt, ury_pt = graph.vpos_pt(1)
>          if graph.direction == "horizontal":
>              lly_pt -= 0.5*graph.height_pt
>              ury_pt += 0.5*graph.height_pt
> @@ -2132,7 +2142,7 @@
>  
>          t = trafo.trafo_pt(((0, urx_pt-llx_pt), (ury_pt-lly_pt, 0)), (llx_pt, lly_pt))
>  
> -        c = canvas.canvas([canvas.clip(path.rect_pt(llx_pt, lly_pt, urx_pt, ury_pt))])
> +        c = canvas.canvas([canvas.clip(path.rect_pt(llx_pt, lly_pt, urx_pt-llx_pt, ury_pt-lly_pt))])
>          b = bitmap.bitmap_trafo(t, i)
>          c.insert(b)
>          graph.layer("filldata").insert(c)
> 
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> PyX-checkins mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-checkins
>