Re: [PyX-user] Overlaping X axis

[André Wobst <wobsta@us...>]

Am 29.10.2009 um 19:20 schrieb kzsolt:
> I hope content of the attached file is explain the problem. On 2nd  
> page of st_15.pdf (generated with PyX) you can see the overlapping X  
> titles. The st_15.csv is the plain sample data for plot.
>
> The X is timeaxis use list of timetick as manualtick.


That's what I thought you do. Wouldn't it be better to do equal spaced  
ticks on the axis? Unfortunately there is no automatism for this in  
PyX for time axes (yet), so you have to code it yourself. Still, it is  
quite unusual to put ticks at those positions of the axis, where you  
have data values rather than put them equal spaced or so ...

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

Re: [PyX-user] Overlaping X axis

[kzsolt <kzsolt@da...>]

Dear André!

I hope content of the attached file is explain the problem. On 2nd page of 
st_15.pdf (generated with PyX) you can see the overlapping X titles. The 
st_15.csv is the plain sample data for plot.

The X is timeaxis use list of timetick as manualtick.

Thank for any advise!

kzsolt 

Re: [PyX-user] typo in writePDFfontinfo

[André Wobst <wobsta@us...>]

Sure, fixed in changeset 3010. Thanks for the report.

Am 28.10.2009 um 18:59 schrieb Alan G Isaac:

> afmfile.py line 1420:
>             decent = self.fontbbox[3]
> should be:
>             descent = self.fontbbox[3]
>
> Thanks,
> Alan Isaac
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

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

Re: [PyX-user] Overlaping X axis

[André Wobst <wobsta@us...>]

Hi,

I'm not quite sure I properly understood your problem. Are you using  
manual ticks on the x axis at those positions you have data for? Then  
the labels become close for close values. However, on an axis you  
should put the ticks equal spaced -- independent of your data.

Still, labels on time axes may still be quite long. Note that you  
might want to rotate the labels for those cases (see the  
labeldirection attribute of the axis painter).


André


Am 27.10.2009 um 19:59 schrieb kzsolt:

> Dear Users!
>
> I try to plot graph with sample values. The x is datetime (time())  
> the y is
> simple numeric value. But I have trouble with some sample  
> configuration for
> example:
>
> sample         X                     Y
> 1           15476100               8
> 2           15477100              15
> 3           15477120              16
> 4           15477140              17
> 5           15478100              14
> 6           15479100              18
> 7           15479120              15
> 8           15479140              16
> 9           15480100              11
>
> After using timeaxis nearly working fine but the label on x axis  
> values is
> many times overlapped. The 2-4 and the 6-8 sample is too close for  
> plotting
> to linear axis within the 1 and 9 sample range. Maybe the solution  
> ti hide
> all of close sample label on x axis but how?
>
> Thank for any advise!
>
> kzsolt
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

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

[PyX-user] typo in writePDFfontinfo

[Alan G Isaac <aisaac@am...>]

afmfile.py line 1420:
             decent = self.fontbbox[3]
should be:
             descent = self.fontbbox[3]

Thanks,
Alan Isaac

[PyX-user] Overlaping X axis

[kzsolt <kzsolt@da...>]

Dear Users!

I try to plot graph with sample values. The x is datetime (time()) the y is
simple numeric value. But I have trouble with some sample configuration for
example:

sample         X                     Y
1           15476100               8
2           15477100              15
3           15477120              16
4           15477140              17
5           15478100              14
6           15479100              18
7           15479120              15
8           15479140              16
9           15480100              11

After using timeaxis nearly working fine but the label on x axis values is
many times overlapped. The 2-4 and the 6-8 sample is too close for plotting
to linear axis within the 1 and 9 sample range. Maybe the solution ti hide
all of close sample label on x axis but how?

Thank for any advise!

kzsolt 

Re: [PyX-user] bug report: bad bounding box

[Alan G Isaac <aisaac@am...>]

On 10/21/2009 12:33 PM, Axel Freyn wrote:
> bbox = GetBB(c)
> c.writeEPSfile("bbox",bbox=bbox)
>
> I obtain a perfect bounding box;-)


Thanks.
I'd like to see something like this
in PyX, even though it depends on
GhostScript...

Alan

Re: [PyX-user] bug report: bad bounding box

[Axel Freyn <freynaxe@us...>]

