On Thu, 2015-10-29 at 13:14 -0700, mathog wrote:

I fixed a bug today and found that the emf round trip test no longer worked. (This has nothing to do with the bug I was working on, which just changed a couple of scale factors related to dashed lines.) The round trip test works like this (sorry about the wrap):

$INK --file=/usr/local/src/libUEMF/dist/test_libuemf_ref.emf --export-emf=/tmp/test1.emf $INK --file=/tmp/test1.emf --export-emf=/tmp/test2.emf $INK --file=/tmp/test2.emf --export-emf=/tmp/test3.emf

$READEMF /tmp/test1.emf > /tmp/test1_emf.txt $READEMF /tmp/test2.emf > /tmp/test2_emf.txt $READEMF /tmp/test3.emf > /tmp/test3_emf.txt

afterwards "diff" of any of pair of the test*_emf.txt pairs would show only the one line associated with the name change.

Not anymore though. Now they differ from each other a lot. When the emf files produced are viewed in inkscape they appear to be the same. However, the text dumps of the EMF files are wildly different, apparently because the object order is no longer the same. That is, the input stage is seeing the objects in one order, and the output stage is seeing them in another. The reordering seems to be repeatable, that is, if test1.emf is loaded and saved as test9.emf, then the text dump of that is the same as test2.emf (other than the file name field.)

The same test with WMF is still stable, but that is a much, much simpler and smaller test file.

What has changed in Inkscape that would be causing this?

Are the objects in reverse order? There was work to remove 'glist's awhile back that may result in reversing the order of things is selection is involved.

Tav

On 2015-10-29 21:14 (+0100), mathog wrote:

I fixed a bug today and found that the emf round trip test no longer worked. (This has nothing to do with the bug I was working on, which just changed a couple of scale factors related to dashed lines.) The round trip test works like this (sorry about the wrap):

$INK --file=/usr/local/src/libUEMF/dist/test_libuemf_ref.emf --export-emf=/tmp/test1.emf $INK --file=/tmp/test1.emf --export-emf=/tmp/test2.emf $INK --file=/tmp/test2.emf --export-emf=/tmp/test3.emf

$READEMF /tmp/test1.emf > /tmp/test1_emf.txt $READEMF /tmp/test2.emf > /tmp/test2_emf.txt $READEMF /tmp/test3.emf > /tmp/test3_emf.txt

afterwards "diff" of any of pair of the test*_emf.txt pairs would show only the one line associated with the name change.

Not anymore though. Now they differ from each other a lot. When the emf files produced are viewed in inkscape they appear to be the same. However, the text dumps of the EMF files are wildly different, apparently because the object order is no longer the same. That is, the input stage is seeing the objects in one order, and the output stage is seeing them in another. The reordering seems to be repeatable, that is, if test1.emf is loaded and saved as test9.emf, then the text dump of that is the same as test2.emf (other than the file name field.)

The same test with WMF is still stable, but that is a much, much simpler and smaller test file.

What has changed in Inkscape that would be causing this?

Here are test results with archived trunk builds, using these revisions: 13638 13646 13702 13800 13901 14003 14108 14200 14305 14404 14430 14434

https://gist.github.com/su-v/752aa0c0bcb0b122d9ea

The EMF reference file and reademf is from latest libUEMF 0.2.3.

Based on the numbers, I don't see a regression in recent trunk, rather the opposite (at least wrt consistency). The results with 0.91 (not included) are similar to the earliest tested trunk revisions (r13638 was shortly after the stable release branch was made, r13646 shortly after the merge of the experimental branch). The exported EMF files as well as the compressed TXT files from reademf are available on request.

Regards, V