Menu
▾
▴
pyx-devel — PyX development
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: SourceForge.net <no...@so...> - 2003-09-02 19:02:23
|
Bugs item #799277, was opened at 2003-09-02 19:44 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799277&group_id=45430 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Nobody/Anonymous (nobody) Summary: paperformat units wrong Initial Comment: I just tried for the first time to set paperformat='letter', and discovered an error. in _paperformats, the units for 'letter' and 'legal' are specified as "letter" : ("8.5 t in", "11 t in"), "legal" : ("8.5 t in", "14 t in")} unfortunately, pyx.units defines the inch unit as 'inch' and not 'in'. Please either add 'in' as an alias for an inch in pyx.units, or change _paperformats in pyx.canvas to use the current name. Thanks. ---------------------------------------------------------------------- >Comment By: André Wobst (wobsta) Date: 2003-09-02 21:02 Message: Logged In: YES user_id=405853 The definition of _paperformats was corrected in CVS a few days ago already. Discussing the other way to get rid of the problem (switching to "in" instead of "inch" in pyx.unit) we found, that it would break some naming scheme in pyx.unit because "in" is a python keyword. However, as you requested, it might still be nice to have just another alias "in" for inch in the string handling of pyx.unit while primary keep the name "inch" due to the python keyword "in". Thanks for reporting this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799277&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-09-02 17:44:52
|
Bugs item #799277, was opened at 2003-09-02 12:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799277&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Nobody/Anonymous (nobody) Summary: paperformat units wrong Initial Comment: I just tried for the first time to set paperformat='letter', and discovered an error. in _paperformats, the units for 'letter' and 'legal' are specified as "letter" : ("8.5 t in", "11 t in"), "legal" : ("8.5 t in", "14 t in")} unfortunately, pyx.units defines the inch unit as 'inch' and not 'in'. Please either add 'in' as an alias for an inch in pyx.units, or change _paperformats in pyx.canvas to use the current name. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799277&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-09-02 16:21:10
|
Bugs item #799182, was opened at 2003-09-02 17:08 Message generated for change (Comment added) made by joergl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799182&group_id=45430 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Nobody/Anonymous (nobody) Summary: error (?) in t1strip Initial Comment: It appears that the definitions for t1strip are slightly different depending upon whether the compiled module is used or not. The compiled module takes 3 or 4 arguments, but the pure-python substitute takes only 4. This showed up when I was trying to build the documentation, and because of a path problem, the compiled _t1strip wasn't found. ---------------------------------------------------------------------- >Comment By: Jörg Lehmann (joergl) Date: 2003-09-02 18:21 Message: Logged In: YES user_id=390410 You indeed discovered an error in the pure-python substitute, which is now fixed in CVS. Thanks, Jörg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799182&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-09-02 15:08:07
|
Bugs item #799182, was opened at 2003-09-02 10:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799182&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Nobody/Anonymous (nobody) Summary: error (?) in t1strip Initial Comment: It appears that the definitions for t1strip are slightly different depending upon whether the compiled module is used or not. The compiled module takes 3 or 4 arguments, but the pure-python substitute takes only 4. This showed up when I was trying to build the documentation, and because of a path problem, the compiled _t1strip wasn't found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=799182&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-08-26 11:41:10
|
Bugs item #760764, was opened at 2003-06-25 22:52 Message generated for change (Comment added) made by joergl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Jörg Lehmann (joergl) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- >Comment By: Jörg Lehmann (joergl) Date: 2003-08-26 13:39 Message: Logged In: YES user_id=390410 This problem should be fixed in PyX 0.4. Thanks, Jörg ---------------------------------------------------------------------- Comment By: Gert Ingold (gertingold) Date: 2003-06-27 22:04 Message: Logged In: YES user_id=809523 One more comment concerning the workaround proposed by André: Things become of course more complicated if reencoding takes place (e.g. when the map file contains the statement "TeXBase1Encoding ReEncodeFont"). What was meant to be a ß (germandbls), i.e. character 255 in EC, will turn out as ydieresis in TeXBase1. In order to obtain a ß, one would have to ask for a \SS=Germandbls=character 223. If this is not done, the glyph is not even extracted from the pfb-file so that changing the eps-file would not be an option anymore. ---------------------------------------------------------------------- Comment By: Gert Ingold (gertingold) Date: 2003-06-27 21:04 Message: Logged In: YES user_id=809523 The changes to text.py fixed the original problem. However, there is still a problem (basically already described by André in his message of June 26). Apparently, the map-files are not evaluated so that replacement fonts are used. This behavior can already be obtained with the standard TeX fonts and \usepackage[T1]{fontenc}. The solution suggested by André is not very practical so that the question mark in "To be implemented ... ?!" should be replaced by (at least two) exclamation marks. ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 10:43 Message: Logged In: YES user_id=405853 Fix looks fine to me. I can get marvosym running by that (which didn't work previously due to the same bug). Consider this minimal example: from pyx import * text.set(mode="latex") text.preamble("\usepackage{marvosym}") c = canvas.canvas() c.text(0, 0, "\EUR") c.writetofile("test") Unfortunately you have to do two things for getting this working: 1. You have to copy marvosym.pfb to fmvr8x.pfb (the name used intenally) 2. You have to modify the PostScript output test.eps, namely you have to change the selectfont from /FMVR8X 9.962640 selectfont to /Martin_Vogels_Symbole 9.962640 selectfont The information can be found in marvosym.map To be implemented ... ?! ---------------------------------------------------------------------- Comment By: Jörg Lehmann (joergl) Date: 2003-06-26 10:31 Message: Logged In: YES user_id=390410 Please check whether the changes made in the CVS head fix this problem. Jörg ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 08:52 Message: Logged In: YES user_id=405853 I'm just considering the problem of loading fd-files triggered by TeX when processing some expressions. By default, those messages are errors in PyX 0.3.1. I've just checked in a special handler for font description file loading, enabled by default via texmessagedefaultrun. Thus fd-file loading is not considered to be an error anymore. Beside that, your report about tfm-file handling is still open. PyX might be just to strict in that sence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-08-26 11:35:55
|
Bugs item #795271, was opened at 2003-08-26 11:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=795271&group_id=45430 Category: None Group: None Status: Open 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=795271&group_id=45430 |
|
From: Andre W. <and...@ph...> - 2003-08-14 12:10:47
|
Hi, 'just got the following idea: Couldn't we create a fallback solution for people who can't compile writet1 by using the dvips font inclusion? (We discussed the font inclusion recently, remember the webpage http://www.tug.org/dvipsk/dvips_34.html.) I guess, this could be a workaround for people who can't compile modules. But I'm not sure what an effort it would be in terms of the support of font encodings. It looks to me, that everything would be handled by dvips that way. We would not even have to know about encodings, virtual fonts, etc., but I might be wrong. However, this topic shouldn't defer PyX 0.4 (especially if it's more complicated). I'll hopefully get the graph documentation up-to-date till Monday. Are there other release critical things left? André -- by _ _ _ And...@Ph... / \ \ / ) http://www.physik.uni-augsburg.de/~wobsta/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
|
From: <da...@ma...> - 2003-08-07 19:49:34
|
Hello Has anyone been able to get PyX to build in os x 10.2.6 with fink installed python 2.3 and TeX 2.0.2? is there any specific information that i can provide here to help me debug what is going south in my scenario? Thank you all for your help David A Jones |
|
From: SourceForge.net <no...@so...> - 2003-07-29 07:53:33
|
Bugs item #779129, was opened at 2003-07-28 22:05 Message generated for change (Comment added) made by joergl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=779129&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError on Linux: PyX-0.3.1.tar.gz Initial Comment: I was trying to install the latest version of PyX in Linux (Red Hat) using the Python 2.2.3. Here is the message I got: python setup.py build_ext -i File "setup.py", line 66 **addargs) ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- >Comment By: Jörg Lehmann (joergl) Date: 2003-07-29 09:53 Message: Logged In: YES user_id=390410 I would suggest running the setup.py script via python2.2 setup.py build_ext -i HTH, Jörg ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-07-29 08:46 Message: Logged In: YES user_id=405853 Just to get sure: could you please run "python -V" in your environment to get sure that you do not pick some old flavor of python by accident. (The keyword argument syntax the interpreter complains about was introduced in python 2.0. For newer versions of python this message just doesn't make any sense to me right now.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=779129&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-07-29 06:46:29
|
Bugs item #779129, was opened at 2003-07-28 22:05 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=779129&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError on Linux: PyX-0.3.1.tar.gz Initial Comment: I was trying to install the latest version of PyX in Linux (Red Hat) using the Python 2.2.3. Here is the message I got: python setup.py build_ext -i File "setup.py", line 66 **addargs) ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- >Comment By: André Wobst (wobsta) Date: 2003-07-29 08:46 Message: Logged In: YES user_id=405853 Just to get sure: could you please run "python -V" in your environment to get sure that you do not pick some old flavor of python by accident. (The keyword argument syntax the interpreter complains about was introduced in python 2.0. For newer versions of python this message just doesn't make any sense to me right now.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=779129&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-07-28 20:05:49
|
Bugs item #779129, was opened at 2003-07-28 13:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=779129&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError on Linux: PyX-0.3.1.tar.gz Initial Comment: I was trying to install the latest version of PyX in Linux (Red Hat) using the Python 2.2.3. Here is the message I got: python setup.py build_ext -i File "setup.py", line 66 **addargs) ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=779129&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-07-22 12:10:50
|
Bugs item #775596, was opened at 2003-07-22 14:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=775596&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reichör (xsteve) Assigned to: Nobody/Anonymous (nobody) Summary: Installation on Windows2000 Initial Comment: Hi, I tried to install pyx on my win2000 box, but there was a link error while building t1strip: [c:\ftp\python\pyx-0.3.1]python setup.py install running install running build running build_py creating build creating build\lib.win32-2.2 creating build\lib.win32-2.2\pyx copying pyx\attrlist.py -> build\lib.win32-2.2\pyx copying pyx\base.py -> build\lib.win32-2.2\pyx copying pyx\bbox.py -> build\lib.win32-2.2\pyx copying pyx\box.py -> build\lib.win32-2.2\pyx copying pyx\canvas.py -> build\lib.win32-2.2\pyx copying pyx\color.py -> build\lib.win32-2.2\pyx copying pyx\data.py -> build\lib.win32-2.2\pyx copying pyx\epsfile.py -> build\lib.win32-2.2\pyx copying pyx\graph.py -> build\lib.win32-2.2\pyx copying pyx\helper.py -> build\lib.win32-2.2\pyx copying pyx\mathtree.py -> build\lib.win32-2.2\pyx copying pyx\path.py -> build\lib.win32-2.2\pyx copying pyx\tex.py -> build\lib.win32-2.2\pyx copying pyx\text.py -> build\lib.win32-2.2\pyx copying pyx\trafo.py -> build\lib.win32-2.2\pyx copying pyx\unit.py -> build\lib.win32-2.2\pyx copying pyx\version.py -> build\lib.win32-2.2\pyx copying pyx\__init__.py -> build\lib.win32-2.2\pyx creating build\lib.win32-2.2\pyx\t1strip copying pyx/t1strip\__init__.py -> build\lib.win32-2. 2\pyx/t1strip creating build\lib.win32-2.2\pyx\pykpathsea copying pyx/pykpathsea\__init__.py -> build\lib.win32-2. 2\pyx/pykpathsea running build_ext building 'pyx/t1strip/_t1strip' extension creating build\temp.win32-2.2 creating build\temp.win32-2.2\Release C:\Programme\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -IC:\Python22\include /Tcpyx/t1strip/t1strip.c /Fobuild\temp.win32-2. 2\Release\t1strip.obj t1strip.c C:\Programme\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -IC:\Python22\include /Tcpyx/t1strip/writet1.c /Fobuild\temp.win32-2. 2\Release\writet1.obj writet1.c pyx/t1strip/writet1.c(551) : warning C4244: '=' : conversion from 'float ' to 'int ', possible loss of data pyx/t1strip/writet1.c(837) : warning C4244: '=' : conversion from 'float ' to 'short ', possible loss of data pyx/t1strip/writet1.c(1105) : warning C4244: '=' : conversion from 'float ' to 'int ', possible loss of data pyx/t1strip/writet1.c(1472) : warning C4244: '=' : conversion from 'float ' to 'int ', possible loss of data pyx/t1strip/writet1.c(1667) : warning C4244: '=' : conversion from 'float ' to 'int ', possible loss of data pyx/t1strip/writet1.c(646) : warning C4761: integral size mismatch in argument;conversion supplied pyx/t1strip/writet1.c(627) : warning C4761: integral size mismatch in argument;conversion supplied pyx/t1strip/writet1.c(536) : warning C4761: integral size mismatch in argument;conversion supplied pyx/t1strip/writet1.c(555) : warning C4761: integral size mismatch in argument;conversion supplied pyx/t1strip/writet1.c(665) : warning C4761: integral size mismatch in argument;conversion supplied C:\Programme\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C: \Python22\libs /EXPORT:initpyx/t1strip/_t1strip build\temp.win32-2.2\Release\t1strip.obj build\temp. win32-2.2\Release\writet1.obj /OUT:build\lib.win32-2. 2\pyx/t1strip/_t1strip.pyd /IMPLIB:build\temp.win32-2. 2\Release\_t1strip.lib LINK : error LNK2001: unresolved external symbol initpyx/t1strip/_t1strip build\temp.win32-2. 2\Release\_t1strip.lib : fatal error LNK1120: 1 unresolved externals LINK : fatal error LNK1141: failure during build of exports file error: command '"C:\Programme\Microsoft Visual Studio\VC98\BIN\link.exe"' failed with exit status 1141 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=775596&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-30 08:00:06
|
Bugs item #763021, was opened at 2003-06-30 06:14 Message generated for change (Comment added) made by gertingold You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=763021&group_id=45430 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Nobody/Anonymous (nobody) Summary: arct results in error Initial Comment: The attached file does not run under PyX0.3.1. On the other hand, there is no problem if arc is used instead of arct. ---------------------------------------------------------------------- >Comment By: Gert Ingold (gertingold) Date: 2003-06-30 08:00 Message: Logged In: YES user_id=809523 Then I would suggest to state this clearly in the manual where at present the descriptions of arc and arct are more or less the same. ---------------------------------------------------------------------- Comment By: Jörg Lehmann (joergl) Date: 2003-06-30 07:47 Message: Logged In: YES user_id=390410 This is not a bug. In order to arct being well defined, a current point has to be defined (see Postscript language reference). Note that this is not the case for arc or arcn. Thus, the resulting excepting is the intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=763021&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-30 07:47:57
|
Bugs item #763021, was opened at 2003-06-30 08:14 Message generated for change (Comment added) made by joergl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=763021&group_id=45430 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Nobody/Anonymous (nobody) Summary: arct results in error Initial Comment: The attached file does not run under PyX0.3.1. On the other hand, there is no problem if arc is used instead of arct. ---------------------------------------------------------------------- >Comment By: Jörg Lehmann (joergl) Date: 2003-06-30 09:47 Message: Logged In: YES user_id=390410 This is not a bug. In order to arct being well defined, a current point has to be defined (see Postscript language reference). Note that this is not the case for arc or arcn. Thus, the resulting excepting is the intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=763021&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-30 06:14:30
|
Bugs item #763021, was opened at 2003-06-30 06:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=763021&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Nobody/Anonymous (nobody) Summary: arct results in error Initial Comment: The attached file does not run under PyX0.3.1. On the other hand, there is no problem if arc is used instead of arct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=763021&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-27 20:04:24
|
Bugs item #760764, was opened at 2003-06-25 20:52 Message generated for change (Comment added) made by gertingold You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Jörg Lehmann (joergl) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- >Comment By: Gert Ingold (gertingold) Date: 2003-06-27 20:04 Message: Logged In: YES user_id=809523 One more comment concerning the workaround proposed by André: Things become of course more complicated if reencoding takes place (e.g. when the map file contains the statement "TeXBase1Encoding ReEncodeFont"). What was meant to be a ß (germandbls), i.e. character 255 in EC, will turn out as ydieresis in TeXBase1. In order to obtain a ß, one would have to ask for a \SS=Germandbls=character 223. If this is not done, the glyph is not even extracted from the pfb-file so that changing the eps-file would not be an option anymore. ---------------------------------------------------------------------- Comment By: Gert Ingold (gertingold) Date: 2003-06-27 19:04 Message: Logged In: YES user_id=809523 The changes to text.py fixed the original problem. However, there is still a problem (basically already described by André in his message of June 26). Apparently, the map-files are not evaluated so that replacement fonts are used. This behavior can already be obtained with the standard TeX fonts and \usepackage[T1]{fontenc}. The solution suggested by André is not very practical so that the question mark in "To be implemented ... ?!" should be replaced by (at least two) exclamation marks. ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 08:43 Message: Logged In: YES user_id=405853 Fix looks fine to me. I can get marvosym running by that (which didn't work previously due to the same bug). Consider this minimal example: from pyx import * text.set(mode="latex") text.preamble("\usepackage{marvosym}") c = canvas.canvas() c.text(0, 0, "\EUR") c.writetofile("test") Unfortunately you have to do two things for getting this working: 1. You have to copy marvosym.pfb to fmvr8x.pfb (the name used intenally) 2. You have to modify the PostScript output test.eps, namely you have to change the selectfont from /FMVR8X 9.962640 selectfont to /Martin_Vogels_Symbole 9.962640 selectfont The information can be found in marvosym.map To be implemented ... ?! ---------------------------------------------------------------------- Comment By: Jörg Lehmann (joergl) Date: 2003-06-26 08:31 Message: Logged In: YES user_id=390410 Please check whether the changes made in the CVS head fix this problem. Jörg ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 06:52 Message: Logged In: YES user_id=405853 I'm just considering the problem of loading fd-files triggered by TeX when processing some expressions. By default, those messages are errors in PyX 0.3.1. I've just checked in a special handler for font description file loading, enabled by default via texmessagedefaultrun. Thus fd-file loading is not considered to be an error anymore. Beside that, your report about tfm-file handling is still open. PyX might be just to strict in that sence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-27 19:13:09
|
Bugs item #760764, was opened at 2003-06-25 20:52 Message generated for change (Comment added) made by gertingold You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Jörg Lehmann (joergl) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- >Comment By: Gert Ingold (gertingold) Date: 2003-06-27 19:04 Message: Logged In: YES user_id=809523 The changes to text.py fixed the original problem. However, there is still a problem (basically already described by André in his message of June 26). Apparently, the map-files are not evaluated so that replacement fonts are used. This behavior can already be obtained with the standard TeX fonts and \usepackage[T1]{fontenc}. The solution suggested by André is not very practical so that the question mark in "To be implemented ... ?!" should be replaced by (at least two) exclamation marks. ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 08:43 Message: Logged In: YES user_id=405853 Fix looks fine to me. I can get marvosym running by that (which didn't work previously due to the same bug). Consider this minimal example: from pyx import * text.set(mode="latex") text.preamble("\usepackage{marvosym}") c = canvas.canvas() c.text(0, 0, "\EUR") c.writetofile("test") Unfortunately you have to do two things for getting this working: 1. You have to copy marvosym.pfb to fmvr8x.pfb (the name used intenally) 2. You have to modify the PostScript output test.eps, namely you have to change the selectfont from /FMVR8X 9.962640 selectfont to /Martin_Vogels_Symbole 9.962640 selectfont The information can be found in marvosym.map To be implemented ... ?! ---------------------------------------------------------------------- Comment By: Jörg Lehmann (joergl) Date: 2003-06-26 08:31 Message: Logged In: YES user_id=390410 Please check whether the changes made in the CVS head fix this problem. Jörg ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 06:52 Message: Logged In: YES user_id=405853 I'm just considering the problem of loading fd-files triggered by TeX when processing some expressions. By default, those messages are errors in PyX 0.3.1. I've just checked in a special handler for font description file loading, enabled by default via texmessagedefaultrun. Thus fd-file loading is not considered to be an error anymore. Beside that, your report about tfm-file handling is still open. PyX might be just to strict in that sence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-26 08:43:09
|
Bugs item #760764, was opened at 2003-06-25 22:52 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Jörg Lehmann (joergl) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- >Comment By: André Wobst (wobsta) Date: 2003-06-26 10:43 Message: Logged In: YES user_id=405853 Fix looks fine to me. I can get marvosym running by that (which didn't work previously due to the same bug). Consider this minimal example: from pyx import * text.set(mode="latex") text.preamble("\usepackage{marvosym}") c = canvas.canvas() c.text(0, 0, "\EUR") c.writetofile("test") Unfortunately you have to do two things for getting this working: 1. You have to copy marvosym.pfb to fmvr8x.pfb (the name used intenally) 2. You have to modify the PostScript output test.eps, namely you have to change the selectfont from /FMVR8X 9.962640 selectfont to /Martin_Vogels_Symbole 9.962640 selectfont The information can be found in marvosym.map To be implemented ... ?! ---------------------------------------------------------------------- Comment By: Jörg Lehmann (joergl) Date: 2003-06-26 10:31 Message: Logged In: YES user_id=390410 Please check whether the changes made in the CVS head fix this problem. Jörg ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 08:52 Message: Logged In: YES user_id=405853 I'm just considering the problem of loading fd-files triggered by TeX when processing some expressions. By default, those messages are errors in PyX 0.3.1. I've just checked in a special handler for font description file loading, enabled by default via texmessagedefaultrun. Thus fd-file loading is not considered to be an error anymore. Beside that, your report about tfm-file handling is still open. PyX might be just to strict in that sence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-26 08:31:24
|
Bugs item #760764, was opened at 2003-06-25 22:52 Message generated for change (Comment added) made by joergl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Jörg Lehmann (joergl) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- >Comment By: Jörg Lehmann (joergl) Date: 2003-06-26 10:31 Message: Logged In: YES user_id=390410 Please check whether the changes made in the CVS head fix this problem. Jörg ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-26 08:52 Message: Logged In: YES user_id=405853 I'm just considering the problem of loading fd-files triggered by TeX when processing some expressions. By default, those messages are errors in PyX 0.3.1. I've just checked in a special handler for font description file loading, enabled by default via texmessagedefaultrun. Thus fd-file loading is not considered to be an error anymore. Beside that, your report about tfm-file handling is still open. PyX might be just to strict in that sence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-26 06:52:33
|
Bugs item #760764, was opened at 2003-06-25 22:52 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) >Assigned to: Jörg Lehmann (joergl) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- >Comment By: André Wobst (wobsta) Date: 2003-06-26 08:52 Message: Logged In: YES user_id=405853 I'm just considering the problem of loading fd-files triggered by TeX when processing some expressions. By default, those messages are errors in PyX 0.3.1. I've just checked in a special handler for font description file loading, enabled by default via texmessagedefaultrun. Thus fd-file loading is not considered to be an error anymore. Beside that, your report about tfm-file handling is still open. PyX might be just to strict in that sence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-25 20:52:30
|
Bugs item #760764, was opened at 2003-06-25 20:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gert Ingold (gertingold) Assigned to: Nobody/Anonymous (nobody) Summary: TFMError "width_index should not be zero" Initial Comment: Hello, I am trying to use a commercial font (Garamond Standard from Softmaker) with PyX 0.3.1. Unfortunately, a TFMError "width_index should not be zero" is raised. A closer look at the TFM files shows indeed that CHARWD is zero for certain characters, namely "17x in the T1 encoding (8t) and "17x and "1Fx in the TS1 encoding (8c). Character "17x is defined as /compoundwordmark while "1Fx is /ffl. The font tables in CTAN:fonts/utilities/fontinst-prerelease/doc/talks/et99-font-tables.pdf don't show glyphs for compoundwordmark in the T1 and TS1 encodings and for the ffl ligature in the TS1 encoding (of course, the ffl ligature is present in the T1 encoding). The same problem arises if I use the package mathptmx while the use of the palatino package leads to: After parsing this message, the following was left: *(/usr/TeX/texmf/tex/latex/psnfss/ot1phv.fd) If the described effect is caused by PyX checking the CHARWD's of all characters, this should, in my opinion, be considered a bug. Best regards, Gert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=760764&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-16 10:12:27
|
Patches item #753569, was opened at 2003-06-12 23:20 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: André Wobst (wobsta) Summary: Axis partitioner for formatting dates & times nicely Initial Comment: I have been doing quite a bit of work collecting data over periods of days and weeks, an have started working on a partitioner which produces nice looking time axes in PyX. I am attaching the code, which should take very much massaging to include in the main PyX distribution, if you think this would be useful (I do). In the near future, I will probably implement another partioner useful for data extending over months & years (which will create non- uniform partitions with ticks at real month boundaries, etc.). A sample of a web page which is being updated with this is: http://129.59.235.188/~michael/Environmental.html which shows some environmental data from our building. Note that to get the most current graphs, you have to click the 'update graphs' button, then go back to the original page and refresh it. We are still developing the website, so it is a little crude in the mechanistics. Note that becasue of the way I have declared the format strings as class globals, it is very easy to override the formatting. The small sample subclass michaeltimepart is the one being used on the webpage. The main difference in this case is the slash in the month/day spec. I prefer this method for handling variations to including all possible information in the arguments to the constructor, since python subclassing is so easy. If you would rather handle format variations as arguments, the changes are easy. Maybe the best bet would be to have format string as arguments defaulted to None, in which case the class defaults arre used, but if non-None formats are given, they override the class defaults. This would allow both programming styles. Comments? Marcus Mendenhall ---------------------------------------------------------------------- >Comment By: André Wobst (wobsta) Date: 2003-06-16 12:12 Message: Logged In: YES user_id=405853 I would like to see a solution, which does not mix the partitioning of a time axis and the creation of the text for the labels. I do understand, that this splitting might look unnatural for the first time. But it increases usability (at least I think so). Thus I'm not totally confident about your patch. But I should remark, that I would have written something very similar to your patch, when I would have needed a quick & easy implementation of a time axis. Concerning the new datetime data type(s) of Python 2.3 I would like to see, that they replace the frac-instances for time axes completely. This means to remove the explicit usage of the frac instances at all those points, where they are not strongly needed (for example in the axis painter). The creation of text for the labels needs to be separated from the axis painter, as I checked it in the CVS head last weekend. I'll try to continue in writting code in that direction during the next weeks. We'll see what happens in terms of a datetime axis by that ... ---------------------------------------------------------------------- Comment By: Marcus Mendenhall (mendenhall) Date: 2003-06-13 16:00 Message: Logged In: YES user_id=470295 I hadn't noticed the new datetime module in 2.3. It is certainly trivial to make this us either time or datetime, since it really mostly needs strftime, which exists in both. The question about how general to make this, and how to allow it to interpret different input time formats, is somewhat philosophical. I soent a fair amount of time thinking about how general to make my version (for now), and concluded that overly general may not be too good. Unlike with many other options for x-axes, one generally knows in advance what time ranges one want to cover in a plot. If it is less than seconds, decimal time is appropriate, and if it is more than years, the same uniform division scheme is appropriate. It is only in a narrow range of civil time scales (minutes to months) that we have pathological divisions. Thus, making an axis formatter that specifically does this range more beautifully and configurably was my goal. If a completely general formatter is desired, maybe it should be a set of classes which implement nice algorithms for each general time range, and an autotimeaxis() which selects one of the specific formatters. That way, if the user wants to force a specific formatter (which in my case will almost always be the case), the specific class can be instantiated, but if one wants a 'no worries' axis, the wrapper can be called to select the right formatter. Comments? ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-13 11:15 Message: Logged In: YES user_id=405853 Its nice to see your time partitioning ... indeed those axes are an important feature to be added to PyX in the future. I thought about this issue myself as well and there are users outside which request it regulary (I myself included). Indeed, the possibility to set ticks not only equal spaced was a design decision quite some years ago having in mind the example of months (with different length) already. Recently I've played around with the new datetime module of python 2.3 (I've installed the beta version at home), which might be a good solution for implementing time axes. (I'm not yet totally sure about it.) One feature would be, that you could use something like strptime as well. You could then overwrite the convert/invert of the axis. In good old Python (<=2.2) a strptime is available in the time module unter Unix only. I think a timeaxis should decode time strings like dates (1.1.2000 etc.) without (or with only an easy) additional efforts. Best would be, if you could just say g = graph.graphxy(x=graph.timeaxis(), ...) and all works out of the box. I definitly want that, but it will take some time. Additionally I'm currently working on texters (I want to separate out the creation of label texts from the axis painter). You're right with your solution, that labels for the time axes can be created most easily in the partitioner, but we could write a time texter as well, which does this job. It definitly has to be taken out of the axispainter. I prefer a texter solution. The axispainter is very ugly already. Beside all this, let me briefly comment your proposed solution about constructor arguments. You're totally right, that it is nice to create classes with personal preferences. PyX Power Users ;-) definitly want that. But what do you think about doing it the following way: class myaxispainter(graph.axispainter): def __init__(self, zerolineattrs=None, **args): graph.axispainter(self, zerolineattrs=zerolineattrs, **args) The advantage is, that it behaves like the original axispainter except for the default value of zerolineattrs ... I like this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-13 14:00:31
|
Patches item #753569, was opened at 2003-06-12 16:20 Message generated for change (Comment added) made by mendenhall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: André Wobst (wobsta) Summary: Axis partitioner for formatting dates & times nicely Initial Comment: I have been doing quite a bit of work collecting data over periods of days and weeks, an have started working on a partitioner which produces nice looking time axes in PyX. I am attaching the code, which should take very much massaging to include in the main PyX distribution, if you think this would be useful (I do). In the near future, I will probably implement another partioner useful for data extending over months & years (which will create non- uniform partitions with ticks at real month boundaries, etc.). A sample of a web page which is being updated with this is: http://129.59.235.188/~michael/Environmental.html which shows some environmental data from our building. Note that to get the most current graphs, you have to click the 'update graphs' button, then go back to the original page and refresh it. We are still developing the website, so it is a little crude in the mechanistics. Note that becasue of the way I have declared the format strings as class globals, it is very easy to override the formatting. The small sample subclass michaeltimepart is the one being used on the webpage. The main difference in this case is the slash in the month/day spec. I prefer this method for handling variations to including all possible information in the arguments to the constructor, since python subclassing is so easy. If you would rather handle format variations as arguments, the changes are easy. Maybe the best bet would be to have format string as arguments defaulted to None, in which case the class defaults arre used, but if non-None formats are given, they override the class defaults. This would allow both programming styles. Comments? Marcus Mendenhall ---------------------------------------------------------------------- >Comment By: Marcus Mendenhall (mendenhall) Date: 2003-06-13 09:00 Message: Logged In: YES user_id=470295 I hadn't noticed the new datetime module in 2.3. It is certainly trivial to make this us either time or datetime, since it really mostly needs strftime, which exists in both. The question about how general to make this, and how to allow it to interpret different input time formats, is somewhat philosophical. I soent a fair amount of time thinking about how general to make my version (for now), and concluded that overly general may not be too good. Unlike with many other options for x-axes, one generally knows in advance what time ranges one want to cover in a plot. If it is less than seconds, decimal time is appropriate, and if it is more than years, the same uniform division scheme is appropriate. It is only in a narrow range of civil time scales (minutes to months) that we have pathological divisions. Thus, making an axis formatter that specifically does this range more beautifully and configurably was my goal. If a completely general formatter is desired, maybe it should be a set of classes which implement nice algorithms for each general time range, and an autotimeaxis() which selects one of the specific formatters. That way, if the user wants to force a specific formatter (which in my case will almost always be the case), the specific class can be instantiated, but if one wants a 'no worries' axis, the wrapper can be called to select the right formatter. Comments? ---------------------------------------------------------------------- Comment By: André Wobst (wobsta) Date: 2003-06-13 04:15 Message: Logged In: YES user_id=405853 Its nice to see your time partitioning ... indeed those axes are an important feature to be added to PyX in the future. I thought about this issue myself as well and there are users outside which request it regulary (I myself included). Indeed, the possibility to set ticks not only equal spaced was a design decision quite some years ago having in mind the example of months (with different length) already. Recently I've played around with the new datetime module of python 2.3 (I've installed the beta version at home), which might be a good solution for implementing time axes. (I'm not yet totally sure about it.) One feature would be, that you could use something like strptime as well. You could then overwrite the convert/invert of the axis. In good old Python (<=2.2) a strptime is available in the time module unter Unix only. I think a timeaxis should decode time strings like dates (1.1.2000 etc.) without (or with only an easy) additional efforts. Best would be, if you could just say g = graph.graphxy(x=graph.timeaxis(), ...) and all works out of the box. I definitly want that, but it will take some time. Additionally I'm currently working on texters (I want to separate out the creation of label texts from the axis painter). You're right with your solution, that labels for the time axes can be created most easily in the partitioner, but we could write a time texter as well, which does this job. It definitly has to be taken out of the axispainter. I prefer a texter solution. The axispainter is very ugly already. Beside all this, let me briefly comment your proposed solution about constructor arguments. You're totally right, that it is nice to create classes with personal preferences. PyX Power Users ;-) definitly want that. But what do you think about doing it the following way: class myaxispainter(graph.axispainter): def __init__(self, zerolineattrs=None, **args): graph.axispainter(self, zerolineattrs=zerolineattrs, **args) The advantage is, that it behaves like the original axispainter except for the default value of zerolineattrs ... I like this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-13 09:15:28
|
Patches item #753569, was opened at 2003-06-12 23:20 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) >Assigned to: André Wobst (wobsta) Summary: Axis partitioner for formatting dates & times nicely Initial Comment: I have been doing quite a bit of work collecting data over periods of days and weeks, an have started working on a partitioner which produces nice looking time axes in PyX. I am attaching the code, which should take very much massaging to include in the main PyX distribution, if you think this would be useful (I do). In the near future, I will probably implement another partioner useful for data extending over months & years (which will create non- uniform partitions with ticks at real month boundaries, etc.). A sample of a web page which is being updated with this is: http://129.59.235.188/~michael/Environmental.html which shows some environmental data from our building. Note that to get the most current graphs, you have to click the 'update graphs' button, then go back to the original page and refresh it. We are still developing the website, so it is a little crude in the mechanistics. Note that becasue of the way I have declared the format strings as class globals, it is very easy to override the formatting. The small sample subclass michaeltimepart is the one being used on the webpage. The main difference in this case is the slash in the month/day spec. I prefer this method for handling variations to including all possible information in the arguments to the constructor, since python subclassing is so easy. If you would rather handle format variations as arguments, the changes are easy. Maybe the best bet would be to have format string as arguments defaulted to None, in which case the class defaults arre used, but if non-None formats are given, they override the class defaults. This would allow both programming styles. Comments? Marcus Mendenhall ---------------------------------------------------------------------- >Comment By: André Wobst (wobsta) Date: 2003-06-13 11:15 Message: Logged In: YES user_id=405853 Its nice to see your time partitioning ... indeed those axes are an important feature to be added to PyX in the future. I thought about this issue myself as well and there are users outside which request it regulary (I myself included). Indeed, the possibility to set ticks not only equal spaced was a design decision quite some years ago having in mind the example of months (with different length) already. Recently I've played around with the new datetime module of python 2.3 (I've installed the beta version at home), which might be a good solution for implementing time axes. (I'm not yet totally sure about it.) One feature would be, that you could use something like strptime as well. You could then overwrite the convert/invert of the axis. In good old Python (<=2.2) a strptime is available in the time module unter Unix only. I think a timeaxis should decode time strings like dates (1.1.2000 etc.) without (or with only an easy) additional efforts. Best would be, if you could just say g = graph.graphxy(x=graph.timeaxis(), ...) and all works out of the box. I definitly want that, but it will take some time. Additionally I'm currently working on texters (I want to separate out the creation of label texts from the axis painter). You're right with your solution, that labels for the time axes can be created most easily in the partitioner, but we could write a time texter as well, which does this job. It definitly has to be taken out of the axispainter. I prefer a texter solution. The axispainter is very ugly already. Beside all this, let me briefly comment your proposed solution about constructor arguments. You're totally right, that it is nice to create classes with personal preferences. PyX Power Users ;-) definitly want that. But what do you think about doing it the following way: class myaxispainter(graph.axispainter): def __init__(self, zerolineattrs=None, **args): graph.axispainter(self, zerolineattrs=zerolineattrs, **args) The advantage is, that it behaves like the original axispainter except for the default value of zerolineattrs ... I like this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 |
|
From: SourceForge.net <no...@so...> - 2003-06-12 21:20:25
|
Patches item #753569, was opened at 2003-06-12 16:20 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=753569&group_id=45430 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Nobody/Anonymous (nobody) Summary: Axis partitioner for formatting dates & times nicely Initial Comment: I have been doing quite a bit of work collecting data over periods of days and weeks, an have started working on a partitioner which produces nice looking time axes in PyX. I am attaching the code, which should take very much massaging to include in the main PyX distribution, if you think this would be useful (I do). In the near future, I will probably implement another partioner useful for data extending over months & years (which will create non- uniform partitions with ticks at real month boundaries, etc.). A sample of a web page which is being updated with this is: http://129.59.235.188/~michael/Environmental.html which shows some environmental data from our building. Note that to get the most current graphs, you have to click the 'update graphs' button, then go back to the original page and refresh it. We are still developing the website, so it is a little crude in the mechanistics. Note that becasue of the way I have declared the format strings as class globals, it is very easy to override the formatting. The small sample subclass michaeltimepart is the one being used on the webpage. The main difference in this case is the slash in the month/day spec. I prefer this method for handling variations to including all possible information in the arguments to the constructor, since python subclassing is so easy. If you would rather handle format variations as arguments, the changes are easy. Maybe the best bet would be to have format string as arguments defaulted to None, in which case the class defaults arre used, but if non-None formats are given, they override the class defaults. This would allow both programming styles. Comments? Marcus Mendenhall ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=753569&group_id=45430 |
49 messages has been excluded from this view by a project administrator.