Hi,
On Wed, Oct 21, 2009 at 12:04:19PM -0400, Alan G Isaac wrote:
> On 10/19/2009 10:03 AM, André Wobst wrote:
> > the issue should be still manageable, as we only need to take into
> > account the path element ends.
> >
> > Still, I don't see somebody just implementing it in the near future.
> 
> Understood.
> Perhaps making it easy to get a bounding box from GhostScript
> (if installed) would be worth while?  I'm going to guess that
> most PyX users install GhostScript.  (?)
then just use my example - maybe changed like this:

def GetBB(c, filename="-", resolution=100,
           gscommand="grep -v -E '^%%(HiRes)?BoundingBox' | gs", gsoptions="",
           textalphabits=4, graphicsalphabits=4,
           ciecolor=False, xshift = 10, yshift = 10, **kwargs):
    gscommand += " -dEPSFit -dNOPAUSE -dQUIET -dBATCH -r%i -q -sDEVICE=bbox -sOutputFile=%s" % (resolution, filename)
    if gsoptions:
        gscommand += " %s" % gsoptions
    if textalphabits is not None:
        gscommand += " -dTextAlphaBits=%i" % textalphabits
    if graphicsalphabits is not None:
        gscommand += " -dGraphicsAlphaBits=%i" % graphicsalphabits
    if ciecolor:
        gscommand += " -dUseCIEColor"
    gscommand += " -"
    pipe_in, pipe_out, pipe_err = os.popen3(gscommand)
    c1 = canvas.canvas()
    c1.insert(c,[trafo.translate(xshift,yshift)])
    c1.writeEPSfile(pipe_in, **kwargs)
    pipe_in.close()
    for line in pipe_err.readlines():
      m=re.match(r"^%%HiResBoundingBox: ([-0-9\.]*) ([-0-9\.]*) ([0-9\.]*) ([0-9\.]*)$",line)
      if m != None:
        b = map(lambda x: unit.length(float(x),unit="pt"), m.groups())
        return bbox.bbox(b[0]-xshift,b[1]-yshift,b[2]-10,b[3]-10)
    raise IOError("Can't determine BoundingBox")

This includes a simple translation in order to obtain positive bounding
boxes (may be you have to pass larger values for xshift and yshift).

In the example:

c = pyx.canvas.canvas(attrs=[pyx.style.linewidth(1),pyx.style.linejoin(0)])
triangle = path(moveto(0,0), rlineto(6,0))
x,y = pyx.trafo.rotate(120).apply(6,0)
triangle.extend([rlineto(x,y),closepath()])
c.stroke(triangle)
bbox = GetBB(c)
c.writeEPSfile("bbox",bbox=bbox)

I obtain a perfect bounding box;-)

Axel

Re: [PyX-user] bug report: bad bounding box

[Alan G Isaac <aisaac@am...>]

On 10/19/2009 10:03 AM, André Wobst wrote:
> the issue should be still manageable, as we only need to take into
> account the path element ends.
>
> Still, I don't see somebody just implementing it in the near future.

Understood.
Perhaps making it easy to get a bounding box from GhostScript
(if installed) would be worth while?  I'm going to guess that
most PyX users install GhostScript.  (?)

In the meantime, I can work around this.

Thanks,
Alan

Re: [PyX-user] bug report: bad bounding box

[André Wobst <wobsta@us...>]

Alan,

I just want to note, that the situation has already improved a lot. In  
earlier versions, PyX did not calculate proper bounding boxes for  
bezier curves and did not take into account the line width at all in  
the calculation of the bounding boxes. This is fixed for some time  
already. It is related to some rework in the output system, where we  
now are able to keep the graphics state (and thus the current line  
width at the moment). The only errors left result from path (element)  
endings. We do not acknowledge linecap, linejoin, and miterlimit. It  
is possible to add that, but nobody did it so far. We would also need  
to implement this for all path elements, not just the normpaths, as we  
certainly don't want to force everything to become normpaths. However,  
the issue should be still manageable, as we only need to take into  
account the path element ends.

Still, I don't see somebody just implementing it in the near future.

Best,


André


Am 16.10.2009 um 23:36 schrieb Alan G Isaac:

