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

ArXiv now offers papers in HTML format

blog.arxiv.org

Post reply on HN
Print view View original

301–310 of 325 posts

Re: ArXiv now offers papers in HTML format

#301

Post by Blikkentrekker »

IlliOnato wrote: post #263
Blikkentrekker wrote: post #157

Earlier quoted context omitted.

I made these arguments two decades ago when I was still in university that PDF is a horrible format because it's purely præsentational, especially for people with disabilities whose software relies on semantic information. LaTeX last time I used it didn't even have a different symbol for uppercase Alpha and A because the glyphs are indistinguishable. They argued that PDF was superior because the publisher could contr…

For scientific articles pagination is still important, because it's how you refer to a particular part of a paper. If things like font size and line spacing are at the control of the consumer, pagination is not preserved. This problem is harder than you one would think naively.

No, the problem is very easy, referring by page number is simply ridiculous. As well as all those “(, )” citations,

Besides, in HTML one can directly link to the relevant part.

Re: ArXiv now offers papers in HTML format

#302

Post by Flimm »

Zuiii wrote: post #199
wolverine876 wrote: post #169

Earlier quoted context omitted.

I mean, how do I save it locally on one platform and read it on any platform? Or share it with someone else to read (without them downloading software)? I.e., we don't have a standard, local, single-file html format.

You're right. We could have such a format if browser and os vendors were interested in supporting such a use case. Unfortunately, they aren't. On the browser side, supporting all-in-one html files can be as simple a reading a single multipart-encoded page. Heck, if they support automatically serializing all external resources as datauris when saving pages, then most browsers will be able to open them without any modi…

.mhtml (or .mhtm) is that format. It's an archive containing an HTML file along with all the resources it references (JavaScript, CSS, and images). These browsers support it: Internet Explorer, Edge, Opera, Chrome, Yandex, and Vivaldi. Create one by saving the web page and choosing the .mhtml format. Safari supports another format called webarchive.

https://en.wikipedia.org/wiki/MHTML

Re: ArXiv now offers papers in HTML format

#303

Post by MahiShafiullah »

z2h-a6n wrote: post #66
reqo wrote: post #45

A lot of AI/ML papers these days have an accompanying interactive page like [0], will we see anything like these now directly in arXive? [0] https://voyager.minedojo.org/

I think then arXiv would have to deal with mantaining the tech stack and providing the presumably much higher server capacity to serve the more varied web pages that would result, so it seems like a tall order. arXiv already has an experimental integration with Papers with Code [0], which I guess provides similar results for the reader, though the authors have to figure out their own web hosting. [0] https://info.arx…

Second that. Something I put out recently had an (admittedly video heavy) webpage that had 1TB of traffic over the past month. Cloudflare handled it for free for me, but at ArXiv’s scale it’s bound to be a problem.

Re: ArXiv now offers papers in HTML format

#304

Post by IlliOnato »

semi-extrinsic wrote: post #274
IlliOnato wrote: post #265

Earlier quoted context omitted.

> Say I have Equation \ref{eq}. Why can't I just say "plot \ref{eq} for x from -6 to 11" and get my graph? Pretty much for the same reason you cannot press a word and get a pop-up dictionary definition in a paper book.

To be clear, I meant in the LaTeX source code. And there I can already write code that plots equations, I just have to re-type the equation in a new syntax.

TeX is about representation, not semantics, by design. To do anything useful with a function (like plotting) you need to get semantics.

An often cited example: what is f(x+y) ? Is it function f with x+y as its argument, or constant f multiplied by (x+y) ? TeX gives you no clue.

Or what is this i in your equation? Is it an index variable, or a square root from minus one?

You as a human figure this out by looking at the context and using domain knowledge. So does a "TeX to HTML/MathML converter". It is ultimately built on heuristics, and cannot be otherwise.

That's why I said basically "for the same reason a paper page is not interactive". It was designed this way!

The goal of TeX was to generate beautiful printed page. The need for semantic structure was not anticipated. To do semantics you need a "semantic version of MathML", or a language used by Wolfram's product, etc.

Re: ArXiv now offers papers in HTML format

#305

Post by IlliOnato »

Blikkentrekker wrote: post #301
IlliOnato wrote: post #263

Earlier quoted context omitted.

For scientific articles pagination is still important, because it's how you refer to a particular part of a paper. If things like font size and line spacing are at the control of the consumer, pagination is not preserved. This problem is harder than you one would think naively.

No, the problem is very easy, referring by page number is simply ridiculous. As well as all those “( , )” citations, Besides, in HTML one can directly link to the relevant part.

I am afraid you are being naive... You see only one factor out of many.

