Dear all, I'm sorry for the troubles you have with PyX on Windows. I must admit that we claim to be cross-plattform (and I did quite some tests many years ago about connecting TeX/LaTeX cross-plattform including Windows). But lately non of the developers did spend any time to test (and fix) PyX on Windows. Obviously things are broken right now. I'm sorry. I plan to setup a test environment on Windows and try to fix the issues. Probably using both, MiKTeX and TeXlive (yeah, texlive 2011 golden master is expected in the next days) on XP and Windows 7. We'll see. I do have several Windows environments available (virtualized though, but that is most probably fine).
I encourage others with know-how about the issue to speak up. This would be of
great help. However, in case nobody is able to answer (and suggest patches),
I'll have a look into the issue myself in the next weeks (not days,
unfortunately). I'll let you know about my progress on this list.
Best,
André
Am 26.06.2011 um 23:16 schrieb Guenter Jaritz:
> Did also notice that PyX 0.11.1 has issues under windows:
>
> My setup:
> Win XP SP3
> Miktex 2.8
> Python 2.6
> PyX 0.11.1 (svn 3173)
>
> PyX has not been installed, just has been checked out with svn
>
> Copied hello.py to main directory (above pyx) and executed it: (got issue
> above)
>
> I had the same problem the previous poster had:
>> The subprocess module informs you about the "close_fds" option not
>> being valid under Windows. You could try to follow its advice and
>> deactivate this option in the file
>>
>> c:\python27\Lib\site-packages\PyX-0.11.1\pyx\text.py", line 910
>>
>> Change it to
>> close_fds=False
>
> Then I ran straight into the next problem:
>
> 'cmr10' should be available at 'C:/miktex/fonts/tfm/public/cm/cmr10.tfm
> ' according to kpsewhich, but the file is not available at this location;
> update your kpsewhich database
> Traceback (most recent call last):
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\hello.py", line 12, in <module>
> c.writeEPSfile()
> [... snip ...]
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\dvi\texfont.py", line 37, in
> __init__
> file = filelocator.open(self.name, [filelocator.format.tfm], "rb")
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\filelocator.py", line 274, in open
> raise IOError("Could not locate the file '%s'." % filename)
> IOError: Could not locate the file 'cmr10'.
>
> pyx.filelocator does seem not to like what kpsewhich is returning. After
> tinkering around a while I found in filelocator.py/line 204
>
> full_filename = full_filenames.split("\n")[0]
>
> This reminded me that kpsewhich is returning answers with a newline on the
> command prompt. Changing the above to windows newline
>
> full_filename = full_filenames.split("\r\n")[0]
>
> made hello.py producing proper PDF and DVI. I also tried
>
> full_filename = full_filenames.strip()
>
> which also worked. This should fix it on both platforms. Is it safe to assume
> that kpsewhich only returns "one" entry (not several entrys separated by
> newlines)?
>
> Then I ran out of luck trying another font:
>
> Inserting
>
> text.set(mode="latex")
> text.preamble(r"\usepackage{times}")
>
> c.text(0, 0, r"\LaTeX{} doesn't need to look like \LaTeX{} all the time.")
>
> yielded (the first lines show which files PyX asked for using kpsewhich)
>
> kpsewhich --format="vf" "ptmr7t"
> C:/miktex/fonts/vf/adobe/times/ptmr7t.vf
> kpsewhich --format="tfm" "ptmr7t"
> C:/miktex/fonts/tfm/adobe/times/ptmr7t.tfm
> kpsewhich --format="tfm" "ptmr8r"
> C:/miktex/fonts/tfm/adobe/times/ptmr8r.tfm
> Traceback (most recent call last):
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\font.py", line 10, in <module>
> c.writeEPSfile("font")
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\canvas.py", line 289, in
> wrappedindocument
> return method(d, file)
> [Snip ...]
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\dvi\dvifile.py", line 227, in
> definefont
> afont = texfont.virtualfont(fontname, fontfile, c, q/self.tfmconv,
> d/self.tfmconv, self.tfmconv, self.pyxconv, self.debug>1)
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\dvi\texfont.py", line 143, in __init__
> self.vffile = vffile.vffile(file, 1.0*q/d, tfmconv, pyxconv, debug > 1)
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\dvi\vffile.py", line 57, in __init__
> cmd = afile.readuchar()
> File "C:\Dokumente und Einstellungen\nep\Eigene
> Dateien\eclipseworkspace\pyxsvn\src\pyx\reader.py", line 80, in readuchar
> return struct.unpack("B", self.file.read(1))[0]
> struct.error: unpack requires a string argument of length 1
>
> Something seems to go wrong when vffile/reader is trying to read *.tfm-files:
> For some reason reader.py tries to read characters, but there is nothing more
> to read (when the self.file.read(1)[0] on line 80 returns nothing, then the
> error comes).
>
> Because I have absolutely no idea what vffile/reader is doing, I have to ask
> the experts advice.
>
> With regards,
> Guenter
>
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> PyX-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyx-user
--
by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
/ \ \ / ) [email protected], http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________ PyX-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-user
