pyx-user — PyX user

Re: [Pyx-user] use on windows

[Joerg L. <jo...@us...>]

On 20.09.03, Brett Calcott wrote:
> - I get a warning from gsview:  The number of begin and end comments do not
> match.

Funny... In fact, they do not match (because there is no BeginComments)
but IMHO this is according to the DSC specs...

> - I get files left around like xxxxxxxx.dvicopy.

That should not be the case. Maybe André wants to look into this.

> However, it doesn't work with integral.py
> 
> Traceback (most recent call last):
>   File "integral.py", line 30, in ?
>     g.writetofile("integral")
>   File "c:\python23\Lib\site-packages\pyx\canvas.py", line 943, in
> writetofile
>     pritem.write(file)
>   File "c:\python23\Lib\site-packages\pyx\prolog.py", line 123, in write
>     raise RuntimeError("cannot find type 1 font %s" % self.filename)
> RuntimeError: cannot find type 1 font cmex10.pfb
> 
> X:\pyx\examples\graphs>find c:\miktex -name cmex10.pfb
> c:\miktex\texmf\fonts\type1\bluesky\cm\cmex10.pfb
> 
> X:\pyx\examples\graphs>kpsewhich cmex10.pfb
> 
> kspewhich doesn't report anything for that file -- I guess it should.

Yes, it should. Maybe you have to rebuild your ls-R database?

> Lastly, dvicopy prints a fair bit to stdout about what it is doing that
> users probably don't want to see.

That's already on the TODO list.

> ps. When this is ironed out, do you want some diffs to the code so that it
> detects Miktex and does the right thing?

Yes, of course, please send us the diffs.

        Jörg

Re: [Pyx-user] use on windows

[Brett C. <br...@co...>]

>
> Ah, you need to enable virtual font support via dvicopy. Please try
>
>         text.set(mode="latex", dvicopy=1)
>
> Hopefully that works with MikTeX!
>

It works with hello.py. 2 things:

- I get a warning from gsview:  The number of begin and end comments do not
match.
- I get files left around like xxxxxxxx.dvicopy.


However, it doesn't work with integral.py

Traceback (most recent call last):
  File "integral.py", line 30, in ?
    g.writetofile("integral")
  File "c:\python23\Lib\site-packages\pyx\canvas.py", line 943, in
writetofile
    pritem.write(file)
  File "c:\python23\Lib\site-packages\pyx\prolog.py", line 123, in write
    raise RuntimeError("cannot find type 1 font %s" % self.filename)
RuntimeError: cannot find type 1 font cmex10.pfb

X:\pyx\examples\graphs>find c:\miktex -name cmex10.pfb
c:\miktex\texmf\fonts\type1\bluesky\cm\cmex10.pfb

X:\pyx\examples\graphs>kpsewhich cmex10.pfb

X:\pyx\examples\graphs>


kspewhich doesn't report anything for that file -- I guess it should.


Lastly, dvicopy prints a fair bit to stdout about what it is doing that
users probably don't want to see.



Cheers,
Brett

ps. When this is ironed out, do you want some diffs to the code so that it
detects Miktex and does the right thing?

Re: [Pyx-user] use on windows

[Brett C. <br...@co...>]

> >
> > Is it not possible to include them in the distro?
>
> Hmm, I don't think that makes much sense, they have to match
> your distribution. However, I forget to mention that
> you have to tell the setup.py script where it has to look for
> the header and library files. This can be done
> via a setup.cfg file (in the same directory as setup.py) which
> contains
>
> [build_ext]
> include_dirs=path-to-your-MikTeX-include-files
> library_dirs=path-to-your-MikTeX-library-filesa
>

I got the whole Miktex distro -- I'll have a look at getting it going later.
It doesn't look like the includes & libs are the same as you have specified.


>
> > >
> > > > 4. temporary .dvi files are left around the place.
> > >
> > > Is this always the case, or only if PyX exits with an exception?
> > >
> >
> > No, they get left around even if everything works.
>
> Hmm. What files precisely?


Let me get back to you on this.


>
> > I use the mathpazo package (palatino with math) all the time.
> > I tried it in the hello.py example after the from pyx import *
> >
> >
> > X:\pyx\examples>python hello.py
> > Traceback (most recent call last):
> >   File "hello.py", line 2, in ?
> >     text.preamble(r"\usepackage{mathpazo}")
> >   File "c:\python23\Lib\site-packages\pyx\text.py", line 2230, in
preamble
> >     self.execute(expr, *args)
> >   File "c:\python23\Lib\site-packages\pyx\text.py", line 2068, in
execute
> >     raise TexResultError("unhandled TeX response (might be an error)",
self)
> > pyx.text.TexResultError: unhandled TeX response (might be an error)
> > The expression passed to TeX was:
> >   \usepackage{mathpazo}%
> >   \PyXInput{5}%
> > After parsing the return message from TeX, the following was left:
> >   *! Undefined control sequence.
> >   <*> \usepackage
> >                  {mathpazo}%
>
> Ah, you are in TeX mode, where \usepackage does not exist. Please
> tell PyX to switch to LaTeX by including
>
>   text.set(mode="latex")
>

Getting better, but still no luck. sorry, I just don't know the font stuff
in latex well enough to guess what is going on.

X:\pyx\examples>cat hello.py
from pyx import *
text.set(mode="latex")
text.preamble(r"\usepackage{times}")
c = canvas.canvas()
c.text(0, 0, "Hello, world!")
c.stroke(path.line(0, 0, 2, 0))
c.writetofile("hello")

X:\pyx\examples>python hello.py
Traceback (most recent call last):
  File "hello.py", line 7, in ?
    c.writetofile("hello")
  File "c:\python23\Lib\site-packages\pyx\canvas.py", line 936, in
