6:46 p.m.
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
6:38 a.m.
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
6:54 a.m.
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&g...
Alexandre
7:23 a.m.
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
7:41 a.m.
>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
8:04 a.m.
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
8:55 a.m.
# 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
--
Issues of control, repair, improvement, cost, or just plain
understandability all come down strongly in favor of open source
solutions to complex problems of any sort.
--Robert G. Brown
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
9:17 a.m.
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
9:51 a.m.
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
10:05 a.m.
# 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
--
"Because understanding simplicity is complicated."
--Eric Raymond
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
10:10 a.m.
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
10:55 a.m.
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_...
-Josh
9:51 a.m.
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. :)
7:51 a.m.
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.
9:59 a.m.
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
11:27 a.m.
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.
1:20 p.m.
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.
7:16 p.m.
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.
8:58 a.m.
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">
<fo:layout-master-set>
<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:block>
<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. ;-)
12:58 p.m.
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
4:04 p.m.
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
1:52 a.m.
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
4:41 p.m.
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
1:42 p.m.
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:
1. 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.
2. 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.
3. 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
9:21 p.m.
On Oct 3, 2005, at 1:42 PM, Bob Jamison wrote:
Nicu Buculei wrote:
> 2. 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.
:-)
> 3. 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.
9:34 a.m.
Quoting "Jon A. Cruz" <jon@...18...>:
On Oct 3, 2005, at 1:42 PM, Bob Jamison wrote:
> Nicu Buculei wrote:
>
>> 2. 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
10:12 a.m.
mental@...3... wrote:
Quoting "Jon A. Cruz" <jon@...18...>:
>On Oct 3, 2005, at 1:42 PM, Bob Jamison wrote:
>
>
>
>>Nicu Buculei wrote:
>>
>>
>>
>>>2. 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
11:40 p.m.
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:
> 1. 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.
> 2. 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.
> 3. 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.
--
nicu
9:37 a.m.
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
10:46 p.m.
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
--
nicu
7:53 a.m.
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.
--
nicu
8:17 a.m.
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
6631
days inactive
6641
days old
inkscape-devel@lists.inkscape.org
32 comments
11 participants
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