Live data from Hacker News

HTML as an Accessible Format for Papers (2023)

info.arxiv.org

81–90 of 141 posts

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

#81

Dumb question but what stops browsers from rendering TeX directly (aside from the work to implement it)? I assume it's more than just the rendering

For starters, TeX is Turing-complete, and the tokenizer is arbitrarily reprogrammable at runtime.

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

#82

Dumb question but what stops browsers from rendering TeX directly (aside from the work to implement it)? I assume it's more than just the rendering

You mean a display engine that works like an HTML renderer, except starting from TeX source instead of HTML source? I think you could get something that mostly works, but it would be a pain and at the end you wouldn't have CSS or javascript, so I don't think browser makers are interested.

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

#83

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…

https://github.com/stevengj/subsuper-proposal

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

#84

Dumb question but what stops browsers from rendering TeX directly (aside from the work to implement it)? I assume it's more than just the rendering

For starters, TeX is Turing-complete, and the tokenizer is arbitrarily reprogrammable at runtime.

Okay then, what would stop you rendering TeX to SVG and embedding that?

Edit: Genuine question, not rhetorical - I don't know how well it would work but it sounds like it should.

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

#85

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 ho…

I've done latex -> mathml -> markdown and it works quite well

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

#86

I don't think HTML is the right approach. HTML is better than PDF, but it is still a format for displaying/rendering. the actual paper content format should be separated from its rendering. i.e. it should contain abstract, sections, equations, figures, citations etc. but it shouldn't have font sizes, layout etc. the viewer platforms then should be able to style the content differently.

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…

I like Arxiv and what they are doing, however, do the auto-generated HTML files contain nothing more than a sea of divs dressed with a billion classes?

I would be delighted if they could do better than that, with figcaptions as well as figures, and sections 'scoped' with just one heading per section. They could specify how it really should be done, the HTML way, with a well defined way of doing the abstract and getting the cited sources to be in semantic markup yet not in some massive footer at the back.

There should also be a print stylesheet so that the paper prints out elegantly on A4 paper. Yes, I know you can 'print to PDF' but you can get all the typesetting needed in modern CSS stylesheets.

Furthermore, they need to write a whole new HTML editor that discards WYSIWYG in favour of semantic markup. WYSIWYG has held us back by decades as it is useless for creating a semantic document. We haven't moved on from typewriters and the conventions needed to get those antiques to work, with word processors just emulating what people were used to at the time. What we really need is a means to evolve the written word, so that our thinking is 'semantic' when we come to put together documents, with a 'document structure first' approach.

LaTeX is great, however, last time I used it was many decades ago, when the tools were 'vi' (so not even vim) and GhostScript, running on a Sun workstation with mono screen. Since then I have done a few different jobs and never have I had the need to do anything in LaTex or even open a LaTeX file. In the wild, LaTeX is rarer than hen's teeth. Yet we all read scientific papers from time to time, and Arxiv was founded on the availability of Tex files.

The lack of widespread adoption of semantic markup has been a huge bonus to Google and other gatekeepers that have the money to develop their own heuristics to make sense of 'seas of divs'. As it happens, Google have also been somewhat helpful with Chrome and advancing the web, even if it is for their gatekeeping purposes.

The whole world of gatekeeping is also atrocious in academia. Knowledge wants to be free, but it is also big business to the likes of Springer, who are already losing badly to open publishing.

As you say, in this instance, accessibility means screen readers, however, I hope that we can do better than that, to get back to the OG Tim Berners Lee vision of what the web should be like, as far as structuring information is concerned.

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

#87

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?

Have you ever written a paper for publication?

HTML doesn't support the necessary features. Citations in various formats, footnotes, references to automatically numbered figures and tables, I could go on and on.

HTML could certainly be extended to support those, but it hasn't been. That's why we're talking about this.

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

#88

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 ho…

It is actually quicker to ask using LaTeX markup!

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

#89

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, not a layout of characters. So I don't really understand what you're asking for.

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

#90

Earlier quoted context omitted.

For starters, TeX is Turing-complete, and the tokenizer is arbitrarily reprogrammable at runtime.

Okay then, what would stop you rendering TeX to SVG and embedding that? Edit: Genuine question, not rhetorical - I don't know how well it would work but it sounds like it should.

That would (mostly if not always) work in the sense of reproducing the layout of the pages, but would defeat the purpose of preserving the semantic information present in the TeX file (what is a heading, a reference and to what, a specific math environment, etc.) which is AFAIK already mostly dropped on conversion to PDF by the latex compiler.
Post reply on HN