EMF import on Linux
Hello I know that there is working EMF import on Linux, and you can paste things from e.g. ChemDraw. Is it possible to make this code also work on Linux, using e.g. libemf, or would it require writing a completely new input filter?
Regards, Krzysztof
On 20-Aug-2013 08:06, Krzysztof Kosiński wrote:
I know that there is working EMF import on Linux, and you can paste things from e.g. ChemDraw. Is it possible to make this code also work on Linux, using e.g. libemf, or would it require writing a completely new input filter?
I am not quite sure what you are asking.
Branch lp988601 has working EMF (and WMF) import and export on Linux and I believe OS X, although I do not have a Mac to test that on. It uses libUEMF, which I wrote for this purpose.
http://sourceforge.net/projects/libuemf/
The pictures you will see on that page are screenshots of three test metafiles produced by libUEMF. These can be read into and then exported from Inkscape.
If you want this in trunk then lp988601 will need to be merged into trunk. Which it probably should be at this point. There is only one outstanding bug that I know of: in some EMF files written by Illustrator on OSX image objects render with the sign of y reversed, even though the rest of the diagram renders correctly. Also, apparently the version of the GPL used by libUEMF is somehow incompatible with that required by Inkscape. Since libUEMF is my code I can change the GPL version to whatever is needed.
EMF+ support is coming, at some point, I hope. The only program I have that emits EMF+ is PowerPoint, and it does so with some pretty dramatic limitations - for instance, it drops all text! Also while PowerPoint can "read" EMF+, it keeps it in a sort of container that it apparently passes to GDI+. I do not think any version of PowerPoint is capable of converting EMF+ records into native PowerPoint graphics objects. My hope is that EMF+ will handle import/export of gradients without having to emulate them through hundreds of little slices, but that may or may not pan out. (EMF, in theory supports gradients specifications too, but every program uses the emulation method instead of the native EMF command. So far I have been unable to get the EMF linear gradient record to work with any program, including Windows Preview, which may explain why none of them use it.)
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2013/8/20 mathog <mathog@...1176...>:
Branch lp988601 has working EMF (and WMF) import and export on Linux and I believe OS X, although I do not have a Mac to test that on. It uses libUEMF, which I wrote for this purpose.
What are the differences between this library and libEMF?
If you want this in trunk then lp988601 will need to be merged into trunk. Which it probably should be at this point. There is only one outstanding bug that I know of: in some EMF files written by Illustrator on OSX image objects render with the sign of y reversed, even though the rest of the diagram renders correctly.
Sounds like most of the work is already done :)
Is this code a suitable replacement for the native EMF extension we have on Windows?
Also, apparently the version of the GPL used by libUEMF is somehow incompatible with that required by Inkscape. Since libUEMF is my code I can change the GPL version to whatever is needed.
Inkscape seems to be GPLv2, but most files do not actually specify the version of the GPL. There is some GPLv3+-only code pulled from GIMP, which strictly speaking should be removed or rewritten, because v2 is incompatible with v3. We also have some dual licensed code (MPL + LGPL, MPL + GPL) and some "public domain" code, mainly from Sodipodi.
It's likely that we will find other useful things in GIMP in the future, so I think we should start an effort to relicense as much code as possible as GPLv2+ explicitly.
Regards, Krzysztof Kosiński
On 20-Aug-2013 16:44, Krzysztof Kosiński wrote:
2013/8/20 mathog <mathog@...1176...>:
Branch lp988601 has working EMF (and WMF) import and export on Linux and I believe OS X, although I do not have a Mac to test that on. It uses libUEMF, which I wrote for this purpose.
What are the differences between this library and libEMF?
Many. I initially started with libEMF, found that there were a lot of things it could not do, and then decided to write my own from scratch. The most important difference is that the Inkscape input/output code for EMF and WMF are already written for libUEMF.
If you want this in trunk then lp988601 will need to be merged into trunk. Which it probably should be at this point. There is only one outstanding bug that I know of: in some EMF files written by Illustrator on OSX image objects render with the sign of y reversed, even though the rest of the diagram renders correctly.
Sounds like most of the work is already done :)
Is this code a suitable replacement for the native EMF extension we have on Windows?
Try importing the test EMF and WMF files from libUEMF into the Windows version of trunk, then do the same with lp988601. The latter works much better. There are also output options in lp988601 to work around EMF import glitches in PowerPoint, which is the most common target. If you have access to a Windows machine there is an lp988601 binary here:
http://saf.bio.caltech.edu/pub/software/windows/inkscape_r11738_lp988601.zip
Also, apparently the version of the GPL used by libUEMF is somehow incompatible with that required by Inkscape. Since libUEMF is my code I can change the GPL version to whatever is needed.
Inkscape seems to be GPLv2, but most files do not actually specify the version of the GPL. There is some GPLv3+-only code pulled from GIMP, which strictly speaking should be removed or rewritten, because v2 is incompatible with v3. We also have some dual licensed code (MPL + LGPL, MPL + GPL) and some "public domain" code, mainly from Sodipodi.
libUEMF's GPL is "Version 2, June 1991". That seems to be the same on in the top layer of my Inkscape Windows build. I will have to dig back through my email to find the message somebody sent me about this issue.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2013/8/21 mathog <mathog@...1176...>:
Many. I initially started with libEMF, found that there were a lot of things it could not do, and then decided to write my own from scratch. The most important difference is that the Inkscape input/output code for EMF and WMF are already written for libUEMF.
That's great. I'll try it out.
libUEMF's GPL is "Version 2, June 1991". That seems to be the same on in the top layer of my Inkscape Windows build. I will have to dig back through my email to find the message somebody sent me about this issue.
The safe thing to do would be to relicense libUEMF as GPL v2+ (the specific wording is "GNU General Public License version 2 or, at your option, any later version"). This way we avoid any possible incompatibility with GPLv3-only code we might integrate from GIMP.
By the way, clause 9 of the GPLv2 says "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." So it seems like we can treat all code which has "released under GNU GPL" without a version given, i.e. the majority of our codebase, as GPL v1+ code.
Regards, Krzysztof
participants (2)
-
Krzysztof Kosiński -
mathog