Re: [Update REQ 6152]: OOGL->VRML

[sowsy at linus.mitre.org]

> I guess I don't understand -- why do you need to repair the OOGL files
> after the fact? 
The generated data is incorrect. 
>  You-all must have access to the program that created 
> the invalid files originally, right? 
Not sure about that. 
>  Can't you just fix it to write them
> correctly?  That certainly seems the easier route to take.

My sentiments exactly; I offered to fix the code.It appears that kludging
through and hacking at the resulting code will yield the quickest solution
than recompiling the rather large system in place that generates the code.
I'm just doing what I have been instructed to do. Gotta love clean-room
reverse engineering, eh? 

> I see couple of problems with what FixOOGL seems to be doing, based on the
> messages it prints and the output you show.
> 
>   ``0 periods replaced by whitespace''
FixOOGL actually just removed one of the periods and placed the other
with a whitespace. 

> 	As far as I could see from the files you'd sent earlier,
> 	the double-periods should have been replaced by single-periods,
> 	not by white space.  I.e. it appeared that something like ``0..50000''
> 	was intended to mean the single number ``0.50000'', not
> 	the two numbers ``0.''  and ``.50000''.  (It's hard for me to imagine
> 	what kind of program would have spuriously written those double
> 	periods, though.)
One that isn't working as desired. 
 
>   ``47 newlines replaced with whitespaces''
> 	Likewise, this won't fix the line-splitting problem either.
> 	Whatever program wrote the erroneous files wasn't inserting
> 	line breaks where blanks were intended; it appeared to be
> 	inventing them out of whole cloth, just because its line-length
> 	limit had been reached.  So a long line that ends with ``1.2''
> 	followed by another line beginning with ``0000 3.50000''
> 	wasn't intended to be read as the three numbers
> 	``1.2 0000 3.5000'', but as *two* numbers ``1.20000 3.50000''.
> 	Thus replacing the newline with a blank is no help.
Got it. 
> 	You *might* be able to repair this defect after-the-fact
> 	by checking the line-length on broken lines (it seemed to be
> 	298 characters, I think, or exactly 300 chars counting CR and LF).
> 	So, whenever you found such a long line, just join it to its successor,
> 	*without* inserting a blank to separate them.
I'm currently working on code to do this. 

> 	If the line wasn't exactly 298 characters long, just leave it alone.
> 	Of course this too would fail if a line just happened to be exactly
> 	298 characters long, but it'd likely fix the bug most of the time.
> 
>   Stuart Levy, Geometry Center

Best Regards,
		David