From: Joerg L. <jo...@us...> - 2011-05-15 16:51:50
|
Hi all, After more than 3 1/2 years, we are very happy that we were able to eventually release PyX 0.11! The most notable change in this release is a major reorganization of the text output code. This paves the way for future cool features like typesetting without using TeX/LaTeX. Furthermore, lots of small improvements have been made all over the place and various bugs have been fixed. Details can be found in the attached list of changes, but here we just want to point out that transparency in bitmaps is now supported and limited functionality of the bar style is available in 3d graphs. We especially want to thank everybody who has reported bugs, suggested features or provided patches! We are sorry that it has taken such a long time for your input to make it into a release, but this did not make it less valuable. Enjoy the new version! André, Michael and Jörg ------------------------------------------------------------------------ 0.11 (2011/05/15): - font and dvi modules: - major reorganization - TeX mapping files are a property of the writer now By that the pdfwriter now uses pdftex.map instead of psfonts.map (It's also possible to pass a fontmap to a texrunners text method to use different mappings within a single output file) - support for font matrices (afm) for Type1 fonts (using fonts without a metrics is still supported, but properly issues a warning now) - interface for basic TeX-less text output - new PS and PDF writer options: strip_fonts, text_as_path, mesh_as_bitmap, mesh_as_bitmap_resolution - fix for commented out UniqueID - fix rounding of font sizes - fix scaling of VF position increments - new filelocator module - graph modules: - bar style on graphxyz (single datasets only) - graphxyz: - fix position of z4 axis - set correct errorname for z axis (thanks to Axel Freyn) - fix wrong y value usage instead of z value in pos methods - fix unused color range settings in surface style (thanks to Michael J Gruber) - fallbackrange for axes with vanishing range - dokeyitem method (to be called with a plotitem) to alter the key order - doplot() was renamed to doplotitem(), dodata() was renamed to doplot() to have similar naming conventions like for the graph key - axis module: do not divide by None for data.min and/or data.max being None (see patch #2833369) - axis painter: - properly rotate axis titles when ticks are not othorgonal to the axis (reported by Christian Delfosse) - correct namedirection in bar axis painter (reported by rhunger, bug #2028032) - graph.style.arrow: decorator is an parameter of the constructor now (thanks to Axel Freyn) - remove ticks with unset ticklevel and labellevel to prevent rating failures (thanks to Brendon Higgins) - canvas and document modules: - auto-guess output filename from the script filename - add ciecolor flag and input type to the pipeGS method of canvas - pyxrc: - new config options for psfontmaps and pdffontmaps - new config option for formatting of Python warnings - new config section for new filelocator module - text module: - fix two bugs in the read pipe of the texrunner (thanks to Laurence Tratt and Eric Faurot) - fix "<" token handling in mapping file parser (thanks to Matthew West) - fix start message parse error in MiKTeX (thanks to Wojciech Jaskowski) - fix rigid aux file checking (thanks to Clayton E. Myers) - use subprocess module if available - proper error messages when TeX is stopped due to unrecoverable error - style module: - implement style.fillrule - deco module: - added an explicit hatch pattern as an alternative for real postscript patterns - arrow decorator: take into account constriction length when arrow pos < 1 - bitmap module: - add support for transparent bitmaps (in postscript stencil masking only) - path and normpath modules: - remove incorrect zero length line in PDF output for each first moveto path element (thanks to Michael J Gruber) - raise correct normpath exception (thanks to Axel Freyn) - epsfile module: - an ugly way to import EPS in PDF using a bitmap (requires PIL) |
From: Michael J G. <mic...@us...> - 2011-05-16 08:11:43
|
Joerg Lehmann venit, vidit, dixit 15.05.2011 18:51: > Hi all, > > After more than 3 1/2 years, we are very happy that we were able to > eventually release PyX 0.11! Congrats on the release! Alas, the tag is botched: svn list https://pyx.svn.sourceforge.net/svnroot/pyx/trunk/ CVSROOT/ pyx/ svn list https://pyx.svn.sourceforge.net/svnroot/pyx/trunk/pyx AUTHORS ... svn list https://pyx.svn.sourceforge.net/svnroot/pyx/tags/pyx_0_10 CVSROOT/ pyx/ svn list https://pyx.svn.sourceforge.net/svnroot/pyx/tags/pyx_0_10/pyx AUTHORS ... BUT: svn list https://pyx.svn.sourceforge.net/svnroot/pyx/tags/pyx_0_11 AUTHORS ... That is, the contents of pyx_0_11 miss one level compared to trunk. I noticed because git-svn refetched all revisions and forked 0_11 directly from 0_10, not from trunk, as a result of: r3129 | joergl | 2011-05-15 17:39:38 +0200 (Sun, 15 May 2011) | 1 line Changed paths: A /tags/pyx_0_11 (from /trunk/pyx:3128) tagging release 0.11 Is that a conscious change of structure? Trunk should follow then, I guess. I'm holding my git-svn mirror push for now... Michael |
From: Michael J G. <mic...@us...> - 2011-05-16 08:40:08
|
Michael J Gruber venit, vidit, dixit 16.05.2011 10:11: > Joerg Lehmann venit, vidit, dixit 15.05.2011 18:51: >> Hi all, >> >> After more than 3 1/2 years, we are very happy that we were able to >> eventually release PyX 0.11! > > Congrats on the release! Alas, the tag is botched: ... > That is, the contents of pyx_0_11 miss one level compared to trunk. I > noticed because git-svn refetched all revisions and forked 0_11 directly > from 0_10, not from trunk, as a result of: Correction: In fact, git-svn does not find any fork point for 0_11. (git log --graph can be misleading for multiple roots.) So it's even worse. Michael |
From: Michael J G. <mic...@us...> - 2011-05-16 11:02:00
|
André Wobst venit, vidit, dixit 16.05.2011 12:42: > Michael, > > Am 16.05.2011 um 10:39 schrieb Michael J Gruber: >> Correction: In fact, git-svn does not find any fork point for 0_11. >> (git log --graph can be misleading for multiple roots.) So it's >> even worse. > > > We can probably alter the content of pyx/tags as well. So it should > be possible to correct that. Could you comment on what the proper > layout should be? Well, strictly speaking there is no single "correct" layout as far as svn goes because it allows you to do anything, such as converting a subdirectory into a branch or tag (it is the same). But I would expect (and before 0_11 it was the case) that the structure underneath the directories trunk/ branches/<branchname>/ tags/<tagname>/ is the same. For 0_11 that is not the case, so that, e.g., when you diff trunk/ against tags/pyx_0_11/ the whole tree will be different, even at r3129 (tagging revision)! I think that that tagging should just have been svn cp trunk tags/pyx_0_11 instead of svn cp trunk/pyx tags/pyx_0_11 (I omitted the URL prefixes) That is, if you want to diff any revision against a tagged revsion you have to do it differently for 0.11 compared to all others. For now I would suggest fixing the tag (rm or mv then "cp trunk tags/pyx_0_11", preferably in individual commits). To go forward, one may get rid of that extra level from cvs times, but it's not necessary (I omit it from the clone at http://repo.or.cz/w/PyX.git which tracks the tree http://repo.or.cz/w/PyX.git/tree) and possibly confusing. And when/if you switch to another vcs that spurious level could disappear automatically anyway. Cheers, Michael |
From: Joerg L. <jo...@us...> - 2011-05-16 21:09:25
|
Hi Michael, On 16.05.11, Michael J Gruber wrote: > Congrats on the release! Alas, the tag is botched: I have redone the tag in the correct way. Cheers, Jörg |
From: Michael J G. <mic...@us...> - 2011-05-17 06:56:27
|
Joerg Lehmann venit, vidit, dixit 16.05.2011 23:09: > Hi Michael, > > On 16.05.11, Michael J Gruber wrote: >> Congrats on the release! Alas, the tag is botched: > > I have redone the tag in the correct way. > > Cheers, Thanks, perfect! I pushed that as git-tag pyx_0_11 and the old one as pyx_0_11@3129 to keep the promise that all svn tags are represented as git tag objects, i.e. all svn revisions are either git commits or git tag objects (I keep the tag creating commits locally but don't push them; they are 1-commit side branches with empty diff). So, for example the following works nicely now: http://repo.or.cz/w/PyX.git/commitdiff/tags/pyx_0_11?hp=tags/pyx_0_10 Compare that to: http://repo.or.cz/w/PyX.git/commitdiff/tags/pyx_0_11@3129?hp=tags/pyx_0_10 That's a real stress test for git's rename detection :-) Cheers, Michael |