emf import - solid round disappears

[Divaker]

While opening graphical plots with symbol "solid circle" the solid (filled) circles 0f all colors in the graph disappear. However the filled circles are visible in the preview of windows explorer. All other symbols even unfilled circles get imported into ink scape.

[jazzynico (jazzynico)]

Not reproduced on Windows XP, Inkscape 0.48.3.1 and trunk revision 11721, with filled and stroked, filled only and stroked only Inkscape arc paths and svg circles elements.

Could you please give your system and Inkscape version, and attach an example file so that we could investigate the issue?

[jazzynico (jazzynico)]

Related or duplicate: Bug #928224 "Save to EMF loses fill color (pattern fill)"
<https://bugs.launchpad.net/inkscape/+bug/928224>

[Divaker (divakerdurairaj)]

Using the release inkscape_r11668-201209182023 downloaded from OSS marketplace Inkscape/Entwicklerversionen.
Problem was in 48.2 also.
Attaching the sample image file "fillimage.emf". Filled circle visible in paint, irfanview, windows viwer, etc, but not in inkscape
Image was created as saved by R statistics version 2.15.1.

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape trunk revision 11738.

(sorry, I misread your initial report and thought it was a bug when exporting SVG files to EMF...).

[Alvin Penner (apenner)]

fix committed to rev 11743

the missing object was of type EMR_BITBLT. support for the PATCOPY operation was added. I apologize for breaking the code frost, but this was a simple change and hopefully will not introduce any problems.

imported svg file is attached

[ScislaC (scislac)]

Alvin: This is fine. We're in frost, not freeze. On a related note, would you be willing to test the omnibus emf fix branch? If we could verify that it's worthy to include in this release, out would be a huge win for emf support. Note: If there are crashes we can fix, that's all good.

[Alvin Penner (apenner)]

good to hear, I was not exactly sure what the status was.

>> On a related note, would you be willing to test the omnibus emf fix branch?
    unfortunately, I am a bit out of my depth when it comes to working with bzr and other branches. The only branch I have ever worked with is Inkscape, and even there it took me about three evenings of extreme frustration and numerous unsuccessful tries before I finally got it right.
     However, I do think that the situation has been recently summarized by ~suv, and if I understand it correctly, then this branch can be tested on any platform.

https://bugs.launchpad.net/inkscape/+bug/988601/comments/71

[su_v (suv-lp)]

> However, I do think that the situation has been recently summarized
> by ~suv, and if I understand it correctly, then this branch can be
> tested on any platform.

@Alvin - one of the major limitations of my tests is not having an EMF reference implementation available on OS X (I do not have MS Office installed, nor other software from Microsoft), and not being familiar with the file format itself. Basically my tests are limited to:
- does compilation succeed?
- does EMF import succeed without crashing inkscape?
- does the converted content show any major (noticeable or unexpected) flaws?
There is no easy way to verify the content of the EMF file itself (beyond what LO 3.6 for OS X supports) in order to compare it to the imported drawing as rendered on Inkscape's canvas. And I barely tested export to EMF (round-trip editing in Inkscape isn't the best method to verify the content of exported EMF files IMHO).

Would providing a diff of the EMF branch against current trunk be helpful for you to test a local build?

[Alvin Penner (apenner)]

- for each of the bug reports that were mentioned in your summary, I could provide the corresponding svg file that I get if I use the existing Windows emf import routine.
- or, I could also provide screenshots of what my standard emf viewer produces when I view these emf files. My normal viewer is Windows Picture and Fax Viewer.

would this be helpful in doing the evaluation? my problem is that I am currently working with the Inkscape code in trying to solve some printing bugs in Windows, so I am reluctant to try to run two projects at the same time on the same repository.

[Alvin Penner (apenner)]

- attached is the file fillexport_12472.svg, obtained by importing the file fillexport.emf into Windows XP, Inkscape rev 12472
 - it shows the red circles as expected

[Alvin Penner (apenner)]

- attached is the file fillexport_12496.svg, obtained by importing the file fillexport.emf into Windows XP, Inkscape rev 12496
 - the red circles are missing
 - re-opening the report due to a recent regression, most likely related to bzr rev 12488

[su_v (suv-lp)]

> - the red circles are missing

The red circles (actually constricted with rectangular slices) are not missing but use the wring fill color (solid white) - confirmed on OS X 10.7.5 with current trunk r12500.

@David - could you take a closer look what happens with those red dots on import?

[David Mathog (mathog)]

That EMF file uses EMR_BitBlt operations to construct the red blobs. The rop (raster operation) parameter for that record can have a huge number of values, not all of which are supported by Inkscape. When it hits one it cannot handle it will often fill with white, which is what is happening here. That was a mistake in this case, because this is one of the rop values that it can handle. The attached patch should fix this, at least for solid brushes.

[David Mathog (mathog)]

Oops, use this patch instead of the preceding. The previous one had another patch mixed in with it.

[David Mathog (mathog)]

Fix also included in patch for bug #1242927.

[su_v (suv-lp)]

'changes_2013_09_11b.patch' tested successfully with r12715 in OS X 10.7.5.

[su_v (suv-lp)]

Fix committed in r12721 (with the combined patch from bug #1242927).