Insert from Clipboard Graphpad Prism 6 Vector graphic - not working

Please add information about OS/platform to the bug description, thank you.

If Windows, please include also information about the installer used for Inkscape 0.91: 32bit or 64bit?

Closing due to lack of feedback.

Windows 7 what else.

It is the 64bit Version.

Still not fixed till today. Ok, i am undersanding no money no work.

could you provide a sample svg file containing a pasted emf image, produced using Inkscape 0.48?

the reason I am asking is because I do not have any software capable of copying an emf file to clipboard. I did this experiment using Inkscape 0.48 and using Microsoft Paint to copy an emf image to clipboard, but what I got in Inkscape was a png image, not emf, and it was linked, not embedded.

Dear Alvin,
in Prism 6 I can choose the wmf old and wmf+ emf old and emf+ format. The only format I can use in inkscape 48.5 is the emf+
You see on the svg File which Version is this made from. Both files I made at home with a fresh Win10Pro x64 but it doesn´t matter,
because on Win7Pro x64 its the same. It look like the new inkscape 91 didn´t know the size of the header in the emf+ format.
I only used the emf+ because its the only way which works on inkscape 48.5.

https://uni-duisburg-essen.sciebo.de/index.php/s/VsNkgxqIyLP4i61

This is a perma link of my University Cloud System. If you have any questions please let me know. I try to do it for you, as described.

Thx for care!

Siegfried

thanks for the links. It appears that the image produced by Inkscape 0.91 does actually contain some useful information, but there is a serious scaling/offset problem. The image contains some very large offsets such as the attached path:
       d="m -140696.05,-137466.07 0,13.04 9.52,0 0,-13.04 -9.52,0 z".
 Attached is a trial version obtained by selecting the image and manually dragging it back onto the page.

<offtopic>are you able to save these images as an emf, emf+, file? It might simplify the debugging process if we had a file to work with, since we probably will not have access to Prism 6</offtopic>

Re 10:

Prism 6 few people are going to have, but it may be that the copy command from PowerPoint keeps the graphics commands in EMF. Could the OP test if pasting that into Inkscape is a problem?

Re 1:

The EMF/WMF import/export code I maintain does not support EMF+ at all in Inkscape. The functions exist in libUEMF, but Inkscape never calls them. If the contents of the clipboard really are EMF+ and they are getting into Inkscape, then it must be through a call out to native Windows libraries somewhere in devlibs.

I have never heard of WMF+ before. Unless it differs in only tiny ways from WMF, it would not be supported by my code either.

EMF+ files are an extension of EMF where comments are pressed into service to carry an entirely new set of information. "EMF" files usually contain mixes of the old EMF and the new EMF+ descriptions of the same document. These are not always complete, PowerPoint, for instance, just drops all the text out of the EMF+ description. (Really, hard to believe, but true.) However, even the purest EMF+ file still contains a couple of the old EMF record types at the ends. Some of the size values in the first EMF record might even be garbage, because the real values would come later in the EMF+ records, which do not use anything from the old EMF. If a file like this hit Inkscape it would most likely not crash, just insert nothing.

In any case, we need this data as a file to see what is going on. If the OP wants to poke around in that file, get libUEMF (sourceforge), build it, and run the "reademf" tool against the problem EMF(+) file. It will show both the EMF and EMF+ records, and usually in a case like this, it is obvious where the issue is. (It might work best with a simpler test file though!)
Otherwise, post the EMF(+) file and I will look at it.

@Alvin

As wished the two demo files emf and emf+ on the same folder.
https://uni-duisburg-essen.sciebo.de/index.php/s/VsNkgxqIyLP4i61
These Files i dropped to inkscape 48.5 and both worked.
But not on inkscape 91, here noting will displayed. I already used the x64 Version these should not be a difference to Version 91 x86.
Thanks for the modified 91 svg file, yes not its readable the gap of the text position loss its a little pitty.

@David

yes you´re right there is no wmf+ sorry its my mistake.
I uploaded the files with drag and drop of these files to Powerpoint 2013. You find these result-files in the upper folder too.
I did an export additionaly to wmf and eps ( eps = however not supported by inkscape). Wmf worked in inkscape 48.5 but not in Version 91 x64. By the way, the wmf export has a better Ungroup result in Powerpoint.

If you need some testfiles more or special settings please let me know.

Thx in advanced for care again.
Siegfried

@Siegfried - thanks for the link.
I have downloaded the two emf files and also the wmf file from the site: https://uni-duisburg-essen.sciebo.de/index.php/s/VsNkgxqIyLP4i61
All three of these files appear to load correctly into Inkscape 0.91. I am not able to detect any obvious differences between them, certainly nothing like the unusual offsets seen in the Paste operation. So I am not sure what the problem is with the paste.

