comp.lang.idl-pvwave archive: archive » Re: IDL 6.1 EPS error

Home » Public Forums » archive » Re: IDL 6.1 EPS error

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

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

Report message to a moderator

[Message index]

		Re: IDL 6.1 EPS error By: Karl Schultz on Fri, 29 October 2004 07:43
		Re: IDL 6.1 EPS error By: Michael Wallace on Thu, 28 October 2004 14:16
		Re: IDL 6.1 EPS error By: Randall Skelton on Thu, 28 October 2004 13:34
		Re: IDL 6.1 EPS error By: Karl Schultz on Thu, 28 October 2004 08:22
		Re: IDL 6.1 EPS error By: Mark Hadfield on Wed, 27 October 2004 16:10
		Re: IDL 6.1 EPS error By: Karl Schultz on Wed, 27 October 2004 15:57
		Re: IDL 6.1 EPS error By: Michael Wallace on Wed, 27 October 2004 15:37
		Re: IDL 6.1 EPS error By: Karl Schultz on Wed, 27 October 2004 15:32
		Re: IDL 6.1 EPS error By: Michael Wallace on Wed, 27 October 2004 15:29
		Re: IDL 6.1 EPS error By: Mark Hadfield on Wed, 27 October 2004 13:50
		Re: IDL 6.1 EPS error By: Michael Wallace on Wed, 27 October 2004 10:26

Previous Topic:	Re: Field of View
Next Topic:	fft_comparison.html (question to David Fanning and Paul van Delst)

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Oct 11 13:18:06 PDT 2025

Total time taken to generate the page: 1.04238 seconds