Being able to link directly to the relevant part is irrelevant (pardon my pun!). Such links are machine-readable, not human-readable. Scientific text need visual citations and being able to name the referred part for reading comprehension.

And Harvard-style citations (AKA name-date) exist for a reason; when your read a paper even in interactive format it helps when you can recognize citations to certain papers and not having to click on them or memorize numbers.

Other styles have their own advantages and disadvantages; that's why they all exist and used by this or that journal, and no consensus on a single "right" style was ever reached.

Re: ArXiv now offers papers in HTML format

#306

Post by IlliOnato »

lsaferite wrote: post #271
IlliOnato wrote: post #263

Earlier quoted context omitted.

For scientific articles pagination is still important, because it's how you refer to a particular part of a paper. If things like font size and line spacing are at the control of the consumer, pagination is not preserved. This problem is harder than you one would think naively.

Seems like they should use detailed section numbering like military documents and laws. Referring by page number seems very course by comparison.

This would require a change from the currently near-uniformly adopted standard.

The problem with this: you need to create a new standard, get everybody to agree to it, and get busy scientists who are concentrating on content and not representation to adapt this new standard in their writing, essentially requiring them to change their habits and spend extra time on writing (which many of them hate), for no obvious gain from their point of view.

I am not saying it's not possible, or not worth it, but it is not easy and simple either.

Re: ArXiv now offers papers in HTML format

#307

Post by lemper »

FredPret wrote: post #28
burkaman wrote: post #4

Earlier quoted context omitted.

And here's the PDF of the same paper for comparison: https://arxiv.org/pdf/2312.12451.pdf

The contrast is massive. I'm much more likely to read the html version; that PDF is deeply off-putting in some hard to define way. Maybe it's the two columns, or the font, or the fact that the format doesn't adjust to fit different screen sizes.

defo concur. will read the html version when on mobile from now on.

Re: ArXiv now offers papers in HTML format

#308

Post by SushiHippie »

odyssey7 wrote: post #231
SushiHippie wrote: post #142

Earlier quoted context omitted.

Mind explaining?

The comment is invalid CSS to apply the Knuth-Plass algorithm in rendering an HTML article. Knuth being a perfectionist’s perfectionist, TeX uses this algorithm to determine optimal line breaks to provide for better text justification. Here’s a discussion of hacks to achieve the algorithm’s results on web pages and an upcoming CSS feature as of 2020. https://mpetroff.net/2020/05/pre-calculated-line-breaks-for-...

Thank you!

Re: ArXiv now offers papers in HTML format

#309

Post by pasc1878 »

turing_complete wrote: post #267
jez wrote: post #33

It would be neat if they offered submitters the chance to upload their own HTML version alongside the PDF version, instead of always relying on an automatic conversion process. - I can imagine authors feeling frustrated if someone reaches out about a problem in the HTML version of their paper, but they have no way to correct it except by hoping that a change to the PDF fixes a change to the generated HTML. Easier to…

With the shelf life of web technologies, authors would constantly have to maintain their "papers" or they just would not be accessible after a while.

Plain html from mid 90s still renders and looks as good as it ever was.

I think CSS is also backwards compatible.

It is the JavaScript birs that change

Re: ArXiv now offers papers in HTML format

#310

Post by kennethologist »

dataflow wrote: post #154
IlliOnato wrote: post #79

Earlier quoted context omitted.

No, it would not. It's critically important that there is only one "logical" article, albeit with different representations. In other words, a single "source of truth". With "sideloading" of HTML there is no way in general to make sure that the contents of LaTeX (and PDF) on one side and HTML on the other side is the same.

> With "sideloading" of HTML there is no way in general to make sure that the contents of LaTeX (and PDF) on one side and HTML on the other side is the same. Is it not possible to write LaTeX code that produces different contents in HTML vs. PDF?

Straight from ChatGPT:

Yes, it is indeed possible to write LaTeX code that produces different contents when compiled to HTML versus PDF. This is typically done by using conditional commands within the LaTeX document that check for the output format being used. These conditional commands can then include or exclude specific content based on whether the document is being compiled to HTML or PDF.

In LaTeX, the ifpdf package is commonly used to check if the output is being compiled to a PDF. For generating HTML from LaTeX, tools like TeX4ht or LaTeX2HTML are used, and they often define their own specific commands or provide a way to detect the output format.

----- It gives simple code that uses:

The \ifpdf ... \else ... \fi command checks if the document is being compiled to PDF. If it is, the content between \ifpdf and \else is included. If not (which would be the case for HTML), the content between \else and \fi is included.

The content outside the \ifpdf ... \fi conditional will appear in both the PDF and HTML versions.

Post reply on HN