pyx-devel — PyX development

[PyX-devel] [ pyx-Bugs-986123 ] Axis labels look weird

[SourceForge.net <no...@so...>]

Bugs item #986123, was opened at 2004-07-06 20:01
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Axis labels look weird

Initial Comment:
When I create an XY graph and specify an axis label that is more than one word long, sometimes the 
two words overlap. Here is ahat I have found so far:
(Axis label specified: What it looks like)

"X values" - Looks normal
"Y values" - Looks normal
"solution variable" - Two words overlap
"variable" - Looks normal
"variableABCDEFGHIJ" - Looks normal
"variable ABCDEFGHIJ" - Looks like: variabl***CDEF GHIJ (where the *** indicates where the "e" and 
"AB" overlap)
"solution-variable" - Looks normal
"solution_variable" - Gives the following error:
Traceback (most recent call last):
   ...
    mycanvas.writeEPSfile(filename)
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 367, in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 129, in bbox
    abbox = cmd.bbox()
  File "/users/mont/PyX-0.6.3/pyx/deco.py", line 71, in bbox
    pbbox = self.path.bbox()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 418, in bbox
    self.finish()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 368, in finish
    self.domethods[0]()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 310, in dolayout
    axis.finish(self.axespos[key])
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/axis.py", line 344, in finish
    ac = self.painter.paint(axispos, self)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 486, in paint
    _title.paint(self, axispos, axis, ac=ac)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 305, in paint
    title = self.texrunner.text_pt(x, y, axis.title, titleattrs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1133, in text_pt
    return self.text(unit.t_pt(x), unit.t_pt(y), expr, *args, **kwargs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1115, in text
    self.execute(expr, self.defaulttexmessagesdefaultrun + self.texmessagesdefaultrun + texmessages)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 944, 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:
  \ProcessPyXBox{\gdef\PyXHAlign{0.50000}\setbox0\hbox{$\vcenter{\vrule 
width0pt}$}\lower\ht0\hbox{{solution_variable}}%
  }{53}%
  \PyXInput{57}%
After parsing the return message from TeX, the following was left:
  *! Missing $ inserted.<inserted text>                 $<to be read again>                    _<argument> 
...h0pt}$}\lower \ht 0\hbox {{solution_
                   variable}}\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                                       
         }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %!
Extra }, or forgotten $.<argument> ...ower \ht 0\hbox {{solution_variable}                                               
   }\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1
                                            }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.<argument> ...wer \ht 0\hbox {{solution_variable}}
                                           \ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                            
                    }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}                                                 
}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}
       %! Extra }, or forgotten $.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}}                           
                       \PyXDimenHAlignLT =\PyXHAl...<*> }{53}
    %

My e-mail address is ale...@ni...


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-07-07 08:18

Message:
Logged In: YES 
user_id=405853

I expect this problem to be related to the text output itself. Could you try 
to run hello.py, which can be found at the example directory. You may 
substitute the string "hello, world!" by something you used before 
("variable ABCDEFGHIJ") to reproduce your problem. In case you find the 
same behaviour it would be a much better suitable (e.g. minimal) 
example to further investigate your problem.

----------------------------------------------------------------------

Comment By: Gert Ingold (gertingold)
Date: 2004-07-07 07:36

Message:
Logged In: YES 
user_id=809523

I cannot reproduce the problem with "variable ABCDEFGHIJ" under
PyX 0.6.3. Do you have a minimal example?

The problem with "solution_variable" is not a PyX bug but
related
to TeX which expects the underscore in math mode where it would
indicate a subscript (see also FAQ 4.3.3). To avoid this
problem,
the underscore has to be escaped with a backslash, i.e. you
should
use "solution\_variable". See also FAQ 2.4 concerning the use
of raw strings in Python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

[PyX-devel] [ pyx-Bugs-986123 ] Axis labels look weird

[SourceForge.net <no...@so...>]

Bugs item #986123, was opened at 2004-07-06 18:01
Message generated for change (Comment added) made by gertingold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Axis labels look weird

Initial Comment:
When I create an XY graph and specify an axis label that is more than one word long, sometimes the 
two words overlap. Here is ahat I have found so far:
(Axis label specified: What it looks like)

