pyx-devel — PyX development

[PyX-devel] valign.middle

[Magnus L. H. <ma...@he...>]

Hi!

I need valign.middle and noticed that it didn't work in the CVS
version. Upon looking in the source, I saw the comment "class
_valignmiddle is missing!". Why has it been removed? Was the old one
unsatisfactory/non-functional?

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

[PyX-devel] [ pyx-Patches-861999 ] Graph Baseline Fixes

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

Patches item #861999, was opened at 2003-12-17 17:18
Message generated for change (Comment added) made by malkerei
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=861999&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Graph Baseline Fixes

Initial Comment:
For PyX version 0.4.1

text.py:
        Add pdftex.map to the font list
        Increases tex timeout to 120

graph.py:
        Makes it so that axispainter can have a axis line 
painted at a value other than 0 (such as 1)
        Adds named parameter axiszeroline to 
graph.axispainter constructor.

        Allows bars to be graph from from a centerline other 
than 0 (such as 1)
        Adds named parameter baseline to graph.bar 
constructor



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

Comment By: Matthew Bridges (malkerei)
Date: 2003-12-22 18:31

Message:
Logged In: YES 
user_id=936473

First, thanks for the quick comments.  

In response to your comments, we didn't check the mailing 
archives before submitting the patch, so we didn't realize a better 
fix was already in CVS for the pdftex and timeout issues.

As for the baseline change, we kept fromzero around for 
backwards compatability, as we weren't sure how willing to break 
it you were.  Your way is how we wanted to do it.

Lastly, since there is already a parameter zerolineattrs specifically 
for the zero line, you've already made the 0 line special.  Why not 
make it a little more general and allow the line to be anywhere.

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

Comment By: André Wobst (wobsta)
Date: 2003-12-19 06:18

Message:
Logged In: YES 
user_id=405853

There are several topics addressed in your patch. Let be briefly 
comment them:

The font map problem was addressed in CVS already. There is an 
option to add further map files within our PyX script. Additionally, 
you can specify map files in a ~/.pyxrc file (and a /etc/pyxrc 
IIRC). We're quite happy about that now and using psfonts.map as 
the default like dvips. Why should we change that (you may use 
the udpmap script to properly setup your psfonts.map)?

About the timeout: We had some discussion about that some time 
ago. The problem with a long timeout is, that the user might think, 
that the hole system hangs, while its just waiting for TeX. Its easy 
relatively easy to get into such a state (if you want to). Try:
    from pyx import *
    text.preamble(r"\def\PyXInput#1{}")
(Of course, nobody wants to do that, but there might be cases, 
where it is much more tricky.) However, there was a good solution 
suggested in a previous discussion, which is implemented in CVS 
now. See http://sourceforge.net/mailarchive/message.php?
msg_id=6332068.

About the zeroline I'm not sure, if this is really needed. You can 
always get a grid line from the graph and stroke that. So I'm not 
sure if we really want that. You can also use spcial ticks for that 
and plot gridlines (i.e. you can draw several lines by that). For 
bars the storry is quite different. It is really a good suggestion to 
add this feature. I like it. However, could you tell me, why we 
shouldn't do it the following way: Couldn't we get rid of the 
fromzero-flag and use the baseline parameter having a value or 
None? Then the name "baseline" might be worth a discussion as 
well ... but in principle I would like to add that feature this way ... 
what do you think? Would this be fine to you or do you have a 
good reason to add the "baseline" feature to both, the axes and 
the bar style?

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

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

[PyX-devel] [ pyx-Patches-861999 ] Graph Baseline Fixes

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

Patches item #861999, was opened at 2003-12-17 23:18
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=861999&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Graph Baseline Fixes

Initial Comment:
For PyX version 0.4.1

text.py:
        Add pdftex.map to the font list
        Increases tex timeout to 120

graph.py:
        Makes it so that axispainter can have a axis line 
painted at a value other than 0 (such as 1)
        Adds named parameter axiszeroline to 
graph.axispainter constructor.

        Allows bars to be graph from from a centerline other 
than 0 (such as 1)
        Adds named parameter baseline to graph.bar 
constructor



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

>Comment By: André Wobst (wobsta)
Date: 2003-12-19 12:18

Message:
Logged In: YES 
user_id=405853

There are several topics addressed in your patch. Let be briefly 
comment them:

The font map problem was addressed in CVS already. There is an 
option to add further map files within our PyX script. Additionally, 
you can specify map files in a ~/.pyxrc file (and a /etc/pyxrc 
IIRC). We're quite happy about that now and using psfonts.map as 
the default like dvips. Why should we change that (you may use 
the udpmap script to properly setup your psfonts.map)?

