Two-column theme?

[dginev]

It is uncanny how close we get to the the 2-column view in the PDF files for some .cls files by simply by adding:

.ltx_abstract,
.ltx_section,
.ltx_appendix,
.ltx_bibliography {
  columns: 2;
}

To the CSS ruleset. Adding that as a toggle-able theme, orthogonal to the light/dark theme toggle, feels rather reasonable as an experiment.

But every type of content that refuses to reflow, makes this difficult. Cases I've spotted on a quick glance:

• long display equations, and their tags
• certain side-margin notes get stuck between columns
• verbatim code blocks sized for a single-column width
• tables sized for a single-column width

So maybe it is best to defer this until we can auto-reflow nearly everything, and see if there is additional interest / ideas floating around.

[dginev]

The recent 2206.08225 would be a good case study for making such a theme look as enticing as possible.

[nis057489]

Just a thought I had after reading your comment about content refusing to reflow. I could be way off... :)

How does LaTeX flow everything on the page? I assume it knows the dimensions of the page (e.g. letter or A4) and the font size, the number of columns, orientation, etc, then it re flows the text until it finds a layout that works within the constraints of the page configuration. Therefore, whatever is happening here should also be aware of the dimensions and how the article contents are meant to flow on the page.

There will be added complexity from supporting arbitrary screen resolutions, sizes and orientations, but it should not be insurmountable. If the important variables in a view port configuration are resolution and orientation, then basic backtracking based algorithm could try different layouts until it finds something that fits the current view port and backtrack in the case that a particular layout doesn't fully work for a particular view port configuration. For example, if a long equation overflows it's bounds and ends up in an adjacent column or running off the page then that's an invalid configuration that would be backed out of and a new layout will be tried.

Thank you for all your effort improving Arxiv!

[dginev]

@nis057489 There is a very nice theoretical discussion about fixed-width vs responsive designs. Your comment leans very heavily into using the original widths, and I agree with you completely on the input interpretation side.

But where I differ is how to transition to a responsive HTML rendering. For the output, we could record some "advisory" (as in "hints") attributes that note the relative widths seen implied by LaTeX, but there is no need to enact them as exact width/height sizes. The browser can give us a lot of that for free.

Our goal is to have a nice single representation in HTML, which is already compatible (i.e. has "sufficiently semantic markup") with one or two column themes, with minimal "smarts" in the rendering stage.

The browser is already perfectly capable of reflowing dynamically the inline kinds of content - especially text, but even flexbox figures and CSS grids. We have some minimal care to deal with footnotes as sidenotes on wide viewports vs in-place onhover notes on narrow viewports.

What we need added is some JavaScript to be able to reflow equations and some decision about tables. And lots of testing...