HTML alternative to PDF?

[jfly]

We could even use our gwt generated javascript if we want to be super cool, although there might be some unacceptable drawbacks doing it that way.

PDFs are great for printing scrambles, but they're not 100% ideal for viewing. Opening individual PDFs on a laptop is annoying as hell. A unified PDF is better, if your viewer has bookmark support, but it's still pretty easy to accidentally scroll away from the scrambles you're looking at (in many viewers, the arrow keys will scroll an entire page). Unified PDFs also are cause for security concerns, and would make it impossible to do something like #139. I believe we could create a super sexy scramble viewer written in javascript and html that could run nicely on tablets and laptops, and wouldn't suffer from any of the aforementioned problems. For example, after a round, you could mark scrambles as "used", and never accidentally give out the same scrambles twice. Marking scrambles as used would also make it easier to find scrambles as the list of unused scrambles gets smaller over the course of a competition.

[pochmann]

Why are individual PDFs annoying?
Maybe that can be improved?

[jfly]

(pardon the long response, I started ranting without any form or structure)

When opening a new pdf, you need to close the old window. Or, depending on the os/program you're using, opening a new pdf may clobber the old pdf. I find it annoying to open individual pdfs because people's desktops can be very cluttered. The folder containing the pdfs may not even be on the desktop. Opening a file is different on each person's computer. While trying to open individual pdfs at a competition, I learned that mac osx asks you to rename a file when you press enter with it selected!

Even on a computer I'm comfortable with, I find it difficult to find scrambles for a particular group/round. At a large competition like worlds, you're dealing with a whole bunch of individual pdfs flattened into one directory. Maybe it would be better to add more hierarchy via folders (event > round > groups), but I think browsing someone's filesystem isn't the best solution here. A lot of my annoyance with using the filesystem applies to tablets as well. In particular, I'm not really sure what sort of view of the filesystem ios gives you, and to me, it seems a lot more usable if this were all inside of some html file.

[sivashanmukh]

I use OSX and I find individual pdfs so very useful.

• Opening a file in OSX.
  -- This is not intuitive. Instead of pressing the return key, use "Command Key + Down Arrow Key"
• Individual pdfs is good
  -- The default application to open pdfs is called preview and every time I open a new pdf, it opens a new window. This allows me to open two/three non-consecutive groups at the same time and arrange them so that all of them are visible at the same time. This makes it easy when there are multiple scramblers.

If, by having a html ui, we could still achieve this, we can go for it.

[jfly]

I am not suggesting that we get rid of the individual pdfs, so don't worry =). I do think we can do better, though. I imagine that making 3 pdfs visable at the same time involves a good amount of clicking around. I would rather have something that automatically tiles & fills up the visible space.

[sivashanmukh]

Agreed. That will be cool. Reduces a lot of clicking. I am thinking of frames.

[adamschwartz]

Hey all, old-timey cuber here 👋

One potential solution would be to build a webpage that can display the existing PDFs inside them.

As a conceptual proof-of-concept, check out https://lazy.invoice.workers.dev, which leverages the browser’s ability to natively display a PDF inside an iframe.

There’s a form on the left, rendered in HTML, and on the right there’s an iframe pointed at a server responding with the generated PDF, which many browsers can now display in a native viewer.

The form on the left would be replaced with a custom-designed menu which supports the use-cases you have in mind: quickly switching between PDFs, tiling or layering several at once, etc. There may be performance considerations when rendering more than a few native-PDF-viewers-inside-iframes at once, but I suspect modern devices could support the uses-cases discussed here.

As it sounds like keeping the PDFs is an implicit goal, and since there’s a cost to maintaining two separate views of the same information, this solution is potentially the best of both worlds, leveraging the existing PDFs but inside a custom (multi-)PDF viewer that renders natively in the browser for ease of implementation and portability.