This looks like it might be interesting:
http://xmlgraphics.apache.org/fop/
Sounds like it's able to take input from SVG and produce PDF.
If anyone's interested in svg2pdf, this might be worth experimenting with to see if it's any good. It's available under the Apache license.
Bryce
This looks like it might be interesting:
http://xmlgraphics.apache.org/fop/Sounds like it's able to take input from SVG and produce PDF.
If anyone's interested in svg2pdf, this might be worth experimenting with to see if it's any good. It's available under the Apache license.
FOP uses batik (http://xml.apache.org/batik/) to perform its svg-to-pdf "transcoding", as they call it. The output is pretty impressive for many situations, but alas:
1. It's written in java, and doesn't yet compile/run using gcj (although they're close) 2. it's a bit slow, and still occasionally vomits all over your svg
What this does potentially give you, however, is a way of getting transparency into PDFs: PDF1.4+ supports actual transparency, whereas PS-level 3 and friends do not (I believe the current inkscape svg->pdf mode has an (e)ps intermediate step).
Do people feel inkscape should natively output PDF? ...Eric
On 9/27/05, Eric Jonas <jonas@...415...> wrote:
Do people feel inkscape should natively output PDF?
It's one of the most often requested features.
The particular RFE: http://sourceforge.net/tracker/index.php?func=detail&aid=864260&grou...
Alexandre
Eric Jonas wrote:
Do people feel inkscape should natively output PDF?
<imho> Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community. </imho>
Aaron Spike
Do people feel inkscape should natively output PDF?
<imho> Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community. </imho>
Do you mean "inkscape should only ever produce SVG files, and leave the conversion to other external programs"? or "We should really try and avoid implementing our own conversion libraries, and just use what's out there"? They seem to be two very different things, both from an inkscape-developer-effort perspective and a usability one.
...Eric
On 9/27/05, Eric Jonas <jonas@...415...> wrote:
Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community.
</imho>
Do you mean "inkscape should only ever produce SVG files, and leave the conversion to other external programs"? or "We should really try and avoid implementing our own conversion libraries, and just use what's out there"? They seem to be two very different things, both from an inkscape-developer-effort perspective and a usability one.
I suspect that from developer's POV it's easier to use CLI options of other applications to provide import/export (I/E) in different formats. From users POV appilcations should support everything natively. It is usability disaster to keep some applications installed just because they have required I/E functionality.
This topic is often raised in forum/conferences etc. Users do want one good vector I/E library to be reused by different applications.
Thus creation of previously announced Üver-Convertor (I'm lost for words to express my disagreement with this nietschianish name, actually) is quite a good solution.
Alexandre
# from Alexandre Prokoudine # on Tuesday 27 September 2005 08:04 am:
On 9/27/05, Eric Jonas <jonas@...415...> wrote:
Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community. </imho>
Do you mean "inkscape should only ever produce SVG files, and leave the conversion to other external programs"? or "We should really try and avoid implementing our own conversion libraries, and just use what's out there"? They seem to be two very different things, both from an inkscape-developer-effort perspective and a usability one.
Note that "leave the conversion to external programs" does not mean the user must switch to a terminal and run an application. The export will have the same functionality for the user whether it is a plugin or native code. So, there is no reason to add import/export code to the main tree (though aggregating the required programs *next to* the tree in the distribution will simplify the dependency issues.
I suspect that from developer's POV it's easier to use CLI options of other applications to provide import/export (I/E) in different formats. From users POV appilcations should support everything natively. It is usability disaster to keep some applications installed just because they have required I/E functionality.
I agree if you are talking about the proposed use of scribus for I/E, but I also think that using it in the short term is better than nothing.
This topic is often raised in forum/conferences etc. Users do want one good vector I/E library to be reused by different applications.
Thus creation of previously announced Üver-Convertor (I'm lost for words to express my disagreement with this nietschianish name, actually) is quite a good solution.
Heh. You're not the first. It started as a working title and sort of stuck, but right now it seems to be about 50/50 for and against the name (I wonder why that is?) Does it help to know that this is only the name of the project and that the programs themselves have much more mundane names like svg2crs?
--Eric
On 9/27/05, Eric Wilhelm <scratchcomputing@...400...> wrote:
Note that "leave the conversion to external programs" does not mean the user must switch to a terminal and run an application.
Not a big surprise to me ;)
native code. So, there is no reason to add import/export code to the main tree (though aggregating the required programs *next to* the tree in the distribution will simplify the dependency issues.
Aggregation?
I agree if you are talking about the proposed use of scribus for I/E,
Plus Dia, plus Sketch/Skencil, plus pstoedit, plus etc.
but I also think that using it in the short term is better than nothing.
Sure
Thus creation of previously announced Üver-Convertor (I'm lost for words to express my disagreement with this nietschianish name, actually) is quite a good solution.
Heh. You're not the first. It started as a working title and sort of stuck, but right now it seems to be about 50/50 for and against the name (I wonder why that is?)
Why? http://en.wikipedia.org/wiki/Nietzsche and http://en.wikipedia.org/wiki/%C3%9Cbermensch
Does it help to know that this is only the name of the project and that the programs themselves have much more mundane names like svg2crs?
I know that :)
Alexandre
On Tue, Sep 27, 2005 at 08:17:05PM +0400, Alexandre Prokoudine wrote:
native code. So, there is no reason to add import/export code to the main tree (though aggregating the required programs *next to* the tree in the distribution will simplify the dependency issues.
Aggregation?
I agree if you are talking about the proposed use of scribus for I/E,
Plus Dia, plus Sketch/Skencil, plus pstoedit, plus etc.
Really the choice you have is not between having the feature in tree or as an external dependency but having it as an external dependency or not having it at all and having to do the conversions manually.
Note that these are all *optional* dependencies. Inkscape will run fine without foo extension. For people who don't need anything other than SVG, this is great; they install just Inkscape and don't have to muss around with anything else. For people who need more conversion abilities, they can get that too, it just requires more installation work (unless they're using a sane distro that handles the dependencies in a nice way.)
If it bothers you that Inkscape can interoperate with all these other programs, then just don't bother setting up those programs. ;-)
Bryce
# from Alexandre Prokoudine # on Tuesday 27 September 2005 09:17 am:
native code. So, there is no reason to add import/export code to the main tree (though aggregating the required programs *next to* the tree in the distribution will simplify the dependency issues.
Aggregation?
Just ship whatever version is known to be stable and tested alongside inkscape. If necessary, install them outside of $PATH and call them with absolute filenames (/usr/local/inkscape/external/pstoedit or whatever.)
I agree if you are talking about the proposed use of scribus for I/E,
Plus Dia, plus Sketch/Skencil, plus pstoedit, plus etc.
Ok. Including Dia and Sketch in your distribution makes it too heavy. These are short-term workaround dependencies. But aggregating pstoedit or the various uberconverter programs in the distribution won't add that much weight and will certainly ease the install/dependencies issues. Of course, some users have no troubles handling dependencies on their own and would rather not have these in the distribution, but it is simple enough to provide all of them as an optional (one stop shopping) add-on package.
--Eric
I haven't been following the lists for a while, what is the uberconverter? Is this a real piece of software people are working on, or a joke? ...Eric
On Tue, Sep 27, 2005 at 10:05:19AM -0700, Eric Wilhelm wrote:
# from Alexandre Prokoudine # on Tuesday 27 September 2005 09:17 am:
native code. So, there is no reason to add import/export code to the main tree (though aggregating the required programs *next to* the tree in the distribution will simplify the dependency issues.
Aggregation?
Just ship whatever version is known to be stable and tested alongside inkscape. If necessary, install them outside of $PATH and call them with absolute filenames (/usr/local/inkscape/external/pstoedit or whatever.)
I agree if you are talking about the proposed use of scribus for I/E,
Plus Dia, plus Sketch/Skencil, plus pstoedit, plus etc.
Ok. Including Dia and Sketch in your distribution makes it too heavy. These are short-term workaround dependencies. But aggregating pstoedit or the various uberconverter programs in the distribution won't add that much weight and will certainly ease the install/dependencies issues. Of course, some users have no troubles handling dependencies on their own and would rather not have these in the distribution, but it is simple enough to provide all of them as an optional (one stop shopping) add-on package.
--Eric
Eric Jonas wrote:
I haven't been following the lists for a while, what is the uberconverter? Is this a real piece of software people are working on, or a joke? ...Eric
And for anyone else that missed it, please refer to this post by Bryce... http://sourceforge.net/mailarchive/forum.php?thread_id=8281243&forum_id=...
-Josh
Eric Jonas wrote:
Do people feel inkscape should natively output PDF?
<imho> Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community. </imho>
Do you mean "inkscape should only ever produce SVG files, and leave the conversion to other external programs"? or "We should really try and avoid implementing our own conversion libraries, and just use what's out there"? They seem to be two very different things, both from an inkscape-developer-effort perspective and a usability one.
I mean both. Certainly we should avoid implementing our own conversion libraries. We should either contribute to existing library efforts and attempt to spawn an external lib to fill a void if one exists. But if at all possible we should be leaving the conversion to external programs. (Installing huge applications such as scribus or java, doesn't fit my definition of "if at all possible".) This doesn't create a usibility nightmare; Inkscape is designed to handle this. I fully support putting all of our eggs in the Uberconverter basket. This approach will better the FOSS ecosystem.
Aaron Spike
PS. please understand this is just opinion. I don't have the programming skills to back it up. :)
aaron@...749... wrote:
Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community.
</imho>
But sadly not too many programs or viewers support SVG yet so a pdf export is pretty vital - I have to use bitmap export all the time to put a drawing into OpenOffice, on the web page, send an email attachment, etc - try taking your Inkscape designed flyer to Kinkos to get reproduced - they need pdf (or something else but pdf is the best option). So pdf export would be a great addition to make Inkscape a more useful program. Is it that hard to translate the java to c++ ? Shouldn't be, though I've learned nothing in software is trivial.
On Tue, Sep 27, 2005 at 08:51:23AM -0600, John Taber wrote:
aaron@...749... wrote:
Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community.
</imho>
But sadly not too many programs or viewers support SVG yet so a pdf export is pretty vital - I have to use bitmap export all the time to put a drawing into OpenOffice, on the web page, send an email attachment, etc - try taking your Inkscape designed flyer to Kinkos to get reproduced - they need pdf (or something else but pdf is the best option). So pdf export would be a great addition to make Inkscape a more useful program. Is it that hard to translate the java to c++ ? Shouldn't be, though I've learned nothing in software is trivial.
Batik is *huge*. Also remember that beyond just translating it to C++ would also be the work to maintain it, which would be significant.
We definitely need a pdf export capability, but even more importantly, we need someone to support and maintain it. Ideally, someone within the Inkscape community would step forward and volunteer to do this. Lacking that, the next step is to look outside Inkscape for another group that does it. It would be best to find something that doesn't have a huge installation chore attached to it, as Java-based things often seem to do.
Bryce
Bryce Harrington wrote:
Batik is *huge*. Also remember that beyond just translating it to C++ would also be the work to maintain it, which would be significant.
Okay, it was just a thought - I too, like the idea of the uberconverter and making use of other libs in it (ie the ps2pdf lib) In fact, I also do the routine of export to ps then use ps2pdf which seems to work and the lib seems to come with whatever distro I'm using but it would be easier and safer to have it as part of the program.
Le Tue, 27 Sep 2005 09:59:31 -0700, Bryce Harrington a écrit :
Batik is *huge*. Also remember that beyond just translating it to C++ would also be the work to maintain it, which would be significant.
We definitely need a pdf export capability, but even more importantly, we need someone to support and maintain it. Ideally, someone within the Inkscape community would step forward and volunteer to do this. Lacking that, the next step is to look outside Inkscape for another group that does it. It would be best to find something that doesn't have a huge installation chore attached to it, as Java-based things often seem to do.
An option to produce PDF from inkscape could be to use librsvg with its cairo renderer + cairo PDF backend.
librsvg port to cairo is not complete yet, and cairo PDF backend is still experimental in last stable release, but these libraries are well maintained and improving quickly.
Emmanuel.
On Sep 27, 2005, at 7:51 AM, John Taber wrote:
Is it that hard to translate the java to c++ ? Shouldn't be, though I've learned nothing in software is trivial.
Actually, it should.
There's enough fundamental difference to the languages and libraries that anything non-trivial can't just be translated.
Instead it would need to be re-implemented.
Jon A. Cruz wrote:
On Sep 27, 2005, at 7:51 AM, John Taber wrote:
Is it that hard to translate the java to c++ ? Shouldn't be, though I've learned nothing in software is trivial.
Actually, it should.
There's enough fundamental difference to the languages and libraries that anything non-trivial can't just be translated.
Instead it would need to be re-implemented.
I don't see the problem here at all. Calling out to the Java VM is no harder than calling out to Perl or Python. In fact, Java's C API is actually a lot cleaner than those (especially that awful Perl crappy API).
Give FOP a try in generating PDF's. You will be pleasantly surprised. Try the following test... Save this file as 'master.fo'. Change the svg file name to the desired name:
<?xml version="1.0" encoding="utf-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format%22%3E
<fo:simple-page-master master-name="page"
page-height="297mm" page-width="210mm"
margin-top="20mm" margin-bottom="10mm"
margin-left="25mm" margin-right="25mm">
<fo:region-body margin-top="0mm" margin-bottom="15mm"
margin-left="0mm" margin-right="0mm"/>
<fo:region-after extent="10mm"/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="page">
<fo:flow flow-name="xsl-region-body">
<fo:external-graphic src="tux.svg"/>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
Run this command in the FOP distro dir: sh fop.sh master.fo -pdf output.pdf or on Windows: fop master.fo -pdf output.pdf
...then check it out with Acroreader, and you will see some very good output. Note the fine-grained formatting control one gets with XSL-FO. Also note that the SVG can also be inlined, allowing us the possibility of having another output type.
One can even use FOP to configure a printer server to be able to handle XSL-FO natively. Very nice.
Bob
An aside note: Some people have an irrational Java-phobia. More like a language racism. If it works, it works, whatever the paradigm. Any worthwhile programmer should use every available tool in the toolkit, and not limit himself to any single mode. All of those "X is better than Y" arguments are silly and childish. ;-)
Quoting Bob Jamison <rjamison@...357...>:
I don't see the problem here at all. Calling out to the Java VM is no harder than calling out to Perl or Python. In fact, Java's C API is actually a lot cleaner than those (especially that awful Perl crappy API).
There are Free Perl and Python implementations. There are no Free Java implementations sufficiently capable to run FOP/Batik...
-mental
On Sep 30, 2005, at 8:58 AM, Bob Jamison wrote:
Jon A. Cruz wrote:
On Sep 27, 2005, at 7:51 AM, John Taber wrote:
Is it that hard to translate the java to c++ ? Shouldn't be, though I've learned nothing in software is trivial.
Actually, it should.
There's enough fundamental difference to the languages and libraries that anything non-trivial can't just be translated.
Instead it would need to be re-implemented.
I don't see the problem here at all. Calling out to the Java VM is no harder than calling out to Perl or Python. In fact, Java's C API is actually a lot cleaner than those (especially that awful Perl crappy API).
No,
He was talking about taking all the *.java files and converting them to *.cpp files.
An aside note: Some people have an irrational Java-phobia. More like a language racism. If it works, it works, whatever the paradigm. Any worthwhile programmer should use every available tool in the toolkit, and not limit himself to any single mode. All of those "X is better than Y" arguments are silly and childish. ;-)
Not I.
:-)
I've worked professionally with Java since '95 and '96, and have done many personal and company projects with it.
Just wait till we have nice DOM bindings for external languages. :-D
Bob Jamison wrote:
I don't see the problem here at all. Calling out to the Java VM is no harder than calling out to Perl or Python. In fact, Java's C API is actually a lot cleaner than those (especially that awful Perl crappy API).
I see a few problems: 1. JVM is *not* free software and can't be packaged by 3-rd party distributors; 2. regarding the size, JVM is a bigger dependency compared with either Perl and Python; 3. on a free desktop you have a bigger chance to already have both Perl and Python already installed compared with JVM.
An aside note: Some people have an irrational Java-phobia. More like a language racism. If it works, it works, whatever the paradigm. Any worthwhile programmer should use every available tool in the toolkit, and not limit himself to any single mode.
Depending of a non-free Java VM would impede the freedom of Inkscape as a whole - http://www.gnu.org/philosophy/java-trap.html
Depending of a non-free Java VM would impede the freedom of Inkscape as a whole - http://www.gnu.org/philosophy/java-trap.html
There has been (evidently) some work trying to at least get batik (the svg->pdf/png rasterizer/transcoder) to work with gcj; at the moment its jpeg handling evidently depends on a single chunk of non-standardized (i.e. not supported by gcj/gnu-classpath) java. I can't find anything more contemporary than that.
That said, there appear to be three opinions on what should be done:
1. wait for cairo, with native pdf-backend support 2. keep the existing system, generating ps natively, even though this results in some svg features (transparency being the one that keeps me up at night) not working 2a. Try and add / use a better external dependency, like batik, either rewritten or repackaged. 3. Add in native PDF support by performing a bit of modification on inkscape's internal ps generation routines.
I'm sorry, but as a user I really like option #3. This would let you use cool new PDF features for output, including: 1. transparency 2. layers 3. automatic metadata propagation
Again, these features seem like they'd be a pretty easy extension of our existing ps code... ...Eric
Hi, all!
Actually, I wasn't advocating bundling Java with Inkscape, I was just clarifying a couple of points. There would be severe problems with supplying Java, but they are not license issues. We would do, is inherit a huge problem in the area of support for any software like that. Even now, we get bug reports from people who don't know how to use Perl or Python. Java would be huge.
Nicu Buculei wrote:
Bob Jamison wrote:
I don't see the problem here at all. Calling out to the Java VM is no harder than calling out to Perl or Python. In fact, Java's C API is actually a lot cleaner than those (especially that awful Perl crappy API).
I see a few problems:
- JVM is *not* free software and can't be packaged by 3-rd party
distributors;
Actually, yes it can. The -JDK- can't be bundled, but you don't want to do that anyway. The -JRE- is free to distribute. Originally, Sun's license required that end-users be presented their license to click-thru it, but even that requirement was dropped years ago.
- regarding the size, JVM is a bigger dependency compared with either
Perl and Python;
I agree. It would add 15 MB or so for the JRE.
- on a free desktop you have a bigger chance to already have both
Perl and Python already installed compared with JVM.
I agree with this, too. Such a shame.. If every distro had a good Java VM, imagine the potential for Net-empowerment.
An aside note: Some people have an irrational Java-phobia. More like a language racism. If it works, it works, whatever the paradigm. Any worthwhile programmer should use every available tool in the toolkit, and not limit himself to any single mode.
Depending of a non-free Java VM would impede the freedom of Inkscape as a whole - http://www.gnu.org/philosophy/java-trap.html
Actually, (again ;-) , you can call the VM without adding a dependency. Since JDK1.2, the preferred way of calling the VM from C using the Java Invocation API, is to dynamically (and explicitly) load the shared object via dlopen("libname") , or its Win32 equivalent, then using dlsym(lib, "JNI_CreateJavaVM") , or its Win32 equivalent, then calling that function to get a context and VM pointer. That way an application can pick and choose which VM it wants. That way, also, there is no link dependency. You might have noticed that OpenOffice can work with or without the VM. There is no "can't find shared library 'xxxx'" error message.
R. Stallman is my hero, but I disagree on this topic. This is an irrational religious obsession with him. -Using- the VM does not poison software.
But, no, I don't want to add Java as a dep either. But it -can- be called, and it would probably be good to have the capability to use it as an option.
What I -would- like to see is the ability to export an SVG file in XSL-FO format, to get high-quality printing. This would be an easy XML wrapper of the current SVG output.
Bob
On Oct 3, 2005, at 1:42 PM, Bob Jamison wrote:
Nicu Buculei wrote:
- regarding the size, JVM is a bigger dependency compared with
either Perl and Python;
I agree. It would add 15 MB or so for the JRE.
Or 0 MB or so for OS X.
:-)
- on a free desktop you have a bigger chance to already have both
Perl and Python already installed compared with JVM.
I agree with this, too. Such a shame.. If every distro had a good Java VM, imagine the potential for Net-empowerment.
That's why all modern versions of OS X come with Java as a built-in.
:-)
Depending of a non-free Java VM would impede the freedom of Inkscape as a whole - http://www.gnu.org/philosophy/java-trap.html
[SNIP]
R. Stallman is my hero, but I disagree on this topic. This is an irrational religious obsession with him. -Using- the VM does not poison software.
For the record, I'm pretty much of the same opinion as Bob here.
But, no, I don't want to add Java as a dep either. But it -can- be called, and it would probably be good to have the capability to use it as an option.
And I agree with that also.
Quoting "Jon A. Cruz" <jon@...18...>:
On Oct 3, 2005, at 1:42 PM, Bob Jamison wrote:
Nicu Buculei wrote:
- regarding the size, JVM is a bigger dependency compared
with
either Perl and Python;
I agree. It would add 15 MB or so for the JRE.
Or 0 MB or so for OS X.
Or 0 MB for most Linux users, because there's no easy way to install a working JVM.
Do you really expect most end-users to be able to hunt down and install the blackdown stuff?
That's why all modern versions of OS X come with Java as a built-in.
R. Stallman is my hero, but I disagree on this topic. This is an irrational religious obsession with him. -Using- the VM does not poison software.
Maybe that would be true if there was a sufficiently free VM implementation available...
There's a pragmatic issue at the root of this -- a system is only going to be as free as its least free required component. Do you disagree with that?
But, no, I don't want to add Java as a dep either. But it
-can- be
called, and it would probably be good to have the capability to use it as an option.
And I agree with that also.
Yes, as far as that goes I agree. We just can't make anything critical depend on Java.
-mental
mental@...3... wrote:
Quoting "Jon A. Cruz" <jon@...18...>:
On Oct 3, 2005, at 1:42 PM, Bob Jamison wrote:
Nicu Buculei wrote:
- regarding the size, JVM is a bigger dependency compared
with
either Perl and Python;
I agree. It would add 15 MB or so for the JRE.
Or 0 MB or so for OS X.
Or 0 MB for most Linux users, because there's no easy way to install a working JVM.
Do you really expect most end-users to be able to hunt down and install the blackdown stuff?
Actually, the JRE doesn't need to be 'installed'. What we have done in the past for commercial apps, and which would work for anyone, is also the preferred way of doing it... Bundle the jre as a subdirectory of your app's distro directory, and instead of calling "java ClassName", call "./jre/bin/java ClassName". Often the end user is never aware that he is using a Java app.
But, again, I'm not espousing this for Inkscape.. just describing how this is not necessarily such a horrible monster.
bob
Bob Jamison wrote:
Hi, all!
Actually, I wasn't advocating bundling Java with Inkscape, I was just clarifying a couple of points. There would be severe problems with supplying Java, but they are not license issues.
In my experience there *are* license issues, so this is why I put them up for debate.
Nicu Buculei wrote:
I see a few problems:
- JVM is *not* free software and can't be packaged by 3-rd party
distributors;
Actually, yes it can. The -JDK- can't be bundled, but you don't want to do that anyway. The -JRE- is free to distribute. Originally, Sun's license required that end-users be presented their license to click-thru it, but even that requirement was dropped years ago.
Ok, here we go again! I learned about this a bit from OpenOffice.org, where this debate was very hot some months ago.
http://www.java.com/en/download/license.jsp
"Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that [...] (iii) you do not distribute additional software intended to replace any component(s) of the Software"
So if a distro include any free Java, like gcj or Kaffe is *not* allowed to distribute the JRE. As a consequence, free distros like Debian and Fedora used to package a crippled version of OpenOffice.org, with all Java functionality disabled at build time (but now Fedora include a version of OOo built with gcc 4.0 so the Java requirement is covered by gcj).
The compromise reached for OOo was to continue to use Java but to use only features existing also in a free implementation.
- regarding the size, JVM is a bigger dependency compared with either
Perl and Python;
I agree. It would add 15 MB or so for the JRE.
- on a free desktop you have a bigger chance to already have both
Perl and Python already installed compared with JVM.
I agree with this, too. Such a shame.. If every distro had a good Java VM, imagine the potential for Net-empowerment.
considering the advancements in gcj development, there is a good chance every distro will have a JVM at some point
Depending of a non-free Java VM would impede the freedom of Inkscape as a whole - http://www.gnu.org/philosophy/java-trap.html
Actually, (again ;-) , you can call the VM without adding a dependency. Since JDK1.2, the preferred way of calling the VM from C using the Java Invocation API, is to dynamically (and explicitly) load the shared object via dlopen("libname") , or its Win32 equivalent, then using dlsym(lib, "JNI_CreateJavaVM") , or its Win32 equivalent, then calling that function to get a context and VM pointer. That way an application can pick and choose which VM it wants. That way, also, there is no link dependency. You might have noticed that OpenOffice can work with or without the VM. There is no "can't find shared library 'xxxx'" error message.
Install the OOo 2.0 release candidate without a JRE and try to use any wizard: this will get you an error dialog, also try to use the database component (which has HSQLDB as default)
R. Stallman is my hero, but I disagree on this topic. This is an irrational religious obsession with him. -Using- the VM does not poison software.
But if you need the JVM for some functionality, your software will force the users to install non-free software to work at full capacity.
Quoting Nicu Buculei <nicu@...398...>:
considering the advancements in gcj development, there is a good chance every distro will have a JVM at some point
gcj is the precise opposite of a JVM. The only useful free software Java _VM_ in existence is IKVM ... and that depends on .net/mono ...
-mental
mental@...3... wrote:
Quoting Nicu Buculei <nicu@...398...>:
considering the advancements in gcj development, there is a good chance every distro will have a JVM at some point
gcj is the precise opposite of a JVM. The only useful free software Java _VM_ in existence is IKVM ... and that depends on .net/mono ...
my mistake: I should have said there 'classpath' as it is the common ground of various free Java implementations (http://www.gnu.org/software/classpath/stories.html#jvm)
I know gcj is not a JVM, but it proved in the case of OpenOffice.org it can effectively replace a JVM
aaron@...749... wrote:
Eric Jonas wrote:
Do people feel inkscape should natively output PDF?
<imho> Inkscape should support SVG natively and only SVG. That's our purpose. If we can redirect all filetype conversion efforts to software that has conversion as its purpose, there are gains for the whole community. </imho>
I'll trow my two cents with an user point of view: in many cases SVG is used as an intermediary storage format, with the desired destination for web (PNG) or for print (PDF), so for end users printing is very important. PDF is requested because that is a format most print shops will accept. Also for end users easy installation of Inkscape is important and very big external dependencies, like a full Java stack or a complete Scribus install will not be welcomed for what is perceived as core functionality (printing). Is extremely frustrating to produce a wonderful work in Inkscape and be unable to print it at professional quality.
Is extremely frustrating to produce a wonderful work in Inkscape and be unable to print it at professional quality.
This is exactly what has motivated my recent investigation into this matter. Inkscape is the bees knees, but it's hard to convince people of this when my printer disagrees. As I look through the source, it seems like we natively support postscript generation, but PDF output is handled by calling ps2pdf via an extension; is this correct? ...Eric
participants (11)
-
unknown＠example.com -
Alexandre Prokoudine -
Bob Jamison -
Bryce Harrington -
emmanuel -
Eric Jonas -
Eric Wilhelm -
John Taber -
Jon A. Cruz -
Joshua A. Andler -
Nicu Buculei