HTML as an Accessible Format for Papers (2023)

Post by teddy-smith » Sat, Dec 06, 2025, 11:36 PM UTC

tefkah wrote: post #35

teddy-smith wrote: post #32

It's extremely easy to convert HTML/CSS to a PDF with the print to PDF feature of the browser. All papers should be in HTML/CSS or Tex then just simply converted to PDF. Why are we even talking about this?

What are you talking about? No one’s writing their paper in HTML. The problem is having the submissions be in TeX and converting that to HTML, when the only output has been PDF for so long. The problem isn’t converting HTML to PDF, it’s making available a giant portion of TeX/pdf only papers in HTML. If you’re arguing that maybe TeX then shouldn’t be the source format for papers then I agree, but other than Typst (wh…

Post by teddy-smith » Sat, Dec 06, 2025, 11:39 PM UTC

nkrisc wrote: post #40

teddy-smith wrote: post #32

It's extremely easy to convert HTML/CSS to a PDF with the print to PDF feature of the browser. All papers should be in HTML/CSS or Tex then just simply converted to PDF. Why are we even talking about this?

So, uh, where do the HTML versions of the papers come from?

Post by cluckindan » Sat, Dec 06, 2025, 11:51 PM UTC

benatkin wrote: post #48

cluckindan wrote: post #46

Earlier quoted context omitted.

HTML alone is in fact not a format for displaying/rendering. Done properly, it is a structural representation of the content. (This is often called ”semantic HTML”.) They are converting to HTML to make the content more accessible. Accessibility in this context means a11y, in effect ”more accessible” equates to ”more compatible with screen readers”. While PDF documents can be made accessible, it is way easier to do it…

Much of it is a structural representation of how to display the content.

Post by bsder » Sun, Dec 07, 2025, 12:33 AM UTC

crazygringo wrote: post #89

ComputerGuru wrote: post #76

If the Unicode consortium would spend less time and effort on emoji and more on making the most common/important mathematical symbols and notations available/renderable in plain text, maybe we could move past the (LA)TeX/PDF marriage. OpenType and TrueType now (edit: for well over a decade, actually) support the necessary conditional rendering required to perform complicated rendering operations to get sequences of U…

I don't understand. No matter what fancy things you do with superscripts and subscripts, you're not going to be able to do even basic things you need for equations like use a fraction bar, or parentheses that grow in height to match the content inside them. At a fundamental level, Unicode is for characters, not layout. Unicode may abuse the ZWJ for emoji, but it still ultimately results in a single emoji character, n…

Post by austinjp » Sun, Dec 07, 2025, 12:49 AM UTC

bsder wrote: post #107

crazygringo wrote: post #89

Earlier quoted context omitted.

I don't understand. No matter what fancy things you do with superscripts and subscripts, you're not going to be able to do even basic things you need for equations like use a fraction bar, or parentheses that grow in height to match the content inside them. At a fundamental level, Unicode is for characters, not layout. Unicode may abuse the ZWJ for emoji, but it still ultimately results in a single emoji character, n…

> No matter what fancy things you do with superscripts and subscripts, you're not going to be able to do even basic things you need for equations like use a fraction bar, or parentheses that grow in height to match the content inside them. Why not? Things like Arabic ligatures already do that, no?