About the timeout: We had some discussion about that some time 
ago. The problem with a long timeout is, that the user might think, 
that the hole system hangs, while its just waiting for TeX. Its easy 
relatively easy to get into such a state (if you want to). Try:
    from pyx import *
    text.preamble(r"\def\PyXInput#1{}")
(Of course, nobody wants to do that, but there might be cases, 
where it is much more tricky.) However, there was a good solution 
suggested in a previous discussion, which is implemented in CVS 
now. See http://sourceforge.net/mailarchive/message.php?
msg_id=6332068.

About the zeroline I'm not sure, if this is really needed. You can 
always get a grid line from the graph and stroke that. So I'm not 
sure if we really want that. You can also use spcial ticks for that 
and plot gridlines (i.e. you can draw several lines by that). For 
bars the storry is quite different. It is really a good suggestion to 
add this feature. I like it. However, could you tell me, why we 
shouldn't do it the following way: Couldn't we get rid of the 
fromzero-flag and use the baseline parameter having a value or 
None? Then the name "baseline" might be worth a discussion as 
well ... but in principle I would like to add that feature this way ... 
what do you think? Would this be fine to you or do you have a 
good reason to add the "baseline" feature to both, the axes and 
the bar style?

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

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

[PyX-devel] [ pyx-Patches-861999 ] Graph Baseline Fixes

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

Patches item #861999, was opened at 2003-12-17 14:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=861999&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Graph Baseline Fixes

Initial Comment:
For PyX version 0.4.1

text.py:
        Add pdftex.map to the font list
        Increases tex timeout to 120

graph.py:
        Makes it so that axispainter can have a axis line 
painted at a value other than 0 (such as 1)
        Adds named parameter axiszeroline to 
graph.axispainter constructor.

        Allows bars to be graph from from a centerline other 
than 0 (such as 1)
        Adds named parameter baseline to graph.bar 
constructor



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

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

Re: [PyX-devel] Error in manual/Makefile

[Andre W. <wo...@us...>]

Hi Daniel,

On 01.12.03, Daniel Woods Bullok wrote:
> There's a problem (at least on my system) in the makefile for the PyX manual.  
> Currently, building manual.ps causes the command "dvips manual.dvi" to be 
> executed.  In the stock configuration for dvips 5.92b, this sends the output 
> to the printer!  The fix is to explicitly provide an output file with 
> "-omanual.ps".  i.e.
> 
> manual.ps: manual.dvi
> 	dvips manual.dvi -omanual.ps

Thanks for your report. Indeed, this default behaviour of dvips is a
bit annoying. However, since other people reported this as well, we've
already changed the Makefile in CVS head. But you may consider to edit
the config.ps file in $TEXMF/dvips/config (IIRC) to your personal
needs ...


André

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

[PyX-devel] Error in manual/Makefile

[Daniel W. B. <da...@bu...>]

There's a problem (at least on my system) in the makefile for the PyX manual.  
Currently, building manual.ps causes the command "dvips manual.dvi" to be 
executed.  In the stock configuration for dvips 5.92b, this sends the output 
to the printer!  The fix is to explicitly provide an output file with 
"-omanual.ps".  i.e.

manual.ps: manual.dvi
	dvips manual.dvi -omanual.ps

Cheers.
-Dan

Re: [PyX-devel] Dash length relative to line width

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

Hello Otto,

On 19.11.03, Otto Tronarp wrote:
> Sorry for the late reply.

No problem. However, in the meantime, we have (partially) implemented an
attribute system as outlined by André in a previous mail in this thread.

> On Tue, 2003-10-21 at 14:06, Joerg Lehmann wrote:
> > However, I don't like the name normdist too much. It doesn't seem
> > to be very intuitive, does it? How about one of the following.
> 
> Fixed in the attached patch (I used rellengths as suggested by André)

Ok.

> > Similar ordering problems arise at other places in PyX, where we
> > use a similar solution. André, maybe we should use the mechanism
> > of the text module?
> > 
>  
> In the attached patch I use a __cmp__ function instead of supplying sort
> with a custom compare function. (As in the text module)

Dependency of attributes can now be specified more generally with the
new attribute system. In particular, we already took care of the
linestyle vs. linewidth sort order.

> > I really want to avoid the duplication of linestyles, so one
> > should really choose a sensible default. I would tend to
> > use the "automatic" behaviour. Other options?

We discussed this internally some weeks ago and in the end, it came to
the conclusion that probably the old way should be the default. Gert,
could you comment on this?

        Jörg

Re: [PyX-devel] Dash length relative to line width

[Otto T. <zz...@ma...>]

Sorry for the late reply.

On Tue, 2003-10-21 at 14:06, Joerg Lehmann wrote:
> However, I don't like the name normdist too much. It doesn't seem
> to be very intuitive, does it? How about one of the following.

Fixed in the attached patch (I used rellengths as suggested by Andr=E9)

