pyx-devel — PyX development

Re: [PyX-devel] [PATCH 1/2] Fix epsfile(kpsearch=1)

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

Hi Michael,

correct, thanks a lot! I applied the fix (with some slight modifications) in changeset 3201.

Best,


André


Am 13.07.2011 um 16:28 schrieb Michael J Gruber:

> b1b3a96 (use new filelocator code, 2011-05-14) broke kpsearch
> functionality for epsfile.epsfile() because use of the filelocator was
> moved after the determination of an initial bbox, which has to open the
> file unless a bbox was specified.
> 
> Make _readbox() pass kpsearch and appropriate formats to
> linefilereader(), and make linefilereader() use the new filelocator
> accordingly.
> 
> Signed-off-by: Michael J Gruber <mic...@us...>
> ---
> pyx/epsfile.py |   14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/pyx/epsfile.py b/pyx/epsfile.py
> index 4c5fda5..dd1b247 100644
> --- a/pyx/epsfile.py
> +++ b/pyx/epsfile.py
> @@ -65,7 +65,7 @@ class linefilereader:
>     #       in the DSC spec #5001, while '\n\r' *is* a *single* linebreak
>     #       according to the EPSF spec #5002
> 
> -    def __init__(self, filename, typicallinelen=257):
> +    def __init__(self, filename, typicallinelen=257, kpsearch=0, formats=[]):
>         """Opens the file filename for reading.
> 
>         typicallinelen defines the default buffer increase
> @@ -74,8 +74,10 @@ class linefilereader:
>         # note: The maximal line size in an EPS is 255 plus the
>         #       linebreak characters. However, we also handle
>         #       lines longer than that.
> -
> -        self.file = open(filename, "rb")
> +        if kpsearch:
> +            self.file = filelocator.open(filename, formats, "rb")
> +        else:
> +            self.file = open(filename, "rb")
>         self.buffer = ""
>         self.typicallinelen = typicallinelen
> 
> @@ -138,10 +140,10 @@ class linefilereader:
>         self.file.close()
> 
> 
> -def _readbbox(filename):
> +def _readbbox(filename, kpsearch=0):
>     """returns bounding box of EPS file filename"""
> 
> -    file = linefilereader(filename)
> +    file = linefilereader(filename, kpsearch=kpsearch, formats=[filelocator.format.pict])
> 
>     # check the %! header comment
>     if not file.readline().startswith("%!"):
> @@ -248,7 +250,7 @@ class epsfile(canvasitem.canvasitem):
>         self.y_pt = unit.topt(y)
>         self.filename = filename
>         self.kpsearch = kpsearch
> -        self.mybbox = bbox or _readbbox(self.filename)
> +        self.mybbox = bbox or _readbbox(self.filename, kpsearch)
> 
>         # determine scaling in x and y direction
>         self.scalex = self.scaley = scale
> -- 
> 1.7.6.336.gdf067
> 
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> 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/

Re: [PyX-devel] [PATCH 2/2] Correct the name for the pict format

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

Hi Michael,

as far as I checked this libkpathsea uses the singular form consistently. Clearly a bug in PyX. Fixed in changeset 3203. Thank you.

Best,


André


Am 13.07.2011 um 16:28 schrieb Michael J Gruber:

> kpsearch -help says "graphic/figure".
> In fact, this makes no difference, and may be a typo in kpsearch.
> ---
> Optional, of course, dunno what more recent kpsearch says.
> 
> pyx/filelocator.py |    2 +-
> pyx/pykpathsea.c   |    2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/pyx/filelocator.py b/pyx/filelocator.py
> index 69bec5c..cd55037 100644
> --- a/pyx/filelocator.py
> +++ b/pyx/filelocator.py
> @@ -281,7 +281,7 @@ class format:
> format.tfm = format("tfm", [".tfm"])
> format.afm = format("afm", [".afm"])
> format.fontmap = format("map", [])
> -format.pict = format("graphics/figure", [".eps", ".epsi"])
> +format.pict = format("graphic/figure", [".eps", ".epsi"])
> format.tex_ps_header = format("PostScript header", [".pro"])                    # contains also: enc files
> format.type1 = format("type1 fonts", [".pfa", ".pfb"])
> format.vf = format("vf", [".vf"])
> diff --git a/pyx/pykpathsea.c b/pyx/pykpathsea.c
> index 72a7a8d..b26d431 100644
> --- a/pyx/pykpathsea.c
> +++ b/pyx/pykpathsea.c
> @@ -56,7 +56,7 @@ static PyObject *py_kpse_find_file(PyObject *self, PyObject *args)
>     /* if (!strcmp(format, "otp")) kpse_file_format = kpse_otp_format; else */
>     /* if (!strcmp(format, "ovf")) kpse_file_format = kpse_ovf_format; else */
>     /* if (!strcmp(format, "ovp")) kpse_file_format = kpse_ovp_format; else */
> -    if (!strcmp(format, "graphics/figure")) kpse_file_format = kpse_pict_format; else
> +    if (!strcmp(format, "graphic/figure")) kpse_file_format = kpse_pict_format; else
>     /* if (!strcmp(format, "tex")) kpse_file_format = kpse_tex_format; else */
>     /* if (!strcmp(format, "TeX system documentation")) kpse_file_format = kpse_texdoc_format; else */
>     /* if (!strcmp(format, "texpool")) kpse_file_format = kpse_texpool_format; else */
> -- 
> 1.7.6.336.gdf067
> 
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> 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 2/2] Correct the name for the pict format

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

kpsearch -help says "graphic/figure".
In fact, this makes no difference, and may be a typo in kpsearch.
---
Optional, of course, dunno what more recent kpsearch says.

 pyx/filelocator.py |    2 +-
 pyx/pykpathsea.c   |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/pyx/filelocator.py b/pyx/filelocator.py
index 69bec5c..cd55037 100644
--- a/pyx/filelocator.py
+++ b/pyx/filelocator.py
@@ -281,7 +281,7 @@ class format:
 format.tfm = format("tfm", [".tfm"])
 format.afm = format("afm", [".afm"])
 format.fontmap = format("map", [])
-format.pict = format("graphics/figure", [".eps", ".epsi"])
+format.pict = format("graphic/figure", [".eps", ".epsi"])
 format.tex_ps_header = format("PostScript header", [".pro"])                    # contains also: enc files
 format.type1 = format("type1 fonts", [".pfa", ".pfb"])
 format.vf = format("vf", [".vf"])
diff --git a/pyx/pykpathsea.c b/pyx/pykpathsea.c
index 72a7a8d..b26d431 100644
--- a/pyx/pykpathsea.c
+++ b/pyx/pykpathsea.c
@@ -56,7 +56,7 @@ static PyObject *py_kpse_find_file(PyObject *self, PyObject *args)
     /* if (!strcmp(format, "otp")) kpse_file_format = kpse_otp_format; else */
     /* if (!strcmp(format, "ovf")) kpse_file_format = kpse_ovf_format; else */
     /* if (!strcmp(format, "ovp")) kpse_file_format = kpse_ovp_format; else */
-    if (!strcmp(format, "graphics/figure")) kpse_file_format = kpse_pict_format; else
+    if (!strcmp(format, "graphic/figure")) kpse_file_format = kpse_pict_format; else
     /* if (!strcmp(format, "tex")) kpse_file_format = kpse_tex_format; else */
     /* if (!strcmp(format, "TeX system documentation")) kpse_file_format = kpse_texdoc_format; else */
     /* if (!strcmp(format, "texpool")) kpse_file_format = kpse_texpool_format; else */
-- 
1.7.6.336.gdf067

[PyX-devel] [PATCH 1/2] Fix epsfile(kpsearch=1)

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

b1b3a96 (use new filelocator code, 2011-05-14) broke kpsearch
functionality for epsfile.epsfile() because use of the filelocator was
moved after the determination of an initial bbox, which has to open the
file unless a bbox was specified.

Make _readbox() pass kpsearch and appropriate formats to
linefilereader(), and make linefilereader() use the new filelocator
accordingly.

Signed-off-by: Michael J Gruber <mic...@us...>
---
 pyx/epsfile.py |   14 ++++++++------
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/pyx/epsfile.py b/pyx/epsfile.py
index 4c5fda5..dd1b247 100644
--- a/pyx/epsfile.py
+++ b/pyx/epsfile.py
@@ -65,7 +65,7 @@ class linefilereader:
     #       in the DSC spec #5001, while '\n\r' *is* a *single* linebreak
     #       according to the EPSF spec #5002
 
-    def __init__(self, filename, typicallinelen=257):
+    def __init__(self, filename, typicallinelen=257, kpsearch=0, formats=[]):
         """Opens the file filename for reading.
 
         typicallinelen defines the default buffer increase