writetofile
    for pritem in self.prolog():
  File "c:\python23\Lib\site-packages\pyx\canvas.py", line 661, in prolog
    result.extend(cmd.prolog())
  File "c:\python23\lib\site-packages\pyx\text.py", line 1784, in prolog
    return result + self.texrunner.prolog(self.dvinumber, self.page)
  File "c:\python23\lib\site-packages\pyx\text.py", line 2090, in prolog
    self.getdvi()
  File "c:\python23\lib\site-packages\pyx\text.py", line 2084, in getdvi
    self.dvifiles.append(DVIFile(dvifilename, debug=self.dvidebug))
  File "c:\python23\lib\site-packages\pyx\text.py", line 689, in __init__
    self.readfile()
  File "c:\python23\lib\site-packages\pyx\text.py", line 1091, in readfile
    state = self._read_page()
  File "c:\python23\lib\site-packages\pyx\text.py", line 1049, in _read_page
    file.read(file.readuchar()+file.readuchar()))
  File "c:\python23\lib\site-packages\pyx\text.py", line 777, in definefont
    self.fonts[num] =  Font(fontname, c, q, d, self.tfmconv, self.debug > 1)
  File "c:\python23\lib\site-packages\pyx\text.py", line 520, in __init__
    raise RuntimeError("no information for font '%s' found in font mapping
file,
 aborting" % name)
RuntimeError: no information for font 'ptmr7t' found in font mapping file,
abort
ing

If I look at the keys in 'fontmap' with 'pt', I only see these:

ptmb8r
ptmb8y
ptmbi8r
ptmbi8y
ptmbo8r
ptmbo8y
ptmr8r
ptmr8rn
ptmr8y
ptmri8r
ptmri8y
ptmro8r
ptmro8y
ptmrr8re




Cheers,
Brett

Re: [Pyx-user] use on windows

[Joerg L. <jo...@us...>]

Hi Brett,

On 19.09.03, Brett Calcott wrote:
> I got the whole Miktex distro -- I'll have a look at getting it going later.
> It doesn't look like the includes & libs are the same as you have specified.

Ok, that may well be the case. In fact, I have never used MikTeX... On
the other hand, the fallback solution via kpsewhich should be fine -
only a little slower but otherwise fully functional.

> Getting better, but still no luck. sorry, I just don't know the font stuff
> in latex well enough to guess what is going on.
> 
> X:\pyx\examples>cat hello.py
> from pyx import *
> text.set(mode="latex")
> text.preamble(r"\usepackage{times}")
> c = canvas.canvas()
> c.text(0, 0, "Hello, world!")
> c.stroke(path.line(0, 0, 2, 0))
> c.writetofile("hello")
> 
> X:\pyx\examples>python hello.py
> Traceback (most recent call last):
>   File "hello.py", line 7, in ?
>     c.writetofile("hello")
>   File "c:\python23\Lib\site-packages\pyx\canvas.py", line 936, in
> writetofile
>     for pritem in self.prolog():
>   File "c:\python23\Lib\site-packages\pyx\canvas.py", line 661, in prolog
>     result.extend(cmd.prolog())
>   File "c:\python23\lib\site-packages\pyx\text.py", line 1784, in prolog
>     return result + self.texrunner.prolog(self.dvinumber, self.page)
>   File "c:\python23\lib\site-packages\pyx\text.py", line 2090, in prolog
>     self.getdvi()
>   File "c:\python23\lib\site-packages\pyx\text.py", line 2084, in getdvi
>     self.dvifiles.append(DVIFile(dvifilename, debug=self.dvidebug))
>   File "c:\python23\lib\site-packages\pyx\text.py", line 689, in __init__
>     self.readfile()
>   File "c:\python23\lib\site-packages\pyx\text.py", line 1091, in readfile
>     state = self._read_page()
>   File "c:\python23\lib\site-packages\pyx\text.py", line 1049, in _read_page
>     file.read(file.readuchar()+file.readuchar()))
>   File "c:\python23\lib\site-packages\pyx\text.py", line 777, in definefont
>     self.fonts[num] =  Font(fontname, c, q, d, self.tfmconv, self.debug > 1)
>   File "c:\python23\lib\site-packages\pyx\text.py", line 520, in __init__
>     raise RuntimeError("no information for font '%s' found in font mapping
> file,
>  aborting" % name)
> RuntimeError: no information for font 'ptmr7t' found in font mapping file,
> aborting

Ah, you need to enable virtual font support via dvicopy. Please try

        text.set(mode="latex", dvicopy=1)

Hopefully that works with MikTeX!

        Jörg

-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

Re: [Pyx-user] Font problem: '10pt.lfs' not found.

[Michael H. <mic...@un...>]

J=F6rg,


thanks for your answer.

On Thu, 18 Sep 2003 21:41:13 +0200 Joerg Lehmann wrote:

> On 18.09.03, Michael Hagemann wrote:
> > I just installed PyX and it runs well, except for the text output.  When
> > I run any of the example that involve text output I get the following
> > backtrace:
>=20
> Hmm, looking at the code, I don't see what is happening there. PyX
> searches for 10pt.lfs, isn't able to open it for reading and then
> tells you that 10pt.lfs is available... The only thing that I can
> think of at the moment is that there is a permission problem.
> Are you able to open the file
>         /usr/lib/python2.2/site-packages/pyx/lfs/10pt.lfs
> for reading?

I wasn't able to read it, because the lfs directory wasn't installed.=20
After installing it manually everything works fine...

The trouble is, that I couldn't convince the setup script to install
it!?  It always says the following (also for a clean install):

  [...]
  running install_data
  not copying pyx/lfs/10pt.lfs (output up-to-date)
  not copying pyx/lfs/11pt.lfs (output up-to-date)
  not copying pyx/lfs/12pt.lfs (output up-to-date)
  [...]

If you have a clue what the problem might be, I'd be happy to test it
here...  I'm using PyX-0.4.1 and the distutils are from python2.2.2-dev
(debian).


michael

Re: [Pyx-user] A new user having trouble installing

[Michael S. <mic...@ph...>]

Dear Mr. Vignaux,

On 19.09.03, vignaux wrote:
> I have downloaded it but I am having 
> trouble installing. I used the second option
> 
> >    python setup.py install
> 
> as it was implied that one did not need
> 
> >the kpathsea header and library files for this
> 
> It does appear to need kpathsea and library files. I am using XDarwin on 
> Mac OS X 10.2.x. Python version 2.3. This has latex (in the form of 
> TeXshop).

Both is true. Unfortunately, at the moment setup.py uses the
c-extension kpathsea as the default. Then you need indeed some header
files and the kpathsea library. In the teTeX distribution,
they can be found in
    /<...>/teTeX/include
    /<...>/teTeX/lib
Whether they are included in TeXShop is unclear to me.

If they the files are present, you should create a file "setup.cfg" in
the directory where setup.py resides, with the following content:

    [build_ext]
    include_dirs=<Your-Tex-Path>/include
    library_dirs=<Your-Tex-Path>/lib

If this does not work, however, there is the fallback-solution that
uses the usual "kpsewhich" command which should be part of your
TeX-distribution. This tells PyX where the necessary TeX-files are.
In this case setup.py should not try to build the kpathsea extension.
Please remove the entry

    Extension("pyx.pykpathsea._pykpathsea",
              sources=["pyx/pykpathsea/pykpathsea.c"],
              libraries=["kpathsea"])

in setup.py.
Then, the command
    python setup.py install
should work fine.

Best greetings from Germany,

   Michael

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

[Pyx-user] A new user having trouble installing

[vignaux <Ton...@mc...>]

Pyx sounds just what I need! I have downloaded it but I am having 
trouble installing. I used the second option

>     python setup.py install

as it was implied that one did not need

> the kpathsea header and library files for this

However it is failing completely:

> [Bert:~/Documents/pythonstuff/PyX-0.4.1] vignaux% python setup.py install
> /sw/lib/python2.3/distutils/dist.py:227: UserWarning: Unknown distribution option: 'platform'
>   warnings.warn(msg)
> running install
> running build
> running build_py
> running build_ext
> building 'pyx.pykpathsea._pykpathsea' extension
> gcc -Wno-long-double -no-cpp-precomp -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.3 -c pyx/pykpathsea/pykpathsea.c -o build/temp.darwin-6.6-PowerMacintosh-2.3/pyx/pykpathsea/pykpathsea.o
> pyx/pykpathsea/pykpathsea.c:20:31: kpathsea/tex-file.h: No such file or directory
> pyx/pykpathsea/pykpathsea.c:21:31: kpathsea/progname.h: No such file or directory

and a whole lot of similar error messages until:

> pyx/pykpathsea/pykpathsea.c:96: `kpse_program_text_format' undeclared (first use in this function)
> pyx/pykpathsea/pykpathsea.c:97: `kpse_program_binary_format' undeclared (first use in this function)
> pyx/pykpathsea/pykpathsea.c:98: `kpse_miscfonts_format' undeclared (first use in this function)
> error: command 'gcc' failed with exit status 1


It does appear to need kpathsea and library files. I am using XDarwin on 
Mac OS X 10.2.x. Python version 2.3. This has latex (in the form of 
TeXshop).

What is my next step?

-- 
Prof G A Vignaux
School of Mathematical and Computing Sciences,
Victoria University, PO Box 600,    	Work:   +64 4 463 5276
Wellington, NZ               		Home:   +64 4 934 7851
Tony.Vignaux AT(mcs.vuw.ac.nz) 		Mobile: +64 21 89 7851
http://www.mcs.vuw.ac.nz/~vignaux

Re: [Pyx-user] Font problem: '10pt.lfs' not found.

[Joerg L. <jo...@us...>]

Hi Michael,

On 18.09.03, Michael Hagemann wrote:
> I just installed PyX and it runs well, except for the text output.  When
> I run any of the example that involve text output I get the following
> backtrace:
>
> > python latex.py
> Traceback (most recent call last):
>   File "latex.py", line 13, in ?
>     c.insert(plaintex.text(0, -1, r"This is plain \TeX."))
>   File "/usr/lib/python2.2/site-packages/pyx/text.py", line 2283, in text
>     return self._text(unit.topt(x), unit.topt(y), expr, *args)
>   File "/usr/lib/python2.2/site-packages/pyx/text.py", line 2271, in _text
>     self.execute(expr, *helper.getattrs(args, texmessage, default=self.texmessagedefaultrun))
>   File "/usr/lib/python2.2/site-packages/pyx/text.py", line 1994, in execute
>     raise IOError("file '%s' not found. Available latex font sizes: %s" % (lfsname, lfsnames))
> IOError: file '10pt.lfs' not found. Available latex font sizes: ['10pt', '10ptex', '11pt', '11ptex', '12pt', '12ptex', 'foils17pt', 'foils20pt', 'foils25pt', 'foils30pt']

Hmm, looking at the code, I don't see what is happening there. PyX
searches for 10pt.lfs, isn't able to open it for reading and then
tells you that 10pt.lfs is available... The only thing that I can
think of at the moment is that there is a permission problem.
Are you able to open the file
        /usr/lib/python2.2/site-packages/pyx/lfs/10pt.lfs
for reading?

        Jörg

-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

Re: [Pyx-user] use on windows

[Joerg L. <jo...@us...>]

Hi Brett,

On 18.09.03, Brett Calcott wrote:
> > You need the kpathsea header files, which probably are not included
> > in the MikTeX distribution. On the other hand, it's no major drawback
> > if you use the kpsewhich workaround.
> 
> Is it not possible to include them in the distro?

Hmm, I don't think that makes much sense, they have to match 
your distribution. However, I forget to mention that
you have to tell the setup.py script where it has to look for
the header and library files. This can be done
via a setup.cfg file (in the same directory as setup.py) which
contains

[build_ext]
include_dirs=path-to-your-MikTeX-include-files
library_dirs=path-to-your-MikTeX-library-filesa

> I got everything from CVS, installed it and I still get
> 
> X:\pyx\examples>python hello.py
> Traceback (most recent call last):
>   File "hello.py", line 6, in ?
>     c.writetofile("hello")
>   File "c:\python23\Lib\site-packages\pyx\canvas.py", line 943, in
> writetofile
>     pritem.write(file)
>   File "c:\python23\Lib\site-packages\pyx\prolog.py", line 123, in write
>     raise RuntimeError("cannot find type 1 font %s" % self.filename)
> RuntimeError: cannot find type 1 font cmr10.pfb
> 
> This file is here:
> c:\miktex\texmf\type1\bluesky\cm\cmr10.pfb

What is the output of "kpsewhich cmr10.pfb"?

> tstrip builds fine. I have no idea what it does..

t1strip implements the partial font downloading, that is
that only the glyphs that have been used are included in
the files. Otherwise the resulting EPS files become
rather huge.

> >
> > > 4. temporary .dvi files are left around the place.
> >
> > Is this always the case, or only if PyX exits with an exception?
> >
> 
> No, they get left around even if everything works.

Hmm. What files precisely?

> I use the mathpazo package (palatino with math) all the time.
> I tried it in the hello.py example after the from pyx import *
> 
> 
> X:\pyx\examples>python hello.py
> Traceback (most recent call last):
>   File "hello.py", line 2, in ?
>     text.preamble(r"\usepackage{mathpazo}")
>   File "c:\python23\Lib\site-packages\pyx\text.py", line 2230, in preamble
>     self.execute(expr, *args)
>   File "c:\python23\Lib\site-packages\pyx\text.py", line 2068, in execute
>     raise TexResultError("unhandled TeX response (might be an error)", self)
> pyx.text.TexResultError: unhandled TeX response (might be an error)
> The expression passed to TeX was:
>   \usepackage{mathpazo}%
>   \PyXInput{5}%
> After parsing the return message from TeX, the following was left:
>   *! Undefined control sequence.
>   <*> \usepackage
>                  {mathpazo}%

Ah, you are in TeX mode, where \usepackage does not exist. Please
tell PyX to switch to LaTeX by including

  text.set(mode="latex")

before the preamble line.

Regards,

        Jörg

Re: [Pyx-user] use on windows

[Brett C. <br...@co...>]

>
> sorry for the delay, I was on holiday and Andr=E9, too.

Hope it was good!

>
> You need the kpathsea header files, which probably are not included
> in the MikTeX distribution. On the other hand, it's no major drawback
> if you use the kpsewhich workaround.

Is it not possible to include them in the distro?

>
> > 2. it reverts to kpsewhich, but on my machine (using MikTeX), this wo=
n't
> > find the psfonts.map file. I hardcoded this in.
>
> This is a bug indeed, which already has been fixed in CVS.
>

I got everything from CVS, installed it and I still get

X:\pyx\examples>python hello.py
Traceback (most recent call last):
  File "hello.py", line 6, in ?
    c.writetofile("hello")
  File "c:\python23\Lib\site-packages\pyx\canvas.py", line 943, in
writetofile
    pritem.write(file)
  File "c:\python23\Lib\site-packages\pyx\prolog.py", line 123, in write
    raise RuntimeError("cannot find type 1 font %s" % self.filename)
RuntimeError: cannot find type 1 font cmr10.pfb

This file is here:
c:\miktex\texmf\type1\bluesky\cm\cmr10.pfb


> > Everything seems to run now, but :
> > 3. fonts don't seem to be produced properly, prbly cos' my hack in 2
didn't
> > work.
>
> Maybe this are the effects of another bug, which also has been fixed
> in CVS. Btw, have you been able to build the t1strip c extension module=
?

tstrip builds fine. I have no idea what it does..

>
> > 4. temporary .dvi files are left around the place.
>
> Is this always the case, or only if PyX exits with an exception?
>

No, they get left around even if everything works.


> > 5. Output in the eps files seems jammed in the bottom left corner (us=
ing
> > ghostscript viewer) is this just a config problem??
>
> This is normal behaviour of EPS files. However, if you don't like this,
> use something like
>
>     c.writetofile(filename, paperformat=3D"a4")
>
> to shift the output to the centre of an a4 page.
>
> > Also -- how do I change the default font?
>
> For this, you have to use an appropriate LaTeX package (like times.sty).
> Activate it with
>
>    text.preamble(r"\usepackage{times}")
>

I use the mathpazo package (palatino with math) all the time.
I tried it in the hello.py example after the from pyx import *


X:\pyx\examples>python hello.py
Traceback (most recent call last):
  File "hello.py", line 2, in ?
    text.preamble(r"\usepackage{mathpazo}")
  File "c:\python23\Lib\site-packages\pyx\text.py", line 2230, in preambl=
e
    self.execute(expr, *args)
  File "c:\python23\Lib\site-packages\pyx\text.py", line 2068, in execute
    raise TexResultError("unhandled TeX response (might be an error)", se=
lf)
pyx.text.TexResultError: unhandled TeX response (might be an error)
The expression passed to TeX was:
  \usepackage{mathpazo}%
  \PyXInput{5}%
After parsing the return message from TeX, the following was left:
  *! Undefined control sequence.
  <*> \usepackage
                 {mathpazo}%


Sorry I can't be more helpful -- I don't know the internals of latex that
well.
Let me know if you need more info.

Brett

[Pyx-user] Font problem: '10pt.lfs' not found.

[Michael H. <mic...@un...>]

Hi,


I just installed PyX and it runs well, except for the text output.  When
I run any of the example that involve text output I get the following
backtrace:

> python latex.py 
Traceback (most recent call last):
  File "latex.py", line 13, in ?
    c.insert(plaintex.text(0, -1, r"This is plain \TeX."))
  File "/usr/lib/python2.2/site-packages/pyx/text.py", line 2283, in text
    return self._text(unit.topt(x), unit.topt(y), expr, *args)
  File "/usr/lib/python2.2/site-packages/pyx/text.py", line 2271, in _text
    self.execute(expr, *helper.getattrs(args, texmessage, default=self.texmessagedefaultrun))
  File "/usr/lib/python2.2/site-packages/pyx/text.py", line 1994, in execute
    raise IOError("file '%s' not found. Available latex font sizes: %s" % (lfsname, lfsnames))
IOError: file '10pt.lfs' not found. Available latex font sizes: ['10pt', '10ptex', '11pt', '11ptex', '12pt', '12ptex', 'foils17pt', 'foils20pt', 'foils25pt', 'foils30pt']
>

This seems to be a (simple?) problem with the ".lfs" file extension, so
I didn't bother to investigate into it...

My configuration:  I run a quite up-to-date Debian 3.0 installation with
tetex 2.0.2.

> latex --version
TeX (Web2C 7.4.5) 3.14159
kpathsea version 3.4.5
[...]


Any help would be appreciated...


cheers,
michael

Re: [Pyx-user] use on windows

[Joerg L. <jo...@us...>]

Hi Brett,

sorry for the delay, I was on holiday and André, too.

On 10.09.03, Brett Calcott wrote:
> Is this lib supposed to work without problems on Windows?

Yes, of course.

> I have had to make a few hacks to get things going, but I'm not sure if this
> is cos' I have missed something.
> 
> 1. kpathsea lib won't build. Is there anywhere I can get the appropriate
> files?

You need the kpathsea header files, which probably are not included
in the MikTeX distribution. On the other hand, it's no major drawback
if you use the kpsewhich workaround.

> 2. it reverts to kpsewhich, but on my machine (using MikTeX), this won't
> find the psfonts.map file. I hardcoded this in.

This is a bug indeed, which already has been fixed in CVS.

> Everything seems to run now, but :
> 3. fonts don't seem to be produced properly, prbly cos' my hack in 2 didn't
> work.

Maybe this are the effects of another bug, which also has been fixed
in CVS. Btw, have you been able to build the t1strip c extension module?

> 4. temporary .dvi files are left around the place.

Is this always the case, or only if PyX exits with an exception?

> 5. Output in the eps files seems jammed in the bottom left corner (using
> ghostscript viewer) is this just a config problem??

This is normal behaviour of EPS files. However, if you don't like this,
use something like

    c.writetofile(filename, paperformat="a4")

to shift the output to the centre of an a4 page.

> Also -- how do I change the default font?

For this, you have to use an appropriate LaTeX package (like times.sty).
Activate it with

   text.preamble(r"\usepackage{times}")

right after the pyx imports. Please make sure that the necessary 
Type 1 fonts are available in your psfonts.map.

Best regards,

        Jörg

[Pyx-user] use on windows

[Brett C. <br...@co...>]

Hi,

Is this lib supposed to work without problems on Windows?

I have had to make a few hacks to get things going, but I'm not sure if this
is cos' I have missed something.

1. kpathsea lib won't build. Is there anywhere I can get the appropriate
files?
2. it reverts to kpsewhich, but on my machine (using MikTeX), this won't
find the psfonts.map file. I hardcoded this in.

Everything seems to run now, but :
3. fonts don't seem to be produced properly, prbly cos' my hack in 2 didn't
work.
4. temporary .dvi files are left around the place.
5. Output in the eps files seems jammed in the bottom left corner (using
ghostscript viewer) is this just a config problem??


Any help to fix these things would be great. Note that my latex knowledge is
not huge, nor my postscript knowledge.

Also -- how do I change the default font?

Cheers,
Brett

[Pyx-user] Announcement: PyX 0.4 released

[Andre W. <wo...@us...>]

Hi,

we're pround to announce the release of PyX 0.4. Find a list of
changes below.

Enjoy,


Jörg Lehmann, Michael Schindler, André Wobst



0.4 (2003/08/22):
  - graph module:
    - separate texter out of the axispainter
    - axis/partitioner/texter/painter/axispos redesign & interfaces
    - tick.text is renamed to tick.label
    - ticks and labels are renamed to tickpos/tickdist and labelpos/labeldist in partitioning
    - ticks can be used in the part to mix a partitioner with some manual ticks
      -> manualpart and the mix technique is not needed anymore
         (both things are still available and working, but they will be removed in the future)
    - _ensurefrac is implemented inside the frac constructor now; initialization is possible by:
      - a (enum, denom) tuple now (previously there were two arguments)
      - a string (as before via _ensurefrac)
      - exponential strings are allowed as well (e.g. "1e10" etc.)
      - a float (precision is determined by floatprecision -- the number of decimal places)
    - dense -> density
    - axis.maxworse
    - axis interface
  - text module:
    - reset() method for the texrunner
    - automatic restart of a TeX instance with the same preamble (preamble changes are not possible)
    - texmessage.loadfd for accepting font description loading
    - don't bail out on width_index == 0, but mark character invalid instead
    - dvicopy flag
    - support for specials; pyxgraphics flag
    - support psfonts.map: font names, font encodings
    - bugfix \def\ProcessPyXBox -> \long\def\ProcessPyXBox
    - improved lfs handling
  - data module:
    - full documentation via doc strings
  - connector module:
    - some preliminary version
  - box module:
    - multiple radii (up to two per point) and softnesses
    - ensurecenter added --- do we always force the creation of a center?
  - path module:
    - lentopar methods added including some tests
  - epsfile module:
    - new parameter bbox allows to override the bounding box of the eps file

  bugfixes:
  - text module:
    - derive TFMError and DVIError correctly from exceptions.Exception
    - close files and pipes, if they are no longer used (thanks to Marcus Mendenhall)
    - remove DeprecationWarning in Python 2.3 (thanks to Marcus Mendenhall)
  - box module:
    - correct rounding algorithm (Michael Schindler)
  - graph module:
    - refer to the graphs texrunner instead of the defaulttexrunner (cf. #728209)
    - rounding towards zero bugfix in autolinpart
    - log axis range rating bugfix
  - mathtree module:
    - addarg bugs (#738724)
  - epsfile module:
    - fix mixing up of height and width in scale calculation
  - and various other fixer here and there

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

Re: [Pyx-user] colored symbols

[Andre W. <and...@ph...>]

Hi Gert,

On 03.06.03, Gert Ingold wrote:
> I want to draw colored symbols in a graph where the color of each symbol
> is determined via the datafile, i.e. I have a datafile consisting of three
> columns where the first column determines the x-value, the second column the
> y-value and the third value (between 0 and 1) the color. I tried to use
> a color palette but somehow I did not succeed. Is there a simple way to
> accomplish this task?

Unfortunately, the default symbol style does not (yet?!) provide
access to modify those stroke attributes by some additional data given
in a data file. Nevertheless, it is easy to implement such a feature
by creating a specialized subclass of the symbol class of the graph
module. By that, you have to write only a few lines:

    from pyx import *

    class mysymbol(graph.symbol):

        def __init__(self, palette, **args):
            self.palette = palette
            graph.symbol.__init__(self, **args)

        def othercolumnkey(self, key, index):
            if key == "color":
                self.colorindex = index
            else:
                graph.symbol.othercolumnkey(self, key, index)

        def _drawsymbol(self, g, x, y, point=None):
            self.symbolattrs.append(self.palette.getcolor(point[self.colorindex]))
            graph.symbol._drawsymbol(self, g, x, y, point)
            del self.symbolattrs[-1]

    g = graph.graphxy(width=10)
    g.plot(graph.data("test.dat", x=1, y=2, color=3), mysymbol(color.palette.Rainbow))
    g.writetofile("test")


The test.dat file should look like:

    0 0 0.0
    1 1 0.1
    2 2 0.2
    3 3 0.3
    4 4 0.4
    5 5 0.5
    6 6 0.6
    7 7 0.7
    8 8 0.8
    9 9 0.9
    10 10 1.0

I should mention, that a few features are lacking here which could be
added easily. Namely the iteration thru this style ends up with
instances of the parent class symbol and graph keys are poorly
supported (they will end up in regular symbols from the parent class).
Additionally I should add, that I consider the interfaces between
these components of the graph to be not at all stabilized. The are
not even documented yet. Hopefully things will get better in the
future ...


André

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

[Pyx-user] colored symbols

[Gert I. <Ger...@Ph...>]

Hi,

I want to draw colored symbols in a graph where the color of each symbol
is determined via the datafile, i.e. I have a datafile consisting of three
columns where the first column determines the x-value, the second column the
y-value and the third value (between 0 and 1) the color. I tried to use
a color palette but somehow I did not succeed. Is there a simple way to
accomplish this task?

Best regards,
Gert

-- 
 Gert-Ludwig Ingold               |                                  
 Institut fuer Physik             | email: In...@Ph...
 Universitaet Augsburg            | Phone: +49-821-598-3234
 D-86135 Augsburg                 | Fax  : +49-821-598-3222
 Germany                          |                                  

WWW homepage: http://www.physik.uni-augsburg.de/theo1/ingold

Re: [Pyx-user] changing defaults

[Andre W. <and...@ph...>]

Hi Gert,

On Sat, Apr 26, 2003 at 02:33:21PM +0200, Gert Ingold wrote:
> the other day, we had a private email discussion about changing defaults. 

I have to tell you, that the problem you've found has nothing to do
with the discussion we had lately. You've just found a bug in text.py
(which is fine). The fix is to insert the return statement marked with
(***) in the following lines taken from text.py:

  ...
    class _valignbaseline(valign):

        __implements__ = _Itexsetting

        def modifyexpr(self, expr, texsettings, texrunner):
            for texsetting in texsettings:
                if isinstance(texsetting, parbox):
                    raise RuntimeError("valign.baseline: specify top/middle/bottom baseline for parbox")
            return expr # (***)


    class _valignxxxbaseline(valign):
    ...

> This example works fine. However commenting out the first line defining
> the text attributes and uncommenting the second one yields the string
> "None" instead of "egg" although text.valign.baseline is the default.
> One would therefore expect that nothing changes...
> If you have some spare time, you might explain the philosophy behind this
> behavior.

The point is that those attribute defaults are kind of "build-in"
defaults. It is just like writing text without specifying a font size.
You'll end up with a default size. But when you explicitly specify a
font size, this font size setting will be inserted explicitly. When
this code is broken you'll get an error (in your case it was just a
wrong output) even though you just specified the default! You're
right, this shouldn't happen, but PyX is alpha software ...


André

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

[Pyx-user] changing defaults

[Gert I. <Ger...@Ph...>]

Hi André,

the other day, we had a private email discussion about changing defaults. 
After the discussion, you mentioned that it might have been better to 
discuss this on the list so that other people could profit from it. I just 
came across another example which I find quite counterintuitive and which 
you might use to explain to the general public (and to me) the reason why
PyX behaves the way it does. Here comes the minimal example:

--------------------------------------------
from pyx import *

textattr = text.halign.center, text.size.large
# textattr = text.halign.center, text.valign.baseline, text.size.large

c = canvas.canvas()
c.stroke(path.line(0,0,2,0))
c.text(1,0, "egg", *textattr)
c.writetofile("example")
--------------------------------------------

This example works fine. However commenting out the first line defining
the text attributes and uncommenting the second one yields the string
"None" instead of "egg" although text.valign.baseline is the default.
One would therefore expect that nothing changes...
If you have some spare time, you might explain the philosophy behind this
behavior.

Best regards,
Gert

-- 
 Gert-Ludwig Ingold               |                                  
 Institut fuer Physik             | email: In...@Ph...
 Universitaet Augsburg            | Phone: +49-821-598-3234
 D-86135 Augsburg                 | Fax  : +49-821-598-3222
 Germany                          |                                  

WWW homepage: http://www.physik.uni-augsburg.de/theo1/ingold

Re: [Pyx-user] Bugreport in path's at() routine and (maybe) in reversed()

[Joerg L. <jo...@us...>]

Hi Michael, *,

On 25.04.03, Michael Schindler wrote:
> This is exactly what many many poor producers of scientific plots
> dreamed of !!!

Boys, enough is enough, PyX is not bad but not a panacea either.

> Nevertheless I have a little problem with the parameter calculations
> that are done in path.at().

Ok, I we (both) fixed the two bugs that lead to this problems.

Thanks,

        Jörg

-- 
JOERG LEHMANN  | PyX - High quality PostScript figures with Python & TeX
jo...@lu...  | Visit http://pyx.sourceforge.net/

[Pyx-user] Bugreport in path's at() routine and (maybe) in reversed()

[Michael S. <mic...@ph...>]

  Dear André and Jörg,

first of all I really have to stress (once more) that with PyX you have
created a really _great_ program. Again and again it is astonishing,
how powerful it is and what difficult problems it can solve.

This is exactly what many many poor producers of scientific plots
dreamed of !!!

Nevertheless I have a little problem with the parameter calculations
that are done in path.at().
The documentation in the path.py module claims that I can use negative
values in at(). But when comparing at(0.5) and at(-0.5) on a single
path element, the outcome is not the same. The latter does not even
lie on the path. 
This can be easily repaired in path.py by setting the negative value
to a positive ...)

But there is a bigger problem when several subpaths are used. Then the
path is reverted by path.reversed() when using negative values in
path.at().
In the example below I use two straight lines as subpaths. The
parameter range is then from 0 to 2. When asking for path.at(0.5) and
path.at(-0.5) I expect the points on different lines, but both lie on
the first (long) one.
So at(0.5) and at(-0.5) are the same, as well as
   at(1.5) and at(-1.5).


Best greetings from Augsburg ;-)
  Michael Schindler.




################ example code ##########
import pyx
from pyx import *
from pyx.path import *

c = canvas.canvas()

# one long and one short line, _not_ connected
p = path(moveto(0,0), lineto(10,10), moveto(10,0), lineto(15,5))

# learn what is done during reversion
for pel in p:
    print pel
print
for pel in p.reversed():
    print pel

c.stroke(p)

# the first circle is where it is expected
c.stroke(circle(p.at(0.5)[0], p.at(0.5)[1], 0.2), color.rgb.red)

# the second should be in the middle of the short line
# but see where it is!
c.stroke(circle(p.at(-0.5)[0], p.at(-0.5)[1], 0.2), color.rgb.blue)

# after setting t to -t in path.py
# this should be in the middle of the short line
# but is this what we expect for t=-1.5?
c.stroke(circle(p.at(-1.5)[0], p.at(-1.5)[1], 0.2), color.rgb.green)

c.writetofile("pyxbug", paperformat="a4", fittosize=1)
############## END ##########

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [Pyx-user] i'd like to plot xy graphs with contour lines and labels...

[Andre W. <and...@ph...>]

Hi Loic,

On 23.04.03, Loic Chevallier wrote:
> First of all BRAVO and thanks for this great PyX module: this is exactly
> what i need for my publishing work as a scientist (astrophysics),
> disappointed by libraries like gnuplot, pgplot, plplot, and even dislin
> which are too much limited in fine-tuning graphs.

Thanks for the credit. I should mention that we (Jörg and I) are
physicits as well. We were disappointed about the all those other
solutions for creating graphs for a long time until we finally started
this PyX project already quite some time ago. While we have evaluated
quite some available software before this decision, we hopefully do a
good job in combining good features into a new, handy, but at the same
time extremely powerfull package. All this is still very much work in
progess.

> Your graph.graphxy() class is sufficient for my needs, but i frequently
> uses some contour graphs with labels, and i would really appreciate this
> functionality to be included in the next versions of PyX.

Basically there are two possibilities to reach that gool. You could
try to build just a plot style for the existing two dimensional
graphxy. (I'm aware of the fact, that building such a style is very
difficult for an outsider right now, because the graph system is not
yet polished and well documented. I hopefully will do a better job in
the future.) But I myself think, that contour plots should be
implemented more in the way it is done in gnuplot. Although a contour
plot is planar, the data it represents are 3 dimensional data. I
already started some work on a 3-dimensional graph some time ago (the
plot at the web page is one of its results), but I had to postpone
this work until other parts of the graph module become more stable
(axis, painters, etc.). The difficulty is, that changes in the
structure have to be propagated thru all the available graph types.
Thats why I postponed the creation of other graph styles right now.

I expect, that once we are at this point, where we do have a 3
dimensional graph as well (graphxyz?), we should immediately have
contour and surface plots available. But I do not expect this to
happen in the next few months. The reason is, that Jörg and I have
quite some stress in writing our PhD theses right now (finishing our
theses are scheduled for this summer). Up to that point the PyX
development is considerably reduced, but we will continue with the
project after that for sure.

There is another point I want to mention in terms of writing labels at
contour plots. Thats not an easy task. I thought about having this
possibility of attaching labels and other stuff to paths available
independend of the special purpose of contour plots. While there is
another guy (Michael Schindler) starting to attent to the PyX
development and already working in the direction of those
"decorators", I feel encouraged in forcing him to try to do those
decorators in a quite generic way. Adding labels to contour plots will
then become as easy as adding an arrow to a path!

> Of course, starting from your .py files i could try to program this by
> myself (and i will certainly try), but i'm a beginner with python and
> object-oriented programmation, so my progress will be really slow. 

If you really need that feature right now, you may just program that
independend of the exisiting graph stuff. You may use axes (see the
axis test under test/functional/test_axis.py) and do everything else
by yourself for example. I guess, thats the easiest solution, where
you can rely on PyX parts which are already stable and documented.

On the other hand it might be a good starting point to resume the 3d
graph development (what I will certainly do at some later point; may
be around this fall; there are other people asking me about 3d plots
as well). Of course, if you have the time and you want to join the
development, you could try yourself before. I would encourage you to
stay in close contact with me, if you really want to go into that.


André

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

[Pyx-user] i'd like to plot xy graphs with contour lines and labels...

[Loic C. <loi...@ob...>]

Dear Jörg Lehmann and André Wobst,

First of all BRAVO and thanks for this great PyX module: this is exactly
what i need for my publishing work as a scientist (astrophysics),
disappointed by libraries like gnuplot, pgplot, plplot, and even dislin
which are too much limited in fine-tuning graphs.
 
Your graph.graphxy() class is sufficient for my needs, but i frequently
uses some contour graphs with labels, and i would really appreciate this
functionality to be included in the next versions of PyX.
Of course, starting from your .py files i could try to program this by
myself (and i will certainly try), but i'm a beginner with python and
object-oriented programmation, so my progress will be really slow. 

Greetings,

Loïc Chevallier,
CRAL Observatoire de Lyon,
PhD in Astrophysics,
Post-Doctoral position at CRAL,
http://www.obs-univ-lyon1.fr/transfer

Re: [Pyx-user] connecting symbols with lines

[Andre W. <and...@ph...>]

Hi Ralf,

On 15.04.03, Ralf Utermann wrote:
> What I found out from examples and docs is that I have to
> add a lineattrs argument like:
>
> g.plot( graph.data("bd.dat", x=0, y=3, title = "Sys" ),
>         graph.symbol(lineattrs=canvas.linestyle.dashed) )
>
> to the 3 g.plot() calls. The problem is, that the symbols don't
> iterate anymore. I ended up setting this explicitely on every
> call:
>
> g.plot(graph.data("bd.dat", x=0, y=3, title = "X" ),
>        graph.symbol( symbol=graph.changesymbol.circle(),lineattrs=canvas.linestyle.dashed))
> g.plot(graph.data("bd.dat", x=0, y=4, title = "Y" ),
>        graph.symbol( symbol=graph.changesymbol.square(),lineattrs=canvas.linestyle.dashed))
> g.plot(graph.data("bd.dat", x=0, y=5, title = "Z" ),
>        graph.symbol(symbol=graph.changesymbol.triangle(),lineattrs=canvas.linestyle.dashed))
>
> I assume, there is a more elegant way to do this; any ideas?

Yes, of course. The idea of iterateable style attributes is, that you
use them for plotting several data sets. The easiest way to do that is
to apply the iterable style to a list of data instances. The example
above would become:

    g.plot([graph.data("bd.dat", x=0, y=3, title="X"),
            graph.data("bd.dat", x=0, y=4, title="Y"),
            graph.data("bd.dat", x=0, y=5, title="Z")],
           graph.symbol(symbol=graph.changesymbol.circle(), lineattrs=canvas.linestyle.dashed))

Now the style gets iterated over the list of data you've plugged in.
However, if you do not specify any style at all, the defaultstyle of
the provided data is used within the subsequent plot calls. Thus, the
iteration process is performed as well.

You may now think of another solution:

    s = graph.symbol(symbol=graph.changesymbol.circle(), lineattrs=canvas.linestyle.dashed))
    g.plot(graph.data("bd.dat", x=0, y=3, title = "X" ), s)
    g.plot(graph.data("bd.dat", x=0, y=4, title = "Y" ), s)
    g.plot(graph.data("bd.dat", x=0, y=5, title = "Z" ), s)

Well, I've noticed right now, that this doesn't work like expected
(which I immediately added to my TODO list). When doing this, you have
to pass the result of s.iterate() in subsequent plot calls (except for
the first) right now. For future version I'll change that, because it
doesn't fit to my understanding of how this iteration process should
be kicked off. However, the iteration behaviour of the defaultstyle
should be understood that way, that there is a magic behind the scene
which iterates the style when it is applied several times.

> And, BTW, it was not so easy to see that symbols are handled via
> graph and lines via canvas. For me, the symbols and lines which
> make the plot are objects on the same level -- I would always
> assume them to be handled by the same class, which apparently PyX
> does not do.  Could someone elaborate on this?

There is a simple reason for that. The symbol itself is a method (or
some iteration wrapper around a method). Those symbol methods just
return a path and are defined as graph.symbol.cross() and so on. You
can plug the in directly. In your example above where you didn't use
the iteration at all you could have used graph.symbol.cross() etc. The
iterators around those methods are named graph.changesymbol.circle()
etc. (Note: You have to instantiate those iterators manually to always
get a new instance of the iterators). This hole business is very
different from stroke/fill attributes. lineattrs (and symbolattrs as
well) is a list of instances of classes derived from PathStyle. They
are right now defined in the canvas module.

I agree, that the difference between symbol and lineattrs might be
obscure to the user. Also the question when an instantiation of some
attribute is needed or not (is this attribute a class or already an
instance) might be very confusing (on the other hand for iterators an
explicit instantiation is difficult to overcome). I'm not quite sure
how to improve this situation.


André



PS: I'm sorry about my late responses all the time due to some MTA
problems.

-- 
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/          visit http://pyx.sourceforge.net/

[Pyx-user] connecting symbols with lines

[Ralf U. <Ral...@Ph...>]

Hi PyXperts,

my first PyX graph should plot 3 datasets with different symbols,
connected with lines (of the same style).

What I found out from examples and docs is that I have to 
add a lineattrs argument like:

g.plot( graph.data("bd.dat", x=0, y=3, title = "Sys" ),
        graph.symbol(lineattrs=canvas.linestyle.dashed) )

to the 3 g.plot() calls. The problem is, that the symbols don't
iterate anymore. I ended up setting this explicitely on every
call:

g.plot(graph.data("bd.dat", x=0, y=3, title = "X" ),
       graph.symbol( symbol=graph.changesymbol.circle(),lineattrs=canvas.linestyle.dashed))
g.plot(graph.data("bd.dat", x=0, y=4, title = "Y" ),
       graph.symbol( symbol=graph.changesymbol.square(),lineattrs=canvas.linestyle.dashed))
g.plot(graph.data("bd.dat", x=0, y=5, title = "Z" ),
       graph.symbol(symbol=graph.changesymbol.triangle(),lineattrs=canvas.linestyle.dashed))

I assume, there is a more elegant way to do this; any ideas?

And, BTW, it was not so easy to see that symbols are handled via
graph and lines via canvas. For me, the symbols and lines which
make the plot are objects on the same level -- I would always
assume them to be handled by the same class, which apparently PyX
does not do.  Could someone elaborate on this?


Thanks for this nice package,

Ralf

-- 
        Ralf Utermann
_____________________________________________________________________
        Universität Augsburg, Institut für Physik   --   EDV-Betreuer
        Universitätsstr.1             
        D-86135 Augsburg                     Phone:  +49-821-598-3231
        SMTP: Ral...@Ph...         Fax: -3411

Re: [Pyx-user] RE: Problems building PyX 3.0.1 under Windows with VC++ 6.0

[Joerg L. <jo...@us...>]

Hi,

On 11.04.03, Bent Andre Solheim wrote:
> Of course you are right. I tried downloading and using the python
> distribution that comes with CygWin for the build, and it compiles
> smoothly. The reason; the compiler used is not cl.exe (Visual C++
> 6.0),
> but gcc. The environment used is identified by distutils as CygWin, so
> another compiler is used.

Fine.

> One problem still remains, though. It is my opionion that it should be
> possible to build using Visual C++ aswell, so the users of PyX on
> Windows do not have to use CygWin. It's a great library, and I know of
> several LaTeX users on Windows that would enjoy it. However the
> overhead
> of installing and using CygWin-Python would not be considered "worth
> the
> effort" for most of them (qualified quess).

You're right, that's not the optimal solution.

> MikTex does not come with kpathsea-header and library files in a
> standard installation (to my knowledge); only when downloading the
> source from cvs, and then you have to build the library. Would it be
> possible to supply, for VC++ users and python users using the
> Python.org
> distribution, the kpathsea library, as part of the PyX distribution?
> My
> compilation and build experience is limited, so I didn't manage to
> build
> the MikTex libraries propperly within a reasonable amount of time (I
> gave up).

I think that's not that easy. You really need kpathsea libraries that
"know" of your MikTeX distribution - in the sense that they know where
they find the suitable ls-R file. The location of this file of course
depends on your local MikTeX configuration/installation.

> The kpsewhich command works correctly, but it doesn't impact the VC++
> build process.

I was only trying to say that you can also work with PyX without the
_pykpathsea extension module. There is a fallback to kpsewhich which,
while not being as efficient as the other solution, gives you the full
functionality.

        Jörg