In any event, I should bow out of this conversation, since David is the expert on emf import.

just some clarification: I'm using Windows 7 (32 bit), Inkscape 0.91 r13725 (Jan 30 2015)
 - so to double-check: when you load these emf files into Inkscape using File->Load, do they also behave badly? If so, could you attach that svg file as well?

The EMF+ example found a bug in the previously untested (because unseen) EmfPlusDrawDriverString record handling.
That goes somewhere way down on the todo list.

However the EMF demo when run on my linux test system through reademf had problems with both EXTSELECTCLIPRGN records:

U_EMR_EXTSELECTCLIPRGN record: 205 type:75 offset: 4668 rsize: 16 crc32:A3D88BDC
WARNING: Corrupt record. Emitting fields above the problem.
   record corruption HERE

U_EMR_EXTSELECTCLIPRGN record: 220 type:75 offset: 5216 rsize: 16 crc32:A3D88BDC
WARNING: Corrupt record. Emitting fields above the problem.
   record corruption HERE

Now I need to find out why. That type of record has been tested, but it was added fairly recently, so perhaps this example explores some code path which needs work.

Found it. EXTSELECTCLIPRGN has a "reset" mode where the points that normally contain the clip region are ignored. The records in the problem "Demo" file were using that, which I had not encountered before, instead of the more common RESTOREDC. The sanity check on this form of the record failed, because it needed a special case for "ignore the points", and that caused the file load to abort.

A patch to fix this was committed as revision 14617. The patch also includes a fix for the EmfPlusDrawDriverString problem, even though those routines are not yet used by Inkscape.

@Alvin

I added the svg files with dropped emf and emf+ and saved them to the known folder.
When you open the files there seems to be nothing. But there are already inserted. But not displayed. Only in Version 48.5 these things working.

@David

Thanks for finding the needle and figure out the problem.

When the Problem will be fixed your development will bring inkscape more near as an real alternative to Corel Draw and Adobe Illustrator.

Thx for care to all.

Best wishes
Siegfried

thanks for the files. I have loaded the two files:

inserted emf file in inkscape 91 - without visible result.svg
 inserted emf+ file in inkscape 91 - without visible result.svg

into :
 Windows XP, Inkscape 0.91+devel r14624 (Jan 29 2016)

In both cases the results are not visible on the screen.
 In both cases the problem is exactly the same, namely a major offset in the origin.
 Attached is the transform element that is applied to the main group:

emf file : transform="matrix(3.5433068,0,0,3.5433071,-324466.07,-497858.76)">
 emf+ file : transform="matrix(3.5433068,0,0,3.5433071,-325646.07,-497807.33)">

unfortunately that leaves us in a very difficult position because we are not able to confirm whether the commit of rev 14617 has changed the situation or not. The only way to confirm whether anything has changed is to do the paste operation in trunk which we cannot do because we do not have access to Prism 6.

Alvin, do the automatic builds leave a windows version of trunk somewhere so that Siegfried could download trunk that way?

unfortunately, I don't really know, I have pretty much lost track of where things are ever since the upgrade to the new website.
I have two links that used to work. I am not aware of any links on the Inkscape website.

http://ww1.oss-marketplace.com/
https://onedrive.live.com/?id=9706D11303FA52A%21217&cid=09706D11303FA52A

however the first link is dead and the second link is fairly old, rev 13487 or so.

OK, I will ask on the developer's list.

Siegfried, please try this version, recently uploaded by Edward Braun:

https://drive.google.com/folderview?id=0B3IZiqBj23X1eG5JeVBaSFFTanM&usp=drive_web&tid=0B3IZiqBj23X1My1CaUE2NjlpVms#list

@David

Hi David, I documented in the folder the result: https://uni-duisburg-essen.sciebo.de/index.php/s/VsNkgxqIyLP4i61
Every File has the suffix @David.
Bad news, both trunk did not fixed the drag and drop of emf File. The Copy and Paste of emf+ from Prism was insert something in Version 630. The trunk is that new, that the developer not changed the branding.

Please let me know if you want some another beta tests.

Thanks for care.

Siegfried

I am having a very hard time following what you are doing and understanding how things are failing. We need to work from a well defined and SIMPLE test case. Your goal is to create a test Prism drawing that cannot be copy/pasted into Inkscape, but which is as simple as possible.

Please do the following:

1. Verify that the simplest possible drawing can be copy/pasted into Inkscape trunk from Prism. Try a drawing consisting of a single solid colored rectangle.