@@ -74,8 +74,10 @@ class linefilereader:
         # note: The maximal line size in an EPS is 255 plus the
         #       linebreak characters. However, we also handle
         #       lines longer than that.
-
-        self.file = open(filename, "rb")
+        if kpsearch:
+            self.file = filelocator.open(filename, formats, "rb")
+        else:
+            self.file = open(filename, "rb")
         self.buffer = ""
         self.typicallinelen = typicallinelen
 
@@ -138,10 +140,10 @@ class linefilereader:
         self.file.close()
 
 
-def _readbbox(filename):
+def _readbbox(filename, kpsearch=0):
     """returns bounding box of EPS file filename"""
 
-    file = linefilereader(filename)
+    file = linefilereader(filename, kpsearch=kpsearch, formats=[filelocator.format.pict])
 
     # check the %! header comment
     if not file.readline().startswith("%!"):
@@ -248,7 +250,7 @@ class epsfile(canvasitem.canvasitem):
         self.y_pt = unit.topt(y)
         self.filename = filename
         self.kpsearch = kpsearch
-        self.mybbox = bbox or _readbbox(self.filename)
+        self.mybbox = bbox or _readbbox(self.filename, kpsearch)
 
         # determine scaling in x and y direction
         self.scalex = self.scaley = scale
