Comment 9 for bug 197617

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?