Johan Granberg wrote:
> Walter Bright wrote:
> 
> 
>>I've been taking some heat lately about the D web site not making
>>available a PDF version of the D manual that can be downloaded, printed,
>>and read offline.
>>
>>I know some people have made PDFs of the manual before. The trouble is,
>>they rapidly go out of date.
>>
>>So I'm interested in if anyone can recommend a tool that can take text
>>and convert it to PDFs. I'm not interested in a tool with a gui
>>interface, I want one that can be driven from a script, so this can be
>>done automatically with each new release.
>>
>>(The html version of the manual is currently created automatically using
>>a script from Ddoc text files. Such has really cut the workload of
>>maintaining a common look/feel of the site.)
> 
> 
> You could probably make Ddoc output to latex and then compile that into pdf.
> 

Dosn't DDoc have the processing macros in another file? IIRC it should be easy to have it dump both HTML and LaTeX and dump the latex into a PDF.

p.s. If you don't alredy have it, this is a farly painless LaTeX for win package:
http://www.miktex.org/

> 
> htmldoc should be able to do what you want. If started without any
> arguments, it pops up a gui, but it should be no problem to script it.
> 
> http://www.htmldoc.org
> 
> It should be easily available for your Linux distribution, seems to be more
> troublesome to find a free Windows download.
> 

Windows version 1.8.24
http://users.tpg.com.au/naffall/htmldoc.html

On Wed, 29 Nov 2006 21:14:12 +0100, Lars Ivar Igesund <larsivar@igesund.net> wrote:

>htmldoc should be able to do what you want. If started without any arguments, it pops up a gui, but it should be no problem to script it.
>
>http://www.htmldoc.org
>
>It should be easily available for your Linux distribution, seems to be more troublesome to find a free Windows download.

I have an older Windows version - v1.8.23, with source - if needed, from when it was still easy to get the free version. AFAIK it is legal to share it.

I always used the GUI to set things up, but then used the command line to do updates. It mostly worked well, so long as you are aware of it's little quirks (e.g. it used to fail if it couldn't find a H1). The only thing is that between MikTeX, OpenOffice 2, and the fact that I shelled out for Adobe Creative Suite last year, I don't have any real use for it any more and stopped looking for updates quite a while ago.

-- 
Remove 'wants' and 'nospam' from e-mail.

On Thu, 30 Nov 2006 01:27:04 +0100, Markus Dangl <danglm@in.tum.de> wrote:

