Hi, all,
Just FYI, for the next week or so we will be working on ODF drawing (.odg) output from Inkscape. If anyone is interested in helping map svg elements to office:drawing elements, we would certainly appreciate it. Here is an initial export of the tiger.svgz file to odg. Please note that it is a -very- early example, and most things require a lot of tweaking. This is paths-only, which will evolve into smarter exports later. Note that a lot of the style attributes still need to be translated, too. Also note that the coordinates were flipped in the Y-direction, so I fixed it manually.
http://inkscape.org/win32/ink-oo.png
To see what work is involved, compare the original .svg file to the content.xml file in any odg that you save.
bob (ishmal)
Bob Jamison wrote:
Also note that the coordinates were flipped in the Y-direction, so I fixed it manually.
I fixed this, I think. I think the general trick of: 1) flipping in Y 2) shifting by document height 3) scaling to ODF's cm-units ...will work in general.
NR::Matrix tf = sp_item_i2d_affine(item); NR::Rect bbox = sp_item_bbox_desktop(item);
//Flip Y into document coordinates double doc_Height = sp_document_height(SP_ACTIVE_DOCUMENT); NR::Matrix doc2dt_tf = NR::Matrix(NR::scale(1, -1)); doc2dt_tf = doc2dt_tf * NR::Matrix(NR::translate(0, doc_height)); tf = tf * doc2dt_tf; bbox = bbox * doc2dt_tf;
double x = pxToCm * bbox.min()[NR::X]; double y = pxToCm * bbox.min()[NR::Y]; double width = pxToCm * ( bbox.max()[NR::X] - bbox.min()[NR::X] ); double height = pxToCm * ( bbox.max()[NR::Y] - bbox.min()[NR::Y] );
4) And apply this transform to all of the points of an SPCurve.
The bounding box and point sets both must be done, because of the silly requirement in ODF that everything sits on its own rectangular frame.
Anyway, here is the first build to have this at least partially working: http://inkscape.modevia.com/win32-snap/Inkscape0604141337.zip
bob
On 4/14/06, Bob Jamison <rwjj@...127...> wrote:
Bob Jamison wrote:
Also note that the coordinates were flipped in the Y-direction, so I fixed it manually.
I fixed this, I think. I think the general trick of:
- flipping in Y
- shifting by document height
- scaling to ODF's cm-units
...will work in general.
Yes, but please do not write new code implementing this! Exactly this flipping is done by matrix_to/from_desktop in sp-item.cpp, please use it. I've always tried to minimize the number of places where this flipping is done, so it will be easier to eliminate it one day.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Fri, 14 Apr 2006 15:13:37 -0400, "bulia byak" <buliabyak@...400...> wrote:
On 4/14/06, Bob Jamison <rwjj@...127...> wrote:
Bob Jamison wrote:
Also note that the coordinates were flipped in the Y-direction, so I fixed it manually.
I fixed this, I think. I think the general trick of:
- flipping in Y
- shifting by document height
- scaling to ODF's cm-units
...will work in general.
Yes, but please do not write new code implementing this! Exactly this flipping is done by matrix_to/from_desktop in sp-item.cpp, please use it. I've always tried to minimize the number of places where this flipping is done, so it will be easier to eliminate it one day.
I think (hope) this is different, though?
i.e. if I understand correctly, the ODF coordinate system is flipped relative to the SVG one. It happens to correspond to the transformation we do for desktop coordinates right now, but we shouldn't assume forever that ODF coordinates correspond to our desktop coordinates, if we still plan on fixing our own coordinate system to match SVG's one day...
-mental
On Fri, Apr 14, 2006 at 03:51:13AM -0500, Bob Jamison wrote:
Just FYI, for the next week or so we will be working on ODF drawing (.odg) output from Inkscape. If anyone is interested in helping map svg elements to office:drawing elements, we would certainly appreciate it. Here is an initial export of the tiger.svgz file to odg. Please note that it is a -very- early example, and most things require a lot of tweaking. This is paths-only, which will evolve into smarter exports later. Note that a lot of the style attributes still need to be translated, too. Also note that the coordinates were flipped in the Y-direction, so I fixed it manually.
This is great news! OpenOffice support has been a really long standing issue.
One question though - given Eric's nice progress with UberConverter recently, would you consider adding the ODF support at that level?
The benefit would be that your ODF work would then have broader applicability beyond SVG, to XAR and other formats. As well, having it as an extension rather than core code could make it a bit easier for others (like Xara) to help work on it with you (this is definitely a feature they'd be interested in sharing).
Of course, there's a few considerations, such as that it would be less easy to reuse existing Inkscape internals (such as the matrix code), and that you're not as familiar with UberConverter as you would be going directly to SVG. However, despite these challenges, I think in the larger scheme of things it would give a greater amount of benefit.
In any case, again, whatever approach is taken, it's great to see this getting implemented! :-)
Bryce
Bryce Harrington wrote:
On Fri, Apr 14, 2006 at 03:51:13AM -0500, Bob Jamison wrote:
Just FYI, for the next week or so we will be working on ODF drawing (.odg) output from Inkscape. If anyone is interested in helping map svg elements to office:drawing elements, we would certainly appreciate it. Here is an initial export of the tiger.svgz file to odg. Please note that it is a -very- early example, and most things require a lot of tweaking. This is paths-only, which will evolve into smarter exports later. Note that a lot of the style attributes still need to be translated, too. Also note that the coordinates were flipped in the Y-direction, so I fixed it manually.
This is great news! OpenOffice support has been a really long standing issue.
One question though - given Eric's nice progress with UberConverter recently, would you consider adding the ODF support at that level?
The benefit would be that your ODF work would then have broader applicability beyond SVG, to XAR and other formats. As well, having it as an extension rather than core code could make it a bit easier for others (like Xara) to help work on it with you (this is definitely a feature they'd be interested in sharing).
Of course, there's a few considerations, such as that it would be less easy to reuse existing Inkscape internals (such as the matrix code), and that you're not as familiar with UberConverter as you would be going directly to SVG. However, despite these challenges, I think in the larger scheme of things it would give a greater amount of benefit.
Yes, such a converter would be immensely useful, and worthy of contributions.
A couple of months ago, I wrote a Java class for experimenting with converting directly from an SVG file to an ODF office:drawing file. I'd like to donate it, but I'm afraid it doesn't do a very good job. Without a presentation model, it has insufficient information to do a high-fidelity load-and-save.
Doing this internally, odf-output has access to all of the information for the desktop, document, repr tree, and SPObject tree. I can read directly from it, bypass the SVG format, and write ODF directly from Inkscape's memory. You can't beat that! It's called "cheating!" ;-)
bob (ishmal)
p.s.: A lib that can convert anything to anything would necessarily need an internal format-neutral presentation model for reading and writing. I know of exactly two libs that do that: Imagemagick for bitmaps, and Batik for svg/ps/pdf/latex/etc. Imagemagick is large, and Batik is HUGE. It would take a lot of work, and I would gladly contribute to it.
# from Bob Jamison # on Friday 14 April 2006 07:57 pm:
A lib that can convert anything to anything would necessarily need an internal format-neutral presentation model for reading and writing. I know of exactly two libs that do that: Imagemagick for bitmaps,
Format-neutral representations of 2D arrays are a cakewalk compared to 2D/3D vector graphics. Okay, bitmaps are more than just arrays, but still -- cakewalk :-)
Batik for svg/ps/pdf/latex/etc. Imagemagick is large, and Batik is HUGE.
Precisely why the uber-converter does not try to do everything in a single central format. Also, it is not written in Java. Also, it is not written in <name of language you don't like/know>.
It would take a lot of work, and I would gladly contribute to it.
Jump in. It could use a bit more documentation of the central formats, but I'm trying to focus more heavily on testing than specifying. Feel free to ping me on whatever list or IRC channel. For the svg/ps/pdf/xar formats, your hub is chromista, but even that is not set in stone.
--Eric
participants (5)
-
Bob Jamison -
Bryce Harrington -
bulia byak -
Eric Wilhelm -
MenTaLguY