Just had a really nice experience where a loved one asked me to facilitate the conversion of an ebook from epub format to PDF for reading on her computer.
Since converting data is kinda my jam, and I am well-versed in Pandoc this seemed like a one-command job. Pandoc complained at the file being converted for some obscure reason, and manually trying out a few different options under --pdf-engine didn’t yield any results. I next tried Calibre, the popular ebook management software. It has facilities to convert between various readable formats although I’ve historically found its results to be spotty (this might be a case of garbage-in-garbage-out, though). Calibre similarly complained, citing the same reason as Pandoc (something about font encoding I think). Ever the debugger, I asked Calibre to convert the file to mobi which it kindly obliged me. Feeling bold now I asked it to convert the original epub to docx – another success!
With my docx in hand I braced myself and opened the new file in LibreOffice. A quick skim indicated that there were no obviously mangled paragraphs or destroyed pages. From there it was a simple matter to save as PDF et voila – task accomplished! This might mark the first time in history I’ve been happy to see a docx file.
This experience brought me joy because it reminded me of something. I’ve worked in standards for a few years now, and spent a lot of time designing technologies that tried to get it “right”. Where right is either the most technically efficient way, or using the right participatory design technique in the right place, or using the right analytical framework. This exercise gave me a chance to playfully engage my creative problem solving. The “right” thing to do technically might’ve been to try and fix the encoding of the epub file, and I certainly never envisioned using LibreOffice to generate a pdf file when I have the power of Pandoc at my fingertips. But it was nice to play around and hack my way around the problem by stringing tools together in a pipeline.