RFC: Dealing with version-specific docs

[Gabor Kovesdan]

Em 05-02-2013 11:20, Giorgos Keramidas escreveu:
> I think it's a worthy goal to avoid the huge size of Java dependency for
> a while, and I've seen that there are efforts to write alternatives to
> tools like Saxon.  For example there was a time that I saw even xmlroff
> being discussed for PDF output.  I don't recall right now if it was you,
> Gabor, that brought xmlroff to my attention.
It was me and that time xmlroff wasn't mature enough and it isn't 
actively developed since then so no changes there... But yes, it is one 
alternative and if someone could work on improving it (maybe with some 
support from the Foundation), that would be a nice option. But 
typesetting is a very specific field so developing an XSL FO renderer is 
not a trivial work.
>
> Modernizing the entire toolchain behind textproc/docproj is a large
> project though.  It may require a great upfront investment of time and
> effort.  So I'm not sure if it makes sense to gate other work on this
> being completed first.
>
> If we can do our work with the current tools, even if it means we have a
> bit of duplication like the one you proposed, I think we should go for
> this instead of going the Java way.  Then if we can find a PDF output
> toolchain better than DSSSL (for values of 'better' like 'more modern',
> 'easier to grok', 'faster' or some other possibility) we can adapt the
> tools later.
FOP is already better, it generates modern output where you don't feel 
that typewriter feeling that you feel with our current PDF docs. :) It 
also generates significantly smaller files, yet the generation is slower 
and more resource intensive but this factor nowadays is probably not 
that important since PDF isn't generated with that frequency as XHTML.
>
>> >I mentioned these problems at EuroBSDCon but people were quite
>> >reluctant about the Java dependency even though the XHTML part would
>> >still work without Java.  I think that I have to raise this issue
>> >again.  I've been working on improving the doc tree to use up to date
>> >and better standards than the earlier ones and now I have a branch
>> >with some important updates.  I've maintained compatibility with Jade
>> >but sooner or later we'll have to move away from it. The trivial way
>> >is using Fop (a Java-based XSL FO renderer), which all other open
>> >source projects do that use XML-based documentation.
>> >Some people suggested generating PDF from XHTML which imho is a bad
>> >option since XHTML is not a paper-oriented markup so we loose features
>> >in that way, so I don't believe in its success and I'm not really
>> >willing to work on botches. Now I'll bring the tree technologically up
>> >to date until the point where we can avoid Java but then we will have
>> >to choose how to go beyond.
> XHTML is definitely a very bad option as an intermediate format for PDF
> output.  PDF has all these typographically appealing capabilities that
> we instantly lose just by going through XHTML.  It would make more sense
> to transform docbook-xml to some other intermediate format, e.g. even
> plain LaTeX,
People say Java is heavy-weight but isn't LaTeX almost as heavy? 
Besides, we have good Java support but we cannot affirm the same about 
LaTeX. TeXLive is still not officially supported in ports/packages, 
which is quite a big problem. I've also thought of a possible LaTeX 
conversion but this is also problematic because of the lack of support 
and the big dependency. Besides, the XSLT stylesheets have been 
developed for several years and it raises the question if we can develop 
high quality LaTeX stylesheets in a reasonable timeframe if people have 
been working on other format for various years?
>   or even to explore the possibility of using ConTeXt for
> XML->PDF output:
>
>      http://wiki.contextgarden.net/XML
>
> I admit I have only done very simple things with ConTeXt and XML, so
> it's probably a wild idea.  I'm just mentioning it as a more
> output-quality oriented way of producing PDF output, instead of losing
> pretty much everything in an XHTML temporary stage.
I didn't know this but will take a look, thanks!

Gabor