pyx-devel — PyX development

[PyX-devel] Suggestion: deco.curvedtext()

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

Hi again,

I'm kinda getting to like the deco concept... I remembered an old post
by Andre, showing a method (due to J=F6rg, I think) for laying out text
along a curve. I adjusted it to the current API and coded it as a
decorator dubbed deco.curvedtext(). I'm attaching a simple example (how
to achieve typical line ups) and the code. The code goes into deco.py
(current svn). I'm unsure about the following:

a) Is the patch to dvifile.dvifile.putchar appropriate for going into
the trunk, or are there side effects (I don't know that module)?

b) Is it appropriate to attach eps examples here?

c) What's the best format for code suggestions? I'd be happy to send
diffs, but the patch mentioned above made it somehow inconvenient here
(the "local" patch I'm applying won't be the final form, of course).

As for the other text decorators (text as it is or (t)text as suggested
by me recently or text rotated parallel to the curve [tangential
labels]): I imagine a universal decorator deco.insert() would be best
which inserts a given canvas at certain points of the path, with or
without a user specified alignment, with or without rotation with
respect to the absolute co system or the local path tangent. Then, all
text decorators (except for deco.curvedtext) would be simple calls to
deco.insert(text.text(...)). But one could also easily decorate with
symbols "moving" along the path and such. Please tell me what you think,
or else I might start hacking away ;)

Cheers,
Michael

[PyX-devel] deco.text() suggestion

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

Hi there!

deco.text() has an angle attribute specifying the direction (with
respect to the coordinate system) in which to shift the text from the
point on the path. When annotating curves with multiple labels at points
with different slopes I find it more convenient to shift text along the
normal to the curve. I suggest making the default of the angle argument
"None" instead of 0, "None" meaning "use the direction of the normal".

An alternative would be to measure the angle with respect to the tangent
(maybe toggled by a boolean option "usetangent"), although I imagine
only ever using 90 and 270 degrees then.

I also noticed that deco.text() uses "relarclenpos" where deco.arrow()
uses "pos" with the same meaning. A common name would be useful.

I attached a deco.ttext() method implementing the changed default
behaviour (None=use normal). Text decorators are shifted perpendicularly
to the right of the path (to the left if textdist<0).
As it is it's meant to go into deco.py (uses the same imports etc.). I'd
be happy to provide a diff once I know whether deco.ttext() is supposed
to substitute the current deco.text(), complement it or just live in my
own module tree ;)

Cheers,
Michael

P.S.: This is inspired by the vector example!

[PyX-devel] [ pyx-Bugs-1448873 ] Typo in dvifile.py

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

Bugs item #1448873, was opened at 2006-03-13 15:01
Message generated for change (Settings changed) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1448873&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael J Gruber (michaeljgruber)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in dvifile.py

Initial Comment:
Typo in dvifile.py, see attached diff.

Results in PyX choking on font maps with truetype fonts.

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

>Comment By: Jörg Lehmann (joergl)
Date: 2006-03-13 15:31

Message:
Logged In: YES 
user_id=390410

Hallo Michael,

thanks for noticing this in time, checked in.

   Jörg



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

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

[PyX-devel] [ pyx-Bugs-1448873 ] Typo in dvifile.py

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

Bugs item #1448873, was opened at 2006-03-13 15: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=1448873&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael J Gruber (michaeljgruber)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in dvifile.py

Initial Comment:
Typo in dvifile.py, see attached diff.

Results in PyX choking on font maps with truetype fonts.

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

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

Re: [PyX-devel] Re: [PyX-user] latex and dvipdfm problem

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

Hi,

On 09.03.06, Andre Wobst wrote:
> I've just started a migration of our repository to subversion.

This time (Jörg tried before already) it seemed to have worked well.
So we'll start to checkin the new stuff into subversion now. AFAIK CVS
will continue to work, but I've already updated the project page to
contain subversion instead of CVS. To checkout your copy use

    svn co https://svn.sourceforge.net/svnroot/pyx/trunk/pyx pyx