-- 
1.7.6.336.gdf067

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3176] trunk/pyx

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

(I just noticed that I missed to send a copy of my answer to the list, so I'm sending it again.)

Dear Michael,

overall I like this module very much. Some random remarks from a quick review:

You could use self.x_pt etc. internally instead of self.x to remind yourself, that those properties are not PyX length internally anymore. We did so in the path module. Jörg and I kind of agreed and like this convention. You already did that in part of the code (like controlcurve_pt), but in other cases you didn't (like knot_pt).

The float comparisions should probably use an epsilon. In _mp_make_choices the comparisons look similar to the epsilon we have in normpath (epsilon in units of pt). This epsilon could be a parameter of the path, defaulting to 1e-5pt. However, this would mean you can't use *elems to receive the list of elements. Instead path should take a list of elements. We had this issue at other places as well and resolved it by using lists. I suggest to do it here too.

In _mp_solve_choices the comparisions are probably similar to the epsilon found at various places in the graph (epsilon in units of 1 like the graph coordinates). It could also be a named parameter of the path. We need a second name for this epsilon. We could rename this other epsilon in the graph too, no problem. Suggestions?

isinstance is not a pythonic solution. Maybe you could check for attributes to distinguish between the different types. But, well, probably just ignore this comment.

I suggest to move this module into a directory metapost (in favor of mpost) and name it path. This module really is about metapost path creation and there are other things in metapost, we can implement too (like the linear equation solver; we already have some code for that, which is however not yet integrated in PyX).

The module needs some documentation in the manual. Some very small documentation will probably do the job, but without any documentation, most users probably won't notice this functionality at all.

Do you understand why you can't reproduce some cases in the functional examples? I didn't even tried to understand that.

Best,


André



Am 04.07.2011 um 12:35 schrieb Michael SCHINDLER:

> Salut André and Jörg,
> 
> I added a module to imitate the path construction technique of
> MetaPost. The original idea was to have a means to easily get
> nice-looking smooth curves, for example to be used in simple cases of
> function plotting. I was first considering to write a
> graph.style.curve class, but did not know how to do this properly
> without refined re-evaluation of points. Now, it would be rather a
> deformer which takes the series of lines and turns it into curves. The
> result is then at the responsability of the user (data representation
> _is_ difficult).
> 
> In my first attempts, I tried to directly use the C code of MetaPost,
> but there is so much initialisation going on, that I did not succeed.
> So, I translated the C code, which is based on integer arithmetics
> into double-based Python code. I left as much of the original
> structure as I could (that's why there are so many functions _mp_*).
> 
> For the interface, I scratched my head for quite some time. The
> essential task is to reasonably distribute the different properties of
> the metapost knots (smooth tangents, curlyness, given direction,
> endpoint, ... see mpman.pdf) to some classes. I now did it like this:
> 
> * For me, the tension is a property of the link, although what is
>  specified are the tensions at its end. This is why I have a
>  tensioncurve.
> * If control points are specified manually, also the metapost language
>  only allows to specify both of them for one curve element. And I
>  think that is required also in the internals of the algorithm.
>  So, I kept that and made a controlcurve.
> 
> * The remaining three properties,
>    endpoint
>    curlyness
>    tangent direction
>  are kept as properties of the knots.
> 
> Please have a look at it to see whether the logics is consistent and
> convenient in your minds as well. There are some examples in the
> interface() routine of test/functional/test_mpost.py
> 
> Michael
> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> 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/

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3176] trunk/pyx

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

Salut André and Jörg,

I added a module to imitate the path construction technique of
MetaPost. The original idea was to have a means to easily get
nice-looking smooth curves, for example to be used in simple cases of
function plotting. I was first considering to write a
graph.style.curve class, but did not know how to do this properly
without refined re-evaluation of points. Now, it would be rather a
deformer which takes the series of lines and turns it into curves. The
result is then at the responsability of the user (data representation
_is_ difficult).

In my first attempts, I tried to directly use the C code of MetaPost,
but there is so much initialisation going on, that I did not succeed.
So, I translated the C code, which is based on integer arithmetics
into double-based Python code. I left as much of the original
structure as I could (that's why there are so many functions _mp_*).

For the interface, I scratched my head for quite some time. The
essential task is to reasonably distribute the different properties of
the metapost knots (smooth tangents, curlyness, given direction,
endpoint, ... see mpman.pdf) to some classes. I now did it like this:

* For me, the tension is a property of the link, although what is
  specified are the tensions at its end. This is why I have a
  tensioncurve.
* If control points are specified manually, also the metapost language
  only allows to specify both of them for one curve element. And I
  think that is required also in the internals of the algorithm.
  So, I kept that and made a controlcurve.

* The remaining three properties,
    endpoint
    curlyness
    tangent direction
  are kept as properties of the knots.

Please have a look at it to see whether the logics is consistent and
convenient in your minds as well. There are some examples in the
interface() routine of test/functional/test_mpost.py

Michael

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3162] trunk/pyx/pyx/font/t1file.py

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

Hi,

there is some written convention on that! It is about making Type1 fonts readable for software which does not include a full PostScript interpreter. This whole issue is discussed in the Type1 Spec (seehttp://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF) in chapter 10. However, from that document it is not clear that the "dup <index> <charactername> put" command sequence is required to be started at a new line each. Still, it is probably a good idea (and PyX just missed to do so for the very first item). Michael, your fix in changeset 3162 is perfectly fine to resolve this issue you observed using certain programs. As Jörg suggested already it is perfectly fine to adjust the PyX output to make it most compatible.

Best,


André


Am 30.05.2011 um 13:56 schrieb Joerg Lehmann:

> Hello Michael,
> 
> On 30.05.11, Michael SCHINDLER wrote:
>> On 30/05/11, Joerg Lehmann wrote:
>>> Interesting! This looks like a limitation in the PDF engine(s) of
>>> xpdf & Co. A brief look through Adobe's Type-1-font documentation
>>> did not reveal the significance of whitespace in the defintion
>>> of the encoding array.
>> 
>> Yes, you are totally right. I was about to send the bug report to the
>> xpdf developers, but then I realized that in the original pfb file,
>> the "dup"s come one per line. So, even if we are not strictly breaking
>> the functionality according to the rules of PDF, I thought it would be
>> reasonable to add the newline.
> 
> Probably there is some kind of unwritten convention to structure the
> Type 1 font like is in order to simplify its parsing. Anyway, it does
> not make sense to just point to the standard here. The main point is
> that files produced with PyX work on as many output devices as possible,
> so your change is definitely the right thing to do.
> 
> Cheers,
> 
>        Jörg
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery, 
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now. 
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> 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/

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3162] trunk/pyx/pyx/font/t1file.py

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

Hello Michael,

On 30.05.11, Michael SCHINDLER wrote:
> On 30/05/11, Joerg Lehmann wrote:
> > Interesting! This looks like a limitation in the PDF engine(s) of
> > xpdf & Co. A brief look through Adobe's Type-1-font documentation
> > did not reveal the significance of whitespace in the defintion
> > of the encoding array.
> 
> Yes, you are totally right. I was about to send the bug report to the
> xpdf developers, but then I realized that in the original pfb file,
> the "dup"s come one per line. So, even if we are not strictly breaking
> the functionality according to the rules of PDF, I thought it would be
> reasonable to add the newline.

Probably there is some kind of unwritten convention to structure the
Type 1 font like is in order to simplify its parsing. Anyway, it does
not make sense to just point to the standard here. The main point is
that files produced with PyX work on as many output devices as possible,
so your change is definitely the right thing to do.

Cheers,

        Jörg

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3162] trunk/pyx/pyx/font/t1file.py

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