"X values" - Looks normal
"Y values" - Looks normal
"solution variable" - Two words overlap
"variable" - Looks normal
"variableABCDEFGHIJ" - Looks normal
"variable ABCDEFGHIJ" - Looks like: variabl***CDEF GHIJ (where the *** indicates where the "e" and 
"AB" overlap)
"solution-variable" - Looks normal
"solution_variable" - Gives the following error:
Traceback (most recent call last):
   ...
    mycanvas.writeEPSfile(filename)
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 367, in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 129, in bbox
    abbox = cmd.bbox()
  File "/users/mont/PyX-0.6.3/pyx/deco.py", line 71, in bbox
    pbbox = self.path.bbox()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 418, in bbox
    self.finish()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 368, in finish
    self.domethods[0]()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 310, in dolayout
    axis.finish(self.axespos[key])
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/axis.py", line 344, in finish
    ac = self.painter.paint(axispos, self)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 486, in paint
    _title.paint(self, axispos, axis, ac=ac)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 305, in paint
    title = self.texrunner.text_pt(x, y, axis.title, titleattrs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1133, in text_pt
    return self.text(unit.t_pt(x), unit.t_pt(y), expr, *args, **kwargs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1115, in text
    self.execute(expr, self.defaulttexmessagesdefaultrun + self.texmessagesdefaultrun + texmessages)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 944, 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:
  \ProcessPyXBox{\gdef\PyXHAlign{0.50000}\setbox0\hbox{$\vcenter{\vrule 
width0pt}$}\lower\ht0\hbox{{solution_variable}}%
  }{53}%
  \PyXInput{57}%
After parsing the return message from TeX, the following was left:
  *! Missing $ inserted.<inserted text>                 $<to be read again>                    _<argument> 
...h0pt}$}\lower \ht 0\hbox {{solution_
                   variable}}\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                                       
         }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %!
Extra }, or forgotten $.<argument> ...ower \ht 0\hbox {{solution_variable}                                               
   }\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1
                                            }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.<argument> ...wer \ht 0\hbox {{solution_variable}}
                                           \ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                            
                    }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}                                                 
}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}
       %! Extra }, or forgotten $.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}}                           
                       \PyXDimenHAlignLT =\PyXHAl...<*> }{53}
    %

My e-mail address is ale...@ni...


----------------------------------------------------------------------

Comment By: Gert Ingold (gertingold)
Date: 2004-07-07 05:36

Message:
Logged In: YES 
user_id=809523

I cannot reproduce the problem with "variable ABCDEFGHIJ" under
PyX 0.6.3. Do you have a minimal example?

The problem with "solution_variable" is not a PyX bug but
related
to TeX which expects the underscore in math mode where it would
indicate a subscript (see also FAQ 4.3.3). To avoid this
problem,
the underscore has to be escaped with a backslash, i.e. you
should
use "solution\_variable". See also FAQ 2.4 concerning the use
of raw strings in Python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

[PyX-devel] [ pyx-Bugs-986123 ] Axis labels look weird

[SourceForge.net <no...@so...>]

Bugs item #986123, was opened at 2004-07-06 11:01
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=986123&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Axis labels look weird

Initial Comment:
When I create an XY graph and specify an axis label that is more than one word long, sometimes the 
two words overlap. Here is ahat I have found so far:
(Axis label specified: What it looks like)

"X values" - Looks normal
"Y values" - Looks normal
"solution variable" - Two words overlap
"variable" - Looks normal
"variableABCDEFGHIJ" - Looks normal
"variable ABCDEFGHIJ" - Looks like: variabl***CDEF GHIJ (where the *** indicates where the "e" and 
"AB" overlap)
"solution-variable" - Looks normal
"solution_variable" - Gives the following error:
Traceback (most recent call last):
   ...
    mycanvas.writeEPSfile(filename)
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 367, in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 129, in bbox
    abbox = cmd.bbox()
  File "/users/mont/PyX-0.6.3/pyx/deco.py", line 71, in bbox
    pbbox = self.path.bbox()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 418, in bbox
    self.finish()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 368, in finish
    self.domethods[0]()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 310, in dolayout
    axis.finish(self.axespos[key])
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/axis.py", line 344, in finish
    ac = self.painter.paint(axispos, self)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 486, in paint
    _title.paint(self, axispos, axis, ac=ac)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 305, in paint
    title = self.texrunner.text_pt(x, y, axis.title, titleattrs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1133, in text_pt
    return self.text(unit.t_pt(x), unit.t_pt(y), expr, *args, **kwargs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1115, in text
    self.execute(expr, self.defaulttexmessagesdefaultrun + self.texmessagesdefaultrun + texmessages)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 944, 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:
  \ProcessPyXBox{\gdef\PyXHAlign{0.50000}\setbox0\hbox{$\vcenter{\vrule 
width0pt}$}\lower\ht0\hbox{{solution_variable}}%
  }{53}%
  \PyXInput{57}%
After parsing the return message from TeX, the following was left:
  *! Missing $ inserted.<inserted text>                 $<to be read again>                    _<argument> 
...h0pt}$}\lower \ht 0\hbox {{solution_
                   variable}}\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                                       
         }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %!
Extra }, or forgotten $.<argument> ...ower \ht 0\hbox {{solution_variable}                                               
   }\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1
                                            }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.<argument> ...wer \ht 0\hbox {{solution_variable}}
                                           \ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                            
                    }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}                                                 
}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}
       %! Extra }, or forgotten $.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}}                           
                       \PyXDimenHAlignLT =\PyXHAl...<*> }{53}
    %

My e-mail address is ale...@ni...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

[PyX-devel] [ pyx-Bugs-977323 ] rater.py: division by Zero

[SourceForge.net <no...@so...>]

