LaTeX is the first PDF/UA-2 compliance accessible PDF producer
github.com
github.com
As you might be aware, the author of the message is David Carlisle, a very active member at TeX (766k rep) and is also a maintainer of many popular packages.
Needless to say, the guide you followed is 8 years old; Perhaps some things have changed.
I have. I don't want to link my HN identity to my SE identity (which is tied to my real world identity through mathoverflow) so I won't link here.
> Needless to say, the guide you followed is 8 years old; Perhaps some things have changed.
As I said, it was updated in February 2024. I was written by Ulrike Fischer who's also very involved in latex3. It's basically the current state of the art in accessible PDFs. And it's still not good enough.
I wish it were otherwise, but latex is the pinnacle of design-by-committee and tech debt. Given how latex3 turned out, I'm very pessimistic. The only thing latex has going for it is inertia.
If you want to produce accessible documents from LaTeX, you should convert to HTML. ATs such as screen readers just work miles better than with PDFs, and given the resources put in developing browsers compared to PDF readers, I don't think this will change any time soon. Luckily conversion from LaTeX to HTML is very feasible today, as proved by arXiv. (Shameless plug: I maintain BookML specifically to help lecturers with the LaTeX to HTML work)
Very true! Although they are now comparable, if you rely on the browser native MathML instead of MathJax/LaTeX.
(You can test this on long arXiv HTML papers, e.g. https://ar5iv.labs.arxiv.org/html/1710.07304 is more than 60 pages as PDF. Mind you, the ar5iv default CSS is not great. I would use Latin Modern for formulas, at the very least.)
> I've never seen any modern tools that turn TeX into multifile HTML (one per section).
I believe all of them can do it out of the box now. I know for sure that LaTeXML, tex4ht and lwarp can split by chapter or section.
Not yet. There is Tagged PDF project [1] which aims to do something like that. there is tagpdf [2] package that try to do some of these things. If you need good instructions I would suggest overleaf tagging tutorial [3].
[1] https://www.latex-project.org/publications/indexbytopic/pdf/
[2] https://ctan.org/pkg/tagpdf
[3] https://www.overleaf.com/learn/latex/An_introduction_to_tagg...
This sounds amazing! Some years ago I was involved with a project for a company where we tried to extract some data from some PDF files they had. But neither OCR nor my attempts at reconstructing order of text in the documents panned out in the end, and it all ended in tears :(
Perhaps one day in the future dealing with extracting data from PDFs will be less of a mess.
Why not?
Maybe there are no source changes, and everything is handled by the engine, or maybe it introduces some extra \startread \endread tags without the need of an environment.
However, TFA is not about PDF, it is about a profile called PDF/UA-2 aka ISO 14289-2. That one is $223 from the PDF Association[1] or 173 CHF from the ISO[2].
I already can create PDF from latex, what does this repo add to it?
Without special hints (that are ignored by regular PDF readers or printers), PDF is essentially a vector graphics format, and any of these tasks amount to an exercise in OCR.
This is a somewhat little-known fact about PDFs, since many viewers do in fact implement many of these OCR-like heuristics to provide features such as text selection, search etc. that make it look a lot like a text-based format, but it really is a vector graphics format at heart. PDF/UA makes this a bit easier.
As an example, consider a multiple column layout, as is often used in scientific articles. PDF-creating software not concerned with accessibility might just intersperse all columns line by line (i.e. present text in presentational left-to-right, top-to-bottom fashion), but it could just as well achieve the same outcome by drawing column by column in semantic order. Beyond encouraging that, I believe PDF/UA also defines a bunch of (invisible) metadata tags that readers can use to figure out semantic structuring of a document.
Seriously, I know of one experiment that has O(thousands) of papers as latex source, which they publish as PDFs and which (more recently) they convert back to markdown with some ML-based image to text engine. All so that it can be fed to a vector database to make searching easier, of course.
PDFs are a terrible format for machine readable information (and thus for reproducible science), but they are the currency of the scientific community and as such will be the standard output for the foreseeable future.
was terrible format.
PDF 2.0 Tagged PDF has MathML support, Index, Quote, BibEntry, Title, lists, tables, .... you can derive HTML from PDF if it's fully tagged.
PDF also support displaying and print production better than anything.
I'd much rather have plain text, or markdown, or asciidoc than PDF or HTML. It works everywhere. And support for embedded mathematical typesetting is a solved problem.
I mean sure, you can do it, but now you are on the other end of function over form.
I feel like PDFs are, for tons of usecases, the best we've got. The alternative isn't markdown, it's usually .docx.
Most viewers on iOS, macOS, Linux and Android that I've tried are very tied to the idea of all ePubs being ebooks and insist on managing them in their own library, don't optimize latency to first page rendered (because they usually index and cache a bunch of stuff for a "newly opened book", assuming you'll be reading it over the course of days/weeks) etc.
For example, on macOS, the default app associated with ePub is Apple Books, but to be able to use technical papers in ePub format, I really need something like Preview.app (and that doesn't support them). (In that way, the situation is very similar to JPEG XL: macOS supports them in quick view, but only Safari can actually open them...)
Not sure how it is supposed to look like on other OSes, but this is barely a GUI application on macOS. (I have to launch it from the command line, UI and text rendering are extremely pixelated etc.)
It's definitely not up to par with any PDF viewer I've used so far, especially when it comes to quickly navigating between pages and chapters (crucial for non-linearly working with scientific papers etc).
EDIT: there's also this https://sioyek.info/ found thanks to https://github.com/NixOS/nixpkgs/blob/9d13dbb1ef2d0a6a6788d5...
The Android version is a bit more than that however, it has a simple file browser, and I settled on it because it handles large files better than whatever alternatives I went through at the time.
For most content PDFs are used today, I'd much prefer extending something like ePub "downwards" with stylesheets, rendering hints etc. – that can all just be thrown out by an accessibility- or readability-focused viewer.
Yet, the PDF ecosystem is so large at this point, and so many organizations are still tied to skeuomorphic ideas focused around printed pages of text, that I can't see it happen anytime soon. I just hope that at least academia figures something out.
ArXiv's recent HTML efforts [1] are a great step in that direction, but as I understand it, they still use PDF as their main ingestion format.
[1] https://blog.arxiv.org/2023/12/21/accessibility-update-arxiv...