I've just noticed that Inkscape's SVG format doesn't work in cairo for the few drawings we tried - when we save as Plain SVG, they appear correctly. Not sure this is a universal problem but with the advent of Firefox SVG based on Cairo and the soon to be popularity of Cairo and XML in general, it might begin to confuse users that Inkscape's SVG is not Plain SVG and their svg drawings might not show correctly. We're already confused with whether a *.svg drawing is in Inkscape mode or Plain mode - obviously we can parse the xml code but just is more work. Also not sure how this plays out in Safari, Konqueror, or Opera. I would assume this might also affect Inkscape submissions to Open Clip Art which I would assume is standardized on the Plain SVG ? I would like to suggest: 1) make the Plain SVG as the default 2) rename the Inkscape SVG as something like *.svgi
On 10/16/05, John Taber <jtaber@...480...> wrote:
I've just noticed that Inkscape's SVG format doesn't work in cairo for the few drawings we tried - when we save as Plain SVG, they appear correctly.
What exactly causes problems? Can you provide examples?
Anyway, Inkscape SVG _is_ valid SVG, or at least is supposed to be. If it's rendered differently, it can only be due to a bug, in either Inkscape or Cairo. So the right course of action is to fix this bug. I certainly do NOT support making plain SVG the default, since this means losing A LOT of Inkscape functionality after save/reload.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Monday 17 October 2005 00:24, bulia byak wrote:
On 10/16/05, John Taber <jtaber@...480...> wrote:
I've just noticed that Inkscape's SVG format doesn't work in cairo for the few drawings we tried - when we save as Plain SVG, they appear correctly.
What exactly causes problems? Can you provide examples?
Anyway, Inkscape SVG _is_ valid SVG, or at least is supposed to be. If it's rendered differently, it can only be due to a bug, in either Inkscape or Cairo. So the right course of action is to fix this bug. I certainly do NOT support making plain SVG the default, since this means losing A LOT of Inkscape functionality after save/reload.
Side Q on this topic: If Inkscape SVG is valid SVG, then how do you lose Inkscape functionality? By an extended namespace that isnt supported in SVG? or?
Craig
On 10/16/05, Craig Bradney <cbradney@...242...> wrote:
Side Q on this topic: If Inkscape SVG is valid SVG, then how do you lose Inkscape functionality? By an extended namespace that isnt supported in SVG? or?
Yes we use extended namespace, but SVG does not become invalid by adding other namespaces to it. Elements and attributes in Inkscape/Sodipodi namespaces only affect how objects _behave when edited_, but never affect how they are _rendered_, and therefore Inkscape SVG is always rendered the same as plain SVG.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Monday 17 October 2005 00:58, bulia byak wrote:
On 10/16/05, Craig Bradney <cbradney@...242...> wrote:
Side Q on this topic: If Inkscape SVG is valid SVG, then how do you lose Inkscape functionality? By an extended namespace that isnt supported in SVG? or?
Yes we use extended namespace, but SVG does not become invalid by adding other namespaces to it. Elements and attributes in Inkscape/Sodipodi namespaces only affect how objects _behave when edited_, but never affect how they are _rendered_, and therefore Inkscape SVG is always rendered the same as plain SVG.
So any app that ignores that namespace should still be able to render them correctly.. hmm. Good to know. thanks
Craig
bulia byak wrote:
Anyway, Inkscape SVG _is_ valid SVG, or at least is supposed to be. If it's rendered differently, it can only be due to a bug, in either Inkscape or Cairo. So the right course of action is to fix this bug. I certainly do NOT support making plain SVG the default, since this means losing A LOT of Inkscape functionality after save/reload.
Okay, I'll do some more testing tonight to see if I can narrow the problem, then submit some examples here and to cairo list.
On Oct 16, 2005, at 3:12 PM, John Taber wrote:
I've just noticed that Inkscape's SVG format doesn't work in cairo for the few drawings we tried
Can you define "doesn't work" ?
I would like to suggest:
- make the Plain SVG as the default
- rename the Inkscape SVG as something like *.svgi
A more ideal solution would probably be to figure out exactly what's causing things to fail, and then either fix it to fall back gracefully, or to fix Cairo if that's what is broken.
OK.
1. Cairo is not an SVG implementation
2. Cairo is not an SVG implementation :)
3. Cairo is a 2d graphics API
Are you perhaps referring to librsvg-cairo? Firefox has its own, different, SVG implementation.
-mental
mental@...3... wrote:
OK.
- Cairo is not an SVG implementation
- Cairo is not an SVG implementation :)
- Cairo is a 2d graphics API
Are you perhaps referring to librsvg-cairo? Firefox has its own, different, SVG implementation.
well yes, you are right, shall we call it "svg under cairo" meaning the libsvg-cairo (which I guess is librsvg-cairo since they apparently have merged - I just don't know all the details). And I read that Firefox was going to Cairo rendering - what that means exactly I'm not sure, I just assumed they were going to use svg rendering under cairo.
Anyway after a bunch of testing I found Bulia was correct (most of the problem was our mistake of missing image link paths on another machine). But I did isolate another problem which seems to be on the "libsvg-cairo" end - it doesn't seem to recognize text line breaks with tspan (this happens with Inkscape and Plain SVG). The following example gives ADT 80 (same line) on cairo instead of ADT 80 (two lines) in Inkscape
same problem happened with a bunch of other multi line text examples. here is the example code:
<text xml:space="preserve" style="font-size:16.531573;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1.0000000;
stroke:none;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linejoin:miter; stroke-opacity:1.0000000;font-family:Bitstream Vera Sans;font-stretch:normal; font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125.00003%" x="525.83685" y="362.78998" id="text2029" transform="scale(0.948876,1.053878)" sodipodi:linespacing="125%"><tspan sodipodi:role="line" id="tspan2047" x="525.83685" y="362.78998">ADT</tspan><tspan sodipodi:role="line" id="tspan2049" x="525.83685" y="383.45444">80</tspan></text>
Librsvg's text support is known to suck, and it's something that we plan to improve before our 3.0 release. Bug reports and patches are, of course, welcome.
Firefox renders SVGs to screen (well, to a RGBA picture, and then blits that to screen) using Cairo. librsvg also uses Cairo, but only in our CVS HEAD version. No released version of librsvg uses Cairo.
This has nothing to do with Cairo. Cairo is just a drawing API. It doesn't know anything about SVGs. This has everything to do with librsvg's and Firefox's internals, which do understand SVGs.
On 10/17/05, John Taber <jtaber@...480...> wrote:
mental@...3... wrote:
OK.
- Cairo is not an SVG implementation
- Cairo is not an SVG implementation :)
- Cairo is a 2d graphics API
Are you perhaps referring to librsvg-cairo? Firefox has its own, different, SVG implementation.
well yes, you are right, shall we call it "svg under cairo" meaning the libsvg-cairo (which I guess is librsvg-cairo since they apparently have merged - I just don't know all the details). And I read that Firefox was going to Cairo rendering - what that means exactly I'm not sure, I just assumed they were going to use svg rendering under cairo.
Anyway after a bunch of testing I found Bulia was correct (most of the problem was our mistake of missing image link paths on another machine). But I did isolate another problem which seems to be on the "libsvg-cairo" end - it doesn't seem to recognize text line breaks with tspan (this happens with Inkscape and Plain SVG). The following example gives ADT 80 (same line) on cairo instead of ADT 80 (two lines) in Inkscape
same problem happened with a bunch of other multi line text examples. here is the example code:
<text xml:space="preserve" style="font-size:16.531573;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1.0000000;
stroke:none;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linejoin:miter; stroke-opacity:1.0000000;font-family:Bitstream Vera Sans;font-stretch:normal; font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125.00003%" x="525.83685" y="362.78998" id="text2029" transform="scale(0.948876,1.053878)" sodipodi:linespacing="125%"><tspan sodipodi:role="line" id="tspan2047" x="525.83685" y="362.78998">ADT</tspan><tspan sodipodi:role="line" id="tspan2049" x="525.83685" y="383.45444">80</tspan></text>
This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Librsvg-devel mailing list Librsvg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/librsvg-devel
Librsvg's text support is known to suck, and it's something that we plan to improve before our 3.0 release. Bug reports and patches are, of course, welcome.
You are welcome to have Inkscape's text layout code if it would help. As far as I know all the really interesting bits only have three people's code in them so it shouldn't be too hard to re-licence under the LGPL.
There are a few things that would need to be looked at:
- The binding to Inkscape's css system is a bit tighter than you would like it to be, but it shouldn't be too hard to fix given that most of it is isolated in one file.
- The font management backend is coupled to the rendering engine a bit, but you're going to want to swap both out for Cairo anyway.
- It is written to maintain state for the purpose of editable text, so (presuming memory usage is important to you) there would need to be hooks added to flush each line as it is finished, rather than saving everything for one big batch render at the end. I don't think you can go smaller than a line while still keeping the ability to do bidirectional text and text on a path.
- If you've been relying on your graphics library for polygon rasterisation you might not have all the capabilities needed for flowtext to work, if you're interested in that.
Other than that, all the external interfaces are fairly neat (well, I think so anyway) and any help you need, up to and including coding, give me a shout (with the caveat that I'd prefer not to have to learn a significant percentage of the librsvg codebase).
Richard.
Thanks, Richard. This is something that we'll keep in mind when we rewrite our text engine. If we can't share code, at least we can share the wisdom of Inkscape's experience.
On 10/17/05, Richard Hughes <cyreve@...400...> wrote:
Librsvg's text support is known to suck, and it's something that we plan to improve before our 3.0 release. Bug reports and patches are, of course, welcome.
You are welcome to have Inkscape's text layout code if it would help. As far as I know all the really interesting bits only have three people's code in them so it shouldn't be too hard to re-licence under the LGPL.
There are a few things that would need to be looked at:
- The binding to Inkscape's css system is a bit tighter than you would
like it to be, but it shouldn't be too hard to fix given that most of it is isolated in one file.
- The font management backend is coupled to the rendering engine a
bit, but you're going to want to swap both out for Cairo anyway.
- It is written to maintain state for the purpose of editable text, so
(presuming memory usage is important to you) there would need to be hooks added to flush each line as it is finished, rather than saving everything for one big batch render at the end. I don't think you can go smaller than a line while still keeping the ability to do bidirectional text and text on a path.
- If you've been relying on your graphics library for polygon
rasterisation you might not have all the capabilities needed for flowtext to work, if you're interested in that.
Other than that, all the external interfaces are fairly neat (well, I think so anyway) and any help you need, up to and including coding, give me a shout (with the caveat that I'd prefer not to have to learn a significant percentage of the librsvg codebase).
Richard.
On Mon, 2005-10-17 at 20:28 +0100, Richard Hughes wrote:
- The binding to Inkscape's css system is a bit tighter than you would
like it to be, but it shouldn't be too hard to fix given that most of it is isolated in one file.
But isn't Inkscape using libcroco just like librsvg is?
Christian
- The binding to Inkscape's css system is a bit tighter than you would
like it to be, but it shouldn't be too hard to fix given that most of it is isolated in one file.
But isn't Inkscape using libcroco just like librsvg is?
Yes, but there's an extra step in between. I don't know how librsvg does it, but Inkscape just uses libcroco as a parser and has its own structures into which it dumps the parsed data. libcroco does have a stateful interface but we don't use it because it only includes a subset of the necessary properties (a subset that's optimised for html, not svg).
Richard.
On Mon, 17 Oct 2005 11:04:26 -0600, John Taber wrote:
well yes, you are right, shall we call it "svg under cairo" meaning the libsvg-cairo (which I guess is librsvg-cairo since they apparently have merged - I just don't know all the details). And I read that Firefox was going to Cairo rendering - what that means exactly I'm not sure, I just assumed they were going to use svg rendering under cairo.
"SVG under cairo" is a rather too-vague notion. What you are referring to up above is three different pieces of code that can use cairo to do rendering:
1) libsvg-cairo
2) librsvg-cairo
3) Firefox
So, rendering bugs you find might be in cairo, or might be in one of the libraries above. And if the bug is not in cairo, a bug report won't be useful unless it is directed at the proper code base.
But I did isolate another problem which seems to be on the "libsvg-cairo" end - it doesn't seem to recognize text line breaks with tspan (this happens with Inkscape and Plain SVG).
A bug in a high-level construct such as the layout of a tspan is almost guaranteed to be in code above cairo, (since cairo only sees the text after layout has been performed for each line).
So, you've found a bug in libsvg-cairo here. As the primary "maintainer" of libsvg-cairo, I'll say that I'm not doing much with libsvg-cairo anymore, and I would encourage you to investigate librsvg-cairo and see if it doesn't meet your needs better.
(It's possible librsvg-cairo has the same bug, but its maintainers are much more likely to actually do something about fixing it.)
There's really nothing about inkscape in this thread at this point, so please feel free to drop inkscape-devel from the recipient list of any replies.
-Carl
participants (9)
-
unknown＠example.com -
bulia byak -
Carl Worth -
Christian Fredrik Kalager Schaller -
Craig Bradney -
Dominic Lachowicz -
John Taber -
Jon A. Cruz -
Richard Hughes