Bugs item #977323, was opened at 2004-06-22 11:25
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=977323&group_id=45430

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marko Vendelin (tmp001)
Assigned to: André Wobst (wobsta)
Summary: rater.py: division by Zero

Initial Comment:
I would like to report a bug (or rather strange feature
:) ) in
pyx/graph/axis/rater.py. If I specify limits of axis
equal to [12.5 to 1050] then pyx crashes somewhere in
rater.py:

------
Example program:

from pyx import *

g = graph.graphxy(height=8, width=8,
                  x=graph.axis.linear(min=12.5,
max=1050, title=r"\large{X}"),
                  y=graph.axis.linear(title=r"\large{Y}") )

g.plot( graph.data.list( [[0, 50], [10, 50]],
addlinenumbers=0, x=0, y=1),
   
graph.style.line(lineattrs=[style.linewidth.thick,style.linecap.round])
)

g.writetofile("test.eps")

-------
Output:

Traceback (most recent call last):
  File "test.py", line 10, in ?
    g.writetofile("test.eps")
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/canvas.py",
line 533,
in writetofile
    self.writeEPSfile(filename, *args, **kwargs)
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/canvas.py",
line 367,
in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
418, in bbox
    self.finish()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
368, in finish
    self.domethods[0]()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
310, in dolayout
    axis.finish(self.axespos[key])
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/axis/axis.py",
line 313, in finish
    newrate = self.rater.rateticks(self, newticks,
self.density)
  File "/home/markov/python/pyx/graph/axis/rater.py",
line 193, in
rateticks
    return rate/weight
ZeroDivisionError: integer division or modulo by zero

cheers,

Marko

----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-06-29 17:37

Message:
Logged In: YES 
user_id=405853

Thanks for reporting this issue and sorry for my late response. The 
problem is, that a partitioner might return an empty list of ticks but was 
not considered in the code. This behaviour of the partitioner is also 
beyond to be changed. Its also interesting to see your example, where 
you step into that problem even for the default parameters of the 
automatic linear partitioner.

To solve the problem at least the axis need to take care of this special 
case. (While the axis must take care of it, the rater might not even be 
asked for such a case.) A patch is enclosed. Note, that you will get an 
error from the partitioner for the y axis in your example, but this is due 
to the y range from 50 to 50. I do not consider this later issue to be a 
bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=977323&group_id=45430

[PyX-devel] [ pyx-Bugs-977323 ] rater.py: division by Zero

[SourceForge.net <no...@so...>]

Bugs item #977323, was opened at 2004-06-22 11:25
Message generated for change (Settings changed) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=977323&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Vendelin (tmp001)
>Assigned to: André Wobst (wobsta)
Summary: rater.py: division by Zero

Initial Comment:
I would like to report a bug (or rather strange feature
:) ) in
pyx/graph/axis/rater.py. If I specify limits of axis
equal to [12.5 to 1050] then pyx crashes somewhere in
rater.py:

------
Example program:

from pyx import *

g = graph.graphxy(height=8, width=8,
                  x=graph.axis.linear(min=12.5,
max=1050, title=r"\large{X}"),
                  y=graph.axis.linear(title=r"\large{Y}") )

g.plot( graph.data.list( [[0, 50], [10, 50]],
addlinenumbers=0, x=0, y=1),
   
graph.style.line(lineattrs=[style.linewidth.thick,style.linecap.round])
)

g.writetofile("test.eps")

-------
Output:

Traceback (most recent call last):
  File "test.py", line 10, in ?
    g.writetofile("test.eps")
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/canvas.py",
line 533,
in writetofile
    self.writeEPSfile(filename, *args, **kwargs)
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/canvas.py",
line 367,
in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
418, in bbox
    self.finish()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
368, in finish
    self.domethods[0]()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
310, in dolayout
    axis.finish(self.axespos[key])
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/axis/axis.py",
line 313, in finish
    newrate = self.rater.rateticks(self, newticks,
self.density)
  File "/home/markov/python/pyx/graph/axis/rater.py",
line 193, in
rateticks
    return rate/weight
ZeroDivisionError: integer division or modulo by zero

cheers,

Marko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=977323&group_id=45430

[PyX-devel] [ pyx-Bugs-977323 ] rater.py: division by Zero

[SourceForge.net <no...@so...>]

Bugs item #977323, was opened at 2004-06-22 12:25
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=977323&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marko Vendelin (tmp001)
Assigned to: Nobody/Anonymous (nobody)
Summary: rater.py: division by Zero

Initial Comment:
I would like to report a bug (or rather strange feature
:) ) in
pyx/graph/axis/rater.py. If I specify limits of axis
equal to [12.5 to 1050] then pyx crashes somewhere in
rater.py:

------
Example program:

from pyx import *

g = graph.graphxy(height=8, width=8,
                  x=graph.axis.linear(min=12.5,
max=1050, title=r"\large{X}"),
                  y=graph.axis.linear(title=r"\large{Y}") )

