Simon (aka "the Rock") said, "You're the Christ, God's son."
Jesus replied, "Simon bar-Jonah, you're blessed because God (not man) has revealed this to you. You're 'the Rock', and upon this rock I will build my Church which hell will never win against. I will give you the keys of the kingdom of heaven. What you bind and loose on earth will also be bound and loosed in heaven."
Jesus nicknames Simon "Rock" (a name he continues to use thereafter), says he's going to build his Church on "this rock", and assigns the guy some seriously hardcore authority all in one go. IMO, it's pretty hard to pretend that "this rock" has nothing to do with the rest of the immediately surrounding text.
Well, no, that was the Greek. The original language was Aramaic, with "kepha" (meaning "rock") in both places. (In other places, the Aramaic "kepha" sometimes peeks through in the Greek version when Simon's nickname is simply transliterated as "Cephas" rather than being translated.)
Why translate "kepha" as both "petros" ("pebble") and "petra" ("rock")? Because it would have sounded really funky to Greek-speakers if Jesus had assigned Simon a female nickname here -- in Greek, "petra" is a feminine noun. The closest male noun was "petros". Unfortunately using "petros" in both places would sap the force of the second part -- "...and upon this pebble I build my church?" Nah. I think it was a reasonable compromise on the part of the translator.
Something else to think about: obviously the rock-rock assocation was important to the sense of the passage, or the translator could have avoided the problem simply by transliterating the nickname, "You are Cephas, and upon this rock (petra) I build my Church."
Right, so... I'm having a hard time seeing what you're objecting to. "Node sculpting" is a feature for node editing, not Flash-style editing. In the new version you actually can (using the node tool) drag segments directly rather than manipulating nodes, which is a little bit like dragging segments in Flash, but that's a totally separate feature from node sculpting.
So, wait, you're saying that if you select multiple nodes in Flash and drag one, rather than following in lockstep, the rest of the selected nodes will be influenced depending on tablet pressure and their distance from the node being dragged? Because that's what we mean by "node sculpting", and I don't remember Flash working like that back when I was a heavy Flash user.
I wrote the current incarnation of the XML editor back when Inkscape was still Sodipodi, but as far as I know the original idea and implementation belongs to Lauris Kaplinski, Sodipodi's maintainer.
Have you tried saving as "Inkscape SVGZ" rather than "Inkscape SVG"? Raw SVG, being an XML dialect, is kinda verbose, so there's only so much we can do about that. SVGZ is gzip-compressed SVG, which is (slightly) more reasonable in filesize.
All that said, 20 MB is unusually large in my experience. What exactly do you have in mind when you say "medium-size"?
For now, you can sort of tediously fake it with a lot of transparent gradients -- otherwise, you'll have to wait for 0.45 to implement SVG filter effects, which are basically a whole suite of dynamic raster effects. I don't think any other vector application will have anything like it.
Well, if you really want to donate, you can do that using Sourceforge's donation page. We don't advertise the donations page because we haven't really had a need to solicit donations.:)
Hmm, what did you think we meant by "node sculpting"? It's basically proportional node dragging with a pressure-sensitive falloff radius. You do find that in the mesh editors of a lot of 3d apps, but as far as I know it's the first time I've seen it in a 2d vector application.
The best time to do it would be at game or level startup time rather than install time. These days your graphics properties are probably going to end up as OpenGL textures; while you could use an OpenGL-targeted SVG rendering library in realtime, it's usually not worth the overhead except for visually simple or very dynamic images.
Yes, that's exactly right. A lot of beginners try to draw mostly with their wrist and fingers, which doesn't work well and tires you out fast. Most practiced artists do a lot of their drawing motion from their upper arm/shoulder. Of course, you also have to draw larger for this to work well; beginners also tend to draw too small.
Yes, and yes. It's been done, too -- just off the top of my head, there's Monsterz, but there are other games using SVG graphics as well. Since SVG supports scripting via Javascript (given appropriate browser support), some people have even written games for the web in SVG directly. Browser support isn't widespread enough to make a Flash-killer yet, but if you're just rendering graphics for your own traditional game engine SVG graphics are certainly an option today.
Seconded -- bitmap transformation/scaling has been done to death these days. It'd be insane not to use one of the many existing libraries out there -- and indeed, Firefox 3 will be using cairo for that purpose.
I've never used Acrobat, so I wouldn't know what to suggest. Depending on your needs, e.g. pdftk may fit the bill. Generally it's better to look at the features you need and then search for a tool based on that, rather than looking for a 1:1 replacement for a particular application.
Stability should be a lot better across the board in this release. Memory usage is better in selected circumstances (and we've fixed the most major memory leaks). Give it a try and see how it works for you.
(Speaking as the person who wrote the memory dialog)
There's a memory leak in the memory dialog's treeview widget. I've not been able to track it down yet (it may be a gtkmm issue), but I think your guess is roughly correct.
I have heard that this is the open source replacement for Adobe Acrobat.
You heard wrong.:)
We are going to continue to improve our PDF support, but it's not a central part of our mission. Also, whatever PDF support we have is going to be largely limited to that subset of PDF functionality which is representable in SVG.
Slashdot Mirror
More like:
Simon (aka "the Rock") said, "You're the Christ, God's son."
Jesus replied, "Simon bar-Jonah, you're blessed because God (not man) has revealed this to you. You're 'the Rock', and upon this rock I will build my Church which hell will never win against. I will give you the keys of the kingdom of heaven. What you bind and loose on earth will also be bound and loosed in heaven."
Jesus nicknames Simon "Rock" (a name he continues to use thereafter), says he's going to build his Church on "this rock", and assigns the guy some seriously hardcore authority all in one go. IMO, it's pretty hard to pretend that "this rock" has nothing to do with the rest of the immediately surrounding text.
Well, no, that was the Greek. The original language was Aramaic, with "kepha" (meaning "rock") in both places. (In other places, the Aramaic "kepha" sometimes peeks through in the Greek version when Simon's nickname is simply transliterated as "Cephas" rather than being translated.)
Why translate "kepha" as both "petros" ("pebble") and "petra" ("rock")? Because it would have sounded really funky to Greek-speakers if Jesus had assigned Simon a female nickname here -- in Greek, "petra" is a feminine noun. The closest male noun was "petros". Unfortunately using "petros" in both places would sap the force of the second part -- "...and upon this pebble I build my church?" Nah. I think it was a reasonable compromise on the part of the translator.
Something else to think about: obviously the rock-rock assocation was important to the sense of the passage, or the translator could have avoided the problem simply by transliterating the nickname, "You are Cephas, and upon this rock (petra) I build my Church."
Er, by "you" I meant Kawahee, the OP who seemed to be under the impression that "node sculpting" meant Flash-style segment dragging.
Right, so ... I'm having a hard time seeing what you're objecting to. "Node sculpting" is a feature for node editing, not Flash-style editing. In the new version you actually can (using the node tool) drag segments directly rather than manipulating nodes, which is a little bit like dragging segments in Flash, but that's a totally separate feature from node sculpting.
So, wait, you're saying that if you select multiple nodes in Flash and drag one, rather than following in lockstep, the rest of the selected nodes will be influenced depending on tablet pressure and their distance from the node being dragged? Because that's what we mean by "node sculpting", and I don't remember Flash working like that back when I was a heavy Flash user.
c.f. the original Node Sculpting thread: http://inkscape-forum.andreas-s.net/topic/65646
I wrote the current incarnation of the XML editor back when Inkscape was still Sodipodi, but as far as I know the original idea and implementation belongs to Lauris Kaplinski, Sodipodi's maintainer.
In principle you can specify CYMK in SVG today using an appropriate ICC profile. You just don't get a CYMK-based imaging pipline.
Well, except for the ones that also support SVG filters. :)
Once SVG 1.2 is finalized, general non-destructive path operations should be possible in SVG.
I think that may be a typo.
Have you tried saving as "Inkscape SVGZ" rather than "Inkscape SVG"? Raw SVG, being an XML dialect, is kinda verbose, so there's only so much we can do about that. SVGZ is gzip-compressed SVG, which is (slightly) more reasonable in filesize.
All that said, 20 MB is unusually large in my experience. What exactly do you have in mind when you say "medium-size"?
For now, you can sort of tediously fake it with a lot of transparent gradients -- otherwise, you'll have to wait for 0.45 to implement SVG filter effects, which are basically a whole suite of dynamic raster effects. I don't think any other vector application will have anything like it.
Well, if you really want to donate, you can do that using Sourceforge's donation page. We don't advertise the donations page because we haven't really had a need to solicit donations. :)
Hmm, what did you think we meant by "node sculpting"? It's basically proportional node dragging with a pressure-sensitive falloff radius. You do find that in the mesh editors of a lot of 3d apps, but as far as I know it's the first time I've seen it in a 2d vector application.
The best time to do it would be at game or level startup time rather than install time. These days your graphics properties are probably going to end up as OpenGL textures; while you could use an OpenGL-targeted SVG rendering library in realtime, it's usually not worth the overhead except for visually simple or very dynamic images.
Yes, that's exactly right. A lot of beginners try to draw mostly with their wrist and fingers, which doesn't work well and tires you out fast. Most practiced artists do a lot of their drawing motion from their upper arm/shoulder. Of course, you also have to draw larger for this to work well; beginners also tend to draw too small.
Yes, and yes. It's been done, too -- just off the top of my head, there's Monsterz, but there are other games using SVG graphics as well. Since SVG supports scripting via Javascript (given appropriate browser support), some people have even written games for the web in SVG directly. Browser support isn't widespread enough to make a Flash-killer yet, but if you're just rendering graphics for your own traditional game engine SVG graphics are certainly an option today.
Seconded -- bitmap transformation/scaling has been done to death these days. It'd be insane not to use one of the many existing libraries out there -- and indeed, Firefox 3 will be using cairo for that purpose.
I've never used Acrobat, so I wouldn't know what to suggest. Depending on your needs, e.g. pdftk may fit the bill. Generally it's better to look at the features you need and then search for a tool based on that, rather than looking for a 1:1 replacement for a particular application.
Stability should be a lot better across the board in this release. Memory usage is better in selected circumstances (and we've fixed the most major memory leaks). Give it a try and see how it works for you.
(Speaking as the person who wrote the memory dialog)
There's a memory leak in the memory dialog's treeview widget. I've not been able to track it down yet (it may be a gtkmm issue), but I think your guess is roughly correct.
To be fair, most people never hand-edit AI files. It's more expected for SVG, though.
Inkscape _does_ let you manually reassign ids if you don't like the autogenerated ones, however.
You heard wrong. :)
We are going to continue to improve our PDF support, but it's not a central part of our mission. Also, whatever PDF support we have is going to be largely limited to that subset of PDF functionality which is representable in SVG.
What's the problem with the SVG it produces? Just an issue with verbosity, or what?
Update: I just checked quirksmode.org. Looks like all the major browsers support CSS tables now ... except for IE. *sigh*