MF{type} toString() methods include carriage return

[splace]

trafficstars

example

#VRML V2.0 utf8 Titania V4.5.2

WorldInfo {
  title "print-bug"
}

DEF script Script {
  field          MFFloat  floatArray [1,2,3]
  eventOut       MFString floatArraytext

  url "ecmascript:

function initialize ()
{
	floatArraytext[0] = floatArray
}

"
  directOutput TRUE
}

Shape {
  appearance Appearance {
    material Material { }
  }
  geometry DEF display Text {
    string "default"
  }
}

ROUTE script.floatArraytext TO display.set_string

[create3000]

MF{type} toString() is a browser dependent method and not specified. Please do your own formatting, as you like it, manually.

For instance you could use:

function initialize ()
{
	floatArraytext [0] += "[";

	for (var i = 0; i < floatArray .length; ++ i)
		floatArraytext[0] += floatArray [i] + " ";

	floatArraytext [0] += "]";
}

[create3000]

Please note that Titania is now listed on Flathub and Snap Store. All new updates will be from there, the create3000 Flatpak will not longer be updated. Please follow the instructions from http://create3000.de/titania/download/.

[splace]

Please do your own formatting, as you like it, manually.

this was found causing problems in an existing world, i am testing for compliance.

MF{type} toString() is a browser dependent method and not specified.

AFAIK it is specified for arrays in java/ecmascript to be comma separated.

and newlines don't appear to be being generated by the browser (see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toString )

are you sure this isn't being generated manually by x-ite's js engine? somewhere in the prototype chain directly coded for a 'pretty' print.

[splace]

Please note that Titania is now listed on Flathub and Snap Store. All new updates will be from there, the create3000 Flatpak will not longer be updated. Please follow the instructions from http://create3000.de/titania/download/.

i had been wondering why updates had slowed.

[create3000]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toString describes the JavaScript 'Array' objects method toString. An X3D MF* field is not derived from JavaScript 'Array' and has its own formating,

[splace]

An X3D MF* field is not derived from JavaScript 'Array' and has its own formating,

i, personally, would see 'toString' as producing 'human readable' text and so would not make assumptions about what it produced, (other than that, when displayed to a human, they would be able to read the value of the object), but i would guess that browsers do generally derive MF*'s from JS Array's and so some people may have unfortunately relied on its formatting.

but, here, it was just being used to display a value for a human to read, using the only direct vrml way to do that, through a Text Node. the inclusion of non-printing control characters is what made this stand out as an issue. many other variations in the formatting of the string would not have been an issue.

[create3000]

i, personally, would see 'toString' as producing 'human readable' text

An MF* field produces human readable text if you use print (mffield) or Browser .print (mffield) for debugging purposes, but MF*.toString is not designed to send the output to a Text node, then you must do your own formatting.

[create3000]

It is no rocket science to get nice one line formatting, for instance you could do:

function initialize ()
{
	var a = new MFInt32 (1, 2, 3, 4, 5, 6);
	
	print (a .toString () .replace (/\s+/g, " "));
}

[splace]

It is no rocket science to get nice one line formatting, for instance you could do:

thank you for explaining, again, how easy it is to bypass this issue by modifying the world. i am not making content, this is preexisting (the code in the OP is cut from), and if i were making some it would not be browser dependent.

An MF* field produces human readable text if you use print (mffield) or Browser .print (mffield) for debugging purposes, but MF*.toString is not designed to send the output to a Text node, then you must do your own formatting.

i had not realised that print() doesn't produce the same string as toString(), for me this goes against a very well established behaviour of js, the use of toString() for default string conversions.

it seems to me that this output is more appropriate to toSource(), as this is intended to produce parsable output (machine/human readability) where new lines are expected/handled.