WMF image output size

[David Mathog]

The conversion to from 988601 to trunk, with the new scaling thrown in, uncovered (created?) a bug in the WMF image output code. The implementation in 988601 on reading a WMF file always had a unit scale in the transform matrix, but in the current trunk the same operation never, as far as I can tell, has a unit scale in the transform matrix. Amazingly this only seems to have broken WMF image output, where the images fall in the right place but was the wrong size. The attached patch adds transform scaling for the W and H and resolves the issue.

[David Mathog (mathog)]

(Apologies for the grammar errors in the preceding!)

[su_v (suv-lp)]

@David - could you attach a sample file and provide instructions on how to test the patch?

[David Mathog (mathog)]

Right, sorry.

When picsize.wmf is opened in inkscape (with or without the patch) you should see an image of a protein cartoon on a gray background, with a light blue "border". The border is the outer edge of a slightly larger rectangle underneath the image. To see the bug:

1. open picsize.wmf in inkscape
2. save as -> picsize2.wmf (the state of the option boxes should not matter)
3. open recent... -> select picsize2.wmf

Result:

No patch: the image will have changed size, probably shrunk, revealing a much larger blue area
Patched: image will be the same size, so picsize2.wmf will look like picsize.wmf

Oh rats, I just found what is probably a related problem. WMF input is not scaling the drawing properly. The document created is the right size, but all the components of the image are too small and sit up in one corner of the drawing. This is only happening for WMF, EMF input is good.

Please wait for a patch for the 2nd part of this problem before proceeding with testing.

[David Mathog (mathog)]

Attached patch addresses drawing scaling issue mentioned in the preceding post. It must be applied in addition to the other patch, earlier in this bug report.

The problem was that in WMF files that did not have a ViewPort record, and used different sizes in WindowExt and the header, the graphics were not scaled to the full drawing size. The test file I generally use did not trigger this bug because the sizes in WindowExt and the header were the same. The test file picsize.wmf, made by PowerPoint, did trigger it.

Before this patch is applied when the picsize.wmf test file (above) is opened it will be too small by a factor of about 6.4, and will be located in the upper left corner of the drawing.

After this patch is applied when the picsize.wmf test file is opened it will fill the entire drawing surface.

[su_v (suv-lp)]

Both reported issues (incorrect size of the embedded bitmap image on round-trip editing as WMF file, incorrect scale of drawing content on import) reproduced with trunk (r12721) on OS X 10.7.5, and confirmed fixed with both patches applied.

Have you been able to test both patches on Windows and Linux?

[David Mathog (mathog)]

Already tested on both Windows and Linux.

[su_v (suv-lp)]

Patches committed in r12725 and r12726. Thx!

[David Mathog (mathog)]

There are some WMF files in circulation where the W,H for the drawing from the Placeable header are specified swapped in the SETWINDOWEXT record. This results in a strange transform that does odd things to the drawing. The attached file is in example of this.

[David Mathog (mathog)]

This patch resolves the issue described in the previous post. It detects cases where it looks like W,H have been swapped in the SETWINDOWEXT record, and swaps them back. The test is pretty tight so it should not affect any intended scaling, unless by bad luck that scaling happens to correspond to this sort of swap.

This change is being entered here because it involves the same section of code which was previously modified by the earlier patch for this bug.. After the patch is applied the arcs in the test file all fall within the window, before that they are stretched horizontally and extend to the right of the drawing.

The patch also includes some code cleanup that was part of earlier EMF patches, but which for some reason or other never made it into trunk.

Already tested on Linux and Windows. If it works on Mac please commit. Thanks.

[su_v (suv-lp)]

Patch 'changes_2014_03_05a_wmfonly.patch' tested successfully with r13118 on OS X 10.7.5, committed in r13119.

[su_v (suv-lp)]

JFYI - compiler warning (trunk r13125, Ubuntu 13.10, gcc 4.8.1):

../../trunk/src/extension/internal/wmf-inout.cpp: In static member function ‘static uint32_t Inkscape::Extension::Internal::Wmf::add_dib_image(Inkscape::Extension::Internal::PWMF_CALLBACK_DATA, const char*, uint32_t)’:
../../trunk/src/extension/internal/wmf-inout.cpp:484:31: warning: ‘dibparams’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     if(dibparams == U_BI_JPEG || dibparams==U_BI_PNG){ // image was binary png or jpg in source file
                               ^

[David Mathog (mathog)]

Aargh, some of the changes from the patch for bug #1248753 are also missing. Here they are again, as applied to the current release. That should clear the compiler warnings (and it makes the code a bit neater).

[su_v (suv-lp)]

@David - wrt bug #1248753 - AFAICT the cleanup patch you attached there has not yet been committed (see last comment). Maybe it would be better to hold back 'changes_2014_03_07a_wmfonly.patch' for now and instead try to close bug #1248753?

[David Mathog (mathog)]

It looks like most of that patch eventually went in through other EMF/WMF patches. That probably explains why not all of it made it in

It would be fine to move 'changes_2014_03_07a_wmfonly.patch' to bug #1248753 and apply it there. It seems to be the last piece of that code cleanup that has not yet made it into trunk.