Comment 5 for bug 1250250

Ugh, this issue is worse than I thought.

It also affects EMF but in a strange way. Open an emf file and it looks like it is in the right place, but then save as to "test.emf", and it gets shifted downward by about 1/3, the same way that the wmf file was when it was just opened. That only becomes evident when the new file is read back in though. That problem can be eliminated by making the same change to emf-inout.cpp that the preceding patch made to wmf-inout.cpp.

Unfortunately that is not the end of it. Inkscape used to be round trip stable for simple EMF files, that is, a line segment or a rectangle or something simple like that could be read in, written back out to EMF, and the end points in the EMF file did not change. That seems to have broken somewhere along the line, since the test file attached is off by 1 on Y on most coordinates when it is written back out to disk. (I use reademf from libuemf to dump the EMF files as text, and then use diff for comparison.) There may be other +/-1 coordinate issues, I have not looked very carefully, because there is an even bigger problem - the EMF file headers are wildly different. (This could explain all the +/-1 issues too.)

This is the original header from the test file (just the scale and coordinate values):

   rclBounds: {0,0,14030,9920}
   rclFrame: {0,0,29699,20999}
   szlDevice: {10205,13181}
   szlMillimeters: {216,279}
   szlMicrometers: {216000,279000}

This is what r12792 writes out

   rclBounds: {0,0,1051,743}
   rclFrame: {0,0,29699,20999}
    szlDevice: {1020472,1318110}
   szlMillimeters: {21600,27900}
   szlMicrometers: {21600000,27900000}

It is not OK to change values like that - the drawing went from being A4 to 100X A4!
I suspect that most of the +/-1 coordinate changes are due to the slightly different ratios
of 1051/743 and 14030/9920. (EMF uses integer coordinates.)

Presumably this is all related to the Viewport changes.