Recently we had a bit of a conundrum – we were going to give a presentation where the client wanted access to the slides, but had no access to Google Drive on their corporate network, and also wanted PDFs of the slides for note taking/printed copies. Our solution? HMTL5/JavaScript slides and a little app that converts them to PDF!
The Presentation – mdpress
After we wrote almost all of our slide decks in Google Presentation, we discovered that our client’s network was configured to block all things Google Drive (Docs, Spreadsheets, Presentation, etc.). Although we could have downloaded all the files and had them access the presentations that way, we decided we wanted a slightly new approach.
Notably, we were going to the client’s site to teach them all things Cloud Foundry. As part of the training, we had access to our client’s sandbox Cloud Foundry environment. We thought: how cool would it be to use the very platform we were teaching about to give the presentation? Answer: very cool. (⌐■_■)
Rather than build everything from scratch, we decided to find a tool to help us out. We were looking for something stable, and preferably free, with a minimal learning curve. Needless to say, when we found mdpress we ran with it. mdpress is exactly what we wanted: an awesome tool that would help us write our slide decks and take advantage of some of the special effects that HTML5, CSS, and JavaScript have to offer (without putting our audience into a coma in a valiant effort to be "fun").
A quick "how to" on mdpress: you build a Markdown file and run mdpress to generate an HTML file, named index.html by default, as well as the appropriate CSS and JavaScript files. mdpress uses the impress.js (demo) JavaScript framework and Redcarpet (to process the Markdown files).
The overall experience so far has been great! We even wrote a small Ruby app to generate all our decks from our md files and apply the appropriate CSS template. While building, we used GitHub and pushed the app/decks to our customer’s instance of Cloud Foundry. Once all was said and done, the attendees were able to access the slide decks using the sandbox URL.
Some drawbacks
Despite an overall positive experience, we did run into a couple small "gotchas":
-
Links do not work as expected.
We ran into an issue with links in the slides. If there is only one slide with links then they will consistently work as expected, but when there are multiple slides with links they will either go to a link on a different slide or no where at all. We’re still trying to how to remedy this problem sans editing the index.html file. -
Clicking on a slide takes you to to the end of the deck.
This may not seem like a problem, "just don’t click on the slides", but considering the previous it is a bit of a hassle. i.e. If you click on a link and it "doesn’t go anywhere", you’ve just clicked on a slide and will find yourself at the end of the deck.
Side note: although we didn’t run into the next two issues, they definitely need to be considered when using web based technologies:
-
Since mdpress uses JavaScript, make sure that the people who will have access to the slides won’t run into issues with browser support.
Although your browser may support the tools you are using to build your deck, make sure that anyone else you intend to view the slides has the ability to do so. -
Figure out how/where you want to host your presentations.
This may be obvious, but when deciding where you want to host your slide decks, make sure that they are accessible via the network you will be using to show the slides. If you are goiong to have attendees accessing the slides during/after the presentation, make sure that they can also access your host of choice. (If you are hosting on your own laptop and will not be sharing the decks, then you can skip this caveat.)
The "Papertrail" – deck2pdf
You may recall that our attendees also wanted PDF files of all the presentations to print and share with other members of their organization. Unfortunately, unlike PowerPoint (and similar products), mdpress does not have a built-in feature for sending the slides to a printer or even print-to-PDF.
Luckily, we found deck2pdf. deck2pdf is a free tool that allows you to convert various web based slides to PDF. (Please take a look at the deck2pdf page for all technologies supported.)
Since mdpress uses impress.js, one of the supported technologies, we were able to use this tool to convert our mdpress slides to PDFs. The installation requires JDK 7 or higher and was a breeze. The software runs by "playing" through the slides, converting them to an image, and then storing the image of that slide to a PDF document. The PDF document is created after all the slides have been cycled through.
Some drawbacks
Although this tool is awesome and was the easiest way to get our much-needed PDFs, I wanted to make note of the most major hiccups we encountered.
- Links on slides are not preserved.
Since this tool takes an image of the slide, links are not preserved in the PDF.
- As a workaround, we supplied our attendees with a separate "links" document that included all web sites linked in the slides.
-
Text cannot be copied from the PDF.
This is another side effect of the images – since the PDF is created from images of the slides, text cannot be selected or directly copied from the PDF. -
There is a limit to how many slides the presentation can have.
As far as I can tell, the images are stored in memory and then the PDF file is generated at end. I ran into an issue, consistently, at precisely 40 slides. If the presentation was longer than 40 slides, the PDF would either not render correctly (slides/pages after the 40th were just solid grey) or deck2pdf would throw an exception and I would need to force quit the application and delete the corrupted PDF file. This would happen even if there was minimal text per slide and no images. For reference, the laptop I was doing this on has 8 GB RAM and I wasn’t running any other memory intensive apps at the time.
- As a workaround, I separated the deck we had that was over 40 slides into two separate decks, made separate PDFs for parts one and two, and then used Preview to join them into one PDF document.
- You must supply the full path to the application for deck2pdf to work.
This may seem obvious, but it was less obvious when I was using it while jet-lagged in the middle of the night in my new local time. Since this app isn’t a script, by default I was not able to run it simply by using "deck2pdf" – even if I was in the directory that housed the application. (e.g. If you have the application stored in ~/DevTools, then the path to run it would be ~/DevTools/deck2pdf/bin/deck2pdf even if you are currently in ~/DevTools/deck2pdf/bin/.)
Spread the word