If that does NOT work, then we start with that drawing. If it can be copy/pasted successfully then we need to figure out what element(s) in your current drawing are toxic.

2. Starting with a clean Prism drawing, add elements one at a time, or a few at a time, from your current test drawing which fails, and try copy/paste into Inkscape until the new drawing fails.

Once it fails

3. Try removing earlier elements, at each step, attempt a copy and paste. Continue in this manner until removing any remaining element allows the drawing to be copy/pasted into Inkscape.

4. Once you have it narrowed down to the simplest possible copy/paste failing case post a screen shot of that in Prism (call it "SimpleTestCase1_prism.png"), so we know what it is supposed to look like.

5. Save this drawing from Prism as an EMF file "SimpleTestCase1_prism.emf".

6. Try loading that EMF file by opening it from inside an already running copy of Inkscape (the most recent trunk you have). Tell us if it loaded or not. If it loads, but incorrectly, post the resulting SVG file as "SimpleTestCase1_loaded.svg".

7. If a failed copy/paste gets far enough to produce an SVG, please save that as "SimpleTestCase1_pasted.svg".

If there is a difference between the loaded and the pasted svg's that we might not notice, please point it out to us.

@david

Hi David,
sorry for my delay, some privat things to fix for a movement of my cousin.
You got some files to analyse in the folder. They have all your name.

Thx
Please let me know what i have to do further.
Cu
Siegfried

Got them, no idea what is wrong on your system because the EMF file in that group loads without issue into Inkscape on my my linux machine.

Please use SHORTER NAMES with NO SPACES! Include a separate text file which documents what each of the files is.

Anyway, the file "@david - import emf+ file in trunk ver14657.svg" has at least the issue that the first transform has a crazy large offset in it. If you edit the last two values in the SVG file to 0,0 at least the pieces land on/near the page. That makes most of the drawing look OK, but the text is in the wrong places.

This is TOO COMPLICATED a test file!!! The EMF file has over 500 records in it. Is this really the smallest file that has a problem (see post 27 above)? If you edit the Prism file leaving ONLY the red square and the "serum starved" text, and save that as an EMF, does it also have problems when Inkscape on your system opens it? That will be no more than half a dozen EMF records and will be far easier to work with.

Tried to upgrade to the current source code and the build failed, some problem with the updated make files I think, will get back to that tomorrow.

What happens when you import the attached file "small_test.emf"?

If and when you gain access to a windows trunk version release 14660 or greater it will have EMF/WMF end user debugging enabled. I have asked Eduard Braun to assist with this, but have no idea when he can get to it. In any case, once you have access to that revision do the following (I think, I'm guessing on part of the syntax) to make debugging files.

Let's say you have "problem.emf" which is crashing, or doing something incorrectly. From a windows command line:

set INKSCAPE_DBG_EMF=records
inkscape problem.emf > problem_records.txt

and exit immediately after it opens. Then

set INKSCAPE_DBG_EMF=COMMENTFINAL
inkscape problem.emf > problem_svg_generated.txt

and again exit immediately. Then post here:

problem.emf
problem_records.txt
problem_svg_generated.txt

This information should help me figure out what the problem is. This assumes that getenv() works the same way on Windows that it does on Linux, so that the changes in that revision will work there too.

@david refer to 2016-02-18

I tested the Files on ZORIN Linux Inkscape too. The "crazy large offset" is still there in both worlds (Windows too).
Compared to inkscape 48.5 WINx86 where this issue working perfect is interesting.

I compared the svg files with Notepad2 and I can found small changes in the interpreting of the "offset" refering to the realocation of the text but i didn´t find the option to reset the landing point to 0,0. I have no clue about programming only a half year of JAVA, try and error. But long time ago.

@david last post:

I will wait for the Trunk 660 still not there. Checked 2016-02-19 7:02 AM CET.

Then i will try to open inkscape via command line tool in the new trunk folder as described.

I added the import file as a screenshot to see whats happend in trunk 14657, the same realocation problems. Not that big offset but anyway something happend.

Thx for care...
Siegfried

Eduard compiled the latest one for Windows and left it in the same
place. He did not test the changes I made, but they should work within
an MS-DOS (CMD) shell if you use
the syntax shown in post 30. The only thing you probably need to change
is to provide an explicit path to wherever the binary is, if it is not
in the same directory as your work files.

Something like this (in DOS)

#move to C:\temp, for instance, wherever you are working, with "cd"
commands

set INKSCAPE_DBG_EMF=COMMENTFINAL
"C:\Program Files\Trunk\your_path\inkscape" problem.emf >
problem_svg_generated.txt

Regards,

David Mathog
<email address hidden>
Manager, Sequence Analysis Facility, Biology Division, Caltech