On 24 nov. 05, at 19:34, Bryce Harrington wrote:
On Thu, Nov 24, 2005 at 12:22:54PM +0100, jiho wrote:
[snip]
1/ The bigger problem is probably that few scientific softwares produce plots in SVG (damn, why is that?!). They all export EPS and
This is probably because SVG is a fairly new standard, and not widely adopted yet. You could probably make a long term impact here quite easily by taking an afternoon and writing to each of these companies with a request to support SVG in a future version of their software.
All the one I use are open source projects so they all have nice mailing lists and request feature facilities. This request is already done. But unfortunately they evolve a "little" slower than Inkscape ;-)
the first problem is to get these EPS in Inkscape. At least on OS X, EPS import does not work because Inkscape cannot find pstoedit or ghostscript, though they are installed from fink. Where does inkscape takes the PATH from? With my fink tree added to the PATH in .bashrc or .profile in my home (.profile is the default) it does not work. With uberconverter on the way I hope all this will be solved in a not- so-far-away future.
The path stuff in Inkscape is a bit limited; it works sufficiently on linux but I'd have been surprised if it worked out of the box on OSX. I think it still doesn't work reliably on Windows.
If you'd like to dig into this problem, here are a couple starting points.
First, there is a directory where config files for the extensions are located. On Linux this is in /usr/share/inkscape/extensions. These don't include path info but you may find it illuminating to review their settings and so forth.
Second, the paths are set in the src/path-prefix.h file. There is a section for ENABLE_OSX_APP_LOCATIONS. If I were you, my first step would be to verify that this define is actually set correctly on your machine. If it is, then also doublecheck that the paths match up to what you have on your system.
Third, there is a little bit of path manipulation going on in src/main.cpp in the main() routine. See line 610 for instance, where the current homedir is set for WIN32. I don't see any OSX specific hacks there though.
I'll try to look at those. Thanks for the starting points.
2/ After some pstoedit command line stuff a second problem arises: all files converted this way are displayed fine in Inkscape but behave strangely: any new element is enormous, no dashes can be applied to existing strokes... This is all related to some strange transformation matrices. And some magic (from my point of view at least): copy-pasting all elements in a new document solves everything. Is there a reason why what is done when copying and pasting should not be done when opening the file?
You might browse through the XML editor or the SVG source for the original doc and see what parameters didn't get carried along in the cut-and-paste. Possibly the conversion process tweaked that parameter, leading to those problems.
I posted a diff between the faulty and the copy-pasted file (which behaves correctly). It's in the wiki page: http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair and there are a lot of changes between the two files. Many are attributes additions (inkscape:r_cx and cy) but there are a few transform which changed as in there:
< transform="translate(82.415,255.15) scale(1,-1) scale(1) " < style="font-family:'Helvetica',sans-serif;font-size: 9.4488;stroke:none;fill:black;" < id="text522">0</text> ---
transform="matrix(1,0,0,-1,82.415,255.15)" style="font-size:9.44880009px;fill:#000000;stroke:none;font-
family:"Helvetica", sans-serif"
id="text522" inkscape:r_cx="true" inkscape:r_cy="true">0</text>
in addition there is a scale parameter at the beginning of the file which looks weird and is not preserved by copy-paste in the new document:
< transform="translate(-0.03125,1.1875) scale(1,-1) scale (0.0017361) " < xml:space="preserve" < style="stroke:black;stroke-linecap:butt;stroke- linejoin:miter;stroke-miterlimit:10.433;stroke-dasharray:none;stroke- dashoffset:0;stroke-opacity:1;fill:none;fill-rule:even-odd;fill- opacity:1;font-style:normal;font-variant:normal;font- weight:normal;font-stretch:normal;font-size-adjust:none;letter- spacing:normal;word-spacing:normal;text-anchor:start;" < id="g10"> ---
inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1"> <rect x="-346.13388" y="258.07648" width="720" height="720" style="fill:#ffffff;stroke:none" id="rect8" inkscape:r_cx="true" inkscape:r_cy="true" /> <g transform="matrix(1.249992,0,0,-1.249992,-368.6339,1113.076)" xml:space="preserve" style="font-style:normal;font-variant:normal;font-
weight:normal;font-stretch:normal;letter-spacing:normal;word- spacing:normal;text-anchor:start;fill:none;fill-opacity: 1;stroke:#000000;stroke-linecap:butt;stroke-linejoin:miter;stroke- miterlimit:10.43299961;stroke-dasharray:none;stroke-dashoffset: 0;stroke-opacity:1"
id="g10" inkscape:r_cx="true" inkscape:r_cy="true">
could it be that?
The best solution would be to figure out which tool is introducing the breakage and fixing it, but if you can identify what parameter is getting mis-set, an easy workaround would be to write a little sed script to reset that to something sane, and include that in your conversion procedure.
In addition my point is not to find a way to sort it for my particular use (I'm quite happy with the copy paste even if it's an additional step) but I think that, as Inkscape is apparently capable of handling this, it should be done when first opening the file.
[snip again]
10/ The "Grid" effect is useful but why is it limited to a maximum of 10 pixels grid squares? (in addition the unit is not displayed in the effect's dialog).
Are you sure? Can't this be controlled via File > Document Preferences > Grid ?
I was talking about the Grid effect under Effects > Grid. not the alignement grid.
I'm always fiddling with the grid settings...
(Fwiw, I think the default grid settings are lame, and should be set to something more immediately useful. I'm sure this'd be an easy thing to change, I've just been too lazy to try to figure out what the best defaults would be.)
1px/1px is indeed a bit small. But I imagine that if inkscape started as a tool to design icons as you mentioned it has a nice historical value ;-) I guess that there is no perfect default. I would just suggest to base it on the default unit for the document. If your default unit is cm it's probably because you will do some printed work and your document will be quite large. On the contrary, if your unit is pixels it's because you are interested in some web or icon design. So basically doing 1/1 "default unit of the document" would be a not-so- bad rule of thumb for the default. Or maybe try to compute something a little more complicated based on the size of the document?
** For those who still have time to loose after this long email, here is a (confidential because not already published) draft of my article: "Movement analysis routine and circular statistics using free software". All vector illustrations are made with Inkscape. With such a title it would have been a shame to use something else that free software to write and illustrate the article!!! http://jo.irisson.free.fr/dropbox/inkscape/draft.pdf
Nice!
Thanks ;-)
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/