Hi Günter, thanks for all your correct help and the bug report. It turns out that we failed to open the virtual font files in binary mode, which becomes visible on MS Windows. Fixed in changeset 3181. You example now works fine here (Win XP SP3, MiKTeX 2.9, Python 2.7.2).
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