Hello Jörg,

On 30/05/11, Joerg Lehmann wrote:
> Interesting! This looks like a limitation in the PDF engine(s) of
> xpdf & Co. A brief look through Adobe's Type-1-font documentation
> did not reveal the significance of whitespace in the defintion
> of the encoding array.

Yes, you are totally right. I was about to send the bug report to the
xpdf developers, but then I realized that in the original pfb file,
the "dup"s come one per line. So, even if we are not strictly breaking
the functionality according to the rules of PDF, I thought it would be
reasonable to add the newline.

Michael

Re: [PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3162] trunk/pyx/pyx/font/t1file.py

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

Hello Michael,

On 30.05.11, Michael SCHINDLER wrote:
> Here is some additional info to changeset 3162:
> 
> The minimal example:
> 
> -----
> from pyx import *
> text.set(mode="latex")
> text.preamble(r"\usepackage{mathptmx}")
> c = canvas.canvas()
> c.text(0, 0, r"$\delta$")
> d = document.document([document.page(c)])
> d.writePDFfile("minimal", compress=False)
> -----
> 
> The character $\delta$ does not show up if displayed using xpdf, evince, or
> okular (acroread and Skim do not have problems). The problematic PDF is
> attached.

> 
> The problem can be boiled down to the encoding of the partially included font:
> In the non-working file the font encoding is given as
> 
>   /Encoding 256 array
>   0 1 255 {1 index exch /.notdef put} for dup 100 /delta put
>   readonly def
> 
> If I change it manually to
> 
>   /Encoding 256 array
>   0 1 255 {1 index exch /.notdef put} for
>   dup 100 /delta put
>   readonly def
> 
> then it works.

