Hacker News Reader

Comment by strogonoff | Hacker News Reader

A GUI app for manually crafting PDFs is one thing, but a library instead would enable countless developers to create software capable of producing PDF deliverables as output, possibly improving the accessibility situation too.

I would gladly sponsor the development of a reliable library that allows to programmatically produce compliant, accessible tagged PDFs with arbitrary layout[0], correctly printable and viewable by mainstream software.

(Considering it is a difficult, yet to be solved problem, I’d have to know the qualities of the approach that distinguish said library from not-quite-capable attempts that already exist before I commit my personal funds.)

I would not mind if said library’s developers release an entirely paid end-user GUI software based on it, as long as the library itself remains under active maintenance.

[0] Supporting commonly used paged media typesetting features such as headers, footers, page numbers, running headers.

View on HN

Are you familiar with Prawn [1]? Perhaps I just haven't bumped up against its limitations yet, but in my experience it's exactly what you're asking for. Of course, it's in Ruby, which isn't to everyone's taste, but it's the best tool out there that I've found.

[1] https://github.com/prawnpdf/prawn

Prawn was considered and IIRC unfortunately it has very limited styling support.

It looks like there are only commercial and quite expensive options for programmatic generation (Antenna House: XSL-FO, Prince: CSS). Apart from that, the one option that works appears to be Apache FOP. It’s built on Java and uses XSL-FO, which is somewhat limited and seemingly on the way to becoming outdated.

https://weasyprint.org/ is quite nice, though has limited header/footer support (for now).

Check out HexaPDF too, also in Ruby: https://github.com/gettalong/hexapdf

Is it possible to use inkscape as a library? If not you can always use whatever library to produce an SVG and convert it to PDF. Or are there features in PDF that is impossible to produce using SVG?

Most features of PDF can't be produced using SVG. The visual elements are just the surface of what PDFs can do and are used for.

Well, generally it is possible to produce a PDF where each page is one big vector (or even one big raster image for that matter). It would visually look the same as the one created from separate objects and text, but from my understanding with this approach it would be tricky or impossible to create a properly tagged accessible PDF.

That aside, using Inkscape for parts of the doc looked like an interesting idea. I checked and unfortunately the API seems limited. There is a Python plugin system but I don’t think it is possible to create a solution that works entirely headless on CI boxes without having to invoke Inkscape GUI.

Seems a good feature for [0], and I am trying to not ignore this good feature, and still noted it down on my Apple Notes.

Although it seems to be a tough question as well. :p

Guess, you could use PsPDFKit (https://pspdfkit.com) but that costs money but you don't have to deal with all the weirdness of PDF

I should take a deeper look, but at first glance most of its features seem to revolve around working with already existing documents—viewing, annotating, searching, signing, filling out forms.

I would expect other apps to use the core of PEP, Gene. Which will be easy to use as dragging and dropping Gene folder into other projects in Xcode. Gene is a stand alone lib, and is licensed in GPL2.

How would your approach differ from something like RMarkdown or similar? Still trying to nail down the differentiation.

At first approach it seems to be substantially different from what RMarkdown is intended for, though maybe I am not seeing some outside-the-box ways of using it.

What I would like is more oriented around creating documents according to particular layout specs. Documents (books, technical documentation) that can be created using InDesign, but this time programmatically[0].

As content should be authored using semantic markup (for accessible PDFs to be produced), and styling & layout capabilities should be flexible enough, I can see how HTML+CSS paradigm could be viable (and would allow reusing many useful parts from web stack, such as self-containing components).

If going with CSS, the latest spec is close but does not yet seem to be there as far as proper print media layout capabilities. A viable path could be extending an existing engine (Chromium?) specifically where it renders for print media, enabling rendering to accessible tagged PDF, and likely even introducing new styling capabilities making the spec a superset of CSS.

(This all under assumption that it is at all feasible to achieve proper accessible PDF output using browser’s print capabilities.)

[0] I know about variables & data import in InDesign, that is still dependent on GUI so not quite applicable.

I know nothing of InDesign so that's likely where my problem understanding came in :). At work, we have a lot of data-defined reports that will generate daily based on real-world conditions. These reports then go out to business users internally but they're nicely done because they'll occasionally get shared with external audiences. The way the team structured it, which I thought was fairly slick, is they built a bunch of RMarkdown reports that output to LaTex as an intermediary format. Then there's custom LaTex stuff in the pipeline that makes layouts & styling transferable and sharable between the reports. From LaTeX you can go to a number of outputs like html and pdf and it's (I'll probably catch flack for laypersons explanation) maybe a more print-oriented layout/typesetting system, versus html/css which came later. This felt maybe more relevant before than now :)

https://xmlgraphics.apache.org/fop/ or anything TeX related...

reliabrary

Reply on news.ycombinator.com