Buggy CelUrls

Post #21by **Christophe** » 29.07.2004, 23:16

I just tried the following (valid HTML 4.01 Strict)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<title>test</title>
</head>
<body>
<p>test < test</p>
</body>
</html>

in Mozilla 1.6 and Firefox 0.8, and in both it displayed as

Code: Select all

test < test

Post #22by **selden** » 29.07.2004, 23:25

*shrug*
All I can say is that Firefox v0.9.2 running on WinXP does seem to require the trailing semicolon.

I do agree, however, that either Celestia should insert the appropriate quoting when it generates Cel:// URLs, or it should not use the ampersand construct.

Of course, this will break backward compatibility

And this does not address current problem of incompatible URLs

Post #23by **chris** » 30.07.2004, 04:51

selden wrote:Unfortunately, it looks like something changed in the way Cel URL vectors are interpreted between v1.3.2pre4 and 1.3.2pre6.

On my home system, URLs for Ran that I created using pre11 do not work with 1.3.1 final or with 1.3.2pre4 (dated Feb 25), but do work with 1.3.2pre6 (dated Mar 12) .

I don't seem to have a copy of pre5.

I've got pre5 and it exhibits the same behavior as pre6 with regard to cel URLs. It's very suspicious that this is the first version that I built with VC7 instead of VC6.

--Chris

Post #24by **Christophe** » 30.07.2004, 07:23

selden wrote:I do agree, however, that either Celestia should insert the appropriate quoting when it generates Cel:// URLs, or it should not use the ampersand construct.

As you know, ampersand is the standard GET variable separator in URLs, and there is really no reason why Celestia should escape them in the URLs it generates, what if you want to send them by e-mail?

It is really up to the program used to write HTML to properly escape strings.

Now, if Chris can confirm that he indeed started using VC7 with pre5, I think we can definitely conclude that this is a compiler issue. That would also explain why the problem exists with 1.3.1 on OSX. As for a fix...

Harry · Post #25by **Harry** » 30.07.2004, 10:45

The problem seems to not be in the URL code.
Try this script:

Code: Select all

celestia:settime(2453216.3262804)
pos = celestia:find("HIP 31688/b"):getposition()

txt = "" .. pos.x .. "\n" .. pos.y .. "\n" .. pos.z
celestia:print(txt, 999, -1, 0)

It prints the coordinates of HIP 31688/b at the time of the URL. In my tests the x and y coordinates for windows and linux were equal, but the z-coordinate was different by about 15 micro-ly. The result was (third line):
-218448150.61905 (Windows)
-218448135.36026 (Linux)

I am trying to find out if there is anything special with my installation, so it would be great if others could check this result. If it turns out to be true, then maybe BigFix has some more problems, or even the position of "b" itself is different (any other ideas?).

UPDATE: This difference in position also happens for e.g. it's parent star HIP 31688, or Vega, HIP 82716, Proxima Centauri and Betelgeuse (got the last ones wrong in the last update), but not always only the z-coordinate.

Harald

Post #26by **chris** » 30.07.2004, 15:42

My experiments with cel:// URLs give results consistent with Harald's findings: BigFix seems to be fine, but the stars are in the wrong position. In the HIP 31866 example, the error is on the order of 1/2^23--exactly what you'd expect for a least significant bit error in a single precision floating point value. I think something is slightly different in the conversion from spherical to rectangular coordinates in stardb.cpp.

--Chris

Post #27by **chris** » 01.08.2004, 17:29

Sure enough, it's a single bit difference that arises when converting star positions from equatorial coordinates to the rectangular coordinate system that Celestia uses internally . . . I checked a fix into CVS.

--Chris