You can subscribe to this list here.
2002 |
Jan
|
Feb
(13) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(5) |
Jun
(15) |
Jul
(4) |
Aug
(4) |
Sep
(4) |
Oct
(41) |
Nov
(3) |
Dec
(19) |
2004 |
Jan
(7) |
Feb
(1) |
Mar
(6) |
Apr
(13) |
May
(26) |
Jun
(6) |
Jul
(66) |
Aug
(13) |
Sep
|
Oct
(21) |
Nov
(12) |
Dec
(24) |
2005 |
Jan
(7) |
Feb
(24) |
Mar
(9) |
Apr
(5) |
May
|
Jun
(8) |
Jul
(5) |
Aug
(22) |
Sep
(58) |
Oct
(6) |
Nov
|
Dec
(2) |
2006 |
Jan
(1) |
Feb
(11) |
Mar
(12) |
Apr
(8) |
May
(12) |
Jun
(30) |
Jul
(6) |
Aug
(2) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(8) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
(21) |
Apr
(6) |
May
(12) |
Jun
(13) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(4) |
Dec
|
2010 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(26) |
Jun
(1) |
Jul
(40) |
Aug
|
Sep
|
Oct
(15) |
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
(24) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(9) |
Nov
(3) |
Dec
(2) |
2013 |
Jan
(12) |
Feb
(8) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2014 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(6) |
2016 |
Jan
(4) |
Feb
(10) |
Mar
(4) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(4) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: Michael J G. <mic...@us...> - 2023-11-08 15:47:36
|
Am Mi., 8. Nov. 2023 um 14:07 Uhr schrieb Alan <ala...@gm...>: > I would find it convenient to be able to pass a pathlib Path to say > writePDFfile. > > Thanks for PyX! > > Alan Isaac > > Maybe something like the attached can help you. Cheers Michael |
From: Alan <ala...@gm...> - 2023-11-08 13:07:21
|
I would find it convenient to be able to pass a pathlib Path to say writePDFfile. Thanks for PyX! Alan Isaac |
From: André W. <co...@wo...> - 2022-10-16 13:27:13
|
Hi, We're very happy to announce the release of PyX 0.16! This release enables a shortcut for accessing graph-component attributes, simplifying the modification of default components. Small improvements and several bug fixes, especially for the text alignment with TeX Live 2020, are included. See the full list of changes below. Happy PyXing, André and Jörg ------------------------------------------------------------------------- 0.16 (2022/10/16): - graph module: - enable shortcut for passing arguments through graph components (axes, painters, etc.) by passing keyword arguments consisting of graph components separated by underscores. - graph.axis.style: - Allow invalid values (e.g. None) in color values of density style. - text module: - make alignment work with texlive 2020 (reported by Thomas Bending) - fix deprecation warning for isSet - dvi module: - ignore the l3backend header special for dvips - bitmap module: - fix bitmap palette data pdf output being bytes - canvas module: - add clear() method to canvas class (suggested by Camilo Talero) - t1 extension module: - adjust to int/Py_ssize_t change in python 3.10 (thanks to Michael J Gruber) - graph.axis.texter: - rename multiplication_tex -> multiplicationtex and multiplication_unicode -> multiplicationunicode in default texter - manual: - Remove deprecated code in colorname.py and gradientname.py (thanks to grozin for reporting this in bug #37) - the gallery has been moved away from sourceforge.net wiki to the PyX website. Contributions by pull requests are welcome. |
From: Joerg L. <jo...@us...> - 2019-07-14 12:25:27
|
Hi, We're very happy to announce the release of PyX 0.15! This release introduces a new text engine UnicodeEngine, which enables simple typesetting with Type1 fonts without using TeX/LaTeX. The graph axis texters have been adjusted to work on the UnicodeEngine, as well. The exponential and mixed graph axis texters have been merged into the new default texter. A couple of bug fixes are included in this release, as well. See the full list of changes below. Furthermore, PyX' home has been moved to https://pyx-project.org/. The source code repository has been converted to git and is now hosted at https://github.com/pyx-project/pyx. Happy PyXing, André and Jörg ------------------------------------------------------------------------ 0.15 (2019/07/14): - text module: - introduce UnicodeEngine - MultiEngineText to express combined text data for TeX based engines and the new UnicodeEngine - Text and StackedText classes for simple typesetting operations on UnicodeEngine text - rename TexRunner and LatexRunner to TexEngine and LatexEngine - rename cls argument of text.set to engine (with fallback and deprecation warning in place) - improve error handling when input cannot be encoded by texenc - add support for virtual fonts in virtual fonts - font maps: treat font files without extension as Type 1 (to prevent warnings occuring especially with Minion or Libertine fonts) - fix UnicodeDecodeError for invalid character responses by TeX/LaTeX (reported by Gert Ingold) - new examples: - non-ASCII TeX encoding - t1font: - use integers in auto-guessed font descriptors to prevent an issue in pdftex (reported by Michael Hartmann) - fix typo: ItalicAngles -> ItalicAngle (thanks to Ross Moore) - graph.axis.texter: - unify exponential and mixed texter to default texter - use MultiEngineText in all texters (decimal, default, factional) - pdfwriter, pswriter, svgwriter: - removed underscore in PS and PDF and SVG writer options strip_fonts, text_as_path, mesh_as_bitmap, mesh_as_bitmap_resolution (new: stripfonts, textaspath, meshasbitmap and meshasbitmapresolution) to prevent ambiquity with write_ prefixes. - Fix color output in SVG (reported by Michael Hartmann) - deformer: - Fix parallel deformer for empty normsubpaths (thanks to Michael J Gruber) - graph.style: - Use RGBA instead of ARGB in the bitmap fallback of graph.style.density Fix saving SVG as supported modes are limited (thanks to Michael J Gruber) - pattern: - inject default linewidth (reported by Michael J Gruber) - version control: - switched to git on 2018/07/16 with main repository on GitHub |
From: André W. <wo...@us...> - 2018-10-04 08:10:29
|
Dear Roland, there is a not-yet-released example showing how pass and use non-ascii characters in PyX and LaTeX: from pyx import * text.set(cls=text.LatexRunner, texenc='utf-8') text.preamble(r'\usepackage[utf8]{inputenc}') c = canvas.canvas() c.text(0, 0, r'Héllò, wørłd!') c.writeEPSfile() c.writePDFfile() c.writeSVGfile() Best, André > Am 03.10.2018 um 22:47 schrieb Roland Puntaier <rol...@ch...>: > > import pyx > c = pyx.canvas.canvas() > c.stroke(pyx.path.circle(0,0,2),[pyx.style.linewidth.Thick,pyx.color.rgb.red]) > c.text(1, 1, 'на здарове') > > > produced this error > > > File "C:\Python36\Lib\site-packages\pyx\canvas.py", line 409, in text > return self.insert(self.texrunner.text(x, y, atext, *args, **kwargs)) > File "C:\Python36\Lib\site-packages\pyx\text.py", line 1428, in wrapped > return f(self, *args, **kwargs) > File "C:\Python36\Lib\site-packages\pyx\text.py", line 1464, in text > return self.instance.text(*args, **kwargs) > File "C:\Python36\Lib\site-packages\pyx\text.py", line 1304, in text > return self.text_pt(unit.topt(x), unit.topt(y), *args, **kwargs) > File "C:\Python36\Lib\site-packages\pyx\text.py", line 1278, in text_pt > left_pt, right_pt, height_pt, depth_pt = self.do_typeset(expr, self.texmessages_run_default + self.texmessages_run + texmessages) > File "C:\Python36\Lib\site-packages\pyx\text.py", line 1204, in do_typeset > return self._execute(expr, texmessages, STATE_TYPESET, STATE_TYPESET) > File "C:\Python36\Lib\site-packages\pyx\text.py", line 1073, in _execute > self.texinput.write(expr) > UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-18: ordinal not in range(128) > _______________________________________________ > 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/ |
From: Roland P. <rol...@ch...> - 2018-10-03 20:48:04
|
<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <tt>import pyx</tt><br> <p><tt>c = pyx.canvas.canvas()<br> c.stroke(pyx.path.circle(0,0,2),[pyx.style.linewidth.Thick,pyx.color.rgb.red])<br> c.text(1, 1, 'на здарове')<br> <br> </tt></p> <p>produced this error</p> <p><br> </p> <p> File "C:\Python36\Lib\site-packages\pyx\canvas.py", line 409, in text<br> return self.insert(self.texrunner.text(x, y, atext, *args, **kwargs))<br> File "C:\Python36\Lib\site-packages\pyx\text.py", line 1428, in wrapped<br> return f(self, *args, **kwargs)<br> File "C:\Python36\Lib\site-packages\pyx\text.py", line 1464, in text<br> return self.instance.text(*args, **kwargs)<br> File "C:\Python36\Lib\site-packages\pyx\text.py", line 1304, in text<br> return self.text_pt(unit.topt(x), unit.topt(y), *args, **kwargs)<br> File "C:\Python36\Lib\site-packages\pyx\text.py", line 1278, in text_pt<br> left_pt, right_pt, height_pt, depth_pt = self.do_typeset(expr, self.texmessages_run_default + self.texmessages_run + texmessages)<br> File "C:\Python36\Lib\site-packages\pyx\text.py", line 1204, in do_typeset<br> return self._execute(expr, texmessages, STATE_TYPESET, STATE_TYPESET)<br> File "C:\Python36\Lib\site-packages\pyx\text.py", line 1073, in _execute<br> self.texinput.write(expr)<br> UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-18: ordinal not in range(128)<br> </p> </body> </html> |
From: Michael J G. <mic...@us...> - 2017-05-29 14:40:02
|
Perttu Luukko venit, vidit, dixit 17.05.2017 08:46: > On 2017-05-17 05:52:10, André Wobst wrote: >> I just checked in a quick fix (changeset 3684). Note that the present >> text.py is work in progress, although progress has stalled for about a >> year. I hope to continue on that in the near future. I do have quite >> some uncommitted changes and improvements already on my local dev tree > >> I will discuss a switch to git(hub) with Jörg. > > Thanks! Switching to git(hub|lab)? needs a bit of work, but IMHO it's > absolutely worth it. > For your information: There's an unofficial git mirror at https://github.com/mjg/PyX-svn which is tracking the official sf repo. I had to made a few conversion decisions when svn commits did not follow the trunk/branches/tags layout, but other than that it's a straight conversion (with tag creating commits converted into annotated tags). Cheers, Michael |
From: Perttu L. <per...@ik...> - 2017-05-17 06:46:45
|
On 2017-05-17 05:52:10, André Wobst wrote: > I just checked in a quick fix (changeset 3684). Note that the present > text.py is work in progress, although progress has stalled for about a > year. I hope to continue on that in the near future. I do have quite > some uncommitted changes and improvements already on my local dev tree > I will discuss a switch to git(hub) with Jörg. Thanks! Switching to git(hub|lab)? needs a bit of work, but IMHO it's absolutely worth it. -- Perttu |
From: André W. <wo...@us...> - 2017-05-17 03:52:21
|
Hi Perttu, I just checked in a quick fix (changeset 3684). Note that the present text.py is work in progress, although progress has stalled for about a year. I hope to continue on that in the near future. I do have quite some uncommitted changes and improvements already on my local dev tree ... I will discuss a switch to git(hub) with Jörg. Best, André Am 16.05.2017 um 12:55 schrieb Perttu Luukko <per...@ik...>: > In text.py at line 1517 a new global import statement > > "from pyx.config import open, format" > > was added recently by r3680. This breaks calls to the built-in open() > function on lines 1172 and 1416. > > PS. Are there plans to move PyX from Sourceforge to some less > horrendously obsolete platform, such as GitHub or GitLab? Contributing > to the code would be more pleasant with git clones, issue trackers, pull > requests etc :) > > -- > Perttu Luukko > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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/ |
From: Perttu L. <per...@ik...> - 2017-05-16 10:55:49
|
In text.py at line 1517 a new global import statement "from pyx.config import open, format" was added recently by r3680. This breaks calls to the built-in open() function on lines 1172 and 1416. PS. Are there plans to move PyX from Sourceforge to some less horrendously obsolete platform, such as GitHub or GitLab? Contributing to the code would be more pleasant with git clones, issue trackers, pull requests etc :) -- Perttu Luukko |
From: damiano-michael <dam...@wa...> - 2016-10-13 06:14:24
|
Greetings! Please take a look at the stuff I've just found, I think that's what you were looking for. Chek it out <http://zovowigo.trishalbert.org/e6gdazkx> Hugs, damiano-michael |
From: Michael J G. <mic...@us...> - 2016-09-06 12:00:41
|
The new parallel deformer code chokes on empty normsubpaths (via an assertion). But these are common, the old parallel deformer coped with them, and for an empty normsubpath there is nothing to deform. So do just that for empty normsubpaths: nothing (rather than assert) Signed-off-by: Michael J Gruber <mic...@us...> --- Mostly minimal example: ----->%----- from pyx import * c = canvas.canvas() scale = 5 sfac = 0.01 * scale integral = text.text(0,0, r"$\int$", [trafo.scale(scale)]) intpath = integral.textpath().reversed() c.stroke(intpath, [deformer.parallel(sfac)]) c.fill(intpath,) c.writePDFfile() ----->%----- This works with the old parallel deformer, as well as with the suggested patch. With the unpatched new parallel deformer, one gets: Traceback (most recent call last): File "deformernew.py", line 12, in <module> c.stroke(intpath, [deformer.parallel(sfac)]) File "/usr/lib64/python3.5/site-packages/pyx/canvas.py", line 383, in stroke self.draw(path, [deco.stroked]+list(attrs)) File "/usr/lib64/python3.5/site-packages/pyx/canvas.py", line 362, in draw path = adeformer.deform(path) File "/usr/lib64/python3.5/site-packages/pyx/deformer.py", line 890, in deform parallel_normpath, tmp1, tmp2, par2orig = self.deformsubpath(nsp) File "/usr/lib64/python3.5/site-packages/pyx/deformer.py", line 910, in deformsubpath assert len(orig_nsp.normsubpathitems) != 0 AssertionError pyx/deformer.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/pyx/deformer.py b/pyx/deformer.py index 6de35e1..1bbaa7c 100644 --- a/pyx/deformer.py +++ b/pyx/deformer.py @@ -907,11 +907,12 @@ class parallel(baseclasses.deformer): # <<< dist = self.dist_pt epsilon = orig_nsp.epsilon - assert len(orig_nsp.normsubpathitems) != 0 + + if len(orig_nsp.normsubpathitems) == 0: + return normpath.normpath([]), None, None, {} # avoid too small dists: we would run into instabilities if abs(dist) < abs(epsilon): - assert orig_nsp.normsubpathitems par_to_orig = {} for nspitem in orig_nsp: par_to_orig[nspitem] = nspitem -- 2.10.0.rc2.333.g8ef2d05 |
From: Michael J G. <mic...@us...> - 2016-08-31 14:58:07
|
When PyX computes the bbox of pattern canvases it tries to take the linewidth of stroked paths into account. Fix the case when the context does not know the linewidth. Signed-off-by: Michael J Gruber <mic...@us...> --- A minimal example is the following: from pyx import * p = pattern.pattern() c = canvas.canvas() p.stroke(path.line(0,0,1,1)) c.fill(path.rect(0,0,2,2), [p]) c.writePDFfile() For whatever reason, linewidth_pt is None in the active context. I'm pretty sure that the right fix would be to fix the context, and the above is just a band aid. Unfortunately, I have no idea about pdfwriter contexts. pyx/deco.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/pyx/deco.py b/pyx/deco.py index a5be92b..d4ba5de 100644 --- a/pyx/deco.py +++ b/pyx/deco.py @@ -282,7 +282,10 @@ class decoratedpath(baseclasses.canvasitem): strokepath.outputPDF(file, writer) file.write("S\n") # stroke # take linewidth into account for bbox when stroking a path - bbox += strokepath.bbox().enlarged_pt(0.5*acontext.linewidth_pt) + if acontext.linewidth_pt is None: + bbox += strokepath.bbox() + else: + bbox += strokepath.bbox().enlarged_pt(0.5*acontext.linewidth_pt) if self.strokestyles: file.write("Q\n") # grestore -- 2.10.0.rc1.279.gdb7c8d3 |
From: Tom K. <to...@ko...> - 2016-04-06 17:53:05
|
Superb! Works perfectly so far. Thank you! Tom > On Apr 5, 2016, at 6:32 PM, bne...@ro... wrote: > > > Hi Folks, > > I have created a wrapper for PyX that allows it's use in the language > Julia, using the PyCall.jl library. This is similar to the popular > PyPlot.jl language, which wraps matplotlib. > > I don't expect this wrapper to become particularly popular, as there are > multiple layers of dependencies and abstractions to sort out (particularly > to get recent versions of PyX working via Python3), but it does provide > some nice features (like SVG inlining in Jupyter notebooks), and the > wonderful aesthetics of PyX make it worth installing for some > applications. > > Comments and feedback are welcome! This is my first Julia package. > > The license is the same as PyX: GPLv2. Repository is on github for now: > > https://github.com/bnewbold/PyX.jl > > --bryan > > ------------------------------------------------------------------------------ > _______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel |
From: <bne...@ro...> - 2016-04-05 22:32:32
|
Hi Folks, I have created a wrapper for PyX that allows it's use in the language Julia, using the PyCall.jl library. This is similar to the popular PyPlot.jl language, which wraps matplotlib. I don't expect this wrapper to become particularly popular, as there are multiple layers of dependencies and abstractions to sort out (particularly to get recent versions of PyX working via Python3), but it does provide some nice features (like SVG inlining in Jupyter notebooks), and the wonderful aesthetics of PyX make it worth installing for some applications. Comments and feedback are welcome! This is my first Julia package. The license is the same as PyX: GPLv2. Repository is on github for now: https://github.com/bnewbold/PyX.jl --bryan |
From: Michael J G. <mic...@us...> - 2016-02-23 19:43:44
|
graph.style.density() needs to use an alpha channel when the set of points is not a complete rectangle but has missing points. It uses ARGB format for that, which is fine for PDF output. But the save method of image which is used for SVG output can deal with RGBA only (__init__ allows ARGB), so that writeSVGfile() fails. This affects also the inline display in ipython notebooks which uses _repr_svg_(). While a complete fix would teach the save method how to deal with ARGB, RGBA can be saved more quickly anyways. That is why this patch teaches graph.style.density to use RGBA instead of ARGB. A simple test case: from pyx import * g = graph.graphxy(width=10) g.plot(graph.data.points([ [0, 0, 0], [0, 1, 1], [1, 0, 2] ], x=1, y=2, color=3), [graph.style.density(gradient=color.rgbgradient.Hue)]) g.writePDFfile() # embeds directly; works g._repr_png_() # uses pipeGS; works g.writeSVGfile() # fails g._repr_svg_() # uses writeSVGfile; fails Signed-off-by: Michael J Gruber <mic...@us...> --- pyx/graph/style.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pyx/graph/style.py b/pyx/graph/style.py index 1d1e283..165b076 100644 --- a/pyx/graph/style.py +++ b/pyx/graph/style.py @@ -1967,7 +1967,7 @@ class density(_keygraphstyle): "/DeviceRGB": "RGB", "/DeviceCMYK": "CMYK"}[self.gradient.getcolor(0).colorspacestring()] if needalpha: - mode = "A" + mode + mode = mode +"A" empty = b"\0"*len(mode) data = io.BytesIO() for value2 in values2: @@ -1982,9 +1982,9 @@ class density(_keygraphstyle): continue c = privatedata.colors[value1][value2] c = self.color(privatedata, c) + data.write(c.to8bitbytes()) if needalpha: data.write(bytes((255,))) - data.write(c.to8bitbytes()) i = bitmap.image(len(values1), len(values2), mode, data.getvalue()) v1enlargement = (values1[-1]-values1[0])*0.5/(len(values1)-1) -- 2.7.1.505.g1c9a602 |
From: André W. <wo...@us...> - 2016-02-13 00:28:40
|
Hi Michael, I just fixed it. I hope I did it right this time (and won't make it wrong in the future again). 0.14.1 seems to have been the only version where it was wrong. Best, André Am 12.02.2016 um 11:18 schrieb Michael J Gruber <mic...@us...>: > Hi there, > > maybe this isn't too important for svn users, but I think it does make a > difference for certain downstreams (distro maintainers): The tree of > "trunk" and most tags contains "pyx/", then "pyx/manual", "pyx/pyx/" > etc. This is true also for 0_14. > > For the tag 0_14_1, the first "pyx/" was omitted so that "pyx/" has the > content that would normally be at "pyx/pyx/", that is the path is > different and CHANGES, manual and the like "appear to be" missing (they > are at "/" now). > > Note that stable tree layouts makes it easier to do diffs between > releases, automated tarball generation and such. > > Cheers > Michael > > svn list http://svn.code.sf.net/p/pyx/code/tags/pyx_0_14/pyx > AUTHORS > CHANGES > INSTALL > LICENSE > MANIFEST.in > README > TODO > contrib/ > design/ > examples/ > faq/ > manual/ > pyx/ > setup.cfg > setup.py > test/ > www/ > > svn list http://svn.code.sf.net/p/pyx/code/tags/pyx_0_14_1/pyx > __init__.py > attr.py > baseclasses.py > bbox.py > bitmap.py > box.py > canvas.py > color.py > config.py > connector.py > data/ > deco.py > deformer.py > document.py > dvi/ > epsfile.py > font/ > graph/ > mathutils.py > mesh.py > metapost/ > normpath.py > path.py > pattern.py > pdfextra.py > pdfwriter.py > pswriter.py > pykpathsea.c > reader.py > style.py > svgfile.py > svgwriter.py > text.py > trafo.py > unit.py > version.py > writer.py > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael J G. <mic...@us...> - 2016-02-12 10:18:31
|
Hi there, maybe this isn't too important for svn users, but I think it does make a difference for certain downstreams (distro maintainers): The tree of "trunk" and most tags contains "pyx/", then "pyx/manual", "pyx/pyx/" etc. This is true also for 0_14. For the tag 0_14_1, the first "pyx/" was omitted so that "pyx/" has the content that would normally be at "pyx/pyx/", that is the path is different and CHANGES, manual and the like "appear to be" missing (they are at "/" now). Note that stable tree layouts makes it easier to do diffs between releases, automated tarball generation and such. Cheers Michael svn list http://svn.code.sf.net/p/pyx/code/tags/pyx_0_14/pyx AUTHORS CHANGES INSTALL LICENSE MANIFEST.in README TODO contrib/ design/ examples/ faq/ manual/ pyx/ setup.cfg setup.py test/ www/ svn list http://svn.code.sf.net/p/pyx/code/tags/pyx_0_14_1/pyx __init__.py attr.py baseclasses.py bbox.py bitmap.py box.py canvas.py color.py config.py connector.py data/ deco.py deformer.py document.py dvi/ epsfile.py font/ graph/ mathutils.py mesh.py metapost/ normpath.py path.py pattern.py pdfextra.py pdfwriter.py pswriter.py pykpathsea.c reader.py style.py svgfile.py svgwriter.py text.py trafo.py unit.py version.py writer.py |
From: Michael J G. <mic...@us...> - 2016-02-05 16:21:55
|
Hi, I think most people would be happy with arrow length proportional to the "size"-column and a choice for the head size: either proportional or fixed size. Maybe my convex combination was overdoing it a bit, but the same code gives the choice above (0 or 1). Alternatively, the arrow style could use an extra data column "head" whose value defaults to "$size" but could be set to "1" easily (everything still scaling with the same PyX base length that is currently used). Michael André Wobst venit, vidit, dixit 05.02.2016 16:46: > Hi again, > > I have to reply to myself. I just noticed, that by your change you can alter the length of the arrow (i.e. the line) independent from the size of the arrow cap. Now, this is something you need, and want. Ok. But wouldn't this mean, that we should have another input column, as an optional input column? Well, and yes, this maybe is again too complicated, as the arrow length (the line) and the size of the cap should depend on a single parameter only. Right. > > How about making linelength and arrowsize a callable (optionally) to enable insertion of non-linear dependance on the scaling. > > Still, this could maybe done on a translation step similar to the value-to-color conversion in a surface plot. Hmmm. I'm not yet done with getting myself to a final suggestion for a better implementation. > > Best, > > > André > > Am 05.02.2016 um 16:35 schrieb André Wobst <wo...@us...>: > >> Hi Michael, >> >> Such a scaling should not be done within PyX, at least not within a pyx graph style. It is different from arrowsize, as arrowsize is a PyX length. It defined the length of the arrow for a length data value of 1. Preprocess the length data values has nothing to do with plotting. One could think about a transformation done in a separate step, similar to the 1d-graph for the colors in a 3d graph. Well, interesting idea (to my mind). It could create a scale plot with different arrow sizes and their data value "automatically". >> >> However, within the graph style an arrowscale to (smoothly) enable arrow length adjustment between no-adjustment at all (fixed size) and 1 (linear scaling according to the data value) is too specific. It is not the right thing to do, IMHO. >> >> Best, >> >> >> André >> >> Am 05.02.2016 um 10:29 schrieb Michael J Gruber <mic...@us...>: >> >>> Currently, the length of the arrow as well as the size of the arrow head >>> are scaled by the value of the "size" column, which can get out of hand >>> quickly for vector field plots. >>> >>> Introduce an argument "arrowscale" (defaulting to 1) that makes the >>> arrow head scale by a convex combination of "1" and the value of "size": >>> >>> 1 (default): scale by "size" as before >>> 0: fixed size (as if the value of "size" were 1, just for the arrow >>> head) >>> >>> Signed-off-by: Michael J Gruber <mic...@us...> >>> --- >>> I'll try and reply with two PNGs showing the output for arrowscale=0 (default) >>> and arrowscale=1. >>> >>> Alternative to the RFC here, one could think about abstracting to graph.style.deco() >>> with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). >>> That would make it more complicated to specify a decorator which takes into account "size", though. >>> >>> pyx/graph/style.py | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/pyx/graph/style.py b/pyx/graph/style.py >>> index 1d1e283..57cf2de 100644 >>> --- a/pyx/graph/style.py >>> +++ b/pyx/graph/style.py >>> @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): >>> defaultlineattrs = [] >>> defaultarrowattrs = [] >>> >>> - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): >>> + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): >>> self.linelength = linelength >>> self.arrowsize = arrowsize >>> self.lineattrs = lineattrs >>> self.arrowattrs = arrowattrs >>> self.arrowpos = arrowpos >>> + self.arrowscale = arrowscale >>> self.epsilon = epsilon >>> self.decorator = decorator >>> >>> @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): >>> y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size >>> if self.decorator: >>> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), >>> - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) >>> + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) >>> else: >>> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) >>> >>> -- >>> 2.7.0.341.gc1754cc >>> >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >>> _______________________________________________ >>> PyX-devel mailing list >>> PyX...@li... >>> https://lists.sourceforge.net/lists/listinfo/pyx-devel >> >> -- >> by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim >> / \ \ / ) wo...@us..., http://www.wobsta.de/ >> / _ \ \/\/ / PyX - High quality PostScript and PDF figures >> (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ >> PyX-devel mailing list >> PyX...@li... >> https://lists.sourceforge.net/lists/listinfo/pyx-devel > |
From: André W. <wo...@us...> - 2016-02-05 15:46:53
|
Hi again, I have to reply to myself. I just noticed, that by your change you can alter the length of the arrow (i.e. the line) independent from the size of the arrow cap. Now, this is something you need, and want. Ok. But wouldn't this mean, that we should have another input column, as an optional input column? Well, and yes, this maybe is again too complicated, as the arrow length (the line) and the size of the cap should depend on a single parameter only. Right. How about making linelength and arrowsize a callable (optionally) to enable insertion of non-linear dependance on the scaling. Still, this could maybe done on a translation step similar to the value-to-color conversion in a surface plot. Hmmm. I'm not yet done with getting myself to a final suggestion for a better implementation. Best, André Am 05.02.2016 um 16:35 schrieb André Wobst <wo...@us...>: > Hi Michael, > > Such a scaling should not be done within PyX, at least not within a pyx graph style. It is different from arrowsize, as arrowsize is a PyX length. It defined the length of the arrow for a length data value of 1. Preprocess the length data values has nothing to do with plotting. One could think about a transformation done in a separate step, similar to the 1d-graph for the colors in a 3d graph. Well, interesting idea (to my mind). It could create a scale plot with different arrow sizes and their data value "automatically". > > However, within the graph style an arrowscale to (smoothly) enable arrow length adjustment between no-adjustment at all (fixed size) and 1 (linear scaling according to the data value) is too specific. It is not the right thing to do, IMHO. > > Best, > > > André > > Am 05.02.2016 um 10:29 schrieb Michael J Gruber <mic...@us...>: > >> Currently, the length of the arrow as well as the size of the arrow head >> are scaled by the value of the "size" column, which can get out of hand >> quickly for vector field plots. >> >> Introduce an argument "arrowscale" (defaulting to 1) that makes the >> arrow head scale by a convex combination of "1" and the value of "size": >> >> 1 (default): scale by "size" as before >> 0: fixed size (as if the value of "size" were 1, just for the arrow >> head) >> >> Signed-off-by: Michael J Gruber <mic...@us...> >> --- >> I'll try and reply with two PNGs showing the output for arrowscale=0 (default) >> and arrowscale=1. >> >> Alternative to the RFC here, one could think about abstracting to graph.style.deco() >> with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). >> That would make it more complicated to specify a decorator which takes into account "size", though. >> >> pyx/graph/style.py | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/pyx/graph/style.py b/pyx/graph/style.py >> index 1d1e283..57cf2de 100644 >> --- a/pyx/graph/style.py >> +++ b/pyx/graph/style.py >> @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): >> defaultlineattrs = [] >> defaultarrowattrs = [] >> >> - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): >> + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): >> self.linelength = linelength >> self.arrowsize = arrowsize >> self.lineattrs = lineattrs >> self.arrowattrs = arrowattrs >> self.arrowpos = arrowpos >> + self.arrowscale = arrowscale >> self.epsilon = epsilon >> self.decorator = decorator >> >> @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): >> y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size >> if self.decorator: >> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), >> - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) >> + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) >> else: >> privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) >> >> -- >> 2.7.0.341.gc1754cc >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> PyX-devel mailing list >> PyX...@li... >> https://lists.sourceforge.net/lists/listinfo/pyx-devel > > -- > by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim > / \ \ / ) wo...@us..., http://www.wobsta.de/ > / _ \ \/\/ / PyX - High quality PostScript and PDF figures > (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: André W. <wo...@us...> - 2016-02-05 15:35:54
|
Hi Michael, Such a scaling should not be done within PyX, at least not within a pyx graph style. It is different from arrowsize, as arrowsize is a PyX length. It defined the length of the arrow for a length data value of 1. Preprocess the length data values has nothing to do with plotting. One could think about a transformation done in a separate step, similar to the 1d-graph for the colors in a 3d graph. Well, interesting idea (to my mind). It could create a scale plot with different arrow sizes and their data value "automatically". However, within the graph style an arrowscale to (smoothly) enable arrow length adjustment between no-adjustment at all (fixed size) and 1 (linear scaling according to the data value) is too specific. It is not the right thing to do, IMHO. Best, André Am 05.02.2016 um 10:29 schrieb Michael J Gruber <mic...@us...>: > Currently, the length of the arrow as well as the size of the arrow head > are scaled by the value of the "size" column, which can get out of hand > quickly for vector field plots. > > Introduce an argument "arrowscale" (defaulting to 1) that makes the > arrow head scale by a convex combination of "1" and the value of "size": > > 1 (default): scale by "size" as before > 0: fixed size (as if the value of "size" were 1, just for the arrow > head) > > Signed-off-by: Michael J Gruber <mic...@us...> > --- > I'll try and reply with two PNGs showing the output for arrowscale=0 (default) > and arrowscale=1. > > Alternative to the RFC here, one could think about abstracting to graph.style.deco() > with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). > That would make it more complicated to specify a decorator which takes into account "size", though. > > pyx/graph/style.py | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/pyx/graph/style.py b/pyx/graph/style.py > index 1d1e283..57cf2de 100644 > --- a/pyx/graph/style.py > +++ b/pyx/graph/style.py > @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): > defaultlineattrs = [] > defaultarrowattrs = [] > > - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): > + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): > self.linelength = linelength > self.arrowsize = arrowsize > self.lineattrs = lineattrs > self.arrowattrs = arrowattrs > self.arrowpos = arrowpos > + self.arrowscale = arrowscale > self.epsilon = epsilon > self.decorator = decorator > > @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): > y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size > if self.decorator: > privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), > - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) > + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) > else: > privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) > > -- > 2.7.0.341.gc1754cc > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael J G. <mic...@us...> - 2016-02-05 09:31:58
|
Michael J Gruber venit, vidit, dixit 05.02.2016 10:29: > I'll try and reply with two PNGs showing the output for arrowscale=0 (default) > and arrowscale=1. So let's see. |
From: Michael J G. <mic...@us...> - 2016-02-05 09:29:29
|
Currently, the length of the arrow as well as the size of the arrow head are scaled by the value of the "size" column, which can get out of hand quickly for vector field plots. Introduce an argument "arrowscale" (defaulting to 1) that makes the arrow head scale by a convex combination of "1" and the value of "size": 1 (default): scale by "size" as before 0: fixed size (as if the value of "size" were 1, just for the arrow head) Signed-off-by: Michael J Gruber <mic...@us...> --- I'll try and reply with two PNGs showing the output for arrowscale=0 (default) and arrowscale=1. Alternative to the RFC here, one could think about abstracting to graph.style.deco() with general decoargs and decokwargs arguments (defaulting to [arrowpos=0.5] and such). That would make it more complicated to specify a decorator which takes into account "size", though. pyx/graph/style.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/pyx/graph/style.py b/pyx/graph/style.py index 1d1e283..57cf2de 100644 --- a/pyx/graph/style.py +++ b/pyx/graph/style.py @@ -880,12 +880,13 @@ class arrow(_styleneedingpointpos): defaultlineattrs = [] defaultarrowattrs = [] - def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, epsilon=1e-5, decorator=deco.earrow): + def __init__(self, linelength=0.25*unit.v_cm, arrowsize=0.15*unit.v_cm, lineattrs=[], arrowattrs=[], arrowpos=0.5, arrowscale=1, epsilon=1e-5, decorator=deco.earrow): self.linelength = linelength self.arrowsize = arrowsize self.lineattrs = lineattrs self.arrowattrs = arrowattrs self.arrowpos = arrowpos + self.arrowscale = arrowscale self.epsilon = epsilon self.decorator = decorator @@ -930,7 +931,7 @@ class arrow(_styleneedingpointpos): y2 = y_pt+(1-self.arrowpos)*dy*linelength_pt*size if self.decorator: privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), - privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*size)]) + privatedata.lineattrs+[self.decorator(privatedata.arrowattrs, size=self.arrowsize*((1-self.arrowscale) + self.arrowscale*size))]) else: privatedata.arrowcanvas.stroke(path.line_pt(x1, y1, x2, y2), privatedata.lineattrs) -- 2.7.0.341.gc1754cc |
From: André W. <wo...@us...> - 2016-01-26 13:15:23
|
I've applied that. Thanks. André Am 25.01.2016 um 17:26 schrieb Michael J Gruber <mic...@us...>: > As it stands, one would think that the bbox of a page is enlarged in any > case. Switch the two sentences to make it clear that an explicit manual > bbox is not enlarged. > > Signed-off-by: Michael J Gruber <mic...@us...> > --- > manual/document.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/manual/document.rst b/manual/document.rst > index df0bbed..696d268 100644 > --- a/manual/document.rst > +++ b/manual/document.rst > @@ -26,9 +26,9 @@ additional properties of the page. > page. If *centered* is set, the output is centered on the given paperformat. If > *fittosize* is set, the output is scaled to fill the full page except for a > given *margin*. Normally, the bounding box of the canvas is calculated > - automatically from the bounding box of its elements. Alternatively, you may > - specify the *bbox* manually. In any case, the bounding box is enlarged on all > - sides by *bboxenlarge*. > + automatically from the bounding box of its elements. In any case, the bounding > + box is enlarged on all sides by *bboxenlarge*. Alternatively, you may specify > + the *bbox* manually. > > > Class :class:`document` > -- > 2.7.0.275.g1900774 > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael J G. <mic...@us...> - 2016-01-25 16:27:05
|
As it stands, one would think that the bbox of a page is enlarged in any case. Switch the two sentences to make it clear that an explicit manual bbox is not enlarged. Signed-off-by: Michael J Gruber <mic...@us...> --- manual/document.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/manual/document.rst b/manual/document.rst index df0bbed..696d268 100644 --- a/manual/document.rst +++ b/manual/document.rst @@ -26,9 +26,9 @@ additional properties of the page. page. If *centered* is set, the output is centered on the given paperformat. If *fittosize* is set, the output is scaled to fill the full page except for a given *margin*. Normally, the bounding box of the canvas is calculated - automatically from the bounding box of its elements. Alternatively, you may - specify the *bbox* manually. In any case, the bounding box is enlarged on all - sides by *bboxenlarge*. + automatically from the bounding box of its elements. In any case, the bounding + box is enlarged on all sides by *bboxenlarge*. Alternatively, you may specify + the *bbox* manually. Class :class:`document` -- 2.7.0.275.g1900774 |