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/
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 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
On Fri, 2004-09-24 at 15:14, Mark Johnson wrote:
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?
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?
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
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.
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.
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.
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
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.
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?
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
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
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?
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.
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.
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.
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
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
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
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. */
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. */
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.
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?
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
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.
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
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@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
-
docs@lists.stg.fedoraproject.org
-
Dalibor Topic -
Dashamir Hoxha -
Dave Pawson -
Karsten Wade -
Mark Johnson -
Mark Wielaard -
Paul W. Frields -
Tammy Fox -
Tim Waugh