well, you are right. We should not write NaN in the PDF output. However, the problem is, that we have plenty of positions where floats are written into the PDF (and PostScript) files. I remember that we discussed before, that we could check at all those positions for NaN. The most convenient way would probably be to use a writeFloat-Function adding such an additional function call and some condition check to all the float output. Furthermore, as far as I remember it is not that trivial to check a float for NaN (and +/-Inf). So for the moment we don't do that. However, we might want to discuss this again. It is certainly a problem, that you accidentally created a PDF file with NaN inside.
Am 19.11.2010 um 06:53 schrieb Brendon Higgins:
> Hi André,
> Yep, the problem isn't difficult to work around. I forgot to mention that the
> way I got around it was by having separate data files. In my case that required
> only two files.
> But to address the issue itself, are you saying that this arises *because* NaN
> can be (and is) parsed as a float? Do you mean that PyX actually is attempting
> to draw data points at NaN positions?
> If yes, is it wise of PyX to try to do that? As you might've guessed, my
> intuition is that if a value is not a number, NaN, it should not even attempt
> to be drawn.
> André Wobst wrote (2010-11-19 15:21):
>> Hi Brendon,
>> Well, NaN can be stored in a float and is even "created" by float('NaN').
>> It should be fine if you use something else to mark nonexistent data
>> points. I prefer to use "*".
>> Am 19.11.2010 um 04:06 schrieb Brendon Higgins:
>>> For one plot I had a set of data defined in a text file, but not all of
>>> them were sensible for particular x positions. So I set some data points
>>> to NaN so that they wouldn't be drawn in the plot (I'm using a line
>>> style). Things seemed to work fine like this when viewing the resulting
>>> PDF in Okular, but I later found out that acroread and foxit come up
>>> with errors, and do not show the complete plot, when they try to render
>>> the PDF.
>>> I've been too busy to test it thoroughly, unfortunately. Is anyone else
>>> aware of this? Perhaps my assumption that "NaN" would be parsed to
>>> something sensible was unjustified. (If so, should PyX be allowing such
>>> things to pass without error or warning?)
>>> ----- Beautiful is writing same markup. Internet Explorer 9 supports
>>> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
>>> Spend less time writing and rewriting code and more time creating great
>>> experiences on the web. Be a part of the beta today
>>> PyX-user 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/