On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote:
> On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote:
>> I used text files and LaTeX in the past, it works with everything
>>
>> textfile -> process -> LaTeX -> pdf
>
> This.
>
> Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf.


Then that begs the question about how to generate ps in D and just kicks the can down the road.

On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote:
> On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote:
>> On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote:
>>> I used text files and LaTeX in the past, it works with everything
>>>
>>> textfile -> process -> LaTeX -> pdf
>>
>> This.
>>
>> Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf.
>
>
> Then that begs the question about how to generate ps in D and just kicks the can down the road.

PostScript is a programming language and PS files are plain text files with programs written in it, so formatted file output is your friend here.

"Lower-level" means that you need to take care of the layout of items on a page manually, using physical positions. It's quite straightforward for simple vector graphics, but not so much for multi-page text documents with figures and tables.

On Tuesday, 15 November 2016 at 15:23:29 UTC, Adrian Matoga wrote:
> On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote:
>> On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote:
>>> On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote:
>>>> I used text files and LaTeX in the past, it works with everything
>>>>
>>>> textfile -> process -> LaTeX -> pdf
>>>
>>> This.
>>>
>>> Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf.
>>
>>
>> Then that begs the question about how to generate ps in D and just kicks the can down the road.
>
> PostScript is a programming language and PS files are plain text files with programs written in it, so formatted file output is your friend here.
>
> "Lower-level" means that you need to take care of the layout of items on a page manually, using physical positions. It's quite straightforward for simple vector graphics, but not so much for multi-page text documents with figures and tables.

Cairo can render to a postscript surface and PDF surface[1]. Maybe there is something in gtkd that suits your needs[2]?

[1] https://www.cairographics.org/manual/cairo-PDF-Surfaces.html
[2] http://gtkd.org/

On Tuesday, 15 November 2016 at 15:23:29 UTC, Adrian Matoga wrote:
> On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote:
>> On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote:
>>> On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote:
>>>> I used text files and LaTeX in the past, it works with everything
>>>>
>>>> textfile -> process -> LaTeX -> pdf
>>>
>>> This.
>>>
>>> Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf.
>>
>>
>> Then that begs the question about how to generate ps in D and just kicks the can down the road.
>
> PostScript is a programming language and PS files are plain text files with programs written in it, so formatted file output is your friend here.
>
> "Lower-level" means that you need to take care of the layout of items on a page manually, using physical positions. It's quite straightforward for simple vector graphics, but not so much for multi-page text documents with figures and tables.

What's your point?

"PDF is largely based on PostScript but simplified to remove flow control features like these, while graphics commands such as lineto remain.

As a document format, PDF has several advantages over PostScript:

    PDF contains tokenized and interpreted results of the PostScript source code, for direct correspondence between changes to items in the PDF page description and changes to the resulting page appearance.
    PDF (from version 1.4) supports true graphic transparency; PostScript does not.
    PostScript is an interpreted programming language with an implicit global state, so instructions accompanying the description of one page can affect the appearance of any following page. Therefore, all preceding pages in a PostScript document must be processed to determine the correct appearance of a given page, whereas each page in a PDF document is unaffected by the others. As a result, PDF viewers allow the user to quickly jump to the final pages of a long document, whereas a PostScript viewer needs to process all pages sequentially before being able to display the destination page (unless the optional PostScript Document Structuring Conventions have been carefully complied with).
"

On Wednesday, 16 November 2016 at 01:22:33 UTC, Jot wrote:

> What's your point?

My point is that PS as a textual format can be easily generated without external libraries or tools, and then converted to an identically looking PDF.

On Thursday, 10 November 2016 at 22:30:34 UTC, Karabuta wrote:
> Hello community, does anyone have on something for PDF generation in D? I may need a PDF generation library in a vibe.d project I'm working on. :)

Hi,

I did read all the replies posted up to now. Posting a few alternative methods I thought of, some of which involve calling C libraries from D - not sure how suitable they will be for your specific needs, some checking will be required:

