Hacker News Reader

Comment by jez | Hacker News Reader

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 just fix the formatting problem in the PDF outright.

- It would be neat to allow people to experiment with alternative formatting for their papers. For example, imagine a paper about a programming language that embeds a sandbox you can use to play around with the language under discussion. Or a paper about multivariable calculus and you can interact with a three dimensional plot of some function.

View on HN

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?

Well, perhaps by exploiting bugs/shortcomings in PDF and HTML converters. Not by design.

However, bugs get fixed, and since the PDF and HTML are generated dynamically, any such hack would be extremely fragile.

And while "single source of truth" can help to prevent such malicious discrepancy, it's unlikely that people would try to hack the system this way: what for?

Far more likely scenario is unintentional discrepancy, and single source of truth definitely helps to prevent that!

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.

Huh? What's the point of html version if you define it as source of deception?

Maybe some day for some papers HTML could be the source of truth instead of LaTeX. After all, the original use case for HTML and the web was academics. The HTML and CSS specs have evolved a lot since then, with support for the typesetting features you need for papers (justified text, hyphenation, page breaks, page numbers, ...) and even math formulas are possible now again natively with MathML thanks to Igalia. Diagrams can be accessible vector SVGs instead of raster images. Referencing, linking, citing, figures, tables, etc have always been native to HTML. It's trivial nowadays too to wrap a headless chromium in a CLI to convert an HTML document to PDF rendered in the exact same way that the browser would (i.e. not some static conversion tool that lags behind standards or has render implementation differences).

> 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.

Please don't. Then you will have a mismatch between the source and the "own html" which ruins the point of uploading the source.

Pdf isn't the source

But the PDF is also generated. LaTeX is the single source of truth.

They’d have to define and document a “safe” subset of HTML, and implement a filter/checker for it. Otherwise we’d end up with papers containing ads and tracking and XSS vulnerabilities and whatnot.

Those are issues with JavaScript, not HTML. Wouldn't filtering out iframes pretty much keep us in the clear?

The parent wanted interactive 3D plots, which means JavaScript embedded in or linked from the HTML. Then there‘s stuff like JavaScript embedded in SVG.

> Those are issues with JavaScript, not HTML

What about various HTML tags that remote load resources? From script, link, to things like img or CSS `background-image` attribute, added in a `style` attribute.

There is a bunch of ways to do remote requests even without HTML.

The same problem exists in HN comments. This comment gets converted to html.

   But it is fine!

"gets converted to" and "gets rendered as uploaded by the user" are two different things.

There are no issues with arXiv generating the HTML and sending that over: they control the generation process, and users who visit arXiv already trust it to not be malicious. The issue is with letting the user upload their own and having it sent on to other users as is.

Most authors probably have no interest in learning html. Also most authors want nothing to do with the work by the time its submitted. It was probably hell getting the project to that point of publishing, they want to be done with it and move on to the next thing going on in their career asap.

I think this is an argument in favor of doing automatic PDF -> HTML conversion for the authors that don't want to touch it, but I don't think it's an argument against letting those who are fine with HTML provide their own.

HTML is not generated from PDF. Both PDF and HTML are generated from LaTeX.

Probably only a small percentage of people are using latex today. I’ve never personally seen it used. Just MS word docs sent to coauthors then to the paper editor.

You hit on an unappreciated truth. By the time my papers appeared in print, I was so sick of them and the endless effort involved in taking them from raw data to finished, edited, proofed, rewritten a zillion times to meet the reviewers' and editors' requests and corrections and suggestions, that I didn't even read the published paper when it arrived as preprints and in the journal.

Enough!

My proof: https://scholar.google.com/citations?user=5DdrMc8AAAAJ&hl=en

I was under the impression the source authors publish to arxiv was a latex file

It is.

Ah, thanks for clarifying!

I looked up the submission formats, and it looks like if you authored the paper in TeX/LaTeX, they do not accept pre-rendered versions of the document.

https://info.arxiv.org/help/submit/index.html#formats-for-te...

But if you did not author it in TeX/LaTeX (e.g., Word, Google Docs, etc.) it appears you can upload a PDF or HTML yourself.

But it's still a single source of truth. Only one document is submitted. So for works submitted as HTML no PDF or LaTeX version is available.

> 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.

Can you recommend a system I can use to compile my latex, while also making sure the html is going to look good? I'd like some kinds of css style @media queries to switch between certain parts of the layout, while keeping a single latex file.

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

Knuth’s stated intent in maintaining TeX is only to fix bugs, not evolve the system in a way that might break old documents. Not sure if this is equally true for Lamport’s LaTeX macros but it wouldn’t surprise me.

Reply on news.ycombinator.com