> A picture is worth 1000 words:
>
> import pyx
> from pyx.path import path, moveto, rlineto, closepath
> c = pyx.canvas.canvas(attrs=[pyx.style.linewidth 
> (1),pyx.style.linejoin(0)])
> triangle = path(moveto(0,0), rlineto(6,0))
> x,y = pyx.trafo.rotate(120).apply(6,0)
> triangle.extend([rlineto(x,y),closepath()])
> c.stroke(triangle)
> c.writeEPSfile('c:/temp/temp.eps')
>
> As you see, the corners are cut off of every vertex of
> the triangle.  (Current SVN.)
>
> Cheers,
> Alan Isaac
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

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

Re: [PyX-user] bug report: bad bounding box

[Axel Freyn <freynaxe@us...>]

Hi,
Another proposal:
I'm using the following code when I need a precise Bounding Box -
letting ghostscript do the job:

def GetBB(c, filename="-", resolution=100,
           gscommand="grep -v -E '^%%(HiRes)?BoundingBox' | gs", gsoptions="",
           textalphabits=4, graphicsalphabits=4,
           ciecolor=False, **kwargs):
    gscommand += " -dEPSCrop -dNOPAUSE -dQUIET -dBATCH -r%i -q -sDEVICE=bbox -sOutputFile=%s" % (resolution, filename)
    if gsoptions:
        gscommand += " %s" % gsoptions
    if textalphabits is not None:
        gscommand += " -dTextAlphaBits=%i" % textalphabits
    if graphicsalphabits is not None:
        gscommand += " -dGraphicsAlphaBits=%i" % graphicsalphabits
    if ciecolor:
        gscommand += " -dUseCIEColor"
    gscommand += " -"
    pipe_in, pipe_out, pipe_err = os.popen3(gscommand)
    c.writeEPSfile(pipe_in, **kwargs)
    pipe_in.close()
    for line in pipe_err.readlines():
      m=re.match(r"^%%HiResBoundingBox: ([-0-9\.]*) ([-0-9\.]*) ([0-9\.]*) ([0-9\.]*)$",line)
      if m != None:
        b = map(lambda x: unit.length(float(x),unit="pt"), m.groups())
        return bbox.bbox(b[0],b[1],b[2],b[3])
    raise IOError("Can't determine BoundingBox")

It's more or less a copy of "canvas.pipeGS", however:
 - as ghostscript writes the bbox onto the standard error-stream, I need
   "os.popen3" to get the result from within python.
 - I use a trivial regexp to get the boundingboxes-Data
 - I use "grep" to guarantee that pyx is not passing its
   BoundingBox-Date to ghostscript.

With that code, I can pass an arbitrary canvas to "GetBB", and it will
return the precise boundingBox - including linewidth.

However, the huge problem is: my ghostscript gives wrong results for
negative coordinates - maybe it's just a question of the parameters?

Axel

On Sun, Oct 18, 2009 at 01:56:12PM +0200, Joerg Lehmann wrote:
> Hi,
> 
> On 17.10.09, Alan G Isaac wrote:
> > On 10/17/2009 9:26 AM, Michael SCHINDLER wrote:
> > > The problem is that
> > > the true bounding box of a picture does depend on both the paths and
> > > the respective linewidth. It is simple to calculate bounding boxes for
> > > lines; for curves it is more difficult. PyX calculates these two.
> > > Including also the linewidth and stroke effects coming from the
> > > different linejoin parameters is really difficult. We decided not to
> > > do this, as it would lead to a reimplementation of ghostscript.
> > 
> > Did you consider using Bless's bbox code (comes with  ps2eps, GPL license)?
> 
> I guess, you mean this code:
> 
>    http://www.tex.ac.uk/tex-archive/support/ps2eps/src/C/bbox.c
> 
> Unfortunately, it requires having a rasterized version of the graphics
> output. 
> 
> > It would be really nice to get a better bounding box.
> 
>  From a perfectionists point of view, I would agree. Practically,
> however, it only very seldomnly happened that the bounding box produced
> by PyX was not good enough.
> 
> Best,
> 
>         Jörg

Re: [PyX-user] bug report: bad bounding box

[Joerg Lehmann <joergl@us...>]

Hi,

