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

[daemon]

OK, here's what seems wrong with the latest (4/28) version:

  - Some long lines are still broken.
	I guess you're now repairing the ones that break at 300 characters,
	but there seem to be others that are broken at 256 (lines 921, 1197,
	and 1199), and others at perhaps 74 and 48 characters (line 641 &c),
	or something.  So maybe line length isn't usable as a reliable guide
	for repairing broken lines.


	You might use a diagnostic like the following.  Whenever you see
	a line beginning with a digit, if that line contains more than 
	three blank-separated numbers, it's presumably a face-description
	for an OFF object.  The first number, say N, gives the number of
	vertices on the face; it's followed by N more integers, plus
	(in this system's case) four more floating-point numbers giving the
	face color.  Thus if the first number is N, you should find 1+N+4
	or N+5 blank-separated fields on that line.  If there are fewer,
	then concatenate the following line onto this one (without adding
	a space when joining the two lines).  Repeat until you find N+5
	fields on the line.

	One thing worries me about this: in the data you sent, some faces
	don't seem to include the last ("1") color field even in
	following lines, i.e. some long lines have N+5 fields and some
	have only N+4 (e.g. compare lines 410 and 411).  Could this be an
	artifact of your post-processing, or is that true in the original
	output, too?

	If even the original output sometimes omits the final "1", you
	might need a further rule: gather up to N+4 fields, then look ahead
	at the following line.  If it includes exactly one or two fields, 
	comprising only digits, "." and blanks, then concatenate it onto the
	preceding line.

  - OFF objects really need to be preceded by "OFF".
	This should be easy to arrange; it looks as though the system
	always emits OFF objects preceded by a 5-line "appearance { ... }",
	so you could just insert "OFF" after the matching
	close-brace following an "appearance".  If the system (as opposed to
	your postprocessor) sometimes adds its own "OFF" keywords, you'd
	have to insert "OFF" only if the next line began with a number.

  - There's an unmatched brace: an open-brace after the initial LIST
	with no close-brace.  I don't know how you can fix this; it depends
	how consistent it is, and whether it comes from the original system
	or from your repair processing.  In this case, just deleting that
	one open-brace is sufficient.

If after this you still have trouble, could I suggest you try sending me
two or three samples of raw output from the system, with no postprocessing at 
all?  It's hard for me to tell what all the problems are, especially since
I don't know what kind of processing you're doing.

  Stuart