2:12 p.m.
Hi All,
I believe the broken part of the FDP XML -> PDF toolchain is due to
the passivetex component of the TeX backend.
After discussing the situation with Sebastian Rahtz, the upstream
developer of passivetex, I sadly report that passivetex is no longer
being developed or maintained. The last update, in fact, was in
November 2003.
When I asked Sebastian about the status of passivetex, here's what
he had to say (he gave permission to post his remarks, BTW):
PassiveTeX does what it does, ie about 90% of FO, and thats where
its frozen. Fixing the bugs are now so hard, I cannot do them.
The > decision
to parse the XML using TeX seemed like a good idea,
but in practice its a dead end. If I was starting again I'd work
on a translator to plain TeX markup. thats doable, but a lot of
work.
[...]
I convert my XML direct to LaTeX, and process that. It gives
better results, faster :-}
[...]
others may disagree, but I don't see this particular path
(parsing > XSLFO
using xmltex) ever being able to work 100%
Hence I think it's time to consider a different toolchain for pdf
output.
Two possibilities come to mind: FOP [1] and dblatex [2]. IMO fop
would be the better choice as customizing the output requires XSL
expertise, whereas dblatex requires LaTeX expertise to customize the
output.
If we were to adopt FOP, it would be nice to get it working under
gcj (via gij), so that we stick to a 100% free toolchain, though I
think it will also run under kaffe [3]. Some testing would clearly
need to be done... And if such a toolchain proves sufficient for the
needs of the FDP, it probably wouldn't be too difficult to find
someone to package FOP.
I hope this info helps us get to work on building a new XML -> PDF
toolchain:)
Anyway, that's my $0.02.
Cheers,
Mark
[1] http://xml.apache.org/fop/
[2] http://dblatex.sourceforge.net/
[3] http://www.kaffe.org/
--
----------------------------------------------------------
Mark Johnson <mjohnson(a)redhat.com>
OS Product Documentation
Engineering, Red Hat, Inc. <http://www.redhat.com>
Tel: 919.754.4151 Fax: 919.754.3708
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
3:30 p.m.
On Thu, 2004-09-23 at 12:12, Mark Johnson wrote:
Hi All,
I believe the broken part of the FDP XML -> PDF toolchain is due to
the passivetex component of the TeX backend.
Thanks for bringing this up. Obviously most of our target output is
HTML, but many readers rely upon PDF. It's been bugging me for a while
that we couldn't do this properly.
[snip background on broken tools]
Hence I think it's time to consider a different toolchain for pdf
output.
Agreed.
Two possibilities come to mind: FOP [1] and dblatex [2]. IMO fop
would be the better choice as customizing the output requires XSL
expertise, whereas dblatex requires LaTeX expertise to customize the
output.
Obviously there are going to be many ways to approach this. One reason
I support the FOP choice is because of the momentum of development.
This is more of a personal gut-feeling than proper research.
Mainly, I think our tool choices should tie into our technical
philosophy (open, works, XML) and provide us with a wide pool of
knowledgeable users (DocBook, XML, XSL, FOP).
If we were to adopt FOP, it would be nice to get it working under
gcj (via gij), so that we stick to a 100% free toolchain, though I
think it will also run under kaffe [3]. Some testing would clearly
need to be done... And if such a toolchain proves sufficient for the
needs of the FDP, it probably wouldn't be too difficult to find
someone to package FOP.
Can anyone step up to demonstrate a method to get FOP to compile and run
using gcj and gij?
*wracks his brain thinking of developers he can bargain with ...*
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
9:14 a.m.
Karsten Wade wrote:
On Thu, 2004-09-23 at 12:12, Mark Johnson wrote:
Obviously there are going to be many ways to approach this. One reason
I support the FOP choice is because of the momentum of development.
This is more of a personal gut-feeling than proper research.
Geesh, I went to http://xml.apache.org/fop to get an idea of the
development cycle and found that the latest release (0.20.5) is
dated July 2003. So much for active development. (Yikes!)
FWIW, we (we=some RH Docs folks) did some testing a few months ago
on a doc that had the typical level of complexity that approximated
our needs: variablelists, nested lists, and a number of tables. FOP
produced excellent output with no funky formatting. OTOH, the
passivetex output was quite messed up in a variety of ways (most of
which escape me at the moment). Hence my recommedation to try FOP.
But if there is a better solution, I'm all ears. My concern is
simply to get the print toolchain in working order. Many people
(myself included) *do* want to print out a document to read, rather
than reading from a screen. Yes, we can print out the HTML, but due
to the combo of chunking & formatting, the process is inefficient
and can produce low-quality print copy.
Mainly, I think our tool choices should tie into our technical
philosophy (open, works, XML) and provide us with a wide pool of
knowledgeable users (DocBook, XML, XSL, FOP).
I know this may sound crazy, but if we have to, we can use the
DSSSL/jade toolchain as a last-resort fallback. Of course, doing so
will put some restrictions on the content of the source files (e.g.
no Xincludes), but I don't see this as being a problem, as the
markup used in Fedora docs is not likely to be complex.
DaveP: being the resident XSL-FO expert, what fo -> pdf (or even xml
-> pdf) tool(s) do you recommend?
Can anyone step up to demonstrate a method to get FOP to compile and
run
using gcj and gij?
Strictly speaking, we shouldn't need to recompile it under gcj, but
it's a nice, safe thing to do if we're going to use gij as the java
interpreter.
While on vacation all next week, I'll see if I can get FOP running
under gij (I need to do this for an internal project, anyway) and
will report back when I return.
*wracks his brain thinking of developers he can bargain with ...*
s/bargain with/bribe/
Cheers,
Mark
--
----------------------------------------------------------
Mark Johnson <mjohnson(a)redhat.com>
OS Product Documentation
Engineering, Red Hat, Inc. <http://www.redhat.com>
Tel: 919.754.4151 Fax: 919.754.3708
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
11:58 a.m.
On Fri, 2004-09-24 at 15:14, Mark Johnson wrote:
> DaveP: being the resident XSL-FO expert, what fo ->
pdf (or even xml
> -> pdf) tool(s) do you recommend?
XEP, AH, fop. There are a couple more, but despite its minimal
development, there are a couple of people hard at work on fop.
Its no mean feat.
> > Can anyone step up to demonstrate a method to get
FOP to compile and run
> > using gcj and gij?
> Strictly speaking, we shouldn't need to recompile it
under gcj, but
> it's a nice, safe thing to do if we're going to use gij as the java
> interpreter.
Is that pure NIH, or are there other reasons?
Why make life hard?
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
FWIW, we (we=some RH Docs folks) did some testing a few months ago
on a doc that had the typical level of complexity that approximated
our needs: variablelists, nested lists, and a number of tables. FOP
produced excellent output with no funky formatting. OTOH, the
passivetex output was quite messed up in a variety of ways (most of
which escape me at the moment). Hence my recommedation to try FOP.
The only real place that fop falls down is in the automatic layout
of tables, which is also passivetext weak spot.
For sensible, non-nested stuff, its more than adquate.
I know this may sound crazy, but if we have to, we can use the
DSSSL/jade toolchain as a last-resort fallback. Of course, doing so
will put some restrictions on the content of the source files (e.g.
no Xincludes), but I don't see this as being a problem, as the
markup used in Fedora docs is not likely to be complex.
An XSLT script could be used to test for nasties which would trip
up a fop based toolchain. Perhaps as part of the editorial process?
3:09 p.m.
On Mon, 2004-09-27 at 09:58, Dave Pawson wrote:
On Fri, 2004-09-24 at 15:14, Mark Johnson wrote:
> I know this may sound crazy, but if we have to, we can use the
> DSSSL/jade toolchain as a last-resort fallback. Of course, doing so
> will put some restrictions on the content of the source files (e.g.
> no Xincludes), but I don't see this as being a problem, as the
> markup used in Fedora docs is not likely to be complex.
An XSLT script could be used to test for nasties which would trip
up a fop based toolchain. Perhaps as part of the editorial process?
I like that. Either as part of the editorial process, or as a
pre-processing step in the Makefile.
> DaveP: being the resident XSL-FO expert, what fo -> pdf (or
even xml
> -> pdf) tool(s) do you recommend?
XEP, AH, fop. There are a couple more, but despite its minimal
development, there are a couple of people hard at work on fop.
Its no mean feat.
AH is the tool from Antenna House? Looking over their site, I don't see
a free version. FOP is entirely free, so the is the only possible
choice for Fedora. Unless I missed something about XEP or AH.
> > Can anyone step up to demonstrate a method to get FOP to
compile and run
> > using gcj and gij?
>
> Strictly speaking, we shouldn't need to recompile it under gcj, but
> it's a nice, safe thing to do if we're going to use gij as the java
> interpreter.
Is that pure NIH, or are there other reasons?
Why make life hard?
FOP needs to compile with a free Java compiler and run in a free Java
environment to be part of a completely free toolchain. Personally, I'd
prefer it to be compiled with gcj.
One reason for using gcj for compiling is that if we need to report bugs
with other free software, our components are going to be suspect if they
have been tainted by non-free components during compiling or runtime.
There are developers who will push bug reports back at us in those
situations, and I support them in doing so.
As hard as it may be to start, having a completely free toolchain will
be blessing.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
11:20 a.m.
On Mon, 2004-09-27 at 21:09, Karsten Wade wrote:
> > Strictly speaking, we shouldn't need to recompile it
under gcj, but
> > it's a nice, safe thing to do if we're going to use gij as the java
> > interpreter.
>
> Is that pure NIH, or are there other reasons?
> Why make life hard?
FOP needs to compile with a free Java compiler and run in a free Java
environment to be part of a completely free toolchain.
That's a view. I don't support it.
Sun provide Java. Lets use it.
One reason for using gcj for compiling is that if we need to report bugs
with other free software, our components are going to be suspect if they
have been tainted by non-free components during compiling or runtime.
Your
definition. Not mine.
What's your definition of a bug in this context?
Any reason we shouldn't support fop by feeding back to them?
Or would you prefer to fix them on the version used here?
I can't see the rationale there.
There are developers who will push bug reports back at us in those
situations, and I support them in doing so.
As hard as it may be to start, having a completely free toolchain will
be blessing.
To whom?
Sounds like whipping yourself to me.
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
3:06 p.m.
Dave Pawson <davep <at> dpawson.co.uk> writes:
On Mon, 2004-09-27 at 21:09, Karsten Wade wrote:
> FOP needs to compile with a free Java compiler and run in a free Java
> environment to be part of a completely free toolchain.
That's a view. I don't support it.
Sun provide Java. Lets use it.
FOP is free software. GNU/Linux is free software. There is no need
to use a non-free wedge in between if equivalent[1] free software
replacements exist. :)
> One reason for using gcj for compiling is that if we need to
report bugs
> with other free software, our components are going to be suspect if they
> have been tainted by non-free components during compiling or runtime.
Your definition. Not mine.
Some non-free java compilers are known to generate broken bytecode that
nicely passes through Sun's VM, but fails to meet the constraints of the
JVM specification 2nd edition. Jacks[2] is your friend if you want to
verify quality of java compilers.
What's your definition of a bug in this context?
A bug in the shipped bytecode introduced by a bug in a non-free compiler,
obviously. You can fix the free software ones, but you can't fix the
non-free ones. A cursory glance over the fixed bugs list of the JDK
1.4.2[3] suffices to show that Sun keeps finding and fixing bugs in
their compiler.
Relying on proprietary software for the toolchain puts a free software
distributor at the disadvantage of not being able to fix the bugs
themselves. They end up being at the mercy of the proprietary vendor.
Any reason we shouldn't support fop by feeding back to them?
I don't see how using gcj would prevent feeding back to fop. Would you care
to elaborate?
> As hard as it may be to start, having a completely free
toolchain will
> be blessing.
To whom?
To everyone, obviously. Including Sun.[4]
Given that Sun does not certify JDK on Fedora, what's the point in going
out of one's ways in order to support it? It's not certified to be
compatible anyway, therefore there is no guarantee from Sun that the JDK
on Fedora will behave in the same way as the JDK on a certified
distribution. Why expose oneself to issues that one has no chance of
addressing?
cheers,
dalibor topic
[1] Or better, in my obviously opiniated opinion. :)
[2] http://www-124.ibm.com/developerworks/oss/cvs/jikes/jacks/
[3] http://java.sun.com/j2se/1.4.2/fixedbugs/fixedbugs.html
[4] They'll finally get a break from all the people telling them how to
license Java.
11:35 a.m.
On Tue, 2004-09-28 at 21:06, Dalibor Topic wrote:
> Sun provide Java. Lets use it.
FOP is free software. GNU/Linux is free software. There is no need
to use a non-free wedge in between if equivalent[1] free software
replacements exist. :)
I guessed Karsten was assuming an else, rather than the if
above?
> What's your definition of a bug in this context?
A bug in the shipped bytecode introduced by a bug in a non-free compiler,
obviously. You can fix the free software ones, but you can't fix the
non-free ones. A cursory glance over the fixed bugs list of the JDK
1.4.2[3] suffices to show that Sun keeps finding and fixing bugs in
their compiler.
So... in order to use fop, we need to go hunting for bugs in
alternatives to Sun's java?
Not report it to the fop group?
Relying on proprietary software for the toolchain puts a free software
distributor at the disadvantage of not being able to fix the bugs
themselves. They end up being at the mercy of the proprietary vendor.
> Any reason we shouldn't support fop by feeding back to them?
I don't see how using gcj would prevent feeding back to fop. Would you care
to elaborate?
Just trying to put the focus where it seems to me, to belong.
> > As hard as it may be to start, having a completely free toolchain will
> > be blessing.
>
> To whom?
To everyone, obviously. Including Sun.[4]
Certainly not obvious to me.
Given that Sun does not certify JDK on Fedora, what's the point in going
out of one's ways in order to support it?
Now that's where we differ.
I'd say chasing alts to Sun java was
'going out of ones way', but never mind.
I'm beginning to feel I don't fit with this logic.
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
4:06 p.m.
Dave Pawson <davep <at> dpawson.co.uk> writes:
So... in order to use fop, we need to go hunting for bugs in
alternatives to Sun's java?
No. You are welcome to hunt for bugs, though, and submit patches, bug reports,
critique and sensible comments to respective projects for consideration.
Not report it to the fop group?
I'd assume that the fop group would welcome bug reports from their users.
cheers,
dalibor topic
4:16 p.m.
On Tue, 2004-09-28 at 12:20, Dave Pawson wrote:
On Mon, 2004-09-27 at 21:09, Karsten Wade wrote:
> > > Strictly speaking, we shouldn't need to recompile it under gcj, but
> > > it's a nice, safe thing to do if we're going to use gij as the
java
> > > interpreter.
> >
> > Is that pure NIH, or are there other reasons?
> > Why make life hard?
>
> FOP needs to compile with a free Java compiler and run in a free Java
> environment to be part of a completely free toolchain.
That's a view. I don't support it.
That's a pity, I *do* support it.
Sun provide Java. Lets use it.
Adobe provides Acrobat; shall we simply use that instead? ;-)
> One reason for using gcj for compiling is that if we need to
report bugs
> with other free software, our components are going to be suspect if they
> have been tainted by non-free components during compiling or runtime.
Your definition. Not mine.
What's your definition of a bug in this context?
Any reason we shouldn't support fop by feeding back to them?
Or would you prefer to fix them on the version used here?
I can't see the rationale there.
A look at the kernel developers' list and searching for "Nvidia" might
convince you otherwise.
> There are developers who will push bug reports back at us in
those
> situations, and I support them in doing so.
>
> As hard as it may be to start, having a completely free toolchain will
> be blessing.
To whom?
Sounds like whipping yourself to me.
No, I think it's more a case that Karsten is trying to cleave to the
purpose of the Fedora Project as a 100% free O/S. Violating that
principle on the docs side just means that, at best, we fail to support
or act on a free alternative; at worst, we support a crippled O/S.
IMHO, anyone should be able to use a totally free O/S to "bootstrap" the
building of any component thereof, including docs.
--
Paul W. Frields, RHCE
11:40 a.m.
On Tue, 2004-09-28 at 22:16, Paul W. Frields wrote:
> Sun provide Java. Lets use it.
Adobe provides Acrobat; shall we simply use that instead? ;-)
fop produces pdf
output?
> I can't see the rationale there.
A look at the kernel developers' list and searching for "Nvidia" might
convince you otherwise.
I don't know Paul. No idea what Nvidia is.
> > As hard as it may be to start, having a completely free
toolchain will
> > be blessing.
>
> To whom?
> Sounds like whipping yourself to me.
No, I think it's more a case that Karsten is trying to cleave to the
purpose of the Fedora Project as a 100% free O/S. Violating that
principle on the docs side just means that, at best, we fail to support
or act on a free alternative; at worst, we support a crippled O/S.
IMHO, anyone should be able to use a totally free O/S to "bootstrap" the
building of any component thereof, including docs.
I guess I'd consider that an extremist view. Especially for a tool to
produce documentation, a third order product. How far back does this
view go?
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
4:09 p.m.
Dave Pawson <davep <at> dpawson.co.uk> writes:
fop produces pdf output?
Yes.
I guess I'd consider that an extremist view. Especially for a
tool to
produce documentation, a third order product. How far back does this
view go?
Different people have different standards.
cheers,
dalibor topic
12:08 a.m.
On Wed, 2004-09-29 at 09:40, Dave Pawson wrote:
On Tue, 2004-09-28 at 22:16, Paul W. Frields wrote:
>
> No, I think it's more a case that Karsten is trying to cleave to the
> purpose of the Fedora Project as a 100% free O/S. Violating that
> principle on the docs side just means that, at best, we fail to support
> or act on a free alternative; at worst, we support a crippled O/S.
>
> IMHO, anyone should be able to use a totally free O/S to "bootstrap" the
> building of any component thereof, including docs.
I guess I'd consider that an extremist view. Especially for a tool to
produce documentation, a third order product. How far back does this
view go?
So ... should we abandon all this stuff and use Framemaker + SGML?
Intel makes a proprietary C/C++ compiler, icc. Some call icc a "better"
compiler because it optimizes for x86 (obvious how it gains that
advantage), and these same people wonder why we should use a free
compiler (gcc) since there is a better alternative available?
Forget the idealism for a second. The technical reason is simple.
If I write a program, compile it, and six months later get a bug report,
how do I know if the bug is in my program or the compiler? I don't
know, and I can't know, because I can't look at the source to figure it
out.
If I run my C++ program on Linux and it causes the kernel to fall over,
when I report that to the kernel developers, they are going to want to
see my program, including Makefile. "Gee," they will say, "this looks
like you compile with Intel's proprietary compiler. Since I can't see
the source code for icc, it's impossible for me to know where or what
your problem is. I can't help you, sorry."
Okay, they won't really say "sorry."
It is impossible to debug something happening in a toolchain if there is
a link in the chain that is closed source.
Take the above example, substitute "XEM" for "icc" and "FOP"
for "gcc".
The *entirety* of Fedora _must_be_ free. The point of Fedora
documentation is _not_ to build a toolchain that will run on Solaris,
HP-UX, AIX, Windows, or OSX. It is to build a toolchain that runs under
Fedora. To do that, the packages should be at least part of the Core
packages, and in either case (Core or Extras) they _must_ be 100% free.
It's not like I made up these rules, although I do approve of them with
all my heart.
'Nuff said.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
10:42 a.m.
On Thu, 2004-09-30 at 06:08, Karsten Wade wrote:
> I guess I'd consider that an extremist view. Especially for
a tool to
> produce documentation, a third order product. How far back does this
> view go?
So ... should we abandon all this stuff and use Framemaker + SGML?
More extremism
Karsten?
Forget the idealism for a second. The technical reason is simple.
If I write a program, compile it, and six months later get a bug report,
how do I know if the bug is in my program or the compiler? I don't
know, and I can't know, because I can't look at the source to figure it
out.
Practically speaking, would you be able to resolve compiler bugs?
I know I wouldn't.
It is impossible to debug something happening in a toolchain if there
is
a link in the chain that is closed source.
To which I'd posit the notion of
limited sphere of influence.
I.e. I'm unlikely to use fop in such a way that I'd break the compiler.
The *entirety* of Fedora _must_be_ free.
If that's your position I've no problem with that.
I'll guess that Tammy won't come in on this debate, so
I'll ask how/if/whether that position is supported by others
in this group?
I personally don't think its reasonable for documentation.
The point of Fedora
documentation is _not_ to build a toolchain that will run on Solaris,
HP-UX, AIX, Windows, or OSX. It is to build a toolchain that runs under
Fedora. To do that, the packages should be at least part of the Core
packages, and in either case (Core or Extras) they _must_ be 100% free.
It's not like I made up these rules, although I do approve of them with
all my heart.
OK lets blame someone else.
My usual question now follows. Who?
Can you point to a document/person/project manager who has this
documented somewhere?
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
12:47 p.m.
On Thu, 2004-09-30 at 11:42, Dave Pawson wrote:
On Thu, 2004-09-30 at 06:08, Karsten Wade wrote:
> > I guess I'd consider that an extremist view. Especially for a tool to
> > produce documentation, a third order product. How far back does this
> > view go?
>
> So ... should we abandon all this stuff and use Framemaker + SGML?
More extremism Karsten?
Your use of the word "extremism" is ungracious. I would recommend you
take a look again at the Fedora Project overall goals:
"The goal of The Fedora Project is to work with the Linux community to
build a complete, general purpose operating system exclusively from free
software."
The Docs Project, which is part of the overall Fedora Project, builds
documentation which is to eventually be included in the operating
system, as a fedora-docs RPM I would imagine. Any .src.rpm in the Fedora
tree should be buildable on Fedora itself, with free software. Karsten's
point -- which is the same as my earlier point in essenc, I think,
although Karsten may correct me if I'm wrong -- is that when we add
non-free tools to the toolchain we break the project. Period.
I don't know much about some of the tools whose names have been bandied
about, but that's irrelevant. What is relevant is their status as free
software (or otherwise). If it's not free we shouldn't be using it. To
do otherwise runs directly counter to the ambitions of the Project. It's
not about being a zealot; it's about simply accepting the goals of the
&FP; and the &FDP;. They are what they are, and our project either
follows them or gets jettisoned.
> Forget the idealism for a second. The technical reason is
simple.
>
> If I write a program, compile it, and six months later get a bug report,
> how do I know if the bug is in my program or the compiler? I don't
> know, and I can't know, because I can't look at the source to figure it
> out.
Practically speaking, would you be able to resolve compiler bugs?
I know I wouldn't.
Your skills, my skills, and/or Karsten's skills are not particularly
relevant to the discussion either. You're missing the forest for the
trees here. What Karsten is saying, I think, is that any reliance on
non-free software puts us at the mercy of that tool. You or I might not
be able to resolve compiler bugs, but there are plenty of people working
(either now or in the future) on FDP that could. If any of those people
can't resolve problems because the software isn't free for them to
examine, suggest changes, or fix, then the toolchain is broken by
definition. Making a decision that ties those people's hands based on
our own personal experience or skill set is poor planning and a Bad
Idea(tm).
> It is impossible to debug something happening in a toolchain if
there is
> a link in the chain that is closed source.
To which I'd posit the notion of limited sphere of influence.
I.e. I'm unlikely to use fop in such a way that I'd break the compiler.
Again, your specific case does not override the rule, by which I mean,
the fact that *you* wouldn't use it in that way doesn't mean that *no
one* would do so. In fact, can you guarantee that this problem would
never occur? If you can, I need your help with my investments! :-)
> The *entirety* of Fedora _must_be_ free.
If that's your position I've no problem with that.
I'll guess that Tammy won't come in on this debate, so
I'll ask how/if/whether that position is supported by others
in this group?
I personally don't think its reasonable for documentation.
I don't see why Tammy *wouldn't* enter into this debate. She has done
this kind of work for a while as well, from what I understand, and
probably has some insight too. I'm in agreement with Karsten, for the
reasons stated in my topmost comments.
> The point of Fedora
> documentation is _not_ to build a toolchain that will run on Solaris,
> HP-UX, AIX, Windows, or OSX. It is to build a toolchain that runs under
> Fedora. To do that, the packages should be at least part of the Core
> packages, and in either case (Core or Extras) they _must_ be 100% free.
>
> It's not like I made up these rules, although I do approve of them with
> all my heart.
OK lets blame someone else.
My usual question now follows. Who?
Can you point to a document/person/project manager who has this
documented somewhere?
There's no reason to "blame" anyone. The goals of the Fedora Project are
axiomatic -- or more correctly, maxims, meaning they are principles that
we accept when we participate. Anyone who doesn't agree with them is
free to move ahead with their own project. These goals, and their
antecedents (see above), are not really something subject to discussion
and mitigation.
--
Paul W. Frields, RHCE
1:03 p.m.
On Thu, 2004-09-30 at 18:47, Paul W. Frields wrote:
> > So ... should we abandon all this stuff and use Framemaker
+ SGML?
> More extremism Karsten?
Your use of the word "extremism" is ungracious. I would recommend you
take a look again at the Fedora Project overall goals:
I use extreme in its
simplest form Paul. Out at one end. I never
mentioned Frame or SGML in this thread.
"The goal of The Fedora Project is to work with the Linux community to
build a complete, general purpose operating system exclusively from free
software."
The Docs Project, which is part of the overall Fedora Project, builds
documentation which is to eventually be included in the operating
system, as a fedora-docs RPM I would imagine. Any .src.rpm in the Fedora
tree should be buildable on Fedora itself, with free software. Karsten's
point -- which is the same as my earlier point in essenc, I think,
although Karsten may correct me if I'm wrong -- is that when we add
non-free tools to the toolchain we break the project. Period.
OK, that's enough for me.
I don't know much about some of the tools whose names have been bandied
about, but that's irrelevant. What is relevant is their status as free
software (or otherwise). If it's not free we shouldn't be using it. To
do otherwise runs directly counter to the ambitions of the Project.
Set by RH? A
commercial supplier.
It's
not about being a zealot; it's about simply accepting the goals of the
&FP; and the &FDP;. They are what they are, and our project either
follows them or gets jettisoned.
There are other options.
Your skills, my skills, and/or Karsten's skills are not particularly
relevant to the discussion either. You're missing the forest for the
trees here. What Karsten is saying, I think, is that any reliance on
non-free software puts us at the mercy of that tool.
I'd use the word extreme
again.
I really don't believe the statement above.
I'm in agreement with Karsten, for the
reasons stated in my topmost comments.
OK.
>
> OK lets blame someone else.
> My usual question now follows. Who?
>
> Can you point to a document/person/project manager who has this
> documented somewhere?
There's no reason to "blame" anyone. The goals of the Fedora Project are
axiomatic -- or more correctly, maxims, meaning they are principles that
we accept when we participate. Anyone who doesn't agree with them is
free to move ahead with their own project. These goals, and their
antecedents (see above), are not really something subject to discussion
and mitigation.
So much for community development?
Bye.
3:13 p.m.
On Thu, 2004-09-30 at 14:03, Dave Pawson wrote:
On Thu, 2004-09-30 at 18:47, Paul W. Frields wrote:
> > > So ... should we abandon all this stuff and use Framemaker + SGML?
> > More extremism Karsten?
>
> Your use of the word "extremism" is ungracious. I would recommend you
> take a look again at the Fedora Project overall goals:
I use extreme in its simplest form Paul. Out at one end. I never
mentioned Frame or SGML in this thread.
Dave, I understand that you did not bring up Framemaker or SGML, but you
sound like you're being deliberately obtuse here. Karsten's reply is not
about either of those things in specific.
You originally said that using Sun's Java would be fine. According to
the Fedora Project goals, which you seem to agree with below, that's
*not* fine. What Karsten is trying to tell you above is that if we
follow the logic of using whatever works, even if it's not free, because
that approach is expedient in this particular case, that's what's
referred to as a "slippery slope" argument in logic/philosophy. If it's
OK to do it then, why not use a doc-building tool that's even "less
free"? Why use free tools at all for docs? Why use them for building the
O/S itself?
Do you see what I'm getting at? I think this was the point Karsten was
making. He killed the horse with a single, subtle shot, whereas I am now
beating its dead, flyblown corpse. :-P (yuck, sorry)
> "The goal of The Fedora Project is to work with the Linux
community to
> build a complete, general purpose operating system exclusively from free
> software."
>
> The Docs Project, which is part of the overall Fedora Project, builds
> documentation which is to eventually be included in the operating
> system, as a fedora-docs RPM I would imagine. Any .src.rpm in the Fedora
> tree should be buildable on Fedora itself, with free software. Karsten's
> point -- which is the same as my earlier point in essenc, I think,
> although Karsten may correct me if I'm wrong -- is that when we add
> non-free tools to the toolchain we break the project. Period.
OK, that's enough for me.
Well OK, by this statement, are you saying, "I agree with the goals of
the Fedora Project"? Because if that's what you're saying, we can
proceed with argument (the word "argument" here in its good sense, not
"mindless bickering," which I'm sure you don't want any more than I
do).
If not, there's really no way to discuss this subject.
> I don't know much about some of the tools whose names have
been bandied
> about, but that's irrelevant. What is relevant is their status as free
> software (or otherwise). If it's not free we shouldn't be using it. To
> do otherwise runs directly counter to the ambitions of the Project.
Set by RH? A commercial supplier.
Dave, am I mistaking a tone of "beware the Red (Hat) Menace" in some of
your posts? The Project goals are pretty clear, and have been since the
Fedora Project was started by Warren Togami:
http://www.newsforge.com/article.pl?sid=03/10/01/1417208&mode=thread&...
It's about partnership, not dictatorship. No one has to partner up with
Fedora who isn't interested in its goals. Commercial interests are not
mutually exclusive with the interests of the free software community.
Even RMS agrees with that.
> It's
> not about being a zealot; it's about simply accepting the goals of the
> &FP; and the &FDP;. They are what they are, and our project either
> follows them or gets jettisoned.
There are other options.
Sure; for one thing, people are free to fork if desired. But they lose
some of the infrastructure that Red Hat will be providing for the &FP;
in that case. And it may be slow in coming, but it is coming.
> Your skills, my skills, and/or Karsten's skills are not
particularly
> relevant to the discussion either. You're missing the forest for the
> trees here. What Karsten is saying, I think, is that any reliance on
> non-free software puts us at the mercy of that tool.
I'd use the word extreme again.
I really don't believe the statement above.
How so? You make a sweeping pronouncement that you don't believe it, but
you don't support your position with logic. I'm willing to admit I'm
completely off-base but only if you can prove it to me.
> I'm in agreement with Karsten, for the
> reasons stated in my topmost comments.
OK.
> > OK lets blame someone else.
> > My usual question now follows. Who?
> >
> > Can you point to a document/person/project manager who has this
> > documented somewhere?
>
> There's no reason to "blame" anyone. The goals of the Fedora Project
are
> axiomatic -- or more correctly, maxims, meaning they are principles that
> we accept when we participate. Anyone who doesn't agree with them is
> free to move ahead with their own project. These goals, and their
> antecedents (see above), are not really something subject to discussion
> and mitigation.
So much for community development?
Bye.
Any project, whether it's about free software in one's spare time, or at
one's full-time workplace, has to have goals. The goals must be agreed
upon by participants. In some cases, "agreed upon" == "agreed to",
especially when the goals are established prior to gaining participants.
Again, they're maxims, so if you buy the goals, you now have at least
very basic rules for completing any task under the project.
When I participate in a project in the free software world, I buy into
the goals for the project. There's no barrier to entry; I just decide,
"that sounds good to me," and jump in. If I change my mind, no one bars
my exit either. I can even take the product with me and change it
however I like, but I then have to either (1) get other people to help
me, or (2) do it all myself.
If I buy into the goals, though, everything else follows. 100% free
means just what it says. Our docs are supposed to be buildable under
Fedora, as it is, 100% free, not with third-party proprietary add-ons. I
hope this is easier to understand than what I first wrote, if that was
confusing.
--
Paul W. Frields, RHCE
3:55 p.m.
On Thu, 2004-09-30 at 13:13, Paul W. Frields wrote:
Do you see what I'm getting at? I think this was the point
Karsten was
making. He killed the horse with a single, subtle shot, whereas I am now
beating its dead, flyblown corpse. :-P (yuck, sorry)
I think both you and Dalibor were eloquent and accurate, and I think the
three of us are all essentially saying the same thing.
"Free is free is free." When you introduce non-free, you get a chain
like this: "Free is free is not-free." Ooops, broken.
Here is the bottom line -- we will *not* be able to put a non-free
toolchain in Fedora. We might as well rename our project and do
something else, if that is what we are going to do. The Fedora
community won't stand for it, packages won't get included, etc.
However, if we do the right thing and remain 100% free, then we get the
entire community's support. Meaning compiler engineers will debug our
compiler problems for us. :)
The fact is, no matter what we choose, there will be bugs to fix now and
later. Proprietary software is not free of bugs, it's just free of the
ability to fix it yourself _within_your_community_.
On Thu, 2004-09-30 at 14:03, Dave Pawson wrote:
> So much for community development?
> Bye.
Dave, if this is truly a good-bye, I'm sorry to see you go.
You have brought a perspective and opinion that, at least, keeps us on
our toes. I don't always agree with you, that's obvious, but I
appreciate your input, energy, focus, passion, community spirit, and
expertise. On the last item, the project needs your contributions to
the present and future toolchain, whether done as part of this project,
or just in the work you do otherwise.
However, if you are not playing Devil's advocate or are just
troll-baiting for the fun of it, and you _truly_ disagree with these
simple fundamentals of free software development, then I can't see how
we can work together within the Fedora documentation project.
If there is something you are not understanding or appreciating about
free software and the reality of open source development, I will be
happy to continue to explain. At the moment, it sounds as if we are at
an impasse, in that you disagree with the most basic concepts at the
heart of Fedora.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
3:58 p.m.
Mark Johnson <mjohnson <at> redhat.com> writes:
> Can anyone step up to demonstrate a method to get FOP to compile
and run
> using gcj and gij?
Strictly speaking, we shouldn't need to recompile it under gcj, but
it's a nice, safe thing to do if we're going to use gij as the java
interpreter.
While on vacation all next week, I'll see if I can get FOP running
under gij (I need to do this for an internal project, anyway) and
will report back when I return.
>
> *wracks his brain thinking of developers he can bargain with ...*
s/bargain with/bribe/
For Debian people tried and (almost) succeeded.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271654
In general when you want to get some of these things working with a free
toolchain make sure that you check how the Debian hackers are doing and/or
cooperate with them: http://java.debian.net/index.php/MovingJavaToMain
Last year Dalibor got most of it working with kaffe:
http://www.kaffe.org/pipermail/kaffe/2003-December/096361.html
We have a much more complete class library now (both kaffe and gcj use GNU
Classpath as provider of the core class libraries). But you might need to use
CVS versions of kaffe or gcj. Feel free to ask for support on any of the kaffe,
gcj or GNU Classpath mailinglist if you try it out.
Thanks,
Mark
11:43 a.m.
On Thu, 2004-09-23 at 16:30, Karsten Wade wrote:
On Thu, 2004-09-23 at 12:12, Mark Johnson wrote:
> Hi All,
>
> I believe the broken part of the FDP XML -> PDF toolchain is due to
> the passivetex component of the TeX backend.
Thanks for bringing this up. Obviously most of our target output is
HTML, but many readers rely upon PDF. It's been bugging me for a while
that we couldn't do this properly.
[snip background on broken tools]
> Hence I think it's time to consider a different toolchain for pdf
> output.
Agreed.
> Two possibilities come to mind: FOP [1] and dblatex [2]. IMO fop
> would be the better choice as customizing the output requires XSL
> expertise, whereas dblatex requires LaTeX expertise to customize the
> output.
Obviously there are going to be many ways to approach this. One reason
I support the FOP choice is because of the momentum of development.
This is more of a personal gut-feeling than proper research.
Mainly, I think our tool choices should tie into our technical
philosophy (open, works, XML) and provide us with a wide pool of
knowledgeable users (DocBook, XML, XSL, FOP).
Agreed. If we are going to choose a toolchain, let's try to stick to
open source if possible and one that isn't going to be on the
un-maintained list any time soon.
Mark, thanks for bringing this up again. I hope we can find a reliable
solution soon.
Tammy
> If we were to adopt FOP, it would be nice to get it working
under
> gcj (via gij), so that we stick to a 100% free toolchain, though I
> think it will also run under kaffe [3]. Some testing would clearly
> need to be done... And if such a toolchain proves sufficient for the
> needs of the FDP, it probably wouldn't be too difficult to find
> someone to package FOP.
Can anyone step up to demonstrate a method to get FOP to compile and run
using gcj and gij?
*wracks his brain thinking of developers he can bargain with ...*
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
4:18 a.m.
On Fri, Sep 24, 2004 at 12:43:03PM -0400, Tammy Fox wrote:
Agreed. If we are going to choose a toolchain, let's try to stick
to
open source if possible and one that isn't going to be on the
un-maintained list any time soon.
Also, whichever tool we choose, I would love to add support to xmlto
for using it.
Tim.
*/
3:17 a.m.
On Thu, Sep 23, 2004 at 03:12:13PM -0400, Mark Johnson wrote:
Two possibilities come to mind: FOP [1] and dblatex [2].
Another possibility would be xmlroff, if only it were further along in
its development. Unfortunately it is still in its infancy and there
is a lot of mark-up it doesn't handle yet.
Tim.
*/
3:37 a.m.
On Friday 24 September 2004 10:17, Tim Waugh wrote:
On Thu, Sep 23, 2004 at 03:12:13PM -0400, Mark Johnson wrote:
> Two possibilities come to mind: FOP [1] and dblatex [2].
Another possibility would be xmlroff, if only it were further along in
its development. Unfortunately it is still in its infancy and there
is a lot of mark-up it doesn't handle yet.
Do we need all the mark-up? Do we use all the mark-up?
Maybe it supports the subset of DocBook that we use.
Just an idea; I don't know what is xmlroff and what it supports.
11:52 a.m.
On Thu, 2004-09-23 at 20:12, Mark Johnson wrote:
Hi All,
I believe the broken part of the FDP XML -> PDF toolchain is due to
the passivetex component of the TeX backend.
Its been pretty much unused for a long time now Mark.
> XSLFO using xmltex) ever being able to work 100%
Hence I think it's time to consider a different toolchain for pdf
output.
+1
Two possibilities come to mind: FOP [1] and dblatex [2]. IMO fop
would be the better choice as customizing the output requires XSL
expertise, whereas dblatex requires LaTeX expertise to customize the
output.
+1 to fop.
I'd guess that the majority of customisation could be done via
the xslt. If not I have some familiarity with xsl-fo.
http://www.oreilly.com/catalog/xslfo/index.html
If we were to adopt FOP, it would be nice to get it working under
gcj (via gij), so that we stick to a 100% free toolchain, though I
think it will also run under kaffe [3]. Some testing would clearly
need to be done... And if such a toolchain proves sufficient for the
needs of the FDP, it probably wouldn't be too difficult to find
someone to package FOP.
I hope this info helps us get to work on building a new XML -> PDF
toolchain:)
Is there any substantial objection to using Sun java as part of
a toolchain?
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
1:34 a.m.
On Thu, 2004-09-23 at 12:12, Mark Johnson wrote:
If we were to adopt FOP, it would be nice to get it working under
gcj (via gij), so that we stick to a 100% free toolchain, though I
think it will also run under kaffe [3]. Some testing would clearly
need to be done... And if such a toolchain proves sufficient for the
needs of the FDP, it probably wouldn't be too difficult to find
someone to package FOP.
Considering that we have the attention of Kaffe.org developer(s), I'd
definitely like to try parallel testing with (at least) kaffe and
gcj/gij.
You might think it is preferable to use what has been invented at Red
Hat, where the resources exist for gcj work. It is not preferable. We
all want things to be interoperable and open. Knowing that we can swap
virtual machines means people get to make their own choice about free
notJavaVMs.
For the same reason, perhaps we can (at least) share testing data and
results with Debian people tackling the same issues. It would _rock_ if
we could get FOP to do everything well in all free scenarios.
Perhaps an informal sub-committee? Just people interested in the topic,
keep part of the conversation, and volunteer.
What's next?
Ideas:
* Get a new sub-project into CVS (fedora-docs/toolchain? or somesuch
name). Tammy, Mark, and I can commit into this for now, acting as
conduits for changes from the rest of the project.
* We need
** Someone from kaffe
** Someone from gcj
** A willing FOP expert (either one who knows the code and use, or a
coder and an expert user)
** A DocBook XML expert (or three)
** Volunteers willing to test parallel toolchains
** A Debian liaison
** ???
* ... ?
Just some ideas. I really do mean, "What's next?"
- Karsten, who's volunteering for what he knows -- beta testing
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
2:20 a.m.
On Thursday 30 September 2004 08:34, Karsten Wade wrote:
* We need
** Someone from kaffe
** Someone from gcj
** A willing FOP expert (either one who knows the code and use, or a
coder and an expert user)
** A DocBook XML expert (or three)
** Volunteers willing to test parallel toolchains
I would be interested in testing toolchains, however I need
some instructions on how to do it.
4:40 a.m.
Karsten Wade <kwade <at> redhat.com> writes:
You might think it is preferable to use what has been invented at
Red
Hat, where the resources exist for gcj work. It is not preferable. We
all want things to be interoperable and open. Knowing that we can swap
virtual machines means people get to make their own choice about free
notJavaVMs.
Most of the free runtimes now largely pool together in the development of the
class library by contributing to GNU Classpath, a free as in 'free software'
implementation of the core java class libraries. You are not tied to the mercy
of a single project: there is a whole ecosystem of runtimes targetting different
needs, all willing to help their users, in my experience.
For the same reason, perhaps we can (at least) share testing data
and
results with Debian people tackling the same issues. It would _rock_ if
we could get FOP to do everything well in all free scenarios.
Russ Burton, Arnaud Vandyck & Danniel Bonniot are the debian people that are
actively using or packaging fop on free runtimes there. I will contact them.
Perhaps an informal sub-committee? Just people interested in the
topic,
keep part of the conversation, and volunteer.
Sounds good to me.
What's next?
Ideas:
* Get a new sub-project into CVS (fedora-docs/toolchain? or somesuch
name). Tammy, Mark, and I can commit into this for now, acting as
conduits for changes from the rest of the project.
* We need
** Someone from kaffe
Count me in.
** Someone from gcj
Mark Wielaard could probably recommend someone.
** A willing FOP expert (either one who knows the code and use, or
a
coder and an expert user)
I'll get in touch with FOP developers.
** A Debian liaison
I'll try to find someone from Debian's Java side to participate.
Just some ideas. I really do mean, "What's next?"
I'd also recommend getting in touch with the Java side of fedora, to see what
their FOP packaging plans and requirements are. I believe that Thomas
Fitzsimmons and Fernando Nasser are working on making JPackage work with gcj,
they may be able to comment.
cheers,
dalibor topic
2:29 p.m.
Karsten Wade wrote:
Perhaps an informal sub-committee? Just people interested in the topic,
keep part of the conversation, and volunteer.
Sounds good. I'll volunteer for this.
What's next?
Ideas:
* Get a new sub-project into CVS (fedora-docs/toolchain? or somesuch
name). Tammy, Mark, and I can commit into this for now, acting as
conduits for changes from the rest of the project.
* We need
** Someone from kaffe
** Someone from gcj
** A willing FOP expert (either one who knows the code and use, or a
coder and an expert user)
** A DocBook XML expert (or three)
I'm willing to work on the xsl-fo customization, when we get there.
** Volunteers willing to test parallel toolchains
I'm also willing to test toolchains.
** A Debian liaison
If we can't get one of the Debian Java developers [1,2] (Arnaud
Vandyck <avdyk(a)debian.org> comes to mind), in the meantime I'm happy
to volunteer to serve as the Debian liaison. I'm a Debian XML
developer/packager/policy editor and packaged some of the java
tools. (Whoops, I just read Dalibor's message - I'll leave the
debian contacts to him.)
[1] http://pkg-java.alioth.debian.org/
[2] http://alioth.debian.org/projects/pkg-java/
** ???
I'm willing to ask questions:) And supply asterisks.
BTW, I noticed that the debian fop package info used to imply that fop
would run under kaffe. Dalibor: do you know if this is the case?
Just some ideas. I really do mean, "What's next?"
I think Dalibor laid out a pretty decent plan. Below I state his
suggestions and add some of my own.
A. Document the issues the debian java group has had getting fop to
compile &/or run under gcj, and work with them (& other relevant
groups/developers) to resolve outstanding issues.
B. Determine if fop will run under kaffe, as an alternative
C. Ask Mark Wielaard who he recommends as a gcj contact.
I'd also recommend getting in touch with the Java side of fedora,
to see what their FOP packaging plans and requirements are. I
believe that Thomas Fitzsimmons and Fernando Nasser are working
on > making
JPackage work with gcj, they may be able to comment.
D. Either contact the JPackage folks via this list, or designate a
liaison to initiate a dialog with them and report back to this list.
Hopefully hook them up with the debian java group, so as to avoid
duplicate efforts.
E. Form a subcommittee to make A - D above happen.
Cheers,
Mark
-
--
----------------------------------------------------------
Mark Johnson <mjohnson(a)redhat.com>
OS Product Documentation
Engineering, Red Hat, Inc. <http://www.redhat.com>
Tel: 919.754.4151 Fax: 919.754.3708
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
7134
days inactive
7148
days old
28 comments
9 participants
participants (9)
-
Dalibor Topic -
Dashamir Hoxha -
Dave Pawson -
Karsten Wade -
Mark Johnson -
Mark Wielaard -
Paul W. Frields -
Tammy Fox -
Tim Waugh