Am 17.10.2010 19:45, schrieb Walter Bright

> Apparently, it is fairly simple to convert plain text files to PDF.
>
> http://re-factor.blogspot.com/2010/10/text-to-pdf.html
>
> Which suggests to me it should be equally simple to create a Ddoc macro file to allow Ddoc to emit pdf files directly.
>
> Anyone want a nice weekend project to product this?
>

I don't think that it is the best idea to produce a pdf in one step.
First PDF is really complicated (and also evolves over time).
Second this would require dmd to determine the layout of the generated
documentation.

We could easily avoid the frist point. When we just make ddoc generating xsl-fo a tool like apache fop can be used to generate pdf or html from it. This is what xsl-fo is designed for. It's not rocket science to create a xsl-fo layout. But the second problem remains. If i where a company or community writing libraries in d i would like to have some corporate identity in it. This means that I want to decide over the layout. So i would really prefer if ddoc were *additionaly* able to generate a pure semantical version of the document data that is easy to mess with an external tool. This can be a simple xml file which i can feed into my own transformation pipline. This way ddoc does the part it can really shine on, extracting the information, and delegates the rest to something that knows more about the wishes of the actual user.

This shuoldn't  mean that ddoc should stop generating unified standart documentation. But i think it is worth a thought to generate semantic data files on request.

Gerrit

Having two modes? - the basic standart one, and a flag switched one?

On 19 October 2010 15:14, Gerrit Wichert <gwichert@yahoo.com> wrote:

> Am 17.10.2010 19:45, schrieb Walter Bright
>
> > Apparently, it is fairly simple to convert plain text files to PDF.
> >
> > http://re-factor.blogspot.com/2010/10/text-to-pdf.html
> >
> > Which suggests to me it should be equally simple to create a Ddoc macro file to allow Ddoc to emit pdf files directly.
> >
> > Anyone want a nice weekend project to product this?
> >
>
> I don't think that it is the best idea to produce a pdf in one step.
> First PDF is really complicated (and also evolves over time).
> Second this would require dmd to determine the layout of the generated
> documentation.
>
> We could easily avoid the frist point. When we just make ddoc generating xsl-fo a tool like apache fop can be used to generate pdf or html from it. This is what xsl-fo is designed for. It's not rocket science to create a xsl-fo layout. But the second problem remains. If i where a company or community writing libraries in d i would like to have some corporate identity in it. This means that I want to decide over the layout. So i would really prefer if ddoc were *additionaly* able to generate a pure semantical version of the document data that is easy to mess with an external tool. This can be a simple xml file which i can feed into my own transformation pipline. This way ddoc does the part it can really shine on, extracting the information, and delegates the rest to something that knows more about the wishes of the actual user.
>
> This shuoldn't  mean that ddoc should stop generating unified standart documentation. But i think it is worth a thought to generate semantic data files on request.
>
> Gerrit
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

On 19.10.2010 15:14, Gerrit Wichert wrote:
> Am 17.10.2010 19:45, schrieb Walter Bright
>
>> Apparently, it is fairly simple to convert plain text files to PDF.
>>
>> http://re-factor.blogspot.com/2010/10/text-to-pdf.html
>>
>> Which suggests to me it should be equally simple to create a Ddoc
>> macro file to allow Ddoc to emit pdf files directly.
>>
>> Anyone want a nice weekend project to product this?
>>
>
> I don't think that it is the best idea to produce a pdf in one step.
> First PDF is really complicated (and also evolves over time).
> Second this would require dmd to determine the layout of the generated
> documentation.
>
> We could easily avoid the frist point. When we just make ddoc generating
> xsl-fo a tool like apache fop can be used to generate pdf or html from
> it. This is what xsl-fo is designed for. It's not rocket science to
> create a xsl-fo layout. But the second problem remains. If i where a
> company or community writing libraries in d i would like to have some
> corporate identity in it. This means that I want to decide over the
> layout. So i would really prefer if ddoc were *additionaly* able to
> generate a pure semantical version of the document data that is easy to
> mess with an external tool. This can be a simple xml file which i can
> feed into my own transformation pipline. This way ddoc does the part it
> can really shine on, extracting the information, and delegates the rest
> to something that knows more about the wishes of the actual user.
>
> This shuoldn't  mean that ddoc should stop generating unified standart
> documentation. But i think it is worth a thought to generate semantic
> data files on request.
>
> Gerrit

I agree but maybe DDoc as it is now is already enough. I haven't looked closely at the HTML DDoc generates but from what I've seen on the D home page it looks expressive enough. This HTML code can be converted to PDF with [PrinceXML][1] and you have all the flexibility of CSS at your disposal (I know not everyone likes CSS…).

Letting the compiler do the layout of the PDF generation might be overkill. It's a compiler and not a layout engine.

[1]: http://www.princexml.com/

Happy programming
Stephan

On Tue, 19 Oct 2010 15:14:13 +0200
>>>>>> "Gerrit" == Gerrit Wichert <gwichert@yahoo.com> wrote:

Gerrit> When we just make ddoc generating xsl-fo a tool like apache Gerrit> fop can be used to generate pdf or html from it. This is what Gerrit> xsl-fo is designed for. It's not rocket science to create a Gerrit> xsl-fo layout.

Uhh...xsl & fop...I quickly run away from those tools.

Why not just creating some 'standard markup (markdown, reST...) which can be later post-processed into html/pdf/man/...?

Otoh, I'm quite satisfied having some macros to produce LateX, although having e.g. reST markup and processing it with Sphinx gives nice output (HTML- including Windows HTML Help, LaTeX manual pages, plain text) if there is no NIH problem.


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------

David Gileadi wrote:
> Apple has been notorious for making it hard to load files onto their iOS devices.  Recently in iOS 4 they've provided for it through iTunes, but it's still very clunky.  For PDFs I use GoodReader which makes it somewhat easy to load files wirelessly and whose claim to fame is that it supports very large PDFs without crashing.

I haven't had problems with Apple's ipod pdf reader crashing. Just getting files to it! It's very strange that Safari on the ipod cannot look at files on shares on my LAN, whereas Safari on OSX can (and every other browser can, too).