> Similar ordering problems arise at other places in PyX, where we
> use a similar solution. Andr=E9, maybe we should use the mechanism
> of the text module?
>=20
=20
In the attached patch I use a __cmp__ function instead of supplying sort
with a custom compare function. (As in the text module)

> I really want to avoid the duplication of linestyles, so one
> should really choose a sensible default. I would tend to
> use the "automatic" behaviour. Other options?
>=20

Fixed in the attached.

/Otto

[PyX-devel] FAQ now in CVS

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

Hi,

I have checked a first version of the PyX-FAQ into CVS. Developers are welcome
to take a look at the answers and to make comments or corrections. The
preferred way is to edit the third argument of a question command and/or to
send me an email. It may also be appropriate to adjust the status of a question
(first argument, see also the documentation for glifaq).

Suggestions for further questions (there are of course plenty of questions to 
be asked) and answers are welcome from everybody. Just send me an email and I 
try to incorporate these suggestions into the FAQ.

Best regards,
Gert

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

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

[PyX-devel] [ pyx-Bugs-795271 ] wrong token in map file

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

Bugs item #795271, was opened at 2003-08-26 13:35
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=795271&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Gert Ingold (gertingold)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong token in map file

Initial Comment:
With PyX0.4 I got the following error message:

Traceback (most recent call last):
  File "./plot", line 2, in ?
    from pyx import *
  File
"/usr/lib/python2.2/site-packages/pyx/canvas.py", line
41, in ?
    import attrlist, base, bbox, helper, path, unit,
prolog, text, trafo, version
  File "/usr/lib/python2.2/site-packages/pyx/text.py",
line 504, in ?
    fontmap = readfontmap(["psfonts.map"])
  File "/usr/lib/python2.2/site-packages/pyx/text.py",
line 497, in readfontmap
    fontmapping = FontMapping(line)
  File "/usr/lib/python2.2/site-packages/pyx/text.py",