g.plot( graph.data.list( [[0, 50], [10, 50]],
addlinenumbers=0, x=0, y=1),
   
graph.style.line(lineattrs=[style.linewidth.thick,style.linecap.round])
)

g.writetofile("test.eps")

-------
Output:

Traceback (most recent call last):
  File "test.py", line 10, in ?
    g.writetofile("test.eps")
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/canvas.py",
line 533,
in writetofile
    self.writeEPSfile(filename, *args, **kwargs)
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/canvas.py",
line 367,
in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
418, in bbox
    self.finish()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
368, in finish
    self.domethods[0]()
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/graph.py",
line
310, in dolayout
    axis.finish(self.axespos[key])
  File
"/home/markov/python/graphics/PyX-0.6.3/pyx/graph/axis/axis.py",
line 313, in finish
    newrate = self.rater.rateticks(self, newticks,
self.density)
  File "/home/markov/python/pyx/graph/axis/rater.py",
line 193, in
rateticks
    return rate/weight
ZeroDivisionError: integer division or modulo by zero

cheers,

Marko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=977323&group_id=45430

[PyX-devel] =?ISO-2022-JP?B?GyRCIVZMJD41Qno5LTlwIighV0A6Tk86XiVJGyhC?= =?ISO-2022-JP?B?GyRCJWolcyUvGyhC?=

[<vit...@ya...>]

$BFMA3$N%a!<%k<:Ni$$$?$7$^$9!#(B

$B6H3&=i!*JV6bBg4?7^!*8z2LJ]>ZIU!J#2(B,$B#1#0#01_(B $B@G9~!K<+?.$,M-$k$+$i=PMh$k!*(B
$B!c#1K\$@$19XF~!"0{$s$G$7$^$C$?8e$G$b!"G<F@$$$+$J$1$l$PJV6bCW$7$^$9!#!d(B

