Invalid XML-files about pyevtk HOT 7 OPEN

I agree with @xylar in that we should be careful to not degrade current use cases. Making the output mode configurable, defaulting to current mode, would be perfectly fine with me though.

While not space-efficient in itself, the base64 mode would also allow adding inline gzipping of the data, IIRC. That would be a real long-term benefit for us I think.

from pyevtk.

I've never even considered that the output files might not be valid XML since all my (only VTK standard following apparently) consumers happily accept them. I also didn't know that meshio doesn't fully support the VTK standard then, nor that Kitware managed to define a standard that uses xml and isn't fully compliant. Great stuff 🙄

So as far I understood, the only upside of using 'appended-raw' is that the implementation is less complex. Is that correct?

And aside from the implementation being trickier, there's no downside to using 'appended-binary', right?

from pyevtk.

You are right. In the end, it shouldn't be that hard to rewrite the appending routines. But one has to dig through all that serialization and base64 stuff...

from pyevtk.

My main aim would be to produce files, that meshio can read.

from pyevtk.

I cannot really justify pushing time into helping with the implementation, but if you can and want to, I could invest a little time in making the test setup better. I've already pushed a quick & dirty check to the generated examples into the xml_checks branch.

from pyevtk.

Another idea:
If we drop the use of appended and write the dataArray directly at their position of occurrence in the file, we don't have to estimate the offset in the appended data.

Only downside: the file isn't that readable anymore as before, where the data-metainfo was stored at the top of the file and the actual data was appended.

@renefritze , @xylar: would you have any problems with that approach?

from pyevtk.

I think having the file be readable has saved me some debugging trouble in the past but I don't have strong feelings about it.

Regarding base64 encoding, won't it by definition have to take up 4 times as much space, since you're only allowed to use 64 of the 256 values of a given byte? If so, I would be opposed to just switching to base64 as opposed to making that the default option but continuing to support the existing functionality even if it is not valid XML (since it works great in ParaVeiw).

from pyevtk.