On 17.10.09, Alan G Isaac wrote:
> On 10/17/2009 9:26 AM, Michael SCHINDLER wrote:
> > The problem is that
> > the true bounding box of a picture does depend on both the paths and
> > the respective linewidth. It is simple to calculate bounding boxes for
> > lines; for curves it is more difficult. PyX calculates these two.
> > Including also the linewidth and stroke effects coming from the
> > different linejoin parameters is really difficult. We decided not to
> > do this, as it would lead to a reimplementation of ghostscript.
> 
> Did you consider using Bless's bbox code (comes with  ps2eps, GPL license)?

I guess, you mean this code:

   http://www.tex.ac.uk/tex-archive/support/ps2eps/src/C/bbox.c

Unfortunately, it requires having a rasterized version of the graphics
output. 

> It would be really nice to get a better bounding box.

 From a perfectionists point of view, I would agree. Practically,
however, it only very seldomnly happened that the bounding box produced
by PyX was not good enough.

Best,

        Jörg

Re: [PyX-user] bug report: bad bounding box

[Alan G Isaac <aisaac@am...>]

On 10/17/2009 9:26 AM, Michael SCHINDLER wrote:
> The problem is that
> the true bounding box of a picture does depend on both the paths and
> the respective linewidth. It is simple to calculate bounding boxes for
> lines; for curves it is more difficult. PyX calculates these two.
> Including also the linewidth and stroke effects coming from the
> different linejoin parameters is really difficult. We decided not to
> do this, as it would lead to a reimplementation of ghostscript.

Did you consider using Bless's bbox code (comes with  ps2eps, GPL license)?
It would be really nice to get a better bounding box.

Thanks,
Alan Isaac

Re: [PyX-user] bug report: bad bounding box

[Michael SCHINDLER <m-schindler@us...>]

Hello,

On 16.10.09, Alan G Isaac wrote:
> As you see, the corners are cut off of every vertex of
> the triangle.  (Current SVN.)

The effect you describe is well known. In fact, we discussed about it
many years ago and decided to leave it like it is. The problem is that
the true bounding box of a picture does depend on both the paths and
the respective linewidth. It is simple to calculate bounding boxes for
lines; for curves it is more difficult. PyX calculates these two.
Including also the linewidth and stroke effects coming from the
different linejoin parameters is really difficult. We decided not to
do this, as it would lead to a reimplementation of ghostscript.

This is why canvas.writeEPSfile and the equivalent for PDF take a
parameter "bboxenlarge". This is meant to serve as a workaround for
the above problem. It is set to 1pt by default. As you increased the
linewidth to 1cm, you should play also with this parameter.

You may also use ghostscript to calculate the true bounding box:
  gs -dNOPAUSE -q -dBATCH -sDEVICE=bbox

Michael

-- 
Michael Schindler
  Laboratoire de Physico-Chimie Théorique.
  ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France.
  Tel: +33 (0)1 40 79 45 97    Fax: +33 (0)1 40 79 47 31
  http:  http://www.pct.espci.fr/~michael

[PyX-user] bug report: bad bounding box

[Alan G Isaac <aisaac@am...>]

A picture is worth 1000 words:

import pyx
from pyx.path import path, moveto, rlineto, closepath
c = pyx.canvas.canvas(attrs=[pyx.style.linewidth(1),pyx.style.linejoin(0)])
triangle = path(moveto(0,0), rlineto(6,0))
x,y = pyx.trafo.rotate(120).apply(6,0)
triangle.extend([rlineto(x,y),closepath()])
c.stroke(triangle)
c.writeEPSfile('c:/temp/temp.eps')

As you see, the corners are cut off of every vertex of
the triangle.  (Current SVN.)

Cheers,
Alan Isaac

Re: [PyX-user] transforms during path construction?

[André Wobst <wobsta@us...>]

Am 16.10.2009 um 17:45 schrieb Alan G Isaac:

> On 10/16/2009 11:25 AM, André Wobst wrote:
>> BTW note that sum is designed for numerics only.
>
> That seems a bit strong.  How about, "numerics originally*.
>
>> That's why sum([])
>> returns 0 and sum(["spam", "eggs"]) is not allowed. By the way for
>> strings it even doesn't work with sum(["spam", "eggs"], ""), which I
>> think is weird
>
> I consider it a bug (as a violation of duck typing).
> There is an efficiency reason to use `join`, but it
> is beyond weird to enforce it.


Me too.