- check out libharu - it is an open source C library for PDF generation. If you can call it from D, it may work for your needs.

http://libharu.org/ . Libharu needs a new maintainer now, but the site says it still works.

- check out PDFlib(.com). PDFlib is a paid product, and the core is a C library. However it has an open source version IIRC, and may be free for personal use (not sure if you want this for personal or commercial use). Again, would need to call it's (C) functions from D. PDFlib is a mature product which has been around for many years. It also has binding to some other languages.

(I've tried both the above libs at least a bit, and they do work.)

- this one is an obvious, though roundabout method: if the D- and C-based ones are not suitable for whatever reason, there are generic methods applicable to calling (a program that uses) a PDF-generation library (or any library for that matter) in any other language, such as via XML-RPC (if D has a client library for that, or if D can call a C client XML-RPC library), REST or sockets.

- an even simpler method than above (though, of course, less efficient for multiple calls) may be to shell out to some executable [1] written in another language which has a PDF generation library, pass the necessary inputs on the command line (as command-line options,  an input file name, and an output PDF filename.

[1] By executable here, I don't only mean a compiled user executable such as a C or C++ or Java app. It could also be a call to a language interpreter (the executable) taking a script in that language, as an argument to run, and the script name could be followed by arguments for the script itself (e.g. python pdf_gen_prog.py arg1 arg2 ...) . Using this approach, for example, one could shell out to Python, run a Python script that uses ReportLab, and use that to do the job, since ReportLab is fairly powerful for PDF generation, though a bit low-level. However, it does have things like Paragraphs, Stories, Styles, and Platypus which are a bit higher-level. And if your PDF output involves only text (i.e. no images, charts, varying fonts, etc.), then you can even consider shelling out to a Python program you write, that uses xtopdf - which is my PDF generation toolkit written in Python, which uses ReportLab internally, and provides a somewhat higher abstraction for a subset of ReportLab's functionality, namely generation of text-only line-oriented PDF output, with automatic headers, footers, page numbering and pagination). xtopdf is quite easy to use: With low-level Reportlab features, you have to write your PDF generation logic in terms of operations on a Canvas object, not lines of text, so you have to say things like writeString(x, y, string), and calculate each x and y, reset the font to the same value after each new page (a limitation), but with xtopdf you get the higher level abstraction of something like a text file (a PDFWriter object), and you just write lines of text to the PDFWriter object using its writeLine(string) method, until you are done. Just have to set the header and footer and font once, first (3 lines for that). Total for a simple file is under 10 or so lines of Python code, to generate a PDF from text input, using xtopdf - with some amount of simple customized formatting of the text possible, in terms of left-or-right-justifying, centering, etc., using Python's easy string handling, with a few more lines of code.

ReportLab main site: http://reportlab.com

ReportLab open source version: http://reportlab.com/ftp

Good high-level overview of xtopdf: http://slides.com/vasudevram/xtopdf (including uses, users, supported input formats, supported platforms, example programs, etc.)

xtopdf on Bitbucket: https://bitbucket.org/vasudevram/xtopdf

xtopdf examples on my blog: http://jugad2.blogspot.com/search/label/xtopdf

Guide to installing and using xtopdf:

http://jugad2.blogspot.in/2012/07/guide-to-installing-and-using-xtopdf.html

HTH,
Vasudev
jugad2.blogspot.com
vasudevram.github.io

On Tuesday, 22 November 2016 at 18:49:51 UTC, Vasudev Ram wrote:

> - check out libharu - it is an open source C library for PDF

P.S. I just saw here:

http://code.dlang.org/packages/fpdf

that they say "If you don't need to be able to import PDFs, you may want to check out harud"  - which by the name is probably a D wrapper for libharu.

On Thursday, 10 November 2016 at 22:30:34 UTC, Karabuta wrote:
> Hello community, does anyone have on something for PDF generation in D? I may need a PDF generation library in a vibe.d project I'm working on. :)

Try http://code.dlang.org/packages/harud, a D binding to libharu.