Interesting! This looks like a limitation in the PDF engine(s) of
xpdf & Co. A brief look through Adobe's Type-1-font documentation
did not reveal the significance of whitespace in the defintion
of the encoding array.

Cheers,

        Jörg

[PyX-devel] [PyX-checkins] SF.net SVN: pyx:[3162] trunk/pyx/pyx/font/t1file.py

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

Hello,

Here is some additional info to changeset 3162:

The minimal example:

-----
from pyx import *
text.set(mode="latex")
text.preamble(r"\usepackage{mathptmx}")
c = canvas.canvas()
c.text(0, 0, r"$\delta$")
d = document.document([document.page(c)])
d.writePDFfile("minimal", compress=False)
-----

The character $\delta$ does not show up if displayed using xpdf, evince, or
okular (acroread and Skim do not have problems). The problematic PDF is
attached.

The problem can be boiled down to the encoding of the partially included font:
In the non-working file the font encoding is given as

  /Encoding 256 array
  0 1 255 {1 index exch /.notdef put} for dup 100 /delta put
  readonly def

If I change it manually to

  /Encoding 256 array
  0 1 255 {1 index exch /.notdef put} for
  dup 100 /delta put
  readonly def

then it works.

Michael

P.S: The font is usyr.pfb from the URW fonts in Debian squeeze.

[PyX-devel] [ pyx-Patches-1929430 ] Fix: setup.py chokes on paths with forward slashes

[SourceForge.net <no...@so...>]

Patches item #1929430, was opened at 2008-03-30 17:14
Message generated for change (Settings changed) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=1929430&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sue Ann Koay (sueannkoay)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix: setup.py chokes on paths with forward slashes

Initial Comment:
Running setup.py on Windows, non-default paths (via the --home option) produces an error that had me stumped for the longest time:


byte-compiling C:\Software\ELog\xampplite\htdocs\osetology_wordpress\wp-content\plugins\lib\python\pyx\siteconfig.py to siteconfig.pyc
Sorry: ValueError: ('invalid \\x escape',)



This is solveable by a simple change in the type of string used in the configuration to raw:

Change line 131 of setup.py, i.e. the "def run(self)" for "class pyx_install_data(install_data)":


self.siteconfiglines.append("%s = r'%s'\n" % (siteconfignames[files], dir))


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

>Comment By: Andre Wobst (wobsta)
Date: 2011-05-20 20:26

Message:
This issue has been resolved by the recent release 0.11, which removed
siteconfig altogether. PyX data files are now placed along the modules as
it is common practice in Python and most supported by distutils, setuptools
and the like.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=1929430&group_id=45430

[PyX-devel] ANN: PyX 0.11.1 released

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

Hi all,

we just released PyX 0.11.1. This release fixes a few bugs, most importantly the extension build process. The manual has been been ported to Sphinx. You can now install PyX using easy_install and pip.

Enjoy,


André

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

0.11.1 (2011/05/20):
  - canvas:
    - fix pipeGS (adding support for writing using pycompat.popen)
  - deco module:
    - arrow decorator: proper sign of constriction length for positioning
      reversed arrows
  - dvi/texfont:
    - fix exception type
    - increase designsize deviation to 4 (needs some further investigation)
  - contrib files:
    - fixes due to the dvi and font restructuring
  - setup.py:
    - fix build process for extension modules
    - fix download url to allow for easy_install (hopefully)
  - manual:
    - converted to sphinx


-- 
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] ANN: PyX 0.11 released

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

Joerg Lehmann venit, vidit, dixit 16.05.2011 23:09:
> Hi Michael,
> 
> On 16.05.11, Michael J Gruber wrote:
>> Congrats on the release! Alas, the tag is botched:
> 
> I have redone the tag in the correct way.
> 
> Cheers,

Thanks, perfect!

I pushed that as git-tag pyx_0_11 and the old one as pyx_0_11@3129 to
keep the promise that all svn tags are represented as git tag objects,
i.e. all svn revisions are either git commits or git tag objects (I keep
the tag creating commits locally but don't push them; they are 1-commit
side branches with empty diff). So, for example the following works
nicely now:

http://repo.or.cz/w/PyX.git/commitdiff/tags/pyx_0_11?hp=tags/pyx_0_10

Compare that to:

http://repo.or.cz/w/PyX.git/commitdiff/tags/pyx_0_11@3129?hp=tags/pyx_0_10

