Problems with using Acrobat to create tagged PDF files from scans

(I didn’t do screenshots when I tested on MacOSX yesterday, so no screenshots for now. This will be fixed later, but seriously, Adobe need to recommit to releasing Acrobat and/or Reader on Unix, or at least make sure Reader DC’s installer work under Wine. The status quo is unacceptable.)

Since Acrobat CC and Reader DC are really the only tools for creating tagged PDF files from a scan, yesterday I decided to see how well they actually work. (What I used was Acrobat CC on a recent MacOSX, with VoiceOver for testing. The scan was of low quality but sometimes this is what people have to work with.)

Many obvious, major problems surfaced almost right away:

  • The relevant panels and toolbars were difficult to find. You have to google to figure out where to even look.
  • Creating a tag tree will cause OCR. The result contained lots of errors, but there’s no obvious way to fix any.
  • Acrobat made many reasonable guesses at the document structure, but also many bad ones. Some could have been easily fixed by removing container elements but keeping their contents in place, but there’s no obvious way to do this.
  • Structural errors (including the above) can often be fixed by rearranging tags, but drag-and-drop is the only way to reorder tags, and your tags more often than not end up being dropped at unpredictable locations – even if you’re very careful. In other words, Adobe’s official workflow doesn’t actually work.
  • The document object model doesn’t seem to be inconsistent; you can type over the errors in the Content (“TURO”) view, but the errors remain uncorrected in the Tags view (or as revealed by reading the actual PDF with an actual screen reader).
  • When you finally found out how you’re supposed to correct OCR errors, you’d realize the automatic OCR performed by the Tags editor did not create any layers, so you’d have to redo the OCR even though it had already been done.
  • You’re given only one chance to correct “possible” OCR errors — those that Acrobat automatically identifies as “suspects”. If you made an error when correcting, too bad, you’ll have to start the OCR process all over again: There is no Undo.
  • There’s no way to correct OCR errors Acrobat fails to even identify as “suspects”.
  • The contents fields in a tag produce no observable effects; they don’t override anything.

I’ll elaborate on these later, but I’m shocked this is the kind of tool we are forced to work with if we need to “remediate” a PDF file — pretty much unusable if you asked me.

(MM told me when he had to PDF remediation he ended up re-creating almost everything, and AW said my complaints are her daily complaints. I can totally empathize. If I end up doing this kind of work, InDesign will likely end up being a major part of my workflow as well.)

Legibility research, and the perils of citing just the URL

During a recent discussion on EAE the question of the “readability” of two spaces came up. Naturally, since I originally planned to do my thesis in graphic design but failed to find relevant research, I was deeply skeptical.

At the end I was asked if I would be interested in learning about the “science” of readability and, of course, I said yes. Today the person got back to me, and this is the list she gave me, in its entirety:

  5. Lewenstein, M., et al. "Poynter Eyetrack Study." (2000).
  6. Quinn S., Stark P., Edmonds R. (2007) Eyetracking the News: A Study of Print and Online Reading. New York: The Poynter Institute.

I’ll leave aside my pet peeves about URL abuses for now; but when I checked the URL’s I found only a third of the list still accessible: [3] and [4] are 404’s. And [5] and [6] could not be located. Not even Google knows where [5] and [6] are: Poynter has “reorganized” their site and they haven’t placed redirects for their old links, even though there’s no way they’re not aware they have been widely cited.

When all the unlocatable citations are thrown out, the entire reference list contains only two citations.

Both of these ([1] and [2]) are behind a paywall, and I couldn’t read them at my home university. I can track them down, which I will do, and comment later when I’m better informed, but I’m already less than hopeful: [1]’s abstract shows suspicious terminology (such as “font size”) that casts doubts on the study’s methodology.

What does this mean? I don’t know, as I’m not really well informed at this point yet, but the terseness of the list still seems to suggest I wasn’t totally crazy when I tried tracking down research papers but failed.

