| Re: IDL 6.1 EPS error [message #41450] |
Fri, 29 October 2004 07:43 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Michael Wallace" <mwallace.no.spam@no.spam.swri.edu.invalid> wrote in
message news:10o2odm89ncav58@corp.supernews.com...
>> I will try out this solution. It'll take me a few minutes to find all
>> the places in my code where I use empty strings.
>
> Well, I tried replacing my empty strings with ' ' strings and there are
> no longer nan values in the EPS. Everything appears to work okay. I
> did happen to notice that the underflow error is still present in
> IDLgrClipboard -> draw, but it doesn't seem to cause any problems.
>
> % Program caused arithmetic error: Floating underflow
Yes, I've seen this. As you probably know, it is not a serious problem,
because the underflow just indicates a loss of precision, and the true value
is closely approximated by zero.
I tried once to track this down and ended up thinking that the actual
underflow is occuring in Mesa, which is the OpenGL-like library we use to
produce the vector output. There are gobs of floating point math going on
inside of Mesa, and IDL is just reporting the underflow state after a fairly
long sequence of calls into Mesa. I'll have another look for next release.
Karl
|
|
|
|
| Re: IDL 6.1 EPS error [message #41462 is a reply to message #41450] |
Thu, 28 October 2004 14:16  |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> I will try out this solution. It'll take me a few minutes to find all
> the places in my code where I use empty strings.
Well, I tried replacing my empty strings with ' ' strings and there are
no longer nan values in the EPS. Everything appears to work okay. I
did happen to notice that the underflow error is still present in
IDLgrClipboard -> draw, but it doesn't seem to cause any problems.
% Program caused arithmetic error: Floating underflow
|
|
|
|
|
|
| Re: IDL 6.1 EPS error [message #41464 is a reply to message #41463] |
Thu, 28 October 2004 08:22 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Mark Hadfield" <m.hadfield@niwa.co.nz> wrote in message
news:clp9sl$7k2$1@newsreader.mailgate.org...
> Karl Schultz wrote:
>> This answers the question I posed in my first posting to this thread.
There
>> is an empty text string, as evidenced by the () in the PS code above.
>>
>> If you can tolerate a space character in the text string, I'd suggest
>> putting a space character in the text string as a workaround. Or
perhaps
>> some non-printable character.
>>
>> [Several lines snipped]
>>
>>
>> ...Much of the vector output code
>> was reworked in order to draw text objects as text primitives instead of
as
>> a set of triangles for IDL 6.1.
>
> Would another workaround be to set VECT_TEXT_RENDER_METHOD to 1 in
> IDLgrClipboard::Draw, thereby reverting to the old method of
> representing text?
Yes. But then you end up with triangles in the PS file. I don't know how
big a deal that is. It must be for some, otherwise we wouldn't have done
all this :-). Some also might think that the PS-rendered strings look
better or different. But it is an easy workaround.
Yet another workaround: The trick is to get a non-null text string out to
the vector file before any other strings that could be null. One could add
a view to their viewgroup or scene so that this new view draws first (first
in container order). Put a model and single text string object containing a
space char in this view. This view and its text string will always draw
first, independent of the depth relationship of other objects and rotations,
etc.
Karl
|
|
|
|
| Re: IDL 6.1 EPS error [message #41474 is a reply to message #41464] |
Wed, 27 October 2004 16:10 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
Karl Schultz wrote:
> This answers the question I posed in my first posting to this thread. There
> is an empty text string, as evidenced by the () in the PS code above.
>
> If you can tolerate a space character in the text string, I'd suggest
> putting a space character in the text string as a workaround. Or perhaps
> some non-printable character.
>
> [Several lines snipped]
>
>
> ...Much of the vector output code
> was reworked in order to draw text objects as text primitives instead of as
> a set of triangles for IDL 6.1.
Would another workaround be to set VECT_TEXT_RENDER_METHOD to 1 in
IDLgrClipboard::Draw, thereby reverting to the old method of
representing text?
--
Mark Hadfield "Ka puwaha te tai nei, Hoea tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
|
|
|
|
| Re: IDL 6.1 EPS error [message #41475 is a reply to message #41474] |
Wed, 27 October 2004 15:57 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Michael Wallace" <mwallace.no.spam@no.spam.swri.edu.invalid> wrote in
message news:10o089qpr07oa4f@corp.supernews.com...
>> IDL 6.1 has some significant bugs in its EPS output. (I don't think the
>> behaviour you have described resembles any of the bugs I am aware of,
>> but still...) I understand these are to be fixed in 6.1.1, which was
>> announced by email on 2 October as a fix for problem in "reading
>> non-finite data in IDL 6.1", but will also fix a few other problems. It
>> is to be released in "a few weeks".
>
>
> I've found the specific culprit of my problem. I should have thought to
> look at the actual EPS code created, but it didn't dawn on me until now.
> The EPS code is writing nan's to the actual EPS file. This only
> happens for my text objects and always follows the same pattern.
>
> /Courier findfont 13.9875 scalefont setfont
> ()
> nan nan M T
This answers the question I posed in my first posting to this thread. There
is an empty text string, as evidenced by the () in the PS code above.
If you can tolerate a space character in the text string, I'd suggest
putting a space character in the text string as a workaround. Or perhaps
some non-printable character.
I tried :
otext->setproperty, string=STRING(1b)
which seemed to work pretty well.
In the PS file I get:
()
320 240 M T
where the square means undisplayable character, depending on what tool I use
to look at the PS code. But a PostScript viewer would probably draw nothing
for this string.
The bug was that when a string is completely empty, some character size
information was not filled in. This led to the nan or inf numbers ending up
in the output file. It also is a fairly random bug. If a reasonable value
happened to be there, it might sometimes work.
>
>
> It appears that RSI attempted to update the EPS format in the move from
> 6.0.3 to 6.1. EPS files created with 6.0.3 show "%!PS-Adobe-2.0
> EPSF-1.2" while files created with 6.1 show "%!PS-Adobe-3.0 EPSF-3.0".
> And the actual EPS code looks wildly different between the two. So, I
> guess it's back to IDL 6.0.3 for the time being.
The EPS version has nothing to do with it. Much of the vector output code
was reworked in order to draw text objects as text primitives instead of as
a set of triangles for IDL 6.1.
Karl
|
|
|
|
| Re: IDL 6.1 EPS error [message #41477 is a reply to message #41475] |
Wed, 27 October 2004 15:37 |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> Are there any text objects that contain empty text strings in your scene?
Yes. I know I do this.
> The problem you describe would happen only if a null text string was
> processed by the vector output module as the first text string it
> encountered. Remember, "first", means after depth sorting, so it may be
> hard to figure out exactly what text object is involved.
>
> The first thing I'd do is make a quick check for empty text strings in your
> program, and just for now, set them to ' ' or something to see if the
> problem goes away. Once you have verified that this is the cause, a better
> solution is close at hand. Remember to consider text strings in axis
> objects, both tick text and title text. It is not unusual for some
> applications (like iTools) to create a text object with an empty string and
> use it to set the IDLgrAxis TITLE property, thinking that it will come back
> later and change the text without having to see if there was an object there
> first.
I will try out this solution. It'll take me a few minutes to find all
the places in my code where I use empty strings.
> This bug is fixed in 6.1.1.
Cool. Any word on when 6.1.1 will be out or is it a "few weeks"? ;-)
-Mike
|
|
|
|
| Re: IDL 6.1 EPS error [message #41478 is a reply to message #41477] |
Wed, 27 October 2004 15:32 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Mark Hadfield" <m.hadfield@niwa.co.nz> wrote in message
news:clp1nk$uju$1@newsreader.mailgate.org...
> Michael Wallace wrote:
>>> I haven't yet confirmed what is causing the problem, but it may be
>>> related to the text I'm using. I have been able to successfully
>>> create EPS files of axes and plot data, but without text. As soon as
>>> text gets added, it seems that the arithmetic errors start showing up
>>> the the EPS files become corrupt.
>>
>>
>> Well, I just created an EPS with text and it's fine. There must be
>> something really specific I'm doing wrong. I would post my code, but
>> right now it's spread over many files and functions.
Are there any text objects that contain empty text strings in your scene?
The problem you describe would happen only if a null text string was
processed by the vector output module as the first text string it
encountered. Remember, "first", means after depth sorting, so it may be
hard to figure out exactly what text object is involved.
The first thing I'd do is make a quick check for empty text strings in your
program, and just for now, set them to ' ' or something to see if the
problem goes away. Once you have verified that this is the cause, a better
solution is close at hand. Remember to consider text strings in axis
objects, both tick text and title text. It is not unusual for some
applications (like iTools) to create a text object with an empty string and
use it to set the IDLgrAxis TITLE property, thinking that it will come back
later and change the text without having to see if there was an object there
first.
>
> IDL 6.1 has some significant bugs in its EPS output. (I don't think the
> behaviour you have described resembles any of the bugs I am aware of,
> but still...) I understand these are to be fixed in 6.1.1, which was
> announced by email on 2 October as a fix for problem in "reading
> non-finite data in IDL 6.1", but will also fix a few other problems. It
> is to be released in "a few weeks".
This bug is fixed in 6.1.1.
|
|
|
|
| Re: IDL 6.1 EPS error [message #41479 is a reply to message #41478] |
Wed, 27 October 2004 15:29 |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> IDL 6.1 has some significant bugs in its EPS output. (I don't think the
> behaviour you have described resembles any of the bugs I am aware of,
> but still...) I understand these are to be fixed in 6.1.1, which was
> announced by email on 2 October as a fix for problem in "reading
> non-finite data in IDL 6.1", but will also fix a few other problems. It
> is to be released in "a few weeks".
I've found the specific culprit of my problem. I should have thought to
look at the actual EPS code created, but it didn't dawn on me until now.
The EPS code is writing nan's to the actual EPS file. This only
happens for my text objects and always follows the same pattern.
/Courier findfont 13.9875 scalefont setfont
()
nan nan M T
It appears that RSI attempted to update the EPS format in the move from
6.0.3 to 6.1. EPS files created with 6.0.3 show "%!PS-Adobe-2.0
EPSF-1.2" while files created with 6.1 show "%!PS-Adobe-3.0 EPSF-3.0".
And the actual EPS code looks wildly different between the two. So, I
guess it's back to IDL 6.0.3 for the time being.
-Mike
|
|
|
|
| Re: IDL 6.1 EPS error [message #41481 is a reply to message #41479] |
Wed, 27 October 2004 13:50 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
Michael Wallace wrote:
>> I haven't yet confirmed what is causing the problem, but it may be
>> related to the text I'm using. I have been able to successfully
>> create EPS files of axes and plot data, but without text. As soon as
>> text gets added, it seems that the arithmetic errors start showing up
>> the the EPS files become corrupt.
>
>
> Well, I just created an EPS with text and it's fine. There must be
> something really specific I'm doing wrong. I would post my code, but
> right now it's spread over many files and functions.
IDL 6.1 has some significant bugs in its EPS output. (I don't think the
behaviour you have described resembles any of the bugs I am aware of,
but still...) I understand these are to be fixed in 6.1.1, which was
announced by email on 2 October as a fix for problem in "reading
non-finite data in IDL 6.1", but will also fix a few other problems. It
is to be released in "a few weeks".
You should report this behaviour to RSI tech support, who may well pass
it on to Karl Schultz, the resident expert. Or perhaps he will reply on
the newsgroup.
BTW, I notice that RSI have advertised to fill a couple of positions in
quality control & testing. Interesting...
--
Mark Hadfield "Ka puwaha te tai nei, Hoea tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
|
|
|
|
| Re: IDL 6.1 EPS error [message #41489 is a reply to message #41481] |
Wed, 27 October 2004 10:26 |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> I haven't yet confirmed what is causing the problem, but it may be
> related to the text I'm using. I have been able to successfully create
> EPS files of axes and plot data, but without text. As soon as text gets
> added, it seems that the arithmetic errors start showing up the the EPS
> files become corrupt.
Well, I just created an EPS with text and it's fine. There must be
something really specific I'm doing wrong. I would post my code, but
right now it's spread over many files and functions.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