That's a real stress test for git's rename detection :-)

Cheers,
Michael

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

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

Hi Michael,

On 16.05.11, Michael J Gruber wrote:
> Congrats on the release! Alas, the tag is botched:

I have redone the tag in the correct way.

Cheers,

        Jörg

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

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

André Wobst venit, vidit, dixit 16.05.2011 12:42:
> Michael,
> 
> Am 16.05.2011 um 10:39 schrieb Michael J Gruber:
>> Correction: In fact, git-svn does not find any fork point for 0_11.
>> (git log --graph can be misleading for multiple roots.) So it's
>> even worse.
> 
> 
> We can probably alter the content of pyx/tags as well. So it should
> be possible to correct that. Could you comment on what the proper
> layout should be?

Well, strictly speaking there is no single "correct" layout as far as
svn goes because it allows you to do anything, such as converting a
subdirectory into a branch or tag (it is the same).

But I would expect (and before 0_11 it was the case) that the structure
underneath the directories

trunk/
branches/<branchname>/
tags/<tagname>/

is the same. For 0_11 that is not the case, so that, e.g., when you diff
trunk/ against tags/pyx_0_11/ the whole tree will be different, even at
r3129 (tagging revision)!

I think that that tagging should just have been

svn cp trunk tags/pyx_0_11

instead of

svn cp trunk/pyx tags/pyx_0_11

(I omitted the URL prefixes)

That is, if you want to diff any revision against a tagged revsion you
have to do it differently for 0.11 compared to all others.