But the numerics-only (without setting a start value) is a good  
starting point. That allows for a proper return value in case of an  
empty list in the first parameter of the sum function. For sum([],  
path.path()) it will be an empty path. That's perfect. And I agree:  
disallowing sum for strings at all is a weird decision. As this case  
is already caught, it could also just be done efficiently. "".join()  
with an empty separator doesn't look too efficient either.

Anyway, we're clearly getting off-topic ... :-)


André

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

Re: [PyX-user] transforms during path construction?

[Alan G Isaac <aisaac@am...>]

On 10/16/2009 11:25 AM, André Wobst wrote:
> BTW note that sum is designed for numerics only.

That seems a bit strong.  How about, "numerics originally*.

> That's why sum([])
> returns 0 and sum(["spam", "eggs"]) is not allowed. By the way for
> strings it even doesn't work with sum(["spam", "eggs"], ""), which I
> think is weird

I consider it a bug (as a violation of duck typing).
There is an efficiency reason to use `join`, but it
is beyond weird to enforce it.


> Anyway, sum(mypaths, path()) is fine.

OK, good.  Thanks,
Alan

Re: [PyX-user] transforms during path construction?

[André Wobst <wobsta@us...>]

Am 15.10.2009 um 23:28 schrieb Alan G Isaac:

> So two things I am taking away from this conversation are:
>
> 1. PyX is likely to keep its current default line width
> of about half a point, because this is considered a better
> match for the traditional TeX fonts.
>
> 2. To reset the default line width, there is no "obvious"
> (to the ordinary user) way, but  Michael G.'s method is
> considered acceptable:
> 	c = canvas.canvas(atrrs=[style.linewidth(1)])
>
> Hope that's an accurate summary,


Indeed, you did very well!


André

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

Re: [PyX-user] transforms during path construction?

[André Wobst <wobsta@us...>]

Am 15.10.2009 um 23:24 schrieb Alan G Isaac:
> OK, I'm not understanding this:
> `sum` will call `__add__` and that is well defined for paths, right?

Yes.

> I hope you are not speaking against sum(mypaths, path())
> because it is the only nice way I've found to turn a bunch
> of paths into subpaths of a single path.

Yes. It's fine. Note that this is quite different from extending the  
path __add__ operation to allow for 0 + mypath[0].

BTW note that sum is designed for numerics only. That's why sum([])  
returns 0 and sum(["spam", "eggs"]) is not allowed. By the way for  
strings it even doesn't work with sum(["spam", "eggs"], ""), which I  
think is weird (but explicitly enforced by BDFL).

Anyway, sum(mypaths, path()) is fine.


André

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

Re: [PyX-user] transforms during path construction?

[Alan G Isaac <aisaac@am...>]

So two things I am taking away from this conversation are:

1. PyX is likely to keep its current default line width
of about half a point, because this is considered a better
match for the traditional TeX fonts.

2. To reset the default line width, there is no "obvious"
(to the ordinary user) way, but  Michael G.'s method is
considered acceptable:
	c = canvas.canvas(atrrs=[style.linewidth(1)])

Hope that's an accurate summary,
Alan

Re: [PyX-user] transforms during path construction?

[Alan G Isaac <aisaac@am...>]

On 10/15/2009 6:11 AM, Michael SCHINDLER wrote:
> Every time I want to combine paths, I have to learn again the
> difference between adding path elements to an other path, or adding
> whole subpaths. The result is of course different at the joinings. The
> behaviour is even different for paths and for normpaths. I then
> recognize that the variety of variants is wanted and reasonable. I
> think that a single notation such as "sum(mypaths, path())" is too
> implicit. One never knows what will happen.

OK, I'm not understanding this:
`sum` will call `__add__` and that is well defined for paths, right?

I hope you are not speaking against sum(mypaths, path())
because it is the only nice way I've found to turn a bunch
of paths into subpaths of a single path.

Cheers,
Alan Isaac

Re: [PyX-user] transforms during path construction?

[Michael J Gruber <michaeljgruber+gmane@fa...>]

