win32 dependency on uniconv

What exactly does the ".cmd" mean ? Maybe we should change that permanently.

uniconv.cmd is the name of the script file that is in the C:\Python25\Scripts\ directory in a Windows installation.

uniconv is the name of a DOS shortcut that sometimes works and sometimes doesn't.

btw, I'll make sure to download a newer version in a day or so and try the Function Plotter again, thanks

    okay, that was not a very good answer. It appears that in Windows 2000 and later, the .cmd extension plays a role similar to the .bat extension in Windows 9x.
That is to say, the operating system will recognize the file type automatically and will execute it without the extension.
However, excluding the extension represents an unnecessary risk and does not serve any practical purpose.
For example, what if you were comparing two strings, one from inside the .inx file and one from a directory listing. Then I believe it would be safer to include the extension.

Uniconvertor is not included in the Windows bundle and even if it was, there does not seem to be sufficient scripting available now to invoke it properly.

Having program names without extensions in the .inx files serves the practical purpose that Inkscape on Windows can reuse the existing .inx files.

Inkscape searches for the given name and "name.exe" automatically. I guess you could add "name.bat", "name.com" and "name.cmd" as well.. Look at extension/dependency.cpp and search for ".exe".

As Marcin Floryan has said, the existing scripting doesn't suffice to use UniConvertor on Windows even if it's installed. In fact, the existing script is a Unix-style shell script. So the first step is to replace the shell script with a Python script. Here's such a script.

And here's the full patch. With this patch, the extensions that rely on UniConvertor will work on Windows provided UniConvertor has been installed in Inkscape's local copy of Python.

This patch does the following:

  * Removes the shell script cdr2svg.sh

  * Adds the Python script uniconv-ext.py

  * Changes seven .inx files to use uniconv-ext.py instead of cdr2svg.sh

  * Changes dependency.cpp to search for .cmd files as a last resort

  * Changes main.cpp to add the python Scripts subdirectory to the Windows PATH

I can't get uniconv 1.1.2 to install to the Inkscape directory using the installer. If you've got an existing python install, it reads the location straight from the registry and refuses to install elsewhere.

It is possible to extract the files from the installation directory and copy the files across, but it's messy. I've attached a file with what I think are the necessary files to be dropped into the Inkscape directory to install uniconv and PIL (python image library), which it depends upon. All are for python 2.5, which is what we're using.

Tested on build of trunk revision 18424. Patches apply cleanly to trunk, compiled then copied uniconvertor and PIL files into the python directory.

Seems to import wmf files exactly as 0.46 Win32 release.
Opens some cdr files with no problems. Several report "Uniconvertor failed:" in a dialogue. Still, better than 0.46.

When I check out the cdr files in a text editor, those that work have a "CDR7" descriptor in the header, but some that don't work have the same descriptor. I presume that means Corel Draw 7, but it doesn't help me establish a pattern of those that work and those that don't.

=== Some things to consider ===
* I think this needs to be tidied up a little before being applied to trunk. If uniconvertor is not installed in the python directory, it still has cdr available in the open dialogue, and reports the following error on trying to open a legit file - "UniConvertor failed: Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named uniconvertor". Is there some way we can stop uniconvertor supported formats appearing in the open dialogue if the uniconvertor python files aren't present?
* We also need to consider the 700Kb or so of extra files. We can't really make them required ATM, but there needs to be some way of easily integrating them if people want this functionality. Perhaps we need to talk to the python/uniconvertor people about changing their installer?
* Lastly, how does the new uniconv-ext.py change things for Linux?

In reply to Rygle:

CorelDRAW files:
UniConvertor doesn't handle CorelDRAW files earlier than version 7. CDR7 means version 7, so those ought to work. But unless the extension fails for files that UniConvertor can successfully convert on the command line, then this is not a problem with the extension.

UniConvertor-based formats appearing in the open dialog even though they can't be used:
This is because you still have a copy of UniConvertor in the path. So uniconv.cmd is found, and therefore the extensions load - but they need a local copy of UniConvertor to work. Including UniConvertor in the Windows Inkscape package would obviously solve this problem. Other fixes are no doubt possible (but trickier). However, it's unlikely that the user will have UniConvertor installed unless they installed it for use with Inkscape, so rather than find a way to ignore the non-local UniConvertor installation, it would be better to find a way to use it.

Linux:
My patch shouldn't change the situation on Linux in any significant way, but this obviously needs to be tested.

Thanks sas;

My bad about the open dialogue issue - I still had uniconvertor installed in my python directory. Uninstalled, and removed from Inkscape and it disappears from the open menu. Replaced uniconvertor and PIL in the Inkscape python directory (files three posts back) and everything works OK.

Can anyone test this on Linux or Mac?
That would be greatly appreciated. You will need to have uniconvertor and Python Image Library installed - sources available from the sk1project page - http://sk1project.org/modules.php?name=Products&product=uniconvertor - The sourceforge files for uniconvertor are slightly out of date. 1.1.1 vs. 1.1.2