$B@-=U2sI|!*CK@-5!G=8~>e@-%I%j%s%/!!!V%S%?!&%^%s!WB(8z!u;}B3!&@:NO(BUp$B7r9/?)IJ$G$9!#0{MQ!"#4#0J,8e$+$i$,!"$*3Z$7$_!*!*(B
$B#1K\;n$;$PG<F@!*=>$C$FEv<R$G$O!"C1IJCmJ84?7^!*$5$i$K!"8z2L$,F@$i$l$J$+$C$?>l9g!"$*5RMM8}:B$XA43[$4JV6bCW$7$^$9!#(B 
$BJ#?tK\9XF~$NJ}$b!"8z2LJ]>Z!J#1K\!K$@$1$G$O$J$/!"3+@r$7$F$$$J$$>&IJ$O!"$9$Y$FGcLa$7CW$7$^$9!#(B
$B=w@-$NJ}$b$40{MQ2DG=!#Nd@-$NJ}$K$*$9$9$a!*(B

$B:#$9$02<5-%[!<%`%Z!<%8$+$i$4CmJ82<$5$$!*(B
http://www.vitamanjapan.com

$BG[?.Dd;_$r$44uK>$NJ}$O!"$*<j?t$G$O$4$6$$$^$9$,!"(B
$B7oL>$r!VG[?.Dd;_!W$H$7$F$$$?$@$-!V(Bvi...@ya...$B!W$^$G(BE-mail$B$K$F$*CN$i$;2<$5$$!#(B

$B!c;v6H<T!d(B
$B3t<02q<R%M%C%H%o!<%k%I%S%8%M%9(B
$B%S%?%^%s;v6HIt(B
$BEl5~ETJ85~6h8~5V(B2-37-6

[PyX-devel] [ pyx-Bugs-966575 ] install problem on mandrake 10

[SourceForge.net <no...@so...>]

Bugs item #966575, was opened at 2004-06-04 16:38
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=966575&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: install problem on mandrake 10

Initial Comment:
unable to install last Pyx release. after running
setup.py -install, I get this error message :
/usr/lib/python23/config/Makefile 
"can not read file or does not exist"


----------------------------------------------------------------------

>Comment By: Jörg Lehmann (joergl)
Date: 2004-06-04 16:44

Message:
Logged In: YES 
user_id=390410

Are you sure you have installed the Python 2.3 development
packages (probably named python-dev or python2.3-dev)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=966575&group_id=45430

[PyX-devel] [ pyx-Bugs-966575 ] install problem on mandrake 10

[SourceForge.net <no...@so...>]

Bugs item #966575, was opened at 2004-06-04 07:38
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=966575&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: install problem on mandrake 10

Initial Comment:
unable to install last Pyx release. after running
setup.py -install, I get this error message :
/usr/lib/python23/config/Makefile 
"can not read file or does not exist"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=966575&group_id=45430

Re: [PyX-devel] RFE: kpathsea for epsfile

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

Hi Michael,

On 27.05.04, Michael J Gruber wrote:
> LaTeX/epsfig biased users may expect PyX's epsfile to find the same 
> files as LaTeX's epsfig. Currently there is no file searching done.
> The attached patch against PyX 0.6.3 adds an option "kpsearch" to 
> epsfile (to its constructor). Default is 0 (standard behaviour). If 
> "kpsearch=1" is specified then the kpathsea library is used to search 
> for the file with format=graphics/figure.

Good idea! Could be very usefull ... I've a usecase myself (using a
logo everywhere by installing it to kpathsea path). Perfect. I've
just applied your patch to the CVS head. (I've moved the kpsearch
option to be the last in the argument list, but don't mind.)

Thanks.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] RFE: kpathsea for epsfile

[Michael J G. <mic...@ph...>]

LaTeX/epsfig biased users may expect PyX's epsfile to find the same 
files as LaTeX's epsfig. Currently there is no file searching done.
The attached patch against PyX 0.6.3 adds an option "kpsearch" to 
epsfile (to its constructor). Default is 0 (standard behaviour). If 
"kpsearch=1" is specified then the kpathsea library is used to search 
for the file with format=graphics/figure.

Cheers,
Michael

PyX rookie

[PyX-devel] [ pyx-Bugs-945621 ] '%%BoundingBox: (atend)' not recognized

[SourceForge.net <no...@so...>]

Bugs item #945621, was opened at 2004-04-30 23:32
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=945621&group_id=45430

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: '%%BoundingBox: (atend)' not recognized

Initial Comment:
I have a postscript file which has the following lines in the header:
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: (atend)
%%Title: GMT v3.4.4 Document from /sw/bin/grdview
%%Creator: GMT
%%For: boyle
%%DocumentNeededResources: font Helvetica
%%CreationDate: Fri Apr 30 13:43:34 2004
%%LanguageLevel: 1
%%DocumentData: Clean7Bit
%%EndComments

at the end of the file, there occurs the lines:

%%Trailer
%%BoundingBox: 122 36 618 666
% Reset translations and scale and call showpage
S -2325 0 T 4.16667 4.16667 scale 0 A
showpage
end

The bounding box is at the end because the file is built sequentially 
and the final bounds are not known until the end.
In any case this is legal postscript, but Pyx cannot find the 
bounding information since epsfile.py quits the search after finding 
the %%EndComments.
I extended the search in epsfile.py until the showpage line and this 
seems to work. A better fix would key off the (atend) syntax to 
extend the search. 

Jim boyle
bo...@ll...


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-05-27 11:44

Message:
Logged In: YES 
user_id=405853

I've just added some DSC parsing to properly handle the
"%%BoundingBox: (atend)". (You have to handle included
EPS-files and binary data correctly.) The fix is already
uploaded to CVS head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=945621&group_id=45430

[PyX-devel] Re: Marketing

[John <Loo...@ey...>]

E-mail is the fastest growing marketing tool.

We offer E-mail Marketing with quality service and the lowest prices.

1. Targeted E-mail Addresses

We can provide targeted e-mail addresses you need, which are compiled 
only on your order. We will customize your customer e-mail addresses.

* We have millions of e-mail addresses in a wide variety of categories.

2. Send out Targeted E-mails for you

We can send your e-mail message to your targeted customers! We will
customize your email addresses and send your message for you.

* We can Bullet Proof your Web Site $ dedicated server.

We also offer Fax Broadcasting Service. For more details, you can
refer to:  Http://www.9206.com

Looking forward to serving you.


Regards!

John Okoh
www.9206.com
Su...@92...

*************************************************************************
To take your address:  Http://213.172.0x1f.16/index.html
*************************************************************************

Re: [PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

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

Hi,

On 11.05.04, Andre Wobst wrote:
> On 08.05.04, Faheem Mitha wrote:
> > apt-get build-dep python2.3-pyx
> > apt-get install devscripts latex2html
> > apt-get source python2.3-pyx
> > debuild binary
> 
> I've tried that and it doesn't work for me either. I've used the
> package from Debian unstable, since its available now.

I'm sorry, I should be more precise here: while the creation of the
debian package works smoothly, I'm not able to run "make html" for the
manual. Just in case you didn't follow the whole thread ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

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

Hi,

On 08.05.04, Faheem Mitha wrote:
> apt-get build-dep python2.3-pyx
> apt-get install devscripts latex2html
> apt-get source python2.3-pyx
> debuild binary

I've tried that and it doesn't work for me either. I've used the
package from Debian unstable, since its available now.

Faheem, could you try whether you step into the same problem. I've
patched latex2html in order to get it working. Just make a local copy
of the perl script latex2html and apply the following patch:

--- /usr/bin/latex2html	2004-04-23 14:57:26.000000000 +0200
+++ latex2html	2004-05-11 14:27:14.000000000 +0200
@@ -4811,7 +4811,10 @@
 		if ($cmd =~ /$sizechange_rx/o) {
 		    $pc_after = &$cmd_sub($pc_after, $open_tags_R);
 		} else {
-		    $pc_after = &$cmd_sub($pc_after, $open_tags_R);
+		    if ("$cmd_sub" ne "do_cmd_textohtmlinfopage")
+		    {
+		      $pc_after = &$cmd_sub($pc_after, $open_tags_R);
+		    }
 		};
 	    } elsif ((defined &$cmd_msub)&&!$NO_SIMPLE_MATH) {
 #print "\nMCMD:$cmd_msub :  ";

You can than run the creation of the html pages by
PATH=.:$PATH make html
in the manual subdirectory (put the patched latex2html into that
directory).

In case this helps for you as well, you may understand better whats
going wrong here. I just don't understand it (my perl knowledge is
quite limited). I would expect that the subroutine
do_cmd_textohtmlinfopage is callable (at least its defined), but this
seems to fail.

I should note that there seems to be at least two additional problems.
First mkhowto fails due to a missing
/usr/lib/python2.3/doc/html/style.css later on. I havn't yet
investigated it further -- it might be an error in the python package,
but I'm not sure at all. And finally the png creation seems to be
disabled somehow (note that the png we're creating in the Makefile are
for usage in pdf only). I didn't look into that issue either.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

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

On 11.05.04, Joerg Lehmann wrote:
> On 10.05.04, Graham Wilson wrote:
> > Another idea would be to just distribute the PDF files on the web, and
> > users can get them from there, or compile them from source using the
> > tarball. Your call, Andre.
> 
> +1

It would be ok for me, but we should keep in mind, that we can't
download a pdf-manual for an outdated version anymore. On the other
hand, somebody who sticks to an old version for some reason will have
the possibility to build the old version of the manual etc. himself.
(I'm using outdated version quite often myself since I don't port all
my stuff to all new versions -- it would just be a waste of time.)

To summarize this discussion: For future releases we distribute only
the sources (including the ability to build all documentation) and
place the current compiled documentation (pdf and html) on the web.
Please complain now when you would like to see something else to
happen.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

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

On 10.05.04, Graham Wilson wrote:
> Another idea would be to just distribute the PDF files on the web, and
> users can get them from there, or compile them from source using the
> tarball. Your call, Andre.

+1

        Joerg

[PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Graham W. <bo...@de...>]

On Mon, May 10, 2004 at 12:59:56PM -0400, Faheem Mitha wrote:
> On Mon, 10 May 2004, Andre Wobst wrote:
> > I suggest to skip the pdfs in the source distribution. This seems to
> > be the only meaningful solution. We should prepare and distribute a
> > separate documentation file containing *only* the precompiled pdf
> > files.
> 
> Yes, I think this would be a good solution.

Another idea would be to just distribute the PDF files on the web, and
users can get them from there, or compile them from source using the
tarball. Your call, Andre.

> > Ok, I've modified MANIFEST.in accordingly.
> 
> Sorry, I'm not clear what you have changed.

The MANIFEST.in file is what setup.py uses to determine which files
should be in the source tarball.

> Debian's preferred form of documention is html. So I think this is at
> least of some interest wrt the Debian package. I certainly don't think
> this is something the PyX project should be concerned about, but any
> assistance is appreciated.

Agreed.

-- 
gram

Re: [PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Faheem M. <fa...@em...>]

On Mon, 10 May 2004, Andre Wobst wrote:

> Hi,
>
> On 08.05.04, Faheem Mitha wrote:
> > > environment properly (Python, TeX, etc.). However, when building a
> > > source package for a distribution, those pdf files are not *source*
> > > files and should not be part of a source package.
> >
> > Yes, I see. It would optimal if you could ship a separate source-only
> > tar.gz not containing any pdfs. This would save on space on mirrors
> > and could be used by people who only want the source. Currently around
> > half the source by size consists of the pdfs.
>
> I'm not aware of a support to build different kind of source packages
> within Pythons distutils.
>
> > Debian's policy is to ship a copy of the pristine upstream sources (as
> > *.orig.tar.gz) along with a diff. Pristine in the sense that the
> > md5sums of the source shipped should match that of the source from
> > upstream. So the above is not an option.
>
> I suggest to skip the pdfs in the source distribution. This seems to
> be the only meaningful solution. We should prepare and distribute a
> separate documentation file containing *only* the precompiled pdf
> files.

Yes, I think this would be a good solution.

> > > > Also, there appears to be no way to generate examples/examples.pdf from
> > > > source. Is that correct?
> >
> > I think it would be useful to make it possible to build it. For
> > example, the pdf could be built with different options...
>
> Ok, I've modified MANIFEST.in accordingly.

Sorry, I'm not clear what you have changed.

> > I put the PyX packages I produced online. They are the latest version:
> > 0.6.3. Add the following to your sources.list, and you can get them.
> >  You can also get the sources by using deb-src.
> >
> > deb http://www.stat.unc.edu/students/faheem/debian/ ./
> > deb-src http://www.stat.unc.edu/students/faheem/debian/ ./
> >
> > If you download the sources and rename debian/rules.broken to
> > debian/rules, and then try to rebuild the debs on a Debian
> > testing/unstable machine, you should be able to reproduce the problem I
> > was seeing.
>
> I'll try this out tonight (I don't have my debian unstable box here)
> and see, whether I'm able to reproduce/solve/whatever the problem.

Ok. Thanks.

> BTW the whole discussion about latex2html is certainly interesting. On
> the other hand we're not forcing latex2html ourselfs. Its just the way
> the python documentation utilities currently work. It allows us to put
> a html-version of the documentation online -- which is nice. For local
> usage the pdf documents might be ok skipping the issue of latex2html
> completely. As far as I am concerned its a minor point whether you are
> able to provide a python-pyx-doc-html or not.

Debian's preferred form of documention is html. So I think this is at
least of some interest wrt the Debian package. I certainly don't think
this is something the PyX project should be concerned about, but any
assistance is appreciated.

Thanks for the reply.
                                                           Faheem.

Re: [PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

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

Hi,

On 08.05.04, Faheem Mitha wrote:
> > environment properly (Python, TeX, etc.). However, when building a
> > source package for a distribution, those pdf files are not *source*
> > files and should not be part of a source package.
> 
> Yes, I see. It would optimal if you could ship a separate source-only
> tar.gz not containing any pdfs. This would save on space on mirrors
> and could be used by people who only want the source. Currently around
> half the source by size consists of the pdfs.

I'm not aware of a support to build different kind of source packages
within Pythons distutils.

> Debian's policy is to ship a copy of the pristine upstream sources (as
> *.orig.tar.gz) along with a diff. Pristine in the sense that the
> md5sums of the source shipped should match that of the source from
> upstream. So the above is not an option.

I suggest to skip the pdfs in the source distribution. This seems to
be the only meaningful solution. We should prepare and distribute a
separate documentation file containing *only* the precompiled pdf
files.

> > > Also, there appears to be no way to generate examples/examples.pdf from
> > > source. Is that correct?
> 
> I think it would be useful to make it possible to build it. For
> example, the pdf could be built with different options...

Ok, I've modified MANIFEST.in accordingly.

> I put the PyX packages I produced online. They are the latest version:
> 0.6.3. Add the following to your sources.list, and you can get them.
>  You can also get the sources by using deb-src.
> 
> deb http://www.stat.unc.edu/students/faheem/debian/ ./
> deb-src http://www.stat.unc.edu/students/faheem/debian/ ./
> 
> If you download the sources and rename debian/rules.broken to
> debian/rules, and then try to rebuild the debs on a Debian
> testing/unstable machine, you should be able to reproduce the problem I
> was seeing.

I'll try this out tonight (I don't have my debian unstable box here)
and see, whether I'm able to reproduce/solve/whatever the problem.

BTW the whole discussion about latex2html is certainly interesting. On
the other hand we're not forcing latex2html ourselfs. Its just the way
the python documentation utilities currently work. It allows us to put
a html-version of the documentation online -- which is nice. For local
usage the pdf documents might be ok skipping the issue of latex2html
completely. As far as I am concerned its a minor point whether you are
able to provide a python-pyx-doc-html or not.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Faheem M. <fa...@em...>]

On Sun, 9 May 2004, Graham Wilson wrote:

> On Sun, May 09, 2004 at 05:29:57PM -0400, Faheem Mitha wrote:
> > One possibility is that you could separate the doc package into
> > python-pyx-html-doc and python-pyx-pdf-doc, and then put
> > python-pyx-html-doc in contrib.
>
> My preference would be to look more into the latex2html situation to see
> how long until it might be resolved, and also to see if there are any
> other alternatives to latex2html that can be used.

tex4ht (the command htlatex for latex sources) works well in general (I
used it extensively a few years ago), but I don't know if the python tools
would cooperate with it.

                                                                Faheem.

[PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Graham W. <bo...@de...>]

On Sun, May 09, 2004 at 05:29:57PM -0400, Faheem Mitha wrote:
> One possibility is that you could separate the doc package into
> python-pyx-html-doc and python-pyx-pdf-doc, and then put
> python-pyx-html-doc in contrib.

My preference would be to look more into the latex2html situation to see
how long until it might be resolved, and also to see if there are any
other alternatives to latex2html that can be used.

> I don't think you would need to put it in non-free since it seems to
> me to satisfy the requirements of
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib.

Yes, that is a good point.

> I wonder how the main python html docs are done. They seem to be in main.
> It looks like it is generated using latex2html.

Yes, it is probably a good thinkg to look into.

> Have you been able to build the html manual? I have tried and failed.

I tried a while back and didn't have any luck. I'll try again shortly.

-- 
gram

[PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Faheem M. <fa...@em...>]

On Sat, 8 May 2004, Graham Wilson wrote:

> > The official Debian maintainer of PyX just uploaded packages, but he
> > doesn't build html files either.
>
> This is because latex2html is non-free, which means I would have to put
> the PyX documentation package in non-free.

I see. I was misled by the fact that latex2html was in main in woody. I
see that latex2html was moved into non-free relatively recently.

One possibility is that you could separate the doc package into
python-pyx-html-doc and python-pyx-pdf-doc, and then put
python-pyx-html-doc in contrib. I don't think you would need to put it in
non-free since it seems to me to satisfy the requirements of
http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib.

I wonder how the main python html docs are done. They seem to be in main.
It looks like it is generated using latex2html.

Have you been able to build the html manual? I have tried and failed.

                                                               Faheem.

[PyX-devel] Re: minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Graham W. <bo...@de...>]

On Sat, May 08, 2004 at 10:51:43PM -0400, Faheem Mitha wrote:
> I think it would be useful to make it possible to build it. For
> example, the pdf could be built with different options...

Yes, I agree that this is good idea, especially if a source-only tarball
were to be created.

> The official Debian maintainer of PyX just uploaded packages, but he
> doesn't build html files either.

This is because latex2html is non-free, which means I would have to put
the PyX documentation package in non-free.

--=20
gram

Re: [PyX-devel] minor comments about 0.6.3 tarball, Debian package for PyX 0.6.3

[Faheem M. <fa...@em...>]

On Mon, 3 May 2004, Andre Wobst wrote:

> Hi,
>
> On 01.05.04, Faheem Mitha wrote:
> > svn-buildpackage got upset becasuse the upstream tarball contains
> > manual/manual.pdf, but this gets cleaned by `make clean' and gets built=
 by
> > make, so it looks like it should not be there in the upstream tarball. =
The
> > same comments apply to faq/pyfaq.pdf.
>
> I think there is difference between creating a source package (for
> debian or similar) and our distribution of PyX. We include a
> precompiled version of the manual and faq to make it easier for the
> user to become familiar with PyX. You are right, you can create both
> documents from the source, which is also included in the distribution.
> But in order to build the pdf files you already have to setup your
> environment properly (Python, TeX, etc.). However, when building a
> source package for a distribution, those pdf files are not *source*
> files and should not be part of a source package.

Yes, I see. It would optimal if you could ship a separate source-only
tar.gz not containing any pdfs. This would save on space on mirrors
and could be used by people who only want the source. Currently around
half the source by size consists of the pdfs.

> > I've considering removing these from the upstream tarball and rebuildin=
g
> > it, but I thought I would ask here first, since the tarball is supposed=
 to
> > correspond to pristine sources. Perhaps the *.pdf files were provided f=
or
> > people who don't want to build their own docs? It was not there in the
> > 0.4.1 version in the official Debian package (I have not checked the
> > others). It does make the tarball rather big.
>
> Feel free do create the package the way it suits best to the policy of
> the distribution. Nothing else matters as far as I am concerned.

Debian's policy is to ship a copy of the pristine upstream sources (as
*.orig.tar.gz) along with a diff. Pristine in the sense that the
md5sums of the source shipped should match that of the source from
upstream. So the above is not an option.

> > Also, there appears to be no way to generate examples/examples.pdf from
> > source. Is that correct?
>
> Yes. I consider example.pdf to be not at all usefull, once you can run
> the examples yourself. We've build and included the pdf for promotion
> only. I would suggest to take the source of the examples as parts of
> the documentation without taking care of the examples.pdf. However we
> may provide the build script in future as well (its available via CVS
> already, of course) if there are strong demands for that ...

I think it would be useful to make it possible to build it. For
example, the pdf could be built with different options...

> > Also, I ran into errors when trying to build manual.html. I'd appreciat=
e
> > assistance on this, though the error messages were not very useful, so =
I
> > am not sure how much information I can provide.
>
> You need to create a symbolic link of mkhowto from the python
> documentation tools (Do not just copy the file, since it uses the
> symlink to find further files it requires). In case this doesn't
> already solve your problem, feel free to post a little more
> information about your problem. But I'm not an expert in pythons
> documentation tools ... I just worked it out how to get it running
> myself (on fink, J=F6rg now uses it on debian as well). May be there
> somebody on this list, who has a better knowlegde of pythons
> documentation utils once we know a little more about your problem.

I put the PyX packages I produced online. They are the latest version:
0.6.3. Add the following to your sources.list, and you can get them.
 You can also get the sources by using deb-src.

deb http://www.stat.unc.edu/students/faheem/debian/ ./
deb-src http://www.stat.unc.edu/students/faheem/debian/ ./

If you download the sources and rename debian/rules.broken to
debian/rules, and then try to rebuild the debs on a Debian
testing/unstable machine, you should be able to reproduce the problem I
was seeing.

I can send you the error log, but it is not very informative.

1) as root do

apt-get build-dep python2.3-pyx
apt-get install devscripts latex2html

2) Do

apt-get source python2.3-pyx

as user in some scratch directory

3) Type

debuild binary

in the subdirectory pyx-0.6.3 produced.

The official Debian maintainer of PyX just uploaded packages, but he
doesn't build html files either.

Please CC me. I'm not subscribed. Thanks.
                                                          Faheem.