this is a serious bug in PyX. It is strange we didn't notice it before.
The reason why PyX converts all paths to normpaths is because PyX supports all Postscript path elements natively (as long as they are path elements). You may argue, that this is not necessary, but PyX resembles the whole PostScript path functionality due to its history being a PostScript creation facility at first.
Normpath elements are however limited to lines and curves (bezier curves), which is precisely the path element subset supported by PDF. We use the normpath machinery to convert all paths to normpaths during PDF output. However, we disable all the advanced construction features of the normpaths which are important for numerical stability when doing geometric operations by setting epsilon to None. Fine so far. The problem is, that PyX normsubpaths can contain normlines and normcurves only. There is no moveto operation for normsubpaths, but we add an zero length normline for that. As long as epsilon is not None, but a small positive number, the normsubpath constructor properly deals with that. You may have a look to the skipline property, which collects short path elements not to be added to the normsubpaths for numerical stability. When epsilon is None, this functionality is blocked, and the problem you observed becomes visible.
I patched the normpath creation of the moveto path element when epsilon is None by inserting a special version of normline, which does not output the line operation in PDF. See changeset 3035. It might look like an ugly hack at first, but in reality I think it is a quite clean solution. To my mind it is of similar ugliness like using epsilon being None to produce PDF paths. In the end it reuses a lot of code nicely.
Am 03.12.2010 um 18:01 schrieb Michael J Gruber:
> Hi there,
> I have a strange problem where
> from pyx import *
> c = canvas.canvas()
> c.stroke(path.line(0, 0, 0.05, 0))# .normpath(epsilon=None))
> d = document.document([document.page(c)])
> produces a PDF where the single line is not displayed correctly in
> okular (KDE 4.5.3): The left end-point looks like a stair. The EPS looks
> OK. Now, the EPS has
> 0 0 moveto
> 1.41732 0 lineto
> whereas the PDF has
> 0.000000 0.000000 m
> 0.000000 0.000000 l
> 1.417323 0.000000 l
> I tracked this down to the fact that the pdfwriter converts everything
> to normpaths with epsilon=None. So, inserting the normpath conversion
> from the comment above produces the extra 0 length line in EPS also. If
> I use the standard epsilon it goes away (and both files display nicely).
> This poses the following questions which are only partially pyx-related
> (but which some here might be able to answer):
> - Why does epsilon=None produce a line of length 0?
> - Why doesn't the pdfwriter use the standard epsilon?
> - Why does okular (using poppler) choke on that 0 length line in the PDF?
> - Why does okular (using libspectre) not choke on the 0 length line in
> the EPS (forced with explicit normpath conversion with epsilon=None)?
> - Why does evince (using poppler) not choke on that very same PDF???
> Any hints appreciated.
> P.S.: acrobat probably does OK on this also; I've witnessed that problem
> with okular on many of my presented slides (acrobat did fine) but have
> banned acrobat since my last distro upgrade.
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> PyX-devel mailing list
by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/