While retro video games and consoles have been getting the digital treatment in the forms of emulators, PCs and services like the Virtual Console, buying hardware to specifically play retro games in a digital form (as opposed to a clone console) is a relatively recent phenomenon. There has been a draw for people who want to really use their cartridges on a high quality, high definition system using a modern TV. There has also been a market for people who want a plug-and-play box where they don't have to fiddle with emulator options. Most modern TVs use the HDMI connector for passing digital content through to a LCD panel's display processor. HDMI licensing issues aside (search my blog for information about those issues), most of these retro devices support a maximum resolution of 480p, 720p or 1080p. While some of these devices support 1080p, many only support 720p or 480p. which can lead to thorny problems with lag and image resizing. Let's take a look at the issues in this blog article.
First, here is a list of current or actually released retro-centered solutions by the maximum resolution they support :
Occasionally someone will want to print one of my web pages, even though it means losing access to all the interactive parts. There are a few things I do to make this work better:
I try to start all my interactive diagrams in a state where it's informative without interaction. This is not only helpful for printing, but also for people skimming the page. I haven't always done this in the past so I've been trying to go back through my older pages and change them to work this way.
I have a "print stylesheet" using @media print { … } that changes the page style when printing. It changes the font, removes background colors, removes text shadows, and instructs the browser to avoid breaking the page inside a diagram.
(Added today) When printing, I display the URLs for the links on the page. Since you can't click the links, it's useful to display the URLs.
This makes the links display in Markdown format, as [text](url).
Unfortunately, many URLs are quite long. Markdown has a footnote/endnote-style format which works better for long links: [text][1] followed by [1]: url. It's not something I can do in pure CSS. I would have to edit the HTML to make this work. But I'm not actually writing HTML directly. I write XHTML that is transformed into HTML using XSLT. Can XSLT do this transformation for me? Yes! I was able to adapt this XSLT technique to work on my pages.
First, create an XSLT rule that applies to all links:
This will find links of the form <a href="url">test</a> and turn them into <a href="url">test</a><sup class="print-endnote">[3]</sup>. The count="//a" parameter to xsl:number will generate a counter for all <a> elements, and format it with brackets: the third link will be [3].
Then, at the bottom of the page, make a list of all the links:
This works! Throughout the page, links are annotated with a number like link[3]. Then at the bottom, it displays [3]: url.
However, as usual, there are details that make things more complicated in practice.
I want to exclude relative links (which are often to the same page) so I changed the pattern to match a[starts-with(@href,'http')] instead of a. This is in five places; it would be nice to abstract this somehow. [Update 2019-01-01: looks like XLST 2 might let me abstract over this, but XSLT 1 does not.]
I want to exclude links in the nav bar and table of contents. Due to the page structure I use, these are outside of a <section> element, so I changed a to section//a. Combined with the previous rule, it's now the ugly pattern //x:section//a[starts-with(@href,'http')].
I want to exclude links in the footer, which is inside <section> on some of my pages. I did this by adding a test, <xsl:if test="count(ancestor::x:footer) = 0"> for both the endnote marker and the list of urls. These links still receive a number with xsl:number though; I wasn't able to find a way to avoid that. However, since they're at the end of the page, it's not a problem in practice.
All of these rules messed up the weird whitespace handling rules I have in place. I ended up having to make two passes over all the elements, once to expand <a>, and once to apply the whitespace rules. Even then, it is now applying the whitespace in slightly the wrong place. The printed page has link [3] instead of link[3]. [Update 2019-01-01: I was able to fix this.]
I'm a newbie with XSLT so there's some cargo cult involved. I'm simultaneously impressed that XSLT is able to do this, and horrified by how ugly it is. Someday I hope to revisit all of this, either improving the XSLT or moving away from it, but for now, it works reasonably well, and I'm happy with it.
See screenshots I posted on twitter, or try printing one of my pages to see how it looks. If you run into glitches, please let me know!
Update Here's a slightly different implementation:
Instead of adding a new element in XSLT, add an attribute:
The advantage of this approach is that I don't have to add a new element. The downside is that the underlining of links will apply to the :after element so these superscripts will be underlined. Another downside is that the superscript is purely visual instead of using a semantic tag like <sup>. More CSS, less HTML.