line 454, in __init__
    raise RuntimeError("wrong syntax in font catalog
file 'psfonts.map'")
RuntimeError: wrong syntax in font catalog file
'psfonts.map'

The offending line in psfonts.map seems to be:

Cheq Cheq <cheq.ps

Maybe PyX could treat this line more graciously even if the
syntax should be incorrect (??), in particular since
the cases
where this chessboard font is needed are certainly rare. 
PyX0.4 will stop regardless of whether this font is
needed or not.

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

>Comment By: André Wobst (wobsta)
Date: 2003-10-23 11:59

Message:
Logged In: YES 
user_id=405853

Fixed in CVS. PyX now prints a message and continues. Closing.

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

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

Re: [PyX-devel] Dash length relative to line width

[Andre W. <wo...@us...>]

Hi Otto,

On 21.10.03, Otto Tronarp wrote:
> I admit that my choice wasn't the best. I think that the name should
> communicate that it is a length so that leaves *len and *lengths. When
> it comes to absolute vs. relative I think that relative is more
> suitable. So if I have a vote I would vote for rellengths or rellen (or
> even relativelen).
> 
> I can prepare a new patch when you guys reaches a decision on the name
> issue.

If you spend a look to the new connector module by Michael Schindler,
the matching name would be rellengths ...

> > > BTW: What version of python do you require? Is it ok to use True and
> > > False instead?
> > 
> > At the moment we only require Python 2.1, because it is the default in
> > Debian/stable, which does not know True and False.
> > 
> > > 2: However, for this to work the linewidth must be set before we set
> > > the dash so I introduced a class member in PathStyle named prio
> > > (default 0) and I set this prio to 1 in linewidth. Then in
> > > decoratedpath::_writestyles I do a reverse sort on prio before we
> > > write the styles to file.
> > 
> > Similar ordering problems arise at other places in PyX, where we
> > use a similar solution. André, maybe we should use the mechanism
> > of the text module?
> > 
> 
> I took a quick look and it seems that it only differs on some minor
> points.
> * texsettings uses id instead of prio
> * texsettings defines a __cmp__ in the base class instead of supplying  
> sort with a custom compare function
> Besides that it also defines a class member exclusive and only one
> object with the same id is allowed if the exclusive flag is set.

Exactly.

I should tell you that there is a long standing discussion about
attributes used in methods like canvas.stroke, canvas.fill,
canvas.text and at a few other places. There is no common style in
terms of those attributes. We already thought about building a generic
interface in a new attrib-module (should become a directory with
modules like strokeattr, fillattr, textattr, color, ...) where things
like sorting, excluding, merging etc. should be implemented once and
for all. It would be nice to even include changeable attributes (the
graph has something like that right now, but I consider it a dirty
hack although I've written this specific crap myself), specialization
of attributes (I don't like the special way of arrows having a
__call__ method although we might come up with a solution using
__call__). One idea is to get rid of the problem, that you can not
easily change some default attributes provided in keyword arguments.
Suppose write some function:

def StrokeRedPathWithBlueText(c, p, t, # canvas, path, and text
                              pathattrs=[color.rgb.red],
                              textattrs=[color.rgb.blue]):
    c.stroke(p, *pathattrs)
    c.text(0, 0, t, *textattrs)

You now want stroke the path thick. You can't without repeating the
attribute color.rgb.red. That's bad. On the other hand you want to be
able to remove some default attributes (if you force a removal). And
you want some exclusion of some attributes, some sorting etc.

> I don't know if the last thing is applicable to pathstyles, but I can
> prepare a new patch with id instead of prio and that defines a __cmp__.
> What do you think?

Hmmm. I'm not sure. I think it doesn't really matter for the moment
and it is not worth the trouble to implement something very
complicated while we still have to come up with a solution on the
topic I discussed above (instead you may have some thoughts regarding
this subject as a hole).

> A general question: What is all those __implements__ about, I couldn't
> find anything that uses them in the source tree. So I thought that it
> was some feature in python, but I couldn't find anything in the
> documentation.

No, it is not a python language feature, but a coding style feature.
We use it for documentation purposes only, while some other projects
(cf. zope3) might use it for further code analysis and documentation.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Dash length relative to line width

[Otto T. <zz...@ma...>]

Hi Joerg,

On Tue, 2003-10-21 at 14:06, Joerg Lehmann wrote:
> Hi Otto,
>

> However, I don't like the name normdist too much. It doesn't seem
> to be very intuitive, does it? How about one of the following.
>
> - absolute
> - abslengths
> - abslen
> - relative
> - rellengths
> - rellen
>=20
> Further suggestions?
>=20

I admit that my choice wasn't the best. I think that the name should
communicate that it is a length so that leaves *len and *lengths. When
it comes to absolute vs. relative I think that relative is more
suitable. So if I have a vote I would vote for rellengths or rellen (or
even relativelen).

I can prepare a new patch when you guys reaches a decision on the name
issue.

> > BTW: What version of python do you require? Is it ok to use True and
> > False instead?
>=20
> At the moment we only require Python 2.1, because it is the default in
> Debian/stable, which does not know True and False.
>=20
> > 2: However, for this to work the linewidth must be set before we set
> > the dash so I introduced a class member in PathStyle named prio
> > (default 0) and I set this prio to 1 in linewidth. Then in
> > decoratedpath::_writestyles I do a reverse sort on prio before we
> > write the styles to file.
>=20
> Similar ordering problems arise at other places in PyX, where we
> use a similar solution. Andr=E9, maybe we should use the mechanism
> of the text module?
>=20

I took a quick look and it seems that it only differs on some minor
points.
* texsettings uses id instead of prio
* texsettings defines a __cmp__ in the base class instead of supplying =20
sort with a custom compare function
Besides that it also defines a class member exclusive and only one
object with the same id is allowed if the exclusive flag is set.

I don't know if the last thing is applicable to pathstyles, but I can
prepare a new patch with id instead of prio and that defines a __cmp__.
What do you think?

> > 3: I wasn't sure if it should be default behavior so I
> > introduced dottedn, dashedn, and dashdottedn for now.
>=20
> I really want to avoid the duplication of linestyles, so one
> should really choose a sensible default. I would tend to
> use the "automatic" behaviour. Other options?
>=20

So do I, but the default values might need some tweaking.

A general question: What is all those __implements__ about, I couldn't
find anything that uses them in the source tree. So I thought that it
was some feature in python, but I couldn't find anything in the
documentation.


/Otto

[PyX-devel] [ pyx-Bugs-821284 ] problem in key with title=None

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

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Gert Ingold (gertingold)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem in key with title=None

Initial Comment:
The task was to plot data and to produce a key for only
some of the data files. Omitting the title for these
data files obviously does not help as key entries with
label (unknown) are produced. However, one would expect
title=None to work. Unfortunately, this results in a
TeX error (see attached file fss.err). Shouldn't this
be implemented in such a way that title=None simply
ignores the corresponding data set while generating the
key?

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

>Comment By: André Wobst (wobsta)
Date: 2003-10-22 08:04

Message:
Logged In: YES 
user_id=405853

implemented in CVS, closing.

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

Comment By: André Wobst (wobsta)
Date: 2003-10-13 07:31

Message:
Logged In: YES 
user_id=405853

You are right. It's just missing in the implementation right
now. But I already added this missing feature to the TODO
list in the CHANGELOG quite some time ago. In the meantime
you may use the graphs addkey method to manually add a key
providing a list of plotinfo instances. By that you can
select the plotinfo instances you want to add to the key by
yourself.

Andre

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

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

Re: [PyX-devel] Dash length relative to line width

[Andre W. <wo...@us...>]

Hi,

On 21.10.03, Joerg Lehmann wrote:
> > 2: However, for this to work the linewidth must be set before we set
> > the dash so I introduced a class member in PathStyle named prio
> > (default 0) and I set this prio to 1 in linewidth. Then in
> > decoratedpath::_writestyles I do a reverse sort on prio before we
> > write the styles to file.
> 
> Similar ordering problems arise at other places in PyX, where we
> use a similar solution. André, maybe we should use the mechanism
> of the text module?

Well, I'm not satisfied with the attribute handling (expecially its
ordering) in the text module since it uses magic numbers. I'm still
not sure what to do regarding this subject. For the moment, a magic
sorting is the best we can do, but we should try to think hard for a
generic solution for the future.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: Some comments on PyX

[Fernando P. <fp...@co...>]

Andre Wobst wrote:

> This is a really good suggestion. I've just implemented it in CVS now.
> I've choosen the following timeout defaults:
> 
>         waitfortex=60
>         showwaitfortex=5
> 
> This should help for most cases while not making to much trouble to
> anyone ... I like it.

Great!  And thanks for being so receptive to user feedback.

Best,

Fernando

[PyX-devel] Re: Some comments on PyX

[Andre W. <wo...@us...>]

Fernando,

On 16.10.03, Fernando Perez wrote:
> Again, this is an issue of balancing robustness vs convenience.  I 
> understand your concerns about not making it overly long.  I'd suggest that 
> 30 seconds still sounds reasonable to me, but that's open to debate.  
> However, there's a very simple solution which perhaps will make everyone 
>  happy: you can have a long timeout by default (say 30 seconds), and an 
> internal timeout (harcoded to 5 seconds).  The code waits for the internal 
> timeouts, and every time that expires it prints a warning:
> 
> *** PyX INFO: still waiting for latex after 5 seconds...
> *** PyX INFO: still waiting for latex after 10 seconds...
> *** PyX INFO: still waiting for latex after 15 seconds...
> ...
> *** PyX ERROR: the timeout of 30 seconds expired and latex did not respond. 
> Aborting.
> 
> This way you give your users feedback, and the system will be much more 
> robust in the face of slow networks or fresh latex installations which will 
> need to build many fonts in a first pass.

This is a really good suggestion. I've just implemented it in CVS now.
I've choosen the following timeout defaults:

        waitfortex=60
        showwaitfortex=5

This should help for most cases while not making to much trouble to
anyone ... I like it.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Dash length relative to line width

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

Hi Otto,

On 20.10.03, Otto Tronarp wrote:
> However, I have found one thing that I miss. The length of dashes and
> space in dashed, dotted, and dashdotted is absolute and not relative
> to line width. So if I draw a THICK dotted line I get a semi solid
> line instead. Therefore, I propose to add the possibility to define
> the dashes in terms of the current line width, something like the
> attached patch. 
> 
> It does the following: 
> 
> 1: The init function of dashes takes an additional argument
> normdist. If it is set to true it emitts code like
> [0 currentlinewidth mul 3 currentlinewidth mul ] 0 setdash
> instead of
> [0 3 ] 0 setdash

I could swear that I once - some years ago - tried using noninteger
numbers in the array passed to the setdash operator - and it didn result
in an error. So my first thought was that your solution doesn't work at
all. But, of course, you're right and in principle, we could do 
that.

However, I don't like the name normdist too much. It doesn't seem
to be very intuitive, does it? How about one of the following.

- absolute
- abslengths
- abslen
- relative
- rellengths
- rellen

Further suggestions?

> BTW: What version of python do you require? Is it ok to use True and
> False instead?

At the moment we only require Python 2.1, because it is the default in
Debian/stable, which does not know True and False.

> 2: However, for this to work the linewidth must be set before we set
> the dash so I introduced a class member in PathStyle named prio
> (default 0) and I set this prio to 1 in linewidth. Then in
> decoratedpath::_writestyles I do a reverse sort on prio before we
> write the styles to file.

Similar ordering problems arise at other places in PyX, where we
use a similar solution. André, maybe we should use the mechanism
of the text module?

> 3: I wasn't sure if it should be default behavior so I
> introduced dottedn, dashedn, and dashdottedn for now.

I really want to avoid the duplication of linestyles, so one
should really choose a sensible default. I would tend to
use the "automatic" behaviour. Other options?

> I don't know if this takes care of all cases for dashed lines (can I
> draw a dashed line without decoratedpath?) However, it works for the
> attached test case (dotted-test.py) so it is at least a proof of concept.

