UniConvertor called with wrong filename

The uniconv-ext.py uses run_command.py.

The run_command.py is only for creating SVG files - not for converting from SVG, that's why it goes wrong.

I'll look further into it later.

As UniConvertor ver. 1.1.4 requires Python 2.6, I have made a modification to "uniconv-ext.py", that works with both old and new versions.
At the moment, the modification is working on Windows, if you have another OS, please modify and test.

In particular, modify the cmd string for other OS to match the string given here:
cmd = 'python -c "from uniconvertor import uniconv;uniconv()"'

As mentioned in earlier post, this works for input only. On Windows, I have tested with PLT and CDR input.
Modified "uniconv-ext.py" for Windows file attached.

I have tested a large part of the extensions with Python 2.6 on Windows, but more testing should possibly be done.

I am working further on making the PLT output working, but it will take a little more time to get finished.

attached is a comparison of uniconvertor output to the HPGL output. uniconvertor 1.1.4 was run off-line by itself to do this.
The original svg file is attached. It consists of a single line with coordinates :
svg : d="M 100,200 200,150"

The HPGL output is :
IN;SP1;PU100.0,200.0;PD200.0,150.0;

The uniconvertor PLT output is :
IN;PU1411,12028;PD2822,12733;PU;

Note that the HPGL output is identical to the svg scale, in pixels.
The uniconvertor output has been inverted in the y-axis relative to the svg output. The conversion factor to produce the uniconvertor output from svg is 50*25.4/90, which is consistent with the notion that the uniconvertor PLT scale is in units of 0.02 mm. It is not clear where this scale factor comes from.

When converting to PLT and back to SVG with uniconvertor, I saw a scaling error factor 1.25.
This corresponds to using scaling factor 1016/72, when converting from SVG to PLT and 1016/90, when converting from PLT to SVG.
That this is the case is confirmed by comparison with HPGL output (which is not scaled at all).

There should be an option for mirroring output or not, and I think the default should be no mirroring (according to hp's specification for plotter type device),

When using Windows fonts, uniconvertor cannot find the fonts and will use another font instead. It also cannot find this font.
Uniconvertor uses the Python installation under Windows, not the local installation under Inkscape.
Error output attached.

I will not have much time left the next two month, so I will unassign myself from this bug report.

I forgot to mention, that even when text has been converted to path, the font attributes are still present in the style attribute, causing Uniconvertor to fail.

for future development, I suspect that it would probably be easier to upgrade the existing HPGL output routine to be more flexible, rather than trying to get this particular uniconvertor PLT routine to work, just my 2 cents worth...

Hi all! Thank you for reported problems concerning UniConvertor.
Here is some explanations:

>UniConvertor ver. 1.1.4 requires Python 2.6

UniConvertor can be compiled as for Python 2.6 and for 2.5 version. If Inkscape for win32 requires version for Python 2.5, please let us to know and we will provide this build.

>I saw a scaling error factor 1.25
>...uniconvertor cannot find the fonts...

This scaling issue has been fixed in UniConvertor trunk. Next 1.1.5 version will contains this fix. Also this version will work correctly with fonts and embedded bitmaps because we will include Freetype and LittleCMS bindings in distribution. Another planned valuable feature is py2exe build for UniConvertor win32 version. This should simplify distribution issue.

If you need help with UniConvertor please don't hesitate contact us on our project site (http://sk1project.org)

Since it's a UC bug, I'm marking the report as invalid. Thanks for reporting anyway :)

reopening, see inkscape-devel mailing list:

  File Export (Save-As) Tests for v0.47
  <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/30852>

I'm currently working on a new SVG to PLT, SK1 and WMF extension, based on uniconv-ext.py and run_command.py.

Concerning Python, why not switching to 2.6 on win32 builds? Lots of Linux distros already use Python 2.6. And UniConvertor 1.1.4 would be easier to install.

As long as you don't shut out osx ;) - current OS X still defaults to python 2.5.

OTOH I didn't find yet an easy installer for UniConverter on OS X - so the number of mac inkscape users who have uniconv installed might be much smaller than on Windows, but those who manage the command line install are probably more likely to install python 2.6 as well.

But the MacPython webpage still warns about possible conflicts between MacPython (2.6.2) installations and Mac OS X development tools (Python 2.5.1), so I would not yet count on python 2.6 on OS X.

We can also keep on working with 2.5 and ask Igor for a specific UniConvertor version.
Probably the wisest thing to do for now...

First test version committed rev. 21971.
Tested on Ubuntu 9.04 only.
I plan to proof, clean and test more tomorrow.

Thank you for solving this issue!

Inkscape 0.46+devel r21973 on OS X 10.5.7
UniConverter 1.1.3 with Python 2.5.1

export to *.sk1 and *.wmf no longer produces svg files -> fixed
can't test *.plt, need to port install py-26 first ;-)

@Igor: any plans for a MacPorts UniConverter port?

@~suv: Unfortunately we have no Apple hardware to provide Mac binaries. But UniConvertor can be compiled under MacOS the same manner like under Linux:

python setup.py build

python setup.py install

So you can include UniConvertor binary package into Inkscape distribution without any problems. Also you can use Python 2.5 and even Python 2.4 to compile UniConvertor binaries.

@Igor: MacPorts <http://www.macports.org/> is not a binary distribution system - like the FreeBSD Ports system it provides 'Portfiles' to build and install software on OS X systems and manage all dependencies for the selected software packages.

It allows to install into a separate tree - independent from the operating system. On OS X it is the base of the build environment for Inkscape (installing all GTK+, GNOME, X11 and other libraries needed). Besides the basic Python 2.5 and 2.6 ports there are countless python modules available benefiting from the MacPorts port mechansim (easy to install, update, upgrade or uninstall).

As an example I used it to install both required modules 'PIL' and 'ReportLab' for 'UniConvertor 1.1.3'.
Here are the links to their portfiles for Python 2.5:
  PIL <http://trac.macports.org/browser/trunk/dports/python/py25-pil/Portfile>
  ReportLab <http://trac.macports.org/browser/trunk/dports/python/py25-reportlab/Portfile>
You don't need Mac hardware to provide/maintain these ports ;-)

~suv