For now I would suggest fixing the tag (rm or mv then "cp trunk
tags/pyx_0_11", preferably in individual commits).

To go forward, one may get rid of that extra level from cvs times, but
it's not necessary (I omit it from the clone at
http://repo.or.cz/w/PyX.git which tracks the tree
http://repo.or.cz/w/PyX.git/tree) and possibly confusing. And when/if
you switch to another vcs that spurious level could disappear
automatically anyway.

Cheers,
Michael

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

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

Michael J Gruber venit, vidit, dixit 16.05.2011 10:11:
> Joerg Lehmann venit, vidit, dixit 15.05.2011 18:51:
>> Hi all,
>>
>> After more than 3 1/2 years, we are very happy that we were able to
>> eventually release PyX 0.11!
> 
> Congrats on the release! Alas, the tag is botched:
...
> That is, the contents of pyx_0_11 miss one level compared to trunk. I
> noticed because git-svn refetched all revisions and forked 0_11 directly
> from 0_10, not from trunk, as a result of:

Correction: In fact, git-svn does not find any fork point for 0_11. (git
log --graph can be misleading for multiple roots.) So it's even worse.

Michael

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

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

Joerg Lehmann venit, vidit, dixit 15.05.2011 18:51:
> Hi all,
> 
> After more than 3 1/2 years, we are very happy that we were able to
> eventually release PyX 0.11!

Congrats on the release! Alas, the tag is botched:

svn list https://pyx.svn.sourceforge.net/svnroot/pyx/trunk/
CVSROOT/
pyx/

svn list https://pyx.svn.sourceforge.net/svnroot/pyx/trunk/pyx
AUTHORS
...

svn list https://pyx.svn.sourceforge.net/svnroot/pyx/tags/pyx_0_10
CVSROOT/
pyx/

svn list https://pyx.svn.sourceforge.net/svnroot/pyx/tags/pyx_0_10/pyx
AUTHORS
...

BUT:

svn list https://pyx.svn.sourceforge.net/svnroot/pyx/tags/pyx_0_11
AUTHORS
...

That is, the contents of pyx_0_11 miss one level compared to trunk. I
noticed because git-svn refetched all revisions and forked 0_11 directly
from 0_10, not from trunk, as a result of:

r3129 | joergl | 2011-05-15 17:39:38 +0200 (Sun, 15 May 2011) | 1 line
Changed paths:
   A /tags/pyx_0_11 (from /trunk/pyx:3128)

tagging release 0.11

Is that a conscious change of structure? Trunk should follow then, I
guess. I'm holding my git-svn mirror push for now...

Michael

[PyX-devel] ANN: PyX 0.11 released

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

Hi all,

After more than 3 1/2 years, we are very happy that we were able to
eventually release PyX 0.11!

The most notable change in this release is a major reorganization of the
text output code. This paves the way for future cool features like
typesetting without using TeX/LaTeX. Furthermore, lots of small
improvements have been made all over the place and various bugs have
been fixed. Details can be found in the attached list of changes, but
here we just want to point out that transparency in bitmaps is now
supported and limited functionality of the bar style is available in 3d
graphs.

We especially want to thank everybody who has reported bugs, suggested
features or provided patches! We are sorry that it has taken such a long
time for your input to make it into a release, but this did not make it
less valuable.

Enjoy the new version!

        André, Michael and Jörg

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

0.11 (2011/05/15):
  - font and dvi modules:
    - major reorganization
    - TeX mapping files are a property of the writer now
      By that the pdfwriter now uses pdftex.map instead of psfonts.map
      (It's also possible to pass a fontmap to a texrunners text method to use
      different mappings within a single output file)
    - support for font matrices (afm) for Type1 fonts
      (using fonts without a metrics is still supported, but properly issues
      a warning now)
    - interface for basic TeX-less text output
    - new PS and PDF writer options: strip_fonts, text_as_path, mesh_as_bitmap,
      mesh_as_bitmap_resolution
    - fix for commented out UniqueID
    - fix rounding of font sizes
    - fix scaling of VF position increments
  - new filelocator module
  - graph modules:
    - bar style on graphxyz (single datasets only)
    - graphxyz:
      - fix position of z4 axis
      - set correct errorname for z axis (thanks to Axel Freyn)
      - fix wrong y value usage instead of z value in pos methods
    - fix unused color range settings in surface style (thanks to Michael J Gruber)
    - fallbackrange for axes with vanishing range
    - dokeyitem method (to be called with a plotitem) to alter the key order
    - doplot() was renamed to doplotitem(), dodata() was renamed to doplot()
      to have similar naming conventions like for the graph key
    - axis module: do not divide by None for data.min and/or data.max being None
      (see patch #2833369)
    - axis painter:
      - properly rotate axis titles when ticks are not othorgonal
        to the axis (reported by Christian Delfosse)
      - correct namedirection in bar axis painter (reported by rhunger, bug #2028032)
    - graph.style.arrow: decorator is an parameter of the constructor now
      (thanks to Axel Freyn)
    - remove ticks with unset ticklevel and labellevel to prevent rating failures
      (thanks to Brendon Higgins)
  - canvas and document modules:
    - auto-guess output filename from the script filename
    - add ciecolor flag and input type to the pipeGS method of canvas
  - pyxrc:
    - new config options for psfontmaps and pdffontmaps
    - new config option for formatting of Python warnings
    - new config section for new filelocator module
  - text module:
    - fix two bugs in the read pipe of the texrunner (thanks to
      Laurence Tratt and Eric Faurot)
    - fix "<" token handling in mapping file parser (thanks to Matthew West)
    - fix start message parse error in MiKTeX (thanks to Wojciech Jaskowski)
    - fix rigid aux file checking (thanks to Clayton E. Myers)
    - use subprocess module if available
    - proper error messages when TeX is stopped due to unrecoverable error
  - style module:
    - implement style.fillrule
  - deco module:
    - added an explicit hatch pattern as an alternative for real postscript patterns
    - arrow decorator: take into account constriction length when arrow pos < 1
  - bitmap module:
    - add support for transparent bitmaps (in postscript stencil masking only)
  - path and normpath modules:
    - remove incorrect zero length line in PDF output for each first moveto
      path element (thanks to Michael J Gruber)
    - raise correct normpath exception (thanks to Axel Freyn)
  - epsfile module:
    - an ugly way to import EPS in PDF using a bitmap (requires PIL)

[PyX-devel] [ pyx-Feature Requests-2003313 ] Automatic color-value clipping

[SourceForge.net <no...@so...>]

Feature Requests item #2003313, was opened at 2008-06-26 19:38
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=2003313&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: David Munger (mungerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Automatic color-value clipping

Initial Comment:
It would be convenient if the getcolor() of color gradients would clip their argument to the interval [0,1].

For instance, when specifying mincolor and maxcolor to the surface style, values out of the interval [mincolor, maxcolor] imply normalized values (those passed to the gradient's getcolor() function) that are either negative or greater than unity.

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

>Comment By: Andre Wobst (wobsta)
Date: 2011-05-15 13:02

Message:
This is implemented in changeset 3028 (and issues a warning about the
"color clipping").

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=2003313&group_id=45430

[PyX-devel] [ pyx-Bugs-2001233 ] surface plot color limits

[SourceForge.net <no...@so...>]

Bugs item #2001233, was opened at 2008-06-23 23:36
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=2001233&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: David Munger (mungerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: surface plot color limits

Initial Comment:
The surface style does not obey the imposed color data limits (mincolor and maxcolor).

Proposed fix in pyx/graph/style.py, lines 1761-1764.

OLD:

        if self.mincolor is not None:
            mincolor = self.mincolor
        if self.maxcolor is not None:
            maxcolor = self.maxcolor

NEW:

        if self.mincolor is not None:
            privatedata.mincolor = self.mincolor
        if self.maxcolor is not None:
            privatedata.maxcolor = self.maxcolor


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

>Comment By: Andre Wobst (wobsta)
Date: 2011-05-15 12:56

Message:
Looks like a duplicate of changeset 3028. Closing.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=2001233&group_id=45430

[PyX-devel] [ pyx-Bugs-2833383 ] fixes axis range bug for integer values

[SourceForge.net <no...@so...>]

Bugs item #2833383, was opened at 2009-08-06 23:46
Message generated for change (Settings changed) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=2833383&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixes axis range bug for integer values

Initial Comment:
in /pyx/graph/axis/axis.py:163
if divisor, min and max are integer values and divisor is bigger than max - min the range becomes 0

Patch 2833369 is wrong here is the right one:

163,166c163
<             _min = 0; _max = 0;
<             if data.min != 0: _min = data.min/float(self.divisor)
<             if data.max != 0: _max = data.max/float(self.divisor)
<             partfunctions = parter.partfunctions(_min, _max,
---
>             partfunctions = parter.partfunctions(data.min/self.divisor, data.max/self.divisor,


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

>Comment By: Andre Wobst (wobsta)
Date: 2011-05-15 12:07

Message:
We have most probably solved this in the solution to patch #2833369.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=2833383&group_id=45430

[PyX-devel] [ pyx-Feature Requests-1568021 ] Add support for Type 42 fonts

[SourceForge.net <no...@so...>]

Feature Requests item #1568021, was opened at 2006-09-29 23:02
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1568021&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: John Owens (john_owens)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for Type 42 fonts 

Initial Comment:
When parsing my psfonts.map I get errors like:

/opt/local/lib/python2.4/site-packages/pyx/dvifile.py:396: UserWarning: 
Ignoring line 630 in mapping file 'psfonts.map': wrong syntax
  warnings.warn("Ignoring line %i in mapping file '%s': %s" % (lineno, 
filename, e))

Here's an example of the line that causes the error in psfonts.map:

LY1-Constantia-lnum-kern-liga-smcp--base Constantia 
"AutoEnc_brlkii5is4p7ngrcgioftapdth ReEncodeFont" <[a_brlkii.enc 
<Constan.t42

I'm pretty sure that's a good format for a type42 font. Perhaps you can 
handle it in dvifile.py?

JDO


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

>Comment By: Jörg Lehmann (joergl)
Date: 2011-05-15 12:03

Message:
We now ignore Type 42 lines in mapping silently (see changeset 3100).

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

Comment By: Jörg Lehmann (joergl)
Date: 2007-10-24 21:53

Message:
Logged In: YES 
user_id=390410
Originator: NO

Sorry for this belated comment, but I just wanted to remark that this is
not
a PyX bug but just a non-feature: we do not (yet) support type42 fonts.
Note also that PyX just issues a warning and ignores the corresponding
line
in the map file. If you want or need to, you can configure the Python 
warnings module (see Python docs) to not display the warning at all.

Understanding your bug to be a feature request (for Type 42) fonts, I'll
change
the title and type accordingly.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1568021&group_id=45430

[PyX-devel] [ pyx-Patches-2833369 ] fixes axis division by 0 bug in /pyx/graph/axis/axis.py

[SourceForge.net <no...@so...>]

Patches item #2833369, was opened at 2009-08-06 22:57
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=2833369&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixes axis division by 0 bug in /pyx/graph/axis/axis.py

Initial Comment:
happens when axis min or max value is 0 and divisor is set  (second value has also to be set to something)

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

>Comment By: Andre Wobst (wobsta)
Date: 2011-05-15 11:33

Message:
We most probably fixed this in a better way by changeset 3097.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=2833369&group_id=45430

[PyX-devel] [ pyx-Support Requests-2802563 ] TeX interface

[SourceForge.net <no...@so...>]

Support Requests item #2802563, was opened at 2009-06-07 19:04
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442887&aid=2802563&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: TeX interface

Initial Comment:
I'm having a lot of trouble adding titles to graphs with symbols that TeX wants to interpret.  Is there a good way to title a graph ("Data from file" + path) where the path name contains both back slashes and underscores?

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

>Comment By: Andre Wobst (wobsta)
Date: 2011-05-15 11:18

Message:
You can use pyx.text.escapestring() for the conversion.

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

Comment By: Axel Freyn (freynaxe)
Date: 2009-07-02 12:16

Message:
As PyX depends on TeX / LaTeX to create text, the easiest solution will be
to convert the string into a form acceptable to TeX / LaTeX.  You could
define a function to do this.
For me, the following works perfectly:

from pyx import *

def CleanString(s):
  s = a.replace("\\",r"\textbackslash ")
  s = s.replace("_","\\_")
  return s

text.set(mode="latex")
c = canvas.canvas()
c.text(0,0,CleanString("a\\b_c"))
c.writePDFfile("test")


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442887&aid=2802563&group_id=45430