In principle you can draw a dashed line without decoratedpath but this
is neither the recommended behaviour nor is it documented. So your
solution is fine.

        Jörg



-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: Some comments on PyX

[Fernando P. <fp...@co...>]

Joerg Lehmann wrote:
> Hi,
> 
> On 16.10.03, Andre Wobst wrote:
> 
>>That's bad actually. We should find a coin telling "import all into
>>pyx namespace" or "leave it the way it is" ...
> 
> 
> FYI, I just went ahead and applied the patch proposed by Fernando.
> All in all, it seems to be be a reasonable solution.

Many thanks,

Fernando.

[PyX-devel] Dash length relative to line width

[Otto T. <zz...@ma...>]

Hi,

I just recently discovered PyX and I must say that it looks really
promising. Especially you got one really important thing right that
most (if any) other packages fail with, namely you use (La)TeX for
typesetting the text. And that is number one reason for me to try out
PyX.

However, I have found one thing that I miss. The length of dashes and
space in dashed, dotted, and dashdotted is absolute and not relative
to line width. So if I draw a THICK dotted line I get a semi solid
line instead. Therefore, I propose to add the possibility to define
the dashes in terms of the current line width, something like the
attached patch. 

It does the following: 

1: The init function of dashes takes an additional argument
normdist. If it is set to true it emitts code like
[0 currentlinewidth mul 3 currentlinewidth mul ] 0 setdash
instead of
[0 3 ] 0 setdash
BTW: What version of python do you require? Is it ok to use True and
False instead?