Machine translation is IP theft, if you really think about it

“What mostly annoys human translators isn’t the arrogance of machines but their appropriation of the work of forgotten or anonymous humans,” a New York Times article writes.

I’ve never thought of it this way, but it’s entirely true. Machine translation, as bad as it is, only works because the scientists have stolen the work of countless translators and refuse to credit them as co-creators of the knowledge their machines depend on.

Newline after each sentence

A few days ago MR posted an XKCD comic that mentioned that some people put a newline after each sentence. And the way the comic is drawn seems to suggest these people are outliers.

I had a lot of problems with that comic. For one, being XKCD, the artist should have known that this style is favoured by many programmers, because to do otherwise would mean havoc when diff’ing. This third group of “outliers” is actually much bigger than the artist believes.

In any case, it turns out that putting a newline after each sentence has an unexpected benefit: If the text contains sentences that are too long, they literally stick out and shout at you. If your xterm is 200 columns wide and you’re still seeing tons of line wraps, you know you’ve got a major problem.

This got me thinking: We really need to make it easier for people to edit tagged text, and I don’t think the current breed of “programmer’s editors” is cutting it. We need a new paradigm where distracting details can be hidden, so that the benefits of “newline after each sentence” can be exploited.

Should I get an Orbit Reader?

Yesterday I stumbled onto Debbie Gillespie’s blog, surprisingly, by way of Editors Canada (actually Editors Toronto, even). I wish I had found this earlier, since what Debbie reported back in July 2014 directly contradicts what’s being taught in my program, and had I found it back then I’d still be able to change what I wrote.

Anyway, I followed the rabbit trail and eventually landed on the page to preorder the Orbit Reader 20. $50 would be easy to fork out, but I’d eventually need to pay $450 more, plus taxes (still much less than those other devices that I can’t afford, but still a significant amount of money). So should I get the device, or not?

Maybe not now? I should probably not hold up a device for people who really need it?

That worst designed thing known as systemd

Maybe systemd was not designed for people who customize their Linux systems a lot. So it must have been designed for the “average” end users, right?

How about something as end-user as switching wifi networks? Switching to a better wifi network is such a common thing you’d want to do (at least for people whose school sabotage their own eduroam connections so that people have to disable it while on campus but reenable it while off campus—yes, I’m talking about my own school, hello OCAD ITS) you’d think systemd must make it easy for the end user? How about easy to automate, as in you can script it?

When I started using Ubuntu a year ago I spent tons of time figuring out how to script Network Manager and all the pages I found suggest this simply can’t be done. You have to use the applet. So much for easy to use.

But nm-applet crashes all the time, and sometimes when you restart it it won’t even work. So what to do?

Just a few minutes ago I discovered that nmcli’s c command actually has an up subcommand, so I thought I discovered the treasure. But how well did it work, like actually?

ambrose@pingu:~$ nmcli c up 'xxxxxxxxxxxxxx 1'
Error: Connection activation failed: No suitable device found for this connection.
ambrose@pingu:~$ nmcli c down xxxxx
Error: 'xxxxx' is not an active connection.
Error: no active connection provided.
ambrose@pingu:~$ nmcli c down xxxxx\ 1
Connection 'xxxxx 1' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/0)
ambrose@pingu:~$ nmcli c up 'xxxxxxxxxxxxxx 1'
Error: Connection activation failed: No suitable device found for this connection.
ambrose@pingu:~$ nmcli c up 'xxxxxxxxxxxxxx 1' ifname wlp3s0
Error: device 'wlp3s0' not compatible with connection 'xxxxxxxxxxxxxx 1'.

Hello? How’s a wifi device incompatible with a wifi connection?

Ok, maybe it’s a permissions problem (which means their error messages are crap).

ambrose@pingu:~$ sudo nmcli c up 'xxxxxxxxxxxxxx 1' ifname wlp3s0
[sudo] password for ambrose: 
Error: device 'wlp3s0' not compatible with connection 'xxxxxxxxxxxxxx 1'.

