Skip to main content


Showing posts from April, 2015

Swift and EPUB: Font obfuscation (updated)

There are some basic ingredients required to perform EPUB font obfuscation: first we need to be able to generate a SHA-1 digest from a unique identifier string, second we need to transform the hexadecimal string (40 characters in length) into a UInt8 byte array of 20 bytes third we need to apply the IDPF algorithm, which is provided in pseudo code Generating a SHA-1 Digest The first obstacle is the generation of a SHA-1 digest from a String, because while there is a framework called CommonCrypto, there are some hoops to jump through  when using it with Swift. To avoid these hoops I turned to a JavaScript library called CryptoJS  and ran it in a virtual machine thanks to the JavaScriptCore framework. It sounds like more work but in fact there's not much more than a few lines of code to get this working: import Foundation import JavaScriptCore public struct Crypto { public static func sha1(str:String) -> String? { if let url = NSBundle.mainBundle().URL

Font obfuscation in EPUBs and why you shouldn't change the dc:identifier after exporting from InDesign

Font obfuscation Font obfuscation (otherwise known as font mangling) is a two-way process for which there is a set algorithm recorded by the IDPF . The reason for this algorithm and the very specific instructions that accompany it are because fonts once obfuscated need to be de-obfuscated in order to be used by a reader app. And in order for this reversal of the obfuscation process to occur there needs to be a set of open rules to enable compatibility for this open standard. EPUB font embedding in InDesign In this post I am not going to enter into the technical details of obfuscation but instead focus on the typical person creating EPUBs using InDesign to embed fonts in an EPUB. So let's begin there: when you choose to embed fonts in an EPUB from the InDesign export panel, the app subsets and obfuscates the fonts included in your document as long as no digital restrictions exist to prevent this. The reason for this post is that it is common once you have created an EPUB fro

The story of a black hole and a planet: Apple Watch and Microsoft Band

By Urbane Legend (optimised for web use by Alain r)  | (en:Image:BlackHole_Lensing_2.gif) [ GFDL or CC-BY-SA-3.0 ], via Wikimedia Commons Apple's black hole When Apple sets the price of its products it creates a pricing point black hole, a point at which any products of similar utility that hover around that price are sucked in and either destroyed by spaghettification or a wall of fire . This risk of destruction is what is happening with the Apple Watch already, anything nearing the £299 mark is finding itself in need of heading away from that point in space. This particularly applies to the more advanced end of the fitness band market. Fitness bands and Planet Microsoft So where do these products head? Well, Microsoft has obversely created a gravitational pull around the £169.99 price point, at which it has set the Microsoft Band . Here is a seemingly safe haven for devices of similar utility, especially if they have something different to contribute. The Microsoft

Locating paragraph breaks in Swift: Objective-C in Translation

Apple provides us with advice and code for finding paragraph breaks  using Objective-C in its documentation. In the translation of this code into Swift it is necessary to take into account the difference between a Range and an NSRange. In an NSRange the work is done with simple integers, but with Range<String.Index> integers cannot replace indexes. let string = "my string\n of paragraphs \r is \u{2029} pretty wacky!" let length = string.endIndex var paraStart = string.startIndex, paraEnd = string.startIndex, contentsEnd = string.startIndex var array = [String]() while (paraEnd < length) { string.getParagraphStart(&paraStart, end: &paraEnd, contentsEnd:&contentsEnd, forRange:Range(start: paraEnd,end:paraEnd)) let r = Range(start: paraStart, end: contentsEnd) array.append(string.substringWithRange(r)) } So where Apple initializes the paraStart, paraEnd and contentsEnd variables with 0 in Objective-C, it is necessary in Swift to in

DOCX to JSON in Aldwych and Swift: The Second Parsing

Planning the ascent The current aim in working with DOCX in Aldwych is not to be able to roundtrip and recreate DOCX files that will be valid Word files but rather to get at the essential content: text, paragraph and character styles, footnotes, and endnotes. (For now pushing tables to one side, but with the intent of returning to them once the rest is working well.) The first step to working with DOCX is unzipping the file. For this I will use SSZipArchive  (which is written in Objective-C, so I'll need to get it working with Swift first). Once the file is unzipped and saved to a folder on the disk, it becomes possible to read the text files. But first we need to note how to get at the required content: for this there's a top-level  word folder, and inside there's a range of XML files, the most important of which for our current needs are: document.xml, endnotes.xml, footnotes.xml and styles.xml. We'll worry about variations at a later date, for now I want to

Find and Replace with JSON and Aldwych in Swift

Find and Replace In the ongoing series of posts on parsing JSON with Aldwych in Swift, I want to consider some newly added find and replace functionality and to think of some scenarios where it might be useful. For example, let's suppose we want to Americanize the string content of JSON coming from a UK source. Here this is demonstrated with a small subset of Americanisms . import UIKit let spellingsUS = ["aeroplane":"airplane","aluminium":"aluminum","arse":"ass","behove":"behoove","bogeyman":"boogeyman","brent":"brant","carburettor":"carburetor","coupé":"coupe"] let article:[String:AnyObject] = ["a":["I was on an aluminium aeroplane"],"b":"unafraid","c":[["c":"of the bogeyman","d":"when he ripped the carburettor off my coupé"],&

In and out of JSONness: Parsing Logic with Swift and Aldwych

If you can parse XML in and out of a JSON structure, then you have something that can be natively manipulated as Dictionaries and Arrays are. You also have something that is essentially cross-platform: the logic of the loops that get you from XML to JSON are pretty much the same if you keep them simple enough. And simplicity is the key. The main source of mind melding is the nesting of tags/JSON, because it's a bit like a mirror placed in front of a mirror that reflects forever.  But really if you can get nesting working it can be repeated over and over, and you needn't worry so much about this fact. Target structure You're going to need a logical structure that you want the JSON ending up in and I have a fairly simple one: a tag and its content become a dictionary with the tag as the key and the content as the value. (There'll also be an attribute key in each dictionary containing an attribute dictionary for the tag, which incidentally echoes the NSXMLParser ap