or similar.


André

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

[PyX-devel] Re: [PyX-user] latex and dvipdfm problem

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

Hi,

(This not really belongs to the users list anymore. Upcoming notes
will be posted to the devel list only.)

On 09.03.06, Andre Wobst wrote:
> Just check again. After a cvs update ... :-)

I've just started a migration of our repository to subversion.


André

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

[PyX-devel] [ pyx-Bugs-1443197 ] from pyx import * failes

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: from pyx import * failes

Initial Comment:
(b.r...@gm...) On my system running suse10, I
get the following error after installation when I try
to import PyX:

>>> from pyx import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib/python2.4/site-packages/pyx/__init__.py",
line 42, in ?
    __import__(module, globals(), locals(), [])
  File "/usr/lib/python2.4/site-packages/pyx/box.py",
line 27, in ?
    import bbox, path, unit, trafo, helper
  File "/usr/lib/python2.4/site-packages/pyx/path.py",
line 40, in ?
    import bbox, canvas, trafo, unit
  File
"/usr/lib/python2.4/site-packages/pyx/canvas.py", line
33, in ?
    import attr, base,  bbox, deco, deformer, unit,
prolog, style, trafo, version
  File "/usr/lib/python2.4/site-packages/pyx/deco.py",
line 30, in ?
    import attr, base, canvas, color, helper, path,
style, trafo, unit
  File "/usr/lib/python2.4/site-packages/pyx/trafo.py",
line 60, in ?
    class trafo_pt(canvas.canvasitem, deformer.deformer):
AttributeError: 'module' object has no attribute
'canvasitem'
>>>                

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-05 12:48

Message:
Logged In: NO 

Please ignore this bug. After reinstalling, PyX works. I
assume I messed up my installation of PyX

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

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

[PyX-devel] [ pyx-Bugs-1443197 ] from pyx import * failes

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

Bugs item #1443197, was opened at 2006-03-04 13:09
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1443197&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: from pyx import * failes

Initial Comment:
(b.r...@gm...) On my system running suse10, I
get the following error after installation when I try
to import PyX:

>>> from pyx import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib/python2.4/site-packages/pyx/__init__.py",
line 42, in ?
    __import__(module, globals(), locals(), [])
  File "/usr/lib/python2.4/site-packages/pyx/box.py",
line 27, in ?
    import bbox, path, unit, trafo, helper
  File "/usr/lib/python2.4/site-packages/pyx/path.py",
line 40, in ?
    import bbox, canvas, trafo, unit
  File
"/usr/lib/python2.4/site-packages/pyx/canvas.py", line
33, in ?
    import attr, base,  bbox, deco, deformer, unit,
prolog, style, trafo, version
  File "/usr/lib/python2.4/site-packages/pyx/deco.py",
line 30, in ?
    import attr, base, canvas, color, helper, path,
style, trafo, unit
  File "/usr/lib/python2.4/site-packages/pyx/trafo.py",
line 60, in ?
    class trafo_pt(canvas.canvasitem, deformer.deformer):
AttributeError: 'module' object has no attribute
'canvasitem'
>>>                

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-05 03:48

Message:
Logged In: NO 

Please ignore this bug. After reinstalling, PyX works. I
assume I messed up my installation of PyX

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

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

[PyX-devel] [ pyx-Bugs-1443197 ] from pyx import * failes

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

Bugs item #1443197, was opened at 2006-03-04 13:09
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=1443197&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: from pyx import * failes

Initial Comment:
(b.r...@gm...) On my system running suse10, I
get the following error after installation when I try
to import PyX:

>>> from pyx import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib/python2.4/site-packages/pyx/__init__.py",
line 42, in ?
    __import__(module, globals(), locals(), [])
  File "/usr/lib/python2.4/site-packages/pyx/box.py",