Joerg Lehmann venit, vidit, dixit 15.10.2009 14:19:
> Hi Michael,
> 
> On 15.10.09, Michael J Gruber wrote:
>> I know that one, but is style.linewidth() an instance of trafo.trafo,
>> canvas.clip, style.strokestyle or style.fillstyle? I tried anyways, and
>> it worked, of course, because of the way attrs are handed down.
> 
> It's an instance of style.strokestyle.
> 
> On 15.10.09, Michael J Gruber wrote:
>> from pyx import *
>> ·
>> c = canvas.canvas()
>> c2 = canvas.canvas()
>> ·
>> c.stroke(path.line(0,0,0,1))
>> c2.stroke(path.line(1,0,1,1))
>> c2.stroke(path.line(2,0,2,1), [style.linewidth(0.2)])
>> ·
>> c.insert(c2, [style.linewidth(0.4)])
>> ·
>> c.stroke(path.line(3,0,3,1))
>> c2.stroke(path.line(4,0,4,1))
>> ·
>> c.writePDFfile(__file__[:-3])
>> ·
>> How many (even long time) users will get it right?
> 
> Hey, but that should all be obvious :-)

Yeah, yeah, I should have said "Andre + Joerg + Michael" ;)

> 
> (i) Setting PS attributes is done via the usual PS operators
> encapsulated in a gsave/grestore pair. The "last" operator of course takes
> precedence.

Of course, the last one is the one when I insert c2 into c. But it does
not take precedence. Because it's only the last in py(x) code, not the
last one in the resulting ps/pdf code. This is obvious once you know the
inner workings. But highly confusing if you think that "canvas.stroke"
actually strokes something on a canvas, at the time when you say "stroke".

It reminds me of the discussion we're having over at the git list. We
can't figure out a user-friendly UI simply because we know the inner
workings, so everything is obvious to us, and we can't comprehend how
anyone could be confused...

Cheers,
Michael
Cheers,
Michael

Re: [PyX-user] transforms during path construction?

[Joerg Lehmann <joergl@us...>]

Hi Michael,

On 15.10.09, Michael J Gruber wrote:
> I know that one, but is style.linewidth() an instance of trafo.trafo,
> canvas.clip, style.strokestyle or style.fillstyle? I tried anyways, and
> it worked, of course, because of the way attrs are handed down.

It's an instance of style.strokestyle.

On 15.10.09, Michael J Gruber wrote:
> from pyx import *
>·
> c = canvas.canvas()
> c2 = canvas.canvas()
>·
> c.stroke(path.line(0,0,0,1))
> c2.stroke(path.line(1,0,1,1))
> c2.stroke(path.line(2,0,2,1), [style.linewidth(0.2)])
>·
> c.insert(c2, [style.linewidth(0.4)])
>·
> c.stroke(path.line(3,0,3,1))
> c2.stroke(path.line(4,0,4,1))
>·
> c.writePDFfile(__file__[:-3])
>·
> How many (even long time) users will get it right?

Hey, but that should all be obvious :-)

(i) Setting PS attributes is done via the usual PS operators
encapsulated in a gsave/grestore pair. The "last" operator of course takes
precedence.

(ii) There are no copies what so ever involved, so it doesn't matter
when - i.e. before or after inserting it - you modifiy the contents
of a canvas.


> I thought the line at 2 has width 0.4 (because of the order of
> "assignments" of linewidths) and wasn't sure whether the one at 4
> would
> appear. But I remembered experimenting once with the difference
> between
> inserting a canvas, a copy of a canvas and a *deep* copy of a canvas,
> which explains this.

As I said above, there is no copy happening at all!

Best,

        Jörg

Re: [PyX-user] transforms during path construction?

[Michael J Gruber <michaeljgruber+gmane@fa...>]

André Wobst venit, vidit, dixit 15.10.2009 11:08:
> Am 15.10.2009 um 10:36 schrieb Michael J Gruber:
> 
>> Alan G Isaac venit, vidit, dixit 15.10.2009 02:26:
>>> On 10/14/2009 6:22 AM, Michael J Gruber wrote:
>>>> c = canvas.canvas([style.linewidth(1)])
>>>
>>> So I had wondered about this and did
>>> not understand the documentation.
>>>
>>> If one applies a line style to a canvas, I take
>>> it that it becomes the default for all stroke operations
>>> (by that canvas), including draw operations?
>>
>> It seems so ;)
>> It's not documented (online draw style is), but it works that way.
> 
> See canvas constructor at http://pyx.sourceforge.net/manual/node17.html

I know that one, but is style.linewidth() an instance of trafo.trafo,
canvas.clip, style.strokestyle or style.fillstyle? I tried anyways, and
it worked, of course, because of the way attrs are handed down.