>Lars Ivar Igesund schrieb:
>> A solution that would be more troublesome to implement at first, but that would be more powerful later (and for the D community at large), is to make it possible for DDoc to output DocBook XML (see http://www.docbook.org ), which through some careful transformations can be transformed to any format you like (for X/HTML, just XSL transformations are necessary, using XSL transformations + a XSL-FO processor like FOP (http://xmlgraphics.apache.org/fop), almost any format can be produced, including PDF), and all from the same XML sources.
>> 
>> If someone would like to go this route, I might be able to give further tips, I'm setting up a similar process where I'm currently working.
>> 
>
>This is almost what i intended to do by making DDoc spit out (custom) XML for me. But since DDoc allows for HTML Tags to be included in the documentation i couldn't get it working without additional tools, and thats the point where i left...

Here's an admittedly long term thought...

1.  Find out which HTML tags actually get used in DDoc.
2.  Set up DDoc so it recognises those tags, and rejects any it
    doesn't know.
3.  Extend DDoc so it can generate other formats.

-- 
Remove 'wants' and 'nospam' from e-mail.

Markus Dangl wrote:

> Lars Ivar Igesund schrieb:
>> A solution that would be more troublesome to implement at first, but that would be more powerful later (and for the D community at large), is to make it possible for DDoc to output DocBook XML (see http://www.docbook.org ), which through some careful transformations can be transformed to any format you like (for X/HTML, just XSL transformations are necessary, using XSL transformations + a XSL-FO processor like FOP (http://xmlgraphics.apache.org/fop), almost any format can be produced, including PDF), and all from the same XML sources.
>> 
>> If someone would like to go this route, I might be able to give further tips, I'm setting up a similar process where I'm currently working.
>> 
> 
> This is almost what i intended to do by making DDoc spit out (custom) XML for me. But since DDoc allows for HTML Tags to be included in the documentation i couldn't get it working without additional tools, and thats the point where i left...

That is a problem, possibly one could use XML namespaces to separate the DocBook from the rest. Still, if one wants to use the XML to generate PDF, then having HTML in there is not a good thing. Should be possible to transform the HTML to DocBook though.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Lars Ivar Igesund wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>> (The html version of the manual is currently created automatically using a script from Ddoc text files. Such has really cut the workload of maintaining a common look/feel of the site.)
>> htmldoc should be able to do what you want. If started without any arguments, it pops up a gui, but it should be no problem to script it.
>>
>> http://www.htmldoc.org
>>
>> It should be easily available for your Linux distribution, seems to be more troublesome to find a free Windows download.
> 
> A solution that would be more troublesome to implement at first, but that would be more powerful later (and for the D community at large), is to make it possible for DDoc to output DocBook XML (see http://www.docbook.org ), which through some careful transformations can be transformed to any format you like (for X/HTML, just XSL transformations are necessary, using XSL transformations + a XSL-FO processor like FOP (http://xmlgraphics.apache.org/fop), almost any format can be produced, including PDF), and all from the same XML sources.

I've used DDoc + some xml generation rules found in this ng a year or two ago for small projects. Then converted the xml to pdf using FOP. I think the weakest link is the DDoc implementation. It does not always generate valid and/or well-formed xml so I have made ad hoc filtering rules for the "xml"-like output. Also the FOP generates separate pdf files for every source file. I've just put them together with pdftk.

> If someone would like to go this route, I might be able to give further tips, I'm setting up a similar process where I'm currently working.

I would prefer adding a proper support for D syntax and semantics to doxygen. There's not much point in reinventing the wheel again.

Jari-Matti Mäkelä wrote:

> Lars Ivar Igesund wrote:
>> Lars Ivar Igesund wrote:
>>> Walter Bright wrote:
>>>> (The html version of the manual is currently created automatically using a script from Ddoc text files. Such has really cut the workload of maintaining a common look/feel of the site.)
>>> htmldoc should be able to do what you want. If started without any arguments, it pops up a gui, but it should be no problem to script it.
>>>
>>> http://www.htmldoc.org
>>>
>>> It should be easily available for your Linux distribution, seems to be more troublesome to find a free Windows download.
>> 
>> A solution that would be more troublesome to implement at first, but that would be more powerful later (and for the D community at large), is to make it possible for DDoc to output DocBook XML (see http://www.docbook.org ), which through some careful transformations can be transformed to any format you like (for X/HTML, just XSL transformations are necessary, using XSL transformations + a XSL-FO processor like FOP (http://xmlgraphics.apache.org/fop), almost any format can be produced, including PDF), and all from the same XML sources.
> 
> I've used DDoc + some xml generation rules found in this ng a year or two ago for small projects. Then converted the xml to pdf using FOP. I think the weakest link is the DDoc implementation. It does not always generate valid and/or well-formed xml so I have made ad hoc filtering rules for the "xml"-like output. Also the FOP generates separate pdf files for every source file. I've just put them together with pdftk.

Since the DocBook documents can import others, and you can pass only the main one to FOP, it should be possible to create partial DocBook documents, for instance chapters, and import those in the main document. For larger documents, it almost always is smart to divide into several XML files in any case.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Lars Ivar Igesund wrote:
> Since the DocBook documents can import others, and you can pass only the main one to FOP, it should be possible to create partial DocBook documents, for instance chapters, and import those in the main document. For larger documents, it almost always is smart to divide into several XML files in any case.

Sure. I've just used DDoc for very small projects. I find myself much more productive using doxygen because of the integrated class hierarchy / call graphs. It's just that it needs some preprocessing to be able to handle some of the "newest" features like templates and inner classes.

On Thu, 30 Nov 2006 11:42:27 +0200, Jari-Matti Mäkelä <jmjmak@utu.fi.invalid> wrote:

>I would prefer adding a proper support for D syntax and semantics to doxygen. There's not much point in reinventing the wheel again.

Yes, but then adding D support to Doxygen is re-inventing the wheel in the sense that Doxygen then has to parse and understand D.

Also, I quite like the idea that documentation, unit tests, and target code all reflect the exact same understanding of the original source code. If you use Doxygen and VC++, you'll find some odd things occasionally happen in documentation because Doxygen doesn't understand some Microsoft-specific code (__if_exists for instance).

What might be nice is a standardised intermediate format that compilers could generate, and documentation tools could then process.

-- 
Remove 'wants' and 'nospam' from e-mail.

Steve Horne wrote:

>>I would prefer adding a proper support for D syntax and semantics to
>>doxygen. There's not much point in reinventing the wheel again.
> 
> Yes, but then adding D support to Doxygen is re-inventing the wheel in
> the sense that Doxygen then has to parse and understand D.

Doxygen currently understands a simple subset of "D 1.0",
even if doesn't understand much of templates and "D 2.0".
(Currently using it instead of Ddoc, which just outputs
blank for all code that doesn't have any comments added ?)

We've been using this to share docs between D/C#/Java,
that also have one "native" documentation format each.
I'm sure the D support in Doxygen could be improved...
http://www.prowiki.org/wiki4d/wiki.cgi?DoxygenIssues

But for the D "manual" (specification), there are probably
better formats to use than those done for commenting code ?

--anders