Ok, I give up. I really don’t understand why anyone would think this Network Manager thing helps the end user. I had to work with wpa_supplicant directly on the Pi; working directly with wpa_supplicant is way easier than this once you figured out how to work with wpa_supplicant, you can’t even figure out how Network Manager does its thing.

Why is the granularity returned by the Linux driver so low?

So reading a Macbook’s ambient light sensor in Linux is just reading off /sys/class/hwmon/hwmon2/device/light – That seems easy and good, a far cry from having to write a C program.

The problem? Linux’s granularity of the read is way too low.

In MacOSX, the sample program returns numbers in at least the hundreds range. I can see the numbers change if I try very hard to cover where I think the sensors are. I get nonzero readings even in late afternoon when the room is nearly dark. In MacOSX, the light sensors felt super sensitive.

In Linux, the kernel returns an ordered pair like (12, 0) if I turn on my bright spotlights. If you put a piece of tape over the the webcam like a lot of people do, you get something more like (9, 0).

First disturbing thought: No matter what the ambient lighting looks like, Linux gives you zero for the right-hand-side sensor.

Even more disturbing: If I turn on just my regular 60W light I get all zeroes. From Linux’s point of view there’s no difference between no ambient light at all and having about 800 lumens dispersed in a small room. Heck, I get zero even during the day, right next to a window (so I live in an apartment – we get crappy lighting in apartments, but still). Compared to MacOSX, in Linux the light sensors seem so insensitive they are practically useless.

If we get zero even during the day, what point is reading from the light detectors? I can’t even tell night from day, or a darkened lecture hall from a brightly-lit classroom.

Short of reading the kernel source code is there even a way to figure out why granularity is so low?

Interim test plan

(If you belong to the same organization as I do you’ll know what this is for.)

This is a work in progress, but right now (October 5) I’m thinking:

General usability

  • Menu items should not generate 404 errors


Typography focused

  • Contrast ratio should be adequate
  • Elements intending to have contrast should have perceivable contrast

Keyboard operation focused

  • Each page should be navigable by keyboard alone

Text browing focused

  • Each page should render properly in a text browser
  • Logging in without Javascript should be possible
  • Pages should not contain garbage content when Javascript is not available


  • Dates generated by the template should be in French
  • Other content generated by the template should be in French
  • Static elements in the header and footer, etc. should be in French
  • Hidden elements that can be seen by a screen reader should be in French
  • Hidden elements that can be seen by a text browser ideally should be in French

OCAD Bookstore should do better (yes, @51OCADU)

I received some promotional mail from OCAD’s bookstore today, and this is it, in its entirety:

Having trouble viewing this email? Click here. Terms of Use | Contact Us

Without loading remote images (reading email with remote images is an unsafe practice), the mail they sent me is pretty much completely devoid of content.

So what if I clicked the link? I chose to do it on my text browser and I found that it’s pretty much just the same thing, only worse:

Having trouble viewing this email? Click here. [c8652cd6-9923-4d17-abae-bd5543fc82ca] [6b674e6e-88df-406a-9e68-8645794bc916] Terms of Use | Contact Us. OCAD U Bookstore, 51 McCaul Street, Toronto, Ontario M5T 3K4 Canada. SafeUnsubscribe? Tell a Friend! | Update Profile | About our service provider. Sent by

The mystery: Why did they even bother? If someone is “having trouble” seeing the original email, they probably can’t see images. Why repeat exactly the same thing, with no alternate text?

I was viewing the linked page on a text browser, which when confronted with alt-less images is smart enough to truncate some file names and replace some small ones with asterisks. (Text browsers, after all, are still visual interfaces.) Blind people, using screen readers, are going to be tortured with the images’ super long file names.

I know our bookstore is run by U of T, but if I called out the U of T wouldn’t it be even more damning? This is 2016, friends.

Syndicate content