Clipboard does not contain scalable EMF format

After default copying Marvin 5.4.1.1. content under Windows 7, the generated Windows Metafile graphics type content of the Clipboard does NOT contain scalable vector graphics, but a bitmap image (jpeg, png?) instead. There's no valid EMF code present in the "Graphics (Windows Metadata)" type, as confirmed by an EMF code tool. This looks like a bug to me, especially since receiving applications expecting a clipboard category to contain what it says could crash.-  Hopefully this can be confirmed and fixed.

I also have Win7 and the OLE copy works fine for me. Do you have a desktop version of MarvinSketch? Is it the java or the .NET version?

Anyway, please open the attached file in MS Word, and double click on the structure. Can you edit it? If yes, then please change it, then close it. Is the picture still wrong?

Thanks for your quick response. Your Word Doc indeed looks fine. I am using your Web demo under https://www.chemaxon.com/marvin/sketch/index.php, where I draw a structure. Select All, followed by Edit->Copy provides the menioned non-vector image in Word. Do I need a local installation with an installed OLE server to get the correct EMF image into the clipboard?

Hi,

unfortunatelly Java does not support vectorized emf output, so we are using a native library, and it has to be registered on Windows, otherwise the Java vm can not load it. So yes, the fact is, you have to have an installed MarvinBeans to be able to get clean vectorized emf images from a Marvin Applet.

As a fallback Marvin uses the freehep library, which is buggy, and if there are visible characters on the image then the image is not vectorized, that was the main cause why we have choosen the native library solution.

Regards,
Istvan

Dear Istvan,

Thanks for your quick and competent answer. I have menawhile tested the Marvin installation on a VM and it works as expected.

Still, as a suggestion, you might think about not creating an EMF clipboard entry at all when actually no EMF data are available - just as in case of your web demo. This might be less confusing for clipboard consuming applications, which see an en EMF entry but can't read any data ... 

Hi,

actually, as far as i know, the freehep library creates an emf, and the created stream is a real emf, but unfortunatelly, if it contains literal characters painted by java then the emf is not vectorized, but rasterized, and therefore it has some ugly lines and could not be resized without loosing quality. This is why we left the usage of the freehep libraries as a fallback in Marvin, when OLE is not available.

Which application could not open the emf from the clipboard? As i tested it before, the clipboard format spy for example, but also Microsoft Word can see and open the emf data created by freehep.

Regards,
Istvan

Thanks for following this up. I am using the tool "Paste2XAML" http://www.wpf-graphics.com/Paste2Xaml.aspx (free evaluation version available there), which consumes the emf/wmf content of the clipboard directly (to convert it into WPF XAML code). It works very nicely with all sorts of emf/wmf generating sources, but does not recognize any metafile content for Marvin in case of no installed OLE server -  in the presence of the OLE server it works nicely again. Hopefully this helps...

Thanks for the info, i have checked the Paste2XAML website, and it tells the library is working with vector graphics formats. I assume when Marvin puts a rasterized emf into the clipboard, it simply can not imoprt it, and does not show the metafile data since it does not contain vector graphics data.

The emf format itself can contain also vectorized data, and bitmap data, so it can be valid, but it is possible that Paste2XAML can not work with it.

I understand that this can be confusing for the first sight as a user of such a software that works with vectorized image data, but since Office can work with the bitmap data, we can not get rid of the format in case when only the fallback to freehep is available, and OLE components does not.

Regards,
Istvan

I understand your comments. So the fallback position in the absence of an OLE server is to wrap a JPEG or PNG into EMF. At the same time, if I remember correctly, the marvin clipboard also contained native entries for JPEG and PNG, which themselves could easily be pasted into Office (and other) docs without any wrapping necessary. So the wrapped EMF entry seems not really a necessitiy for simple pasting, and might as well be skipped in this fallback situation, in favor of the native bitmap formats.

This could lead to a consistent clipboard EMF content: Once present in the clipboard, there would be no more doubt if the EMF is vectorized, or rasterized. It always would be vectorized, which probably also is what most people (and apps) expect it to be, if present. When no vector content is possible, then why not place the native JPEG or PNG into the Bitmap section of the clipboard?  I would consider this as the cleaner and more transparent fallback solution. In the absence of an OLE server, this should lead to identical look and  behavior as pasting a wrapped EMF.

The cause of the falback can be seen in the attached document. The first image was pasted in JPEG format, the second in PNG format, the third is an EMF with OLE installed, and the fourth is EMF without OLE installed.

All images has been resized to the page size from its default. The difference i think tells the cause why we use this fallback instead of just simply not support EMF when OLE is not installed.

I do not really tried to understand the difference in the handling of the scaling of different formats in Office or other tools, but as you can see, the EMF which was created without the .NET based EMF export can be scaled quite better then the JPEG and the PNG format. So we can not simply just drop EMF format when the .NET based EMF export is not available.

Regards,
Istvan

Hi Istvan,

Thanks for your example. I must admit that I have never seen the image quality of your  fourth example (non-server), I usually got the fuzzy look of your PNG example when pasting normally sized structures as EMF without server. Also, I have no explanation how a fixed sized embedded raster image possibly could look much better than a non-embedded one of the same size? That's close to a miracle ...

Anyway, I think we can close this thread now. The take home message is that clipboard consuming applications will have to check if the EMF section really contains the usually expected vector content or not.

Thanks a lot for for your time explaining the situation!