2: However, for this to work the linewidth must be set before we set
the dash so I introduced a class member in PathStyle named prio
(default 0) and I set this prio to 1 in linewidth. Then in
decoratedpath::_writestyles I do a reverse sort on prio before we
write the styles to file.

3: I wasn't sure if it should be default behavior so I
introduced dottedn, dashedn, and dashdottedn for now.


I don't know if this takes care of all cases for dashed lines (can I
draw a dashed line without decoratedpath?) However, it works for the
attached test case (dotted-test.py) so it is at least a proof of concept.

What do you think, is this a wanted feature?


/Otto 

Re: [PyX-devel] Missing -o flag to dvips

[Andre W. <wo...@us...>]

Hi Otto,

On 20.10.03, Otto Tronarp wrote:
> most of the dvips that I have seen defaults to dump the ps to printer and not
> to file so it would be nice if you added the -o flag, like in the
> attached patch. 

You're right, some TeX installations are kind of annoying in that
respect. I've patched the Makefile in the examples and the manual
directories.

André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Missing -o flag to dvips

[Otto T. <zz...@ma...>]

Hi,

most of the dvips that I have seen defaults to dump the ps to printer and not
to file so it would be nice if you added the -o flag, like in the
attached patch. 

I also added a -f to the rm command to get rid of the following output 
rm: cannot remove `examples.tex': No such file or directory
rm: cannot remove `examples.log': No such file or directory
rm: cannot remove `examples.aux': No such file or directory
rm: cannot remove `examples.dvi': No such file or directory
rm: cannot remove `examples.ps': No such file or directory
rm: cannot remove `examples.pdf': No such file or directory
rm: cannot remove `*.eps': No such file or directory
rm: cannot remove `*/*.eps': No such file or directory
rm: cannot remove `*.py.html': No such file or directory
rm: cannot remove `*/*.py.html': No such file or directory
rm: cannot remove `*.png': No such file or directory
rm: cannot remove `*/*.png': No such file or directory


/Otto

Re: [PyX-devel] Re: Some comments on PyX

[Andre W. <wo...@us...>]

Jörg,

On 19.10.03, Joerg Lehmann wrote:
> All in all, it seems to be be a reasonable solution.

Good. I was about to suggest it as well after our latest discussion.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: Some comments on PyX

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

Hi,

On 16.10.03, Andre Wobst wrote:
> That's bad actually. We should find a coin telling "import all into
> pyx namespace" or "leave it the way it is" ...

FYI, I just went ahead and applied the patch proposed by Fernando.
All in all, it seems to be be a reasonable solution.

Greetings,

        Jörg

-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

[PyX-devel] Re: Some comments on PyX

[Fernando P. <fp...@co...>]

Hi all,

thanks for your replies on this topic.  I'm subscribed to pyx-devel now, =
so I=20
can follow the discussion better.  I'll try to summarize my replies to th=
e=20
various messages here to minimize overall traffic.

Andre Wobst wrote:

>>'import pyx' doesn't provide access to pyx's modules.  The examples pro=
vided
>>all use 'from pyx import *', which is bad form for larger scripts, wher=
e this
>>kind of blanket import is bound to cause nasty name collisions.
>>
>>FIX: trivial.  In __init__.py, add after __all__ is defined:
>>
>># Load __all__ in pyx namespace so that a simple 'import pyx' gives
>># access to them via pyx.<name>
>>for name in __all__:
>>    __import__(name,globals(),locals(),[])
[snip]
>=20
> Yes, you have to do the second import statement. But is that really a
> crucial point? I'm interested in J=F6rgs response to that as well.

As others have mentioned, the only real drawback is the potential increas=
e in=20
startup time caused by this import.  However, since the current default p=
retty=20
much pushes people to default to 'from pyx import *' all the time, they a=
re=20
_already_ paying that price :)  The above solution therefore won't add an=
y=20
overhead to most users, except those who are careful to do 'from pyx impo=
rt=20
this,that,that_else' alone.  From looking at the examples, not even the=20
developers do that :)

I think it's quite important to encourage clean usage of pyx, and 'import=
 *'=20
statements are just bad coding style.  If the default behavior requires p=
eople=20
to keep track of the subpieces of pyx manually like:

import pyx.canvas, pyx.text, ...

believe me, users will just get used to doing 'import *'.  We're all lazy=
 ;)=20
And one day, a weird bug pops up because you pasted a little pyx script i=
nto a=20
larger program to give the big program eps generation capabilities, and=20
inadvertently you got a namespace clash.

Like the Zen of Python says:
In [1]: import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
... [snip]
Namespaces are one honking great idea -- let's do more of those!

Really, namespaces _are_ a good thing.  I strongly (but humbly :) advocat=
e=20
that pyx follows this design principle.


> BTW, for the second search path: We could do a path search like in the
> third case and walk towards "../../share" in order to reach the share
> directory. But what if you tell the setup.py to install the data_files
> at some other place? (I'm not sure if you're allowed to do so.) I have
> to really address this correctly since we now know that it is broken.

This is most likely a distutils issue.  I warn you: you'll suffer quite a=
 bit=20
trying to get distutils to do what you want.  Distutils is incredibly bad=
ly=20
documented, and getting it to do anything beyond its defaults is _extreme=
ly_=20
difficult.

I'd strongly suggest that you guys download IPython=20
(http://ipython.scipy.org), and look at its setup.py file.  In particular=
,=20
because I faced very similar problems, and a proper solution finally was=20
contributed by a user (Jack Moffit, one of the Ogg Vorbis guys).  He wrot=
e a=20
distutils extension called install_data_ext (in the directory setupext/ o=
f the=20
ipython distro) which handles _precisely_ issues like this.  You'll save=20
yourselves lots of headaches if you use this.

>>fontmap =3D readfontmap(["psfonts.map","psfonts.cmz","psfonts.amz"])
>>
>>It might be worth doing this in the mainline sources.  Even if it is no=
t the
>>ideal default for some latex-related reasons I don't understand, the tr=
uth is
>>that distributions as popular as RedHat choke on the current configurat=
ion.
>>If this simple change makes pyx work out of the box for many users, it =
is that
>>much more likely to become popular.
>=20
>=20
> Its likely that we will have some /etc/pyxrc and ~/.pyxrc for that in
> the future (like you can have a .dvipsrc telling dvips to do the same
> as PyX regarding the fonts; its the 'p' option in the dvipsrc or the
> 'u' at the command line). We should provide an example for that file
> telling people to possibly include that map files when they are
> running a TeX installation not using type1 fonts by default.

I think the pyxrc file is an excellent idea, but is there any reason not =
to=20
use fontmap =3D readfontmap(["psfonts.map","psfonts.cmz","psfonts.amz"]) =
?  As I=20
said, the better things work 'out of the box', the more happy users yoy'l=
l=20
have :)  Unless there is a good technical reason NOT to have a default wh=
ich=20
makes the package more robust in the face of diverse installations and=20
configurations, this approach is IMHO a good one to follow.


>>The problem is that on a system where ~ is NFS mounted, a 5 second time=
out may=20
>>be just too short.  We serve /home from an old Solaris box, and latex'i=
ng a=20
>>file typically is a bit of a slow process with lots of network read/wri=
te=20
>>activity.  I wouldn't be surprised if this was a rather common situatio=
n in=20
>>typical unix shops.
>>
>>FIX: I'd advocate for a much longer timeout, perhaps 30 seconds at leas=
t.  I
>>changed it to 30 (line 1848 of text.py), and it works fine even on our
>>sluggish network.  While this timeout is a bit long, it makes pyx a muc=
h more
>>robust system in the face of 'real world' network environments.
>=20
>=20
> I do not want to make it very long, because people might have to wait
> for that timeout if TeX is broken badly (however, once your setup is
> fine its not likely that you step into that problem). People are
> probably not waiting that long if their script seem to hang. We might
> make that an option in the .pyxrc as well ... so that you can adjust
> it to your specific needs. You're right that you might want to
> increase this value to make PyX more reliable.
>=20
> BTW: You can always do so by "text.set(waitfortex=3D30)" for the defaul=
t
> texrunner and in the same way at the constructor when creating own
> texrunner instances.

Again, this is an issue of balancing robustness vs convenience.  I unders=
tand=20
your concerns about not making it overly long.  I'd suggest that 30 secon=
ds=20
still sounds reasonable to me, but that's open to debate.  However, there=
's a=20
  very simple solution which perhaps will make everyone happy: you can ha=
ve a=20
long timeout by default (say 30 seconds), and an internal timeout (harcod=
ed to=20
5 seconds).  The code waits for the internal timeouts, and every time tha=
t=20
expires it prints a warning:

*** PyX INFO: still waiting for latex after 5 seconds...
*** PyX INFO: still waiting for latex after 10 seconds...
*** PyX INFO: still waiting for latex after 15 seconds...
...
*** PyX ERROR: the timeout of 30 seconds expired and latex did not respon=
d.=20
Aborting.

This way you give your users feedback, and the system will be much more r=
obust=20
in the face of slow networks or fresh latex installations which will need=
 to=20
build many fonts in a first pass.

> It's likely that you're just observing a problem of ghostscript here.
> Try to turn off the anti-aliasing feature of ghostscript (it helps in
> quite some cases where ghostscript behaves badly). In ghostview press
> "a" for that. You may also send this file to a PostScript 2 aware
> printer (IIRC these pattern things are PostScript Level 2 features).
>=20
>=20
>>I've put up what I get (temporarily) in
>>http://windom.colorado.edu/~fperez/tmp/pattern.eps
>>in case the developers find it useful.
>=20
>=20
> Yes, it works for me with disabled antialiasing in ghostscript.

Same here, thanks for the tip.  I had never had problems with AA in gv, s=
o I=20
didn't think of that.  Issue solved then.

> I quickly want to summarize my impression (also in order to tell J=F6rg
> about my point of what we should do):
>=20
> 1) We need some runtime configuration possibility (like a pyxrc). We
> had discussed it in terms of the mapping files before already. There
> are two further use-cases: the timeout configuration (suggested above)
> and the TeX --ipc option (I've done some tests working nicely, but now
> I have to work in the direction of a pagewise dvi-reading inside PyX).

One word of warning: in the scipy lists, there are people trying to use p=
yx=20
under windows.  You may want to be careful not to hardcode /etc or ~ for =
your=20
config file locations if you want pyx to be at least useable under window=
s.=20
You may look at what I did in ipython to address that issue (basically, s=
tore=20
those locations in internal variables which are read by a routine which=20
handles the platform issues; not pretty but effective).

> 2) I have to address the share/data_files search path issue.

Again, that one is a major pain in the ass with distutils, and keep in mi=
nd=20
the ipython suggestion where Jack's module solves the problem.

> Thanks for all your intensive work in testing our package. You
> hopefully will like it so it was worse your effort. You're welcome to
> further join the discussion.

No problem.  Thanks for the great tool.

Regards,

Fernando.

Re: [PyX-devel] Re: Some comments on PyX

[Andre W. <wo...@us...>]

Hi,

On 16.10.03, Michael Schindler wrote:
> > On 16.10.03, Joerg Lehmann wrote:
> > > I'm not sure about that. Of course, at the moment an "import pyx"
> > > doesn't do anything (expect providing access to pyx.__version__ and
> > > pyx.__all__) and using the code given above it would at least do
> > > something reasonable. On the other hand, the behaviour seems to
> > > be rather implicit than explicit to me. So, as I said, I don't know.
> >
> > Well, same for me. Should we play dice now?
> 
> I threw a coin, and it said "Number" -- what now?

That's bad actually. We should find a coin telling "import all into
pyx namespace" or "leave it the way it is" ...

> 2. There might be some conflicts with other module names, and in this
>    case it is more work to import the necessary modules one by one
>    without these conflicts.

Well, thats why the idea is to allow for:

import pyx

pyx.text.set(...)

Note the missing "import pyx.text" statement. Importing something into
the pyx namespace should not make any difficulties in terms of name
clashs.

> 3. Loading everything by default is not a good idea, as can be seen in the
>    scipy-project which is too slow for usage.

It might be also (indeed almost at least for PyX; I'm not familiar
with scipy) a question of creating a lot instances during loading. We
do have this problem with the attributes right now but an proposel
with a different approach is aborning. In terms of loading time this
should be the most crucial aspect.

> Is there a possibility for the following?
>    "import pyx"        --> access via "pyx.canvas.canvas()", everything
>                            is loaded automatically
>    "from pyx import *" --> say "canvas.canvas()" instead

Wasn't exactly this behaviour suggested? But then point 3 applies
always while it doesn't right now. (The automatic loading into the pyx
namespace is done at the import statement.)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/