Progress on Press has been a bit slower lately. I’ve fixed most of the errors I discovered by running the exported PDFs through the 3-Heights PDF validator. I also refactored the code and reorganized the package per Kenneth Reitz’s advice.
I’ve implemented initial support for embedding subsetted fonts (doing the subsetting via fontTools.subset), and while the fonts (including uninstalled fonts) display fine on my macOS box, the PDFs don’t validate properly and the fonts don’t show at all on iOS, which means the embedding isn’t actually working right. Current suspects include the /Differences array (which I’m not generating properly yet) and the CMap (which I haven’t implemented at all yet). I still have to implement ToUnicode as well, so that copying and pasting does what it should, but I’m fairly certain that isn’t what’s causing the fonts to not embed properly.
I’m also trying to figure out color spaces. In general I believe I want the output to be either DeviceRGB or DeviceCMYK, with some way of specifying an output intent, and also an option for the user to embed an ICC profile if they want. I’m part of the way there.
Anyway, the font stuff is far more complicated than I expected going in, but I’m still making progress, and I’m learning a lot.
Font maps are admittedly extra work, but they do have some advantages as well: you can use fonts you haven’t installed, for example, and you can specify exactly which font files you want to use. And I can’t see any good way around the lack of a cross-platform font selection mechanism (meaning, a way to pass in ‘Minion Pro’ with specific weight and styles, and get a font filename in return).
Anyway, I’m in the middle of reading the PDF spec on CIDFonts and CMaps. It’s … complicated. It makes my head hurt. But it’ll be awesome when it’s done.
I’ve renamed inkpdf to Press (as in printing press).
I reached the point where creating the PDF manually is no longer feasible, so I’ve been working on getting Press to a point where I can implement the PDF generation. The basic structure is in place, sans the PDF part. (That’s next.)
Here’s what a Press script looks like right now:
from press import Press
p = Press('output.pdf', width=6*Press.INCH, height=11*Press.INCH,
margin=1*Press.INCH)
# Horizontal borders at top and bottom of page
p.stroke('#000')
p.pen(1.0)
p.line(p.page_min_x, p.page_min_y, p.page_max_x, p.page_min_y)
p.line(p.page_max_x, p.page_min_y, p.page_max_x, p.page_max_y)
# Page 2
p.page(2)
p.layer('base')
p.stroke(rgb=(1, 0, 0))
p.line(150, 150, 300, 300)
p.layer('fg')
p.stroke(hsl=(0, 0.5, 0.8))
p.line(300, 300, 450, 150)
# Go back and add another line to page 1
p.page(1)
p.stroke('#025')
p.line(p.page_min_x, p.page_min_y, p.page_min_x, p.page_max_y)
p.save() # this doesn't work yet
You can also do something like this:
with Press('output2.pdf', size=Press.LETTER,
margin=(0.5*Press.INCH, 1.0*Press.INCH),
inner_margin=0.5*Press.INCH,
outer_margin=1.25*Press.INCH,
bleed=.125*Press.INCH) as p:
p.line(50, 50, 250, 50)
# And so on
(Context manager, inner/outer margin, bleed, built-in paper sizes.)
Up next: adding more primitives, designing the font selection mechanism, getting it to generate an actual PDF, embedding fonts, using arbitrary Unicode code points, integrating HarfBuzz, etc.
I’ve been hand-coding PDFs in Vim, reading the PDF spec to learn how things work. It’s fascinating. My first, extremely simple PDF:
%PDF-1.4
1 0 obj << /Type /Catalog /Pages 2 0 R >>
endobj
2 0 obj << /Type /Pages /Kids [3 0 R] /Count 1 >>
endobj
3 0 obj << /Type /Page /Parent 2 0 R /Resources 4 0 R /MediaBox [0 0 500 800] /Contents 6 0 R >>
endobj
4 0 obj << /Font << /F1 5 0 R >> >>
endobj
5 0 obj << /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>
endobj
6 0 obj
<< /Length 44 >>
stream
BT /F1 24 Tf 175 720 Td (Hello World!) Tj ET
endstream
endobj
xref
0 7
0000000000 65535 f
0000000010 00000 n
0000000059 00000 n
0000000116 00000 n
0000000220 00000 n
0000000263 00000 n
0000000333 00000 n
trailer << /Size 7 /Root 1 0 R >>
startxref
427
%%EOF
It’s not as bad as it looks, I promise. (I’m doing PDF 1.4 because CreateSpace doesn’t seem to support higher versions of the spec.)
Anyway, I’ve been reading through chapter 5 of the spec, learning how text works in PDF. I’ve learned how to modify character spacing with Tc, word spacing with Tw, leading with TL, and individual glyph positions with TJ (not sure yet if I can change vertical positioning or not). I’ve also learned how to change the text color. It’s all been fairly straightforward.
As part of this, I’ve used Hex Fiend (an OS X hex editor) to pry apart some simple PDFs I made with PlotDevice, to see how things were encoded. The streams themselves are generally compressed through Flate compression (opposite of deflate, har har), and I found this script to easily decode the streams:
#!/usr/bin/env python
import zlib
import sys
input = sys.argv[1]
output = sys.argv[2]
with open(input, 'rb') as f:
buffer = f.read()
decomp = zlib.decompress(buffer)
with open(output, 'w') as f:
f.write(decomp)
I copied each stream in hex from Hex Fiend, pasted it into a file, ran the Python script on it, and it would output decoded text to a new file.
Things I don’t know/understand yet, which are legion:
How to encode Unicode (I’m not to this point of the spec yet, but I believe it involves CID fonts and using cmaps to map glyph codes or something like that).
How to take a font name and, in a cross-platform way, get the path to the font file so I can embed it and also use it with HarfBuzz.
How to take the output of HarfBuzz (a list of glyphs with position coordinates for each) and use that in positioning the glyphs in the PDF. I believe HarfBuzz will handle parsing the OpenType features of the font, but I’m not positive on that. I did get HarfBuzz Python bindings working, though, and I plan to play around with it soon.
Whether I need to use FreeType at all. I might need it for font metrics, but HarfBuzz might give me everything I need there.
When typesetting multiple lines, I don’t know whether it’s best to use the PDF built-in support (T* and TL and such), or to set each line manually as its own text object. The built-in support seems better, though I don’t know if that limits what’s possible.
At some point soon — I think when I start embedding fonts — doing this by hand in Vim will stop being as feasible, and at that point I’ll start writing Python to manage the PDF creation process for me. For now, though, it’s easier to just edit the PDF manually.
Turns out reading PDFs of old books (from Google Books, Internet Archive, etc.) on my iPhone works out reasonably well. For example:
On the left is the fully zoomed out page. Indoors, I’m able to read it without too much difficulty, though my eyes do thank me when I zoom in (as on the right). The problem with zooming, however, is that navigating to the next page then requires more swiping, and, at least in iBooks, you have to zoom in again every time you turn the page.
After a bit of this, I got to wondering what it would be like to typeset an iPhone-sized PDF, designed specifically to be read on a phone. Here’s how it turned out (and this is a proof of concept, nothing too polished):
The pages are set at 7.573×4.267″, which I arrived at by taking 1136×640 (iPhone screen dimensions in pixels) and dividing by 150. Arbitrary, but it worked out well enough. And the text is at 16 points on the left and 18 on the right. (Also arbitrary, but dependent on the page size, of course.)
The main advantage to a foolhardy scheme like this is full typographic control — margins, fonts, layout (important for poetry), tracking, etc., all without worrying about limitations of ebook readers. I could try to do something about widows and orphans, for instance, though I didn’t do that with this proof of concept.
The downside is that it’s custom-tailored to the dimensions of the iPhone 5S, and on other devices it wouldn’t fit as perfectly. Not necessarily a dealbreaker, though.
Is it worth pursuing? No idea. One of these days I’ll set a full book this way and try reading it on my phone to see how it compares.