> c = canvas()
> c2 = canvas()
> c.insert(c2, [style.linewidth(1)])
> 
> Maybe this is too much in terms of user friendliness, but I clearly  
> like this solution most.

>From the user's perspective, this is completely unintuitive, because of
the way that inserting a canvas on which you've stroked changes those
lines after the fact, unless they've set their width explicitly, and
because inserting a canvas inserts a reference or copy, not a deep (!)
copy. Try and guess how many lines the following produces, and what
width they will have. I know Andre will get it right ;)

from pyx import *

c = canvas.canvas()
c2 = canvas.canvas()

c.stroke(path.line(0,0,0,1))
c2.stroke(path.line(1,0,1,1))
c2.stroke(path.line(2,0,2,1), [style.linewidth(0.2)])

c.insert(c2, [style.linewidth(0.4)])

c.stroke(path.line(3,0,3,1))
c2.stroke(path.line(4,0,4,1))

c.writePDFfile(__file__[:-3])

How many (even long time) users will get it right?

I don't propose changing the inherent pyx structure which leads to this.
But I would really recommend against relying on it for something as
simple as setting a default line style.

Cheers,
Michael

SPOILER

SPOILER

SPOILER

SPOILER

SPOILER

SPOILER

SPOILER

SPOILER

SPOILER

Full disclosure:
I thought the line at 2 has width 0.4 (because of the order of
"assignments" of linewidths) and wasn't sure whether the one at 4 would
appear. But I remembered experimenting once with the difference between
inserting a canvas, a copy of a canvas and a *deep* copy of a canvas,
which explains this.

Re: [PyX-user] transforms during path construction?

[Michael SCHINDLER <m-schindler@us...>]

Salut,

On 15.10.09, Joerg Lehmann wrote:
> On 15.10.09, André Wobst wrote:

> > There also is (or was) a canvas set method. However, I consider this a  
> > bad design and we are about to remove that (am I right, Jörg?).
> 
> Yes, we wanted to get rid of this. AFAIR we mostly kept it for technical
> reasons.

We had some discussions about canvas.clip at this point. I vaguely
remember that there was an argument why clipping is different and
should be kept as an attr of the canvas constructor. André, Jörg?

> > Its also questionable, whether the canvas constructor attrs-field is a  
> > good design decision. I remember having argued against it. Anyway, it is 
> > likely to stay(?). To my mind, the cleanest way of setting attributes is 
> > while inserting a canvas in another canvas.
> >
> > c = canvas()
> > c2 = canvas()
> > c.insert(c2, [style.linewidth(1)])
> 
> I also don't like the attrs argument of the canvas class too much, but
> the solution with two canvases is too complicated. 

> Anyway, I have to say that in general you should use
> unit.set(wscale=...) instead of setting a default linewidth, since then
> also linewidth.thick, etc., work as wanted. As André has pointed out,
> though, finding the right scaling factor for a given line-width is
> non-trivial, although possible. Btw, that would be an argument for a
> more natural base for the linewidth. 

As wscale scales _only_ the linewidth (there is already the other
parameter vscale for the rest), I fear that we introduce too many
control parameters for the same thing. Either we keep wscale or we
introduce a way to reset the defaultlinewidth. Concerning the "more
natural" base for the linewidth, I insist on a good looking one ;-)

> > However, I don't consider this to be that important. Other things  
> > clearly are, like doing a new release this year (which is a new year's  
> > pledge of mine, and I still hope to get it done).
> 
> Yes :-)
> 
> >>> PS Btw, it is great to be able to sum(mypaths,path()),
> >>> but might it be worth defining mypath+0 to be mypath
> >>> so we can just sum(mypaths)?  Not sure this is a good
> >>> idea but thought I'd throw it out there.

Every time I want to combine paths, I have to learn again the
difference between adding path elements to an other path, or adding
whole subpaths. The result is of course different at the joinings. The
behaviour is even different for paths and for normpaths. I then
recognize that the variety of variants is wanted and reasonable. I
think that a single notation such as "sum(mypaths, path())" is too
implicit. One never knows what will happen.

Btw: There used to be a "glue" which has been abandoned. Why?

-- 
Michael Schindler
  Laboratoire de Physico-Chimie Théorique.
  ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France.
  Tel: +33 (0)1 40 79 45 97    Fax: +33 (0)1 40 79 47 31
  http:  http://www.pct.espci.fr/~michael