File Export (Save-As) Tests for v0.47
Hi,
I've tested all the various file export options under the Save As command. Would the relavent experts for each type please review my comments/questions below? All test were done with Fedora 9 Linux and 0.46+svn updated within the past couple of days. Thanks.
Tav
General comment: I am having trouble getting Uniconvertor to work from within Inkscape. It won't process files with text (error message about not finding correct font). Files without text produce SVG output (Uniconvertor 1.1.4), independent of which file type is selected. Or error message about not finding SVG file in /tmp (Uniconvertor 1.1.3). I may have screwed something up but Uniconvertor does work when used via the command line (as in "uniconv test.svg test.plt") to directly convert SVG files to other types. Does anybody have it working from within Inkscape under Linux?
File Format:
.ai: Missing. Failed to load message in extension-errors.log (same error for DXF and ESPI). Works in v0.46.
.dfx: Generic AutoCAD export failed to load (see .ai). Plotter version updated. Question: what is the target if the "ROBO-Master output" option is not checked?
.emf: Does this still only work on Windows? Uses Uniconvertor.
.eps: This is using the same export dialog as PS. Is this appropriate given that the bounding box is handled differently? Speaking of which, while the specifications do say the bounding box should be the smallest rectangle that fully encloses the drawing, it is a common practice (and very useful in scientific work) to define the box to be bigger than the drawing. In reading the specification, it seems to me, that they were more concerned that the bounding box takes into account stroke width, etc. than in prohibiting bounding boxes larger than the drawing size. I think it should be left up to the user to decide this.
In the past "Canvas" has been used to refer to the entire drawing area while "Page" has been used to refer to the SVG specified drawing area. The dialogs and command line options should use "Page" wherever "Canvas" is used.
.fx I see small bugs in gradients and displaying a pattern.
.gpl OK.
.hpgl I see bugs in object transformations. Uniconvertor as of 1.1.4 also generates .hpgl files. Uniconvertor doesn't handle Inkscape circles.
.odg. Small translation problems.
.pdf. Generally OK. Bug in patterns made from a group of objects drawn off the page. Export dialog almost the same as for EPS and PS but small differences in wording and in order of options. Should match with EPS and PS dialog.
.plt Uses Uniconvertor. Tool tip etc. state it is AutoCAD plot file... but this is really, as far as I can tell, just HPGL.
.png Duplicates "Export Bitmap" menu entry but without handling Filtered objects.
.pov Broken in v0.47. Extra lines are added to object descriptions. Works in v0.46 (some paths missing).
.ps See EPS and PDF comments.
.sk1 Uses Uniconvertor.
.svg OK .svgz Broken in v0.47. Works in v0.46
.tex PSTricks OK, PSFrag needs work-around due to Cairo font subsetting.
.xcf OK
.wmf Uses Uniconvertor.
.xaml Objects translated wrong (could be xaml input problem).
.zip OK.
On Fri, Jul 31, 2009 at 5:49 PM, Tavmjong Bah wrote:
General comment: I am having trouble getting Uniconvertor to work from within Inkscape. It won't process files with text (error message about not finding correct font).
Is really isn't news that UC doesn't support text yet.
.emf: Does this still only work on Windows? Uses Uniconvertor.
Are you sure? EMF exporting used to be written in C++ AFAIK. And I'm sure I never wrote an extension to export to EMF via UC.
.hpgl I see bugs in object transformations. Uniconvertor as of 1.1.4 also generates .hpgl files. Uniconvertor doesn't handle Inkscape circles.
I'll tell Igor
.odg. Small translation problems.
What do you mean?
.plt Uses Uniconvertor. Tool tip etc. state it is AutoCAD plot file... but this is really, as far as I can tell, just HPGL.
PLT comes in all flavours. I picked the first one I saw at http://filext.com/file-extension/PLT
Feel free to fix
Alexandre
There is now a draft of an updated Export section of my book at:
http://tavmjong.free.fr/INKSCAPE/MANUAL_v15Draft/html/File-Export.html
You can see visually the results of outputting a test file to various file formats. The test file includes a gradient, a clipping path, a pattern fill, and a drop shadow filter applied to text.
Tav
On 31/7/09 15:49, Tavmjong Bah wrote:
I've tested all the various file export options under the Save As command. Would the relavent experts for each type please review my comments/questions below? All test were done with Fedora 9 Linux and 0.46+svn updated within the past couple of days. Thanks.
I am not a relevant extension expert but here are my findings anyway: (tested with Inkscape 0.46+devel r21939 on OS X 10.5.7)
.dfx: Generic AutoCAD export failed to load (see .ai).
1) missing helper_extension 'org.inkscape.output.ps' (related bug #407215 https://bugs.launchpad.net/inkscape/+bug/407215) proposed fix: in dxf_output.inx s/org.inkscape.output.ps/org.inkscape.print.ps.cairo/
the 'AutoCAD DXF (*.dxf)'output extension is loaded and creates DXF output if pstoedit is installed, though I cannot get pstoedit to create DXF files that can be re-imported in Inkscape (on OS X 10.5.7, pstoedit 3.45).
.ai: Missing. Failed to load message in extension-errors.log (same error for DXF and ESPI). Works in v0.46.
1) missing helper_extension 'org.inkscape.output.ps' proposed fix: in ai_output.inx and epsi_output.inx s/org.inkscape.output.ps/org.inkscape.print.ps.cairo/ 2) ai_output.inx: 'spawn'-error with <command reldir="path">gs -q -dNODISPLAY -dSAFER ps2ai.ps</command> (related bug #167472 https://bugs.launchpad.net/inkscape/+bug/167472) proposed quick fix: create a shell wrapper script like ps2eps.sh or ps2dxf.sh
.svgz Broken in v0.47. Works in v0.46
1) redundant extension: SVGZ input and output is now handled by internal extension. proposed fix: remove svgz_output.inx and svgz_input.inx 2) If not removed, svgz_output.inx needs to be fixed: 'spawn'-error with <command reldir="path">gzip -c</command> (related bug #167472 https://bugs.launchpad.net/inkscape/+bug/167472) proposed quick fix: create a shell wrapper script like ps2eps.sh or ps2dxf.sh
~suv
.dfx: Generic AutoCAD export failed to load (see .ai).
- missing helper_extension 'org.inkscape.output.ps'
(related bug #407215 https://bugs.launchpad.net/inkscape/+bug/407215) proposed fix: in dxf_output.inx s/org.inkscape.output.ps/org.inkscape.print.ps.cairo/
the 'AutoCAD DXF (*.dxf)'output extension is loaded and creates DXF output if pstoedit is installed, though I cannot get pstoedit to create DXF files that can be re-imported in Inkscape (on OS X 10.5.7, pstoedit 3.45).
This seems to work but it calls up the PostScript output dialog which I am not sure is the best. Qcad does read the output dxf OK. Tested on Fedora 11 with today's svn.
Tav
Tavmjong:
Cool. Thanks for checking these! I guess that a couple of the problem formats are mine:
.odg. Small translation problems.
ODG is a bitch to export. Why? Because the spec is written in Ancient Vague.
But also contributing to it is Inkscape's unfortunate Y-flip causing a mirror to rotations which mess other transforms up, too. Check out recent Reddit articles on SVD's. Since Inkscape stores a single transform for an object, and not a list or tree of the individual transforms from which it is composed, it is difficult to guess them from the single transform. So we use an SVD on the transform to try to pull it apart into the pieces. It's almost like a knapsack problem.
.pov Broken in v0.47. Extra lines are added to object descriptions. Works in v0.46 (some paths missing).
Easier to read, and more easily fixed. You have the output file for this? This is probably a quickie. I -LOVE- POVRay output of Inkscape thingies.
http://inkscape.modevia.com/win32_inkscape_org/pov/
bob
On Fri, 2009-07-31 at 13:10 -0500, Bob Jamison wrote:
Easier to read, and more easily fixed. You have the output file for this? This is probably a quickie. I -LOVE- POVRay output of Inkscape thingies.
I've found a quick way to demonstrate the problem. Take an empty drawing and using the Text Tool, write the letter 'I' in Vera Sans. Convert the I to a path. The path is a rectangle that has five nodes, (one node is on top of another). This is what is in the POV file:
/*################################################### ### PRISM: path3427 ###################################################*/ #declare path3427 = prism { linear_sweep bezier_spline 1.0, //top 0.0, //bottom 16 //nr points /* 0*/ <144.13281000, 154.97657000>, <144.13281000, 154.97657000>, <158.33594000, 154.97657000>, <158.33594000, 154.97657000>, /* 1*/ <158.33594000, 154.97657000>, <158.33594000, 154.97657000>, <158.33594000, 50.00001000>, <158.33594000, 50.00001000>, /* 2*/ <158.33594000, 50.00001000>, <158.33594000, 50.00001000>, <144.13281000, 50.00001000>, <144.13281000, 50.00001000>, /* 3*/ <144.13281000, 50.00001000>, <144.13281000, 50.00001000>, <144.13281000, 154.97657000>, <144.13281000, 154.97657000> /* 4*/ <144.13281000, 154.97657000>, <144.13281000, 154.97657000>, <144.13281000, 154.97657000>, <144.13281000, 154.97657000> }
Note that nr points is 16 but 20 are in the list. Note also that there is no comma after the 16th coordinate pair.
Tav
Ok,
I'll give it a look. There has been a change recently about how to walk the nodes of a curve. We need to make sure that we use Mental's API and not use the private fields explicitly. That caused a one-off problem in the past, so I suspect that this might have the same roots.
bob (ishmal)
On 7/31/2009 3:13 PM, Tavmjong Bah wrote:
On Fri, 2009-07-31 at 13:10 -0500, Bob Jamison wrote:
Easier to read, and more easily fixed. You have the output file for this? This is probably a quickie. I -LOVE- POVRay output of Inkscape thingies.
I've found a quick way to demonstrate the problem. Take an empty drawing and using the Text Tool, write the letter 'I' in Vera Sans. Convert the I to a path. The path is a rectangle that has five nodes, (one node is on top of another). This is what is in the POV file:
/*################################################### ### PRISM: path3427 ###################################################*/ #declare path3427 = prism { linear_sweep bezier_spline 1.0, //top 0.0, //bottom 16 //nr points /* 0*/<144.13281000, 154.97657000>,<144.13281000, 154.97657000>, <158.33594000, 154.97657000>,<158.33594000, 154.97657000>, /* 1*/<158.33594000, 154.97657000>,<158.33594000, 154.97657000>, <158.33594000, 50.00001000>,<158.33594000, 50.00001000>, /* 2*/<158.33594000, 50.00001000>,<158.33594000, 50.00001000>, <144.13281000, 50.00001000>,<144.13281000, 50.00001000>, /* 3*/<144.13281000, 50.00001000>,<144.13281000, 50.00001000>, <144.13281000, 154.97657000>,<144.13281000, 154.97657000> /* 4*/<144.13281000, 154.97657000>,<144.13281000, 154.97657000>, <144.13281000, 154.97657000>,<144.13281000, 154.97657000> }
Note that nr points is 16 but 20 are in the list. Note also that there is no comma after the 16th coordinate pair.
Tav
Bob,
Have you had a chance to took at this? I think POVRay export should be disabled if not fixed.
Tav
On Sat, 2009-08-01 at 01:38 -0500, Bob Jamison wrote:
Ok,
I'll give it a look. There has been a change recently about how to walk the nodes of a curve. We need to make sure that we use Mental's API and not use the private fields explicitly. That caused a one-off problem in the past, so I suspect that this might have the same roots.
bob (ishmal)
On 7/31/2009 3:13 PM, Tavmjong Bah wrote:
On Fri, 2009-07-31 at 13:10 -0500, Bob Jamison wrote:
Easier to read, and more easily fixed. You have the output file for this? This is probably a quickie. I -LOVE- POVRay output of Inkscape thingies.
I've found a quick way to demonstrate the problem. Take an empty drawing and using the Text Tool, write the letter 'I' in Vera Sans. Convert the I to a path. The path is a rectangle that has five nodes, (one node is on top of another). This is what is in the POV file:
/*################################################### ### PRISM: path3427 ###################################################*/ #declare path3427 = prism { linear_sweep bezier_spline 1.0, //top 0.0, //bottom 16 //nr points /* 0*/<144.13281000, 154.97657000>,<144.13281000, 154.97657000>, <158.33594000, 154.97657000>,<158.33594000, 154.97657000>, /* 1*/<158.33594000, 154.97657000>,<158.33594000, 154.97657000>, <158.33594000, 50.00001000>,<158.33594000, 50.00001000>, /* 2*/<158.33594000, 50.00001000>,<158.33594000, 50.00001000>, <144.13281000, 50.00001000>,<144.13281000, 50.00001000>, /* 3*/<144.13281000, 50.00001000>,<144.13281000, 50.00001000>, <144.13281000, 154.97657000>,<144.13281000, 154.97657000> /* 4*/<144.13281000, 154.97657000>,<144.13281000, 154.97657000>, <144.13281000, 154.97657000>,<144.13281000, 154.97657000> }
Note that nr points is 16 but 20 are in the list. Note also that there is no comma after the 16th coordinate pair.
Tav
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
.xaml Objects translated wrong (could be xaml input problem).
This one is about the only one that I have any experience with. Import and Export both make a mess of things. I created an issue on launchpad a month or so back concerning my findings. If there are any specific questions, I think my Dad is better qualified to answer them than me, as he's done most of the conversion from SVG to XAML for his WaterSums software's switch from Adobe SVG Viewer to Silverlight. While Inkscape's XAML export was a good start, it needed quite a bit of cleaning up and similar before it would work.
-- Chris Morgan <chris.morganiser@...400...>
I don't need a quote in my signature. It's hard enough surviving as it is without having to find a meaningful quote. Will you forgive me? Or don't you read this bit?
On Jul 31, 2009, at 5:43 PM, Chris Morgan wrote:
.xaml Objects translated wrong (could be xaml input problem). This one is about the only one that I have any experience with. Import and Export both make a mess of things.
The big problem here is lack of ability to reproduce.
There's no XAML for OS X, Linux, etc., so there's no way to test it.
On 31/7/09 15:49, Tavmjong Bah wrote:
General comment: I am having trouble getting Uniconvertor to work from within Inkscape. It won't process files with text (error message about not finding correct font). Files without text produce SVG output (Uniconvertor 1.1.4), independent of which file type is selected. Or error message about not finding SVG file in /tmp (Uniconvertor 1.1.3). I may have screwed something up but Uniconvertor does work when used via the command line (as in "uniconv test.svg test.plt") to directly convert SVG files to other types. Does anybody have it working from within Inkscape under Linux?
Comments in 'extensions/run_command.py' say: "Module for running SVG-generating commands in Inkscape extensions". Nevertheless it is called when 'uniconv-ext.py' is used in these output extensions:
plt_output.inx sk1_output.inx wmf_output.inx
This might explain why uniconv works on the command line (tested on OS X 10.5.7, python2.5, uniconverter 1.1.3, Inkscape r21939) but not when used by Inkscape with an export extension. I did not test files with text though - my test file just contained a simple shape and always resulted in a svg file when saved as *.plt, *.sk1 or *.wmf.
~suv
~suv wrote:
On 31/7/09 15:49, Tavmjong Bah wrote:
General comment: I am having trouble getting Uniconvertor to work from within Inkscape. It won't process files with text (error message about not finding correct font). Files without text produce SVG output (Uniconvertor 1.1.4), independent of which file type is selected. Or error message about not finding SVG file in /tmp (Uniconvertor 1.1.3). I may have screwed something up but Uniconvertor does work when used via the command line (as in "uniconv test.svg test.plt") to directly convert SVG files to other types. Does anybody have it working from within Inkscape under Linux?
Comments in 'extensions/run_command.py' say: "Module for running SVG-generating commands in Inkscape extensions". Nevertheless it is called when 'uniconv-ext.py' is used in these output extensions:
plt_output.inx sk1_output.inx wmf_output.inx
This might explain why uniconv works on the command line (tested on OS X 10.5.7, python2.5, uniconverter 1.1.3, Inkscape r21939) but not when used by Inkscape with an export extension. I did not test files with text though - my test file just contained a simple shape and always resulted in a svg file when saved as *.plt, *.sk1 or *.wmf.
Looking at the run_command.py source, its supposed to fail noisily. Run inkscape from a terminal once and see what output you find on the console. Or instead of running uniconv directly try formulating the command that inkscape would execute with run_command.py
Aaron Spike
On 2/8/09 05:25, Aaron Spike wrote:
~suv wrote:
On 31/7/09 15:49, Tavmjong Bah wrote:
General comment: I am having trouble getting Uniconvertor to work from within Inkscape. It won't process files with text (error message about not finding correct font). Files without text produce SVG output (Uniconvertor 1.1.4), independent of which file type is selected. Or error message about not finding SVG file in /tmp (Uniconvertor 1.1.3). I may have screwed something up but Uniconvertor does work when used via the command line (as in "uniconv test.svg test.plt") to directly convert SVG files to other types. Does anybody have it working from within Inkscape under Linux?
Comments in 'extensions/run_command.py' say: "Module for running SVG-generating commands in Inkscape extensions". Nevertheless it is called when 'uniconv-ext.py' is used in these output extensions:
plt_output.inx sk1_output.inx wmf_output.inx
This might explain why uniconv works on the command line (tested on OS X 10.5.7, python2.5, uniconverter 1.1.3, Inkscape r21939) but not when used by Inkscape with an export extension. I did not test files with text though - my test file just contained a simple shape and always resulted in a svg file when saved as *.plt, *.sk1 or *.wmf.
Looking at the run_command.py source, its supposed to fail noisily. Run inkscape from a terminal once and see what output you find on the console. Or instead of running uniconv directly try formulating the command that inkscape would execute with run_command.py
'run_command.py' doesn't fail - it just defaults to .svg as target file type - thus uniconv wrongly converts from 'any' to 'svg' when called from an output extension. It works as expected with input extensions.
I couldn't capture failure messages, the only I have is when uniconv failed because I hadn't yet installed py25-pil and py25-reportlab: It's an Inkscape extension failure message I got when saving 'spiral.svg' as 'spiral.sk1' (sK1 vector graphics files).
| UniConvertor failed: | PYTHONHOME: /Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/2.5/ | args: /var/folders/Bx/BxOeEE6mE3OWCL6lydnpAE+++TQ/-Tmp-/ink_ext_XXXXXX.svg5FEFYU /var/folders/Bx/BxOeEE6mE3OWCL6lydnpAE+++TQ/-Tmp-/tmpAfqhs6.svg | | Traceback (most recent call last): | File "<string>", line 1, in <module> | File "/Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/uniconvertor/__init__.py", line 76, in uniconv | from app.io import load | File "/Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/uniconvertor/app/__init__.py", line 69, in <module> | from conf.configurator import Configurator | File "/Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/uniconvertor/app/conf/configurator.py", line 11, in <module> | from app.events import connector | File "/Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/uniconvertor/app/__init__.py", line 125, in <module> | _import_PIL() | File "/Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/uniconvertor/app/__init__.py", line 114, in _import_PIL | warn.warn(warn.USER, "Can't import the Python Imaging Library") | NameError: global name 'warn' is not defined
the first two lines are debug 'echo' commands I added to the 'uniconv' shell script that then calls | /Volumes/blue/mp/bin/python -c "from uniconvertor import uniconv; uniconv();" "$@" As you can see the arguments to uniconv are two temp files, and the target file (for an export to *.sk1) is set to '.svg' instead of '.sk1'
OTOH I'm a python newbie and my python and uniconv installation used is not in the default system path - so any comments from linux/windows users with standard python installations would be helpful!
~suv
On 2/8/09 14:05, ~suv wrote:
'run_command.py' doesn't fail - it just defaults to .svg as target file type - thus uniconv wrongly converts from 'any' to 'svg' when called from an output extension. It works as expected with input extensions.
Finally found the bug about the 'run_command.py' and uniconverter export issue:
Bug #387946 in Inkscape: “UniConvertor called with wrong filename” https://bugs.launchpad.net/inkscape/+bug/387946
which is IMHO wrongly marked 'Invalid' - it is inkscapes faulty output extension, not a bug to be solved by UniConverter.
Any python guru willing to contribute a new 'run_output_command.py'?
~suv
De : ~suv <suv-sf@...58...> Any python guru willing to contribute a new 'run_output_command.py'?
I'm far from being a python guru, but I'v committed a new uniconv_output.py extension in rev.21971, based on run_command.py and uniconv-ext.py, and a py extension for each uniconverter export format we need. sk1, wmf and (if uniconv 1.1.4 is installed!) plt exports should now work.
-- Nicolas
On 31/7/09 15:49, Tavmjong Bah wrote:
.eps: This is using the same export dialog as PS.
(...)
In the past "Canvas" has been used to refer to the entire drawing area while "Page" has been used to refer to the SVG specified drawing area. The dialogs and command line options should use "Page" wherever "Canvas" is used.
Tav, could you document the renaming [1] of the command line option '--export-area-canvas' to '--export-area-page' in the release notes? I couldn't find any reference to this change except in your manual ;-)
The 'Command Line Options' manual page referenced in the Inkscape help menu (redirects to http://inkscape.modevia.com/inkscape-man.html) also still lists '--export-area-canvas' although Inkscape 0.47(pre) no longer accepts the option and fails to export with the message: "Invalid option --export-area-canvas" when called from a script or an extension. I don't know where the source for the man page is - AFAICS the (online) document already includes other changes in 0.47 (BTW - that document needs a date stamp or version information ;-).
thanks, ~suv
[1] http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=22017
Inkscape is being mentioned in the Fedora 12 release notes, including two photographs and a screenshot
http://fedoraproject.org/wiki/Fedora_12_one_page_release_notes
"Better than ever tablet support allows you to enjoy pressure-sensitive drawing out-of-the-box - no mucking with configuration files required!
* Fedora 12's updated version of Inkscape includes the new pen presets tool which lets you choose from a selection of pens to draw with (including 'dip pen,' 'brush,' 'wiggly,' and 'marker') and also gives you the ability to create and save your own pen styles.
"
Always nice to get free publicity! Well, not really for free because we all worked hard for it ;-)
Regards,
Diederik
participants (9)
-
Aaron Spike -
Alexandre Prokoudine -
Bob Jamison -
Chris Morgan -
Diederik van Lierop -
Jon A. Cruz -
Nicolas Dufour -
Tavmjong Bah -
~suv