line 27, in ?
    import bbox, path, unit, trafo, helper
  File "/usr/lib/python2.4/site-packages/pyx/path.py",
line 40, in ?
    import bbox, canvas, trafo, unit
  File
"/usr/lib/python2.4/site-packages/pyx/canvas.py", line
33, in ?
    import attr, base,  bbox, deco, deformer, unit,
prolog, style, trafo, version
  File "/usr/lib/python2.4/site-packages/pyx/deco.py",
line 30, in ?
    import attr, base, canvas, color, helper, path,
style, trafo, unit
  File "/usr/lib/python2.4/site-packages/pyx/trafo.py",
line 60, in ?
    class trafo_pt(canvas.canvasitem, deformer.deformer):
AttributeError: 'module' object has no attribute
'canvasitem'
>>>                

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

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

[PyX-devel] [ pyx-Bugs-1429524 ] wrong parsing of .enc files

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

Bugs item #1429524, was opened at 2006-02-11 03:20
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1429524&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mojca Miklavec (miklavec)
Assigned to: Jörg Lehmann (joergl)
Summary: wrong parsing of .enc files

Initial Comment:
How to reproduce the error?
text.preamble(r"\usepackage{iwona}")

Reason for misbehaviour:
some .enc files may start with something like this:

/enciwona-qx[
/alpha

PyX considers '[' being part of the encoding name and
expects another '[' to appear.

Please also try with
text.preamble(r"\usepackage{lmodern}")

Parsing of .enc files is simple, but yet not as trivial
as it may seem to be.

Mojca

PS: Hoping that PyX will support ConTeXt once as well,
not only (hardcoded) LaTeX;
www.pragma-ade.com/overview.htm. But PyX seems to be
great anyway.


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

>Comment By: Jörg Lehmann (joergl)
Date: 2006-02-25 12:15

Message:
Logged In: YES 
user_id=390410

Hello Mojca,

sorry for my late reply, somehow your response slipped
through my radar. Anyway, could you try again. I'm pretty
sure that both of your problems (with the iwona and the
lmodern package) have been fixed now.

    Jörg


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

Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


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

Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


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

Comment By: Jörg Lehmann (joergl)
Date: 2006-02-11 13:30

Message:
Logged In: YES 
user_id=390410

Hi Mojca,

I checked in a fix. Could you maybe checkout the CVS
version of PyX and try whether it fixes the problem. I 
neither have the iwona package nor, as it seems, the fonts
for the lmodern package installed.

Thanks,
    
    Jörg

PS: With respect to ConTeXt support, I have to say that
adding this, is not a priority for us, since neither of
the developers is a ConTeXt user.



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

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

[PyX-devel] [ pyx-Bugs-1438333 ] Problem parsing psfonts.map

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michele Vallisneri (vallisneri)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing psfonts.map

Initial Comment:
Only a warning (actually, many copies of it), but an annoying one.

With a stock installation of TeTeX on OS X (via i-Installer), PyX cannot 
parse the standard psfonts.map file. It complains

pyx/dvifile.py:391: UserWarning: Ignoring line ... in mapping file 
'psfonts.map': wrong syntax

A few examples of the lines that trigger this message

HoeflerTextOrnaments <hoeflertextornaments.enc 
<HoeflerTextOrnaments.ttf
ec-hoefler-raw-HoeflerText HoeflerText-Regular 4 <HoeflerText.ttf ec-
hoefler.enc
ec-os-raw-Didot Didot 4 <Didot.ttf ec-os.enc
ec-raw-AmericanTypewriter AmericanTypewriter 4 
<AmericanTypewriter.ttf ec.enc

Basically it's the TTF fonts...

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

Comment By: Jörg Lehmann (joergl)
Date: 2006-02-25 12:11

Message:
Logged In: YES 
user_id=390410

Hello Michele,

this problem has already been fixed in the current CVS head.

Anyway, thanks for reporting!

    Jörg

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

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

[PyX-devel] [ pyx-Bugs-1438333 ] Problem parsing psfonts.map

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

Bugs item #1438333, was opened at 2006-02-24 21:25
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1438333&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Michele Vallisneri (vallisneri)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing psfonts.map

Initial Comment:
Only a warning (actually, many copies of it), but an annoying one.

With a stock installation of TeTeX on OS X (via i-Installer), PyX cannot 
parse the standard psfonts.map file. It complains

pyx/dvifile.py:391: UserWarning: Ignoring line ... in mapping file 
'psfonts.map': wrong syntax

A few examples of the lines that trigger this message

HoeflerTextOrnaments <hoeflertextornaments.enc 
<HoeflerTextOrnaments.ttf
ec-hoefler-raw-HoeflerText HoeflerText-Regular 4 <HoeflerText.ttf ec-
hoefler.enc
ec-os-raw-Didot Didot 4 <Didot.ttf ec-os.enc
ec-raw-AmericanTypewriter AmericanTypewriter 4 
<AmericanTypewriter.ttf ec.enc

Basically it's the TTF fonts...

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

>Comment By: Jörg Lehmann (joergl)
Date: 2006-02-25 12:11

Message:
Logged In: YES 
user_id=390410

Hello Michele,

this problem has already been fixed in the current CVS head.

Anyway, thanks for reporting!

    Jörg

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

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

[PyX-devel] [ pyx-Bugs-1438333 ] Problem parsing psfonts.map

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

Bugs item #1438333, was opened at 2006-02-24 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=1438333&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michele Vallisneri (vallisneri)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing psfonts.map

Initial Comment:
Only a warning (actually, many copies of it), but an annoying one.

With a stock installation of TeTeX on OS X (via i-Installer), PyX cannot 
parse the standard psfonts.map file. It complains

pyx/dvifile.py:391: UserWarning: Ignoring line ... in mapping file 
'psfonts.map': wrong syntax

A few examples of the lines that trigger this message

HoeflerTextOrnaments <hoeflertextornaments.enc 
<HoeflerTextOrnaments.ttf
ec-hoefler-raw-HoeflerText HoeflerText-Regular 4 <HoeflerText.ttf ec-
hoefler.enc
ec-os-raw-Didot Didot 4 <Didot.ttf ec-os.enc
ec-raw-AmericanTypewriter AmericanTypewriter 4 
<AmericanTypewriter.ttf ec.enc

Basically it's the TTF fonts...

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

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

[PyX-devel] Re: [PyX-user] Palatino font not embedded in PDF

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

Hi Jörg,

On 20.02.06, Joerg Lehmann wrote:
> this point is probably better suited for the devel list, but anyway...

Right. So let's move to the dev-list.

> On 20.02.06, Andre Wobst wrote:
> Isn't it kind of strange that we need to set the font mapping file via
> text.set?

I don't think so. Note that the mapping files are something very TeX
specific. TeX just doesn't know what the fonts really are. It's
subject to the dvi reader to understand, what kind of typesetting TeX
want's us to do. TeX font names should *not* be passed to the backend.

> I know that we currently need the mapping file in the dvifile
> module, but we sure can get rid of it there. And somehow this sounds
> like being the right thing to do, at least from a conceptual point of
> view. And then only the writers would need to know about the mapping
> file.

I disagree. We should not get the map files out of the dvi, since
without TeX where would be no need for the mapping files at all.
(Sure, fonts needs to be reencoded to make the glyphs available in an
8-bit-encoding, but it's an artifact, that the final output represents
the same reencoding as declared in the mapping file. I don't argue to
remove this coincidence, but it clearly is a coincidence. At some
point we might even want to break that. But it's not an issue at the
moment.)

We could move all the "TeX-fontnames to the final output" features
into our output devices, but I don't think it's The Right Thing to do.
What we really want to have is something like: For PostScript we can
take the builtin font XY and reencode it the following way, while for
PDF, where there is no builtin font XY and we need to do this and
that. *This* is a generic feature, which we need to implement, but
it's not at all generic, that the source of that information are some
stupid TeX mapping files.


André

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

[PyX-devel] [ pyx-Bugs-1429524 ] wrong parsing of .enc files

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

Bugs item #1429524, was opened at 2006-02-11 03:20
Message generated for change (Comment added) made by miklavec
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1429524&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mojca Miklavec (miklavec)
Assigned to: Jörg Lehmann (joergl)
Summary: wrong parsing of .enc files

Initial Comment:
How to reproduce the error?
text.preamble(r"\usepackage{iwona}")

Reason for misbehaviour:
some .enc files may start with something like this:

/enciwona-qx[
/alpha

PyX considers '[' being part of the encoding name and
expects another '[' to appear.

Please also try with
text.preamble(r"\usepackage{lmodern}")

Parsing of .enc files is simple, but yet not as trivial
as it may seem to be.

Mojca

PS: Hoping that PyX will support ConTeXt once as well,
not only (hardcoded) LaTeX;
www.pragma-ade.com/overview.htm. But PyX seems to be
great anyway.


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

>Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


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

Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


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

Comment By: Jörg Lehmann (joergl)
Date: 2006-02-11 13:30

Message:
Logged In: YES 
user_id=390410

Hi Mojca,

I checked in a fix. Could you maybe checkout the CVS
version of PyX and try whether it fixes the problem. I 
neither have the iwona package nor, as it seems, the fonts
for the lmodern package installed.

Thanks,
    
    Jörg

PS: With respect to ConTeXt support, I have to say that
adding this, is not a priority for us, since neither of
the developers is a ConTeXt user.



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

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

[PyX-devel] [ pyx-Bugs-1429524 ] wrong parsing of .enc files

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

Bugs item #1429524, was opened at 2006-02-11 03:20
Message generated for change (Comment added) made by miklavec
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1429524&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mojca Miklavec (miklavec)
Assigned to: Jörg Lehmann (joergl)
Summary: wrong parsing of .enc files

Initial Comment:
How to reproduce the error?
text.preamble(r"\usepackage{iwona}")

Reason for misbehaviour:
some .enc files may start with something like this:

/enciwona-qx[
/alpha

PyX considers '[' being part of the encoding name and
expects another '[' to appear.

Please also try with
text.preamble(r"\usepackage{lmodern}")

Parsing of .enc files is simple, but yet not as trivial
as it may seem to be.

Mojca

PS: Hoping that PyX will support ConTeXt once as well,
not only (hardcoded) LaTeX;
www.pragma-ade.com/overview.htm. But PyX seems to be
great anyway.


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

>Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


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

Comment By: Jörg Lehmann (joergl)
Date: 2006-02-11 13:30

Message:
Logged In: YES 
user_id=390410

Hi Mojca,

I checked in a fix. Could you maybe checkout the CVS
version of PyX and try whether it fixes the problem. I 
neither have the iwona package nor, as it seems, the fonts
for the lmodern package installed.

Thanks,
    
    Jörg

PS: With respect to ConTeXt support, I have to say that
adding this, is not a priority for us, since neither of
the developers is a ConTeXt user.



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

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

[PyX-devel] [ pyx-Bugs-1429524 ] wrong parsing of .enc files

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

Bugs item #1429524, was opened at 2006-02-11 03:20
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1429524&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: low level PostScript functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mojca Miklavec (miklavec)
>Assigned to: Jörg Lehmann (joergl)
Summary: wrong parsing of .enc files

Initial Comment:
How to reproduce the error?
text.preamble(r"\usepackage{iwona}")

Reason for misbehaviour:
some .enc files may start with something like this:

/enciwona-qx[
/alpha

PyX considers '[' being part of the encoding name and
expects another '[' to appear.

Please also try with
text.preamble(r"\usepackage{lmodern}")

Parsing of .enc files is simple, but yet not as trivial
as it may seem to be.

Mojca

PS: Hoping that PyX will support ConTeXt once as well,
not only (hardcoded) LaTeX;
www.pragma-ade.com/overview.htm. But PyX seems to be
great anyway.


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

>Comment By: Jörg Lehmann (joergl)
Date: 2006-02-11 13:30

Message:
Logged In: YES 
user_id=390410

Hi Mojca,

I checked in a fix. Could you maybe checkout the CVS
version of PyX and try whether it fixes the problem. I 
neither have the iwona package nor, as it seems, the fonts
for the lmodern package installed.

Thanks,
    
    Jörg

PS: With respect to ConTeXt support, I have to say that
adding this, is not a priority for us, since neither of
the developers is a ConTeXt user.



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

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

[PyX-devel] [ pyx-Bugs-1429524 ] wrong parsing of .enc files

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

Bugs item #1429524, was opened at 2006-02-11 03:20
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=1429524&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mojca Miklavec (miklavec)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong parsing of .enc files

Initial Comment:
How to reproduce the error?
text.preamble(r"\usepackage{iwona}")

Reason for misbehaviour:
some .enc files may start with something like this:

/enciwona-qx[
/alpha

PyX considers '[' being part of the encoding name and
expects another '[' to appear.

Please also try with
text.preamble(r"\usepackage{lmodern}")

Parsing of .enc files is simple, but yet not as trivial
as it may seem to be.

Mojca

PS: Hoping that PyX will support ConTeXt once as well,
not only (hardcoded) LaTeX;
www.pragma-ade.com/overview.htm. But PyX seems to be
great anyway.


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

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

[PyX-devel] =?iso-2022-jp?B?IBskQkJ0MGYkRyQ5GyhC?=

[<ne...@ci...>]

DQobJEJGTUEzJE4lYSE8JWskRz89JDdMdSQ0JDYkJCReJDskcyEjO2QkTyU7JWwlVjZmM1pJdCRI
JCQkJkE0OXFFODMrJE4jMyMwQmUwSj5lJE40ezonPFQkLD04JF4kayEiJTMlXyVlJUslRiUjJHJF
fTNnJDckRiQkJGtCdDBmOSVIfiRIPz0kNyReJDkhIzRKQzEkS0BiTEAkJCQ/JDckXiQ5JEghIj9N
OkokTj13QC0kLDAmP00kckM1JDklMyVfJWUlSyVGJSMkRyQ5ISMkPSROJGgkJiRKNFg3OCRLNj1M
IyROJCIka0NLQC0kTyUzJUElaSReJEclIiUvJTslOSQ3JEYyPCQ1JCQbKEIgGyRCJTMlQSVpISEb
KEJodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MzQbJEIhISRHJTslbBsoQiANChsk
QiVWNmYzWkl0JEg4ITp3JDckRiRiJGkkKCRsJFA9d0AtJE40aTxMPz9JVSQtJE4lVyVtJVUlIyE8
JWskSE8iTW1AaCRyOCskazt2JCwkRyQtJF4kOSEjJCpCVCRBJDckRiQqJGokXiQ5ISMbKEINCg0K
DQoNCg0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vDQobJEIlYSE8JWtJVE1XJE5K
fSRPJDMkQSRpJEslYSE8JWskciItGyhCDQpjb25jZXB0M19uZXRAeWFob28uY2ENCg0KDQo=

[PyX-devel] Re: [PyX-checkins] pyx/pyx normpath.py,1.11,1.12 helper.py,1.21,1.22

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

Hi nochmals,

On 06.02.06, André Wobst wrote:
> ! def evrealtrisym(d, e):
> ! def realsymtotrisym(a):
> ! def evrealsym(a):
> ! def balancerealsquare(a, radix=2):
> ! def hessrealsquare(a):
> ! def evhessrealsquare(a, realonly=0):
> ! def evrealsquare(a, copy=1, realonly=0):

Übrigens: Cool! :-)

        Jörg

[PyX-devel] [ pyx-Feature Requests-1419658 ] write to stdout

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

Feature Requests item #1419658, was opened at 2006-01-30 22:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1419658&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Jason Pratt (pratt)
Assigned to: Nobody/Anonymous (nobody)
Summary: write to stdout

Initial Comment:
It would nice if there were a simple mechanism to write 
documents to stdout instead of a file on the 
filesystem.  

Possible solutions:
--If the filename argument is None for writePDFfile or 
writeEPSfile, write to sys.stdout.
--Have writePDFfile and writeEPSfile take a file 
argument, which defaults to sys.stdout.  This gives the 
added flexibility of using any file handle.
--Create new methods, writePDFToStdout and 
writeEPSToStdout.



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

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

[PyX-devel] [ pyx-Bugs-1371930 ] psfont.map not found running under idle os x

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

Bugs item #1371930, was opened at 2005-12-02 11:32
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=1371930&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: psfont.map not found running under idle os x

Initial Comment:



I get the following error when running the
example file  that use tex to create labels
from idle in os x 10.3.9.

psfont.map not found 
line 381 in dvifile.py

The same files work ie produce good
pdf/eps output when run under python.
I've tried

1/ rerunning texhash/updmap
2/ editing the .pyxrc
3/ reinstalling pyx

PS congrats it's a great module

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

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

[PyX-devel] [ pyx-Bugs-1371554 ] Missing `key_pt' method in histogram graph style

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

Bugs item #1371554, was opened at 2005-12-02 10:17
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=1371554&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hagemann (mmhagemann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing `key_pt' method in histogram graph style

Initial Comment:
When using the histogram graph style, the illustration
of the curve is not shown in the legend.

Fix:  Copying the method from the line style worked for
me.  There may be better alternatives.

I needed this fix to plot many curves as "staircurves"
(for performance plots), using the `steps' parameter. 
In a single histogram, the illustration may be
superfluous, but I think it does not disturb either. 
Omitting the illustration could be made an option in
the `key' class.


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

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

Re: [PyX-devel] Axis names

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

Hi,

On 11.10.05, Michael Schindler wrote:
> I just tried to create an axis with graph.axis.linked, thinking of the
> similar notation graph.axis.linear
> 
> But the linked axis wants to be called graph.axis.linkedaxis
> 
> This is quite redundant. What about renaming some axes:
> 
> axis.linkedaxis         -> axis.linked
> axis.anchored           -> axis.anchored
> axis.anchoredpathaxis   -> axis.anchoredpath
> axis.pathaxis           -> axis.path

In principle, I do not have any problem with this. You should only be
aware of the point, that in earlier version there was some very
strange axis.linked, which was basically something like axis.regular,
but not calculating axis partitions ... and there there other linked
axis like linkedbar and linkedsplit. All those are gone now. Instead,
we have an anchoredaxis (an axis with position and data storage) and
an linkedaxis (an axis with a position, but not a private data
storage). Overall, this is quite clean now, but we have some strange
namings ... right. So I don't have any problems with changing back the
names ...

I'm sorry for the confusion. It just was very important to clean up
the system ...


André

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

[PyX-devel] Axis names

[Michael S. <m-s...@us...>]

Hello André,

I just tried to create an axis with graph.axis.linked, thinking of the
similar notation graph.axis.linear

But the linked axis wants to be called graph.axis.linkedaxis

This is quite redundant. What about renaming some axes:

axis.linkedaxis         -> axis.linked
axis.anchored           -> axis.anchored
axis.anchoredpathaxis   -> axis.anchoredpath
axis.pathaxis           -> axis.path

Michael.

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