Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML as an Accessible Format for Papers (2023)

info.arxiv.org

Post reply on HN
Print view View original

71–80 of 141 posts

Re: HTML as an Accessible Format for Papers (2023)

#71

Post by afavour »

bawolff wrote: post #69
afavour wrote: post #37

Earlier quoted context omitted.

Yes but we’re specifically talking about a display format here. Something requiring a server side transform before being viewable by a user is a clear step backwards.

How so? I can't think of any advantage to having client side xsl over outputting two files, in this context.

The discussion is about the form in which you share papers. With HTML you just share the HTML file, it opens instantly on basically any device.

If you distribute the paper as XML with an XSLT transform you need to run something that’ll perform that transform before you can read the paper. No matter whether that transform happens on the server or on the client it’s still an extra complication in the flow of sharing information.

Re: HTML as an Accessible Format for Papers (2023)

#72

Post by hombre_fatal »

ekjhgkejhgk wrote: post #50

I wish epub was more common for papers. I have no idea if there's any real difficulties with that, or just not enough demand.

Because what makes epub a format on top of html is just that someone QA'ed it and wrote the html/css with it in mind. Especially considering things like diagrams and tables.

Not really what you want researchers to waste their time doing.

But you can use any of the numerous html->epub packagers yourself.

Re: HTML as an Accessible Format for Papers (2023)

#73

Post by daemonologist »

Tagbert wrote: post #6
ForceBru wrote: post #5

Is this new or somehow updated? HTML versions of papers have been available for several years now. EDIT: indeed, it was introduced in 2023: https://blog.arxiv.org/2023/12/21/accessibility-update-arxiv...

From the paper... Why "experimental" HTML? Did you know that 90% of submissions to arXiv are in TeX format, mostly LaTeX? That poses a unique accessibility challenge: to accurately convert from TeX—a very extensible language used in myriad unique ways by authors—to HTML, a language that is much more accessible to screen readers and text-to-speech software, screen magnifiers, and mobile devices. In addition to the tec…

There are pretty often problems with figure size and with sections being too narrow or wide (for comfortable reading). The PDF versions are more consistently well-laid-out.

Re: HTML as an Accessible Format for Papers (2023)

#74

Post by xworld21 »

DominikPeters wrote: post #66

As an arXiv author who likes using complicated TeX constructions, the introduction of HTML conversion has increased my workload a lot trying to write fallback macros that render okay after conversion. The conversion is super slow and there is no way to faithfully simulate it locally. Still I think it's a great thing to do.

I believe dginev's Docker image https://github.com/dginev/ar5ivist is very close to what runs on arXiv and can be run locally. It uses a recent LaTeXML snapshot from September.

Re: HTML as an Accessible Format for Papers (2023)

#75

Post by xworld21 »

afavour wrote: post #25
billconan wrote: post #23

Earlier quoted context omitted.

no abstract text ... author one author two should be just: [abstract] abstract text [authors] author one | email | affiliation author two | email | affiliation

Sounds like XML and XSL would be a great fit here. Shame it’s being deprecated. But you could still use HTML. Elements with a dash in are reserved for custom elements (that is, a new standardised element will never take that name) so you could do: And it would be valid HTML. Then you’d style it with CSS, with paper-author { display: list-item; } And so on.

Indeed, LaTeXML (the software used by arXiv) converts LaTeX to a semantic XML document which is turned to HTML using primarily XSLT!

Re: HTML as an Accessible Format for Papers (2023)

#76

Post by ComputerGuru »

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 Unicode code points to display in the way needed (theoretically, anyway) and with fallback missing-glyph-only font family substitution support available pretty much everywhere allowing you to seamlessly display symbols not in your primary font from a fallback asset (something like Noto, with every Unicode symbol supported by design, or math-specific fonts like Cambria Math or TeX Gyre, etc), there are no technical restrictions.

I’ve actually dug into this in the past and it was never lack of technical ability that prevented them from even adding just proper superscript/subscript support before, but rather their opinion that this didn’t belong in the symbolic layer. But since emoji abuse/rely on ZWJ and modifiers left and right to display in one of a myriad of variations, there’s really no good reason not to allow the same, because 2 and the squares symbol are not semantically the same (so it’s not a design choice).

An interesting (complete) tangent is that Gemini 3 Pro is the only model I’ve tested (I do a lot of math-related stuff with LLMs) that absolutely will not under any circumstances respect (system/user) prompt requests to avoid inline math mode (aka LATeX) in the output, regardless of whether I asked for a blanket ban on TeX/MathJax/etc or when I insisted that it use extended unicode codes points to substitute all math formula rendering (I primarily use LLMs via the TUI where I don’t have MathJax support, and as familiar as I once was with raw TeX mathematical notations and symbols, it’s still quite easy to confuse unrendered raw output by missing something if you’re not careful). I shared my experiment and results here – Gemini 3 Pro would insist on even rendering single letter constants or variables as $k$ instead of just k (or k in markdown italics, etc) no matter how hard I asked it not to (which makes me think it may have been overfit against raw LATeX papers, and is also an interesting argument in favor of the “VL LLMs are the more natural construct”): https://x.com/NeoSmart/status/1995582721327071367?s=20

Re: HTML as an Accessible Format for Papers (2023)

#77

Post by fsh »

_dain_ wrote: post #67

Wasn't the World Wide Web invented at CERN specifically for sharing scientific papers? Why are we still using PDFs at all?

No, it wasn't. Scientists at CERN used DVI and later PDF like everyone else. HTML has no provisions for typesetting equations and is therefore not suitable for physics papers (without much newer hacks such as MathML).

Re: HTML as an Accessible Format for Papers (2023)

#78

Post by vatsachak »

krapp wrote: post #65
vatsachak wrote: post #64

Earlier quoted context omitted.

Things like LaTeX equation rendering are hosted on a cdn

They can be but don't need to be. Any javascript can be localized like HTML and CSS.

That's fair, but imagine trying to get the average reader up to speed with something like npm.

Re: HTML as an Accessible Format for Papers (2023)

#79

Post by hannahnowxyz »

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…

Have you tried a two-pass approach? For example, where prompt #1 is "Which elliptic curves have rational parameterizations?", and then prompt #2 (perhaps to a smaller/faster model like Gemma) is "In the following text, replace all LaTeX-escaped notation with Markdown code blocks and unicode characters. For example, $F_n = F_{n - 1} + F_{n - 2}$ should be replaced with `Fₙ = Fₙ₋₁ + Fₙ₋₂`. ". Although it's not clear how you would want more complex things to be converted.
Post reply on HN