do I just take this file (python-uniconverter.7z (696.4 KiB, application/octet-stream) and insert/copy it to the python directory in inkscape to get uniconvertor working in inkscape?

I have now applied this patch to the SVN trunk (development version), revision 18463.

So now you should now be able to compile the development version (see http://wiki.inkscape.org/wiki/index.php/Win32Port).
After compiling, drop the contents of http://launchpadlibrarian.net/13891678/python-uniconverter.7z into the inkscape folder.
That should put 7 new files in python\Scripts\ and two folders plus two files in the python\Lib\site-packages\ folder.

I'm toying with the idea of making this an optional download in the installer.
There seems to be a download function in NSIS - see http://nsis.sourceforge.net/NSISdl_plug-in.
Perhaps you could just tick a box to download the extra 700Kb. Could do the same with some other dependencies too, if that works.

Any thoughts?

Rygle, your commit doesn't seem to have added uniconv-ext.py. (Less critically, it doesn't seem to have deleted cdr2svg.sh either, but merely removed its contents.)

Milestoning for 0.46.1 as this is fixing an existing feature.

Added to 0.46 branch under /packaging/win32/patches/0.46.1 as this affects Windows only - Revision 18469.

Sas: Thanks for the heads up there. Don't know how that happened! Fixed now.

Fixed some problems with 0.46.1 patch relating to main.cpp - revision 18470
Fixed problems with trunk patch relating to uniconv.ext.py and cdr2svg.sh - revision 18471

Still thinking about the option to add uniconvertor as an optional download with the installer, as in my previous post;
> I'm toying with the idea of making this an optional download in the installer.
> There seems to be a download function in NSIS - see http://nsis.sourceforge.net/NSISdl_plug-in.
> Perhaps you could just tick a box to download the extra 700Kb. Could do the same with some other dependencies too, if that works.

Any thoughts?

Maybe its just me or my setup, but I think it was rev. 18470 that broke my build...

I got

make[4]: *** No rule to make target `cdr2svg.sh', needed by `all-am'. Stop.

But that was after doing a clean build (on Linux, i.e. ./autogen.sh, ./configure and make). Wasn't that clean enough, or are the makefiles outdated? I worked around this by restoring an old copy of cdr2svg.sh

I'm not very good at this make stuff :-(

It looks like share/extensions/Makefile.am needs to be updated. This file doesn't appear to be used in the build process on Windows, and nobody offered to test the patch on Linux, so this went unnoticed.

I'll try to post a patch for this later, if nobody else does.

Here's the patch for share/extensions/Makefile.am

I've just tested this patch, everything is OK now. I will commit it as soon as sourceforge is back online. Currently I cannot connect to sourceforge.net at all...

Thanks!

Patch already committed to trunk at revision 18480
Patch updated in 0.46 release branch at revision 18482 - I know this is a windows patch, so it's academic in a sense, but still best to do things cleanly in case it does get merged later.

running win32 nightly build from May 2
so when I try to use uniconv, I get no crash but I get the Python message :

UniConvertor failed: Traceback (most recent call last):

  File "<string>", line 1, in <module>

ImportError: No module named uniconvertor

I have uniconv 1.1.2 installed in the C:\python25\ directory as normal. So what do I need to do to get Inkscape to recognize it?

Alvin: You might like to read back over the comments previous to this, and you'll see that it needs to be installed in the Inkscape directory, and there is a 7z file that will do just that.

The file is here - http://launchpadlibrarian.net/13891678/python-uniconverter.7z

One remaining problem with UniConvertor-based extensions on Windows, is that they don't handle spaces in filenames or paths. This may have been why Rygle was getting UniConvertor failures on some .cdr files. This is a problem with UniConvertor itself, as it doesn't work on the command-line either.

Fixing UniConvertor to handle spaces is easy: just change the line

@python -c "import uniconvertor" "%1" "%2"

in uniconv.cmd to

@python -c "import uniconvertor" %1 %2

I've reported this on the UniConvertor forum, so hopefully it will be fixed in the next version of UniConvertor.

sorry, it was late and I was tired...
    I manually copied my directory of uniconvertor and PIL into the location C:\Program Files\Inkscape\python\Lib\site-packages and now it works great!

excellent, thanks for the help.

New package with updated uniconv.cmd and corrected spelling! Unzip straight into the Inkscape directory along with patched inkscape - latest dev versions patched.

Here's a new version of uniconv-ext.py. This version deals with two problems in the original version:

  1) In the original version I used the subprocess module, which is the recommended way of running subprocesses. However, this module is not included in Python 2.3, which we still need to support. So the new version uses a fallback method if the subprocess module isn't found.

  2) The original version only reports error messages from UniConvertor if they are sent to stderr. However, UniConvertor sometimes writes error messages to stdout instead. So, when UniConvertor fails, the new version reports anything written to stdout, as well as anything written to stderr.

I would be grateful if people could test this new version (particularly on Linux and OS X).

The version of uniconv-ext.py in my last post is superseded by a refactored version that I've posted in bug 227449.

uniconvertor is now part of the standard package