(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.)

I have not used this so I can’t vet for its effectiveness, but AW is using Access for All’s “PAC” PDF accessibility checker.

So this is why they use SuperCollider for sonification, I think. First a lot of things like metronome beats are just one line of code. And second how do you record something written in WebAudioAPI? If I did this in SC that would be one line of code (I have already forgotten what that one line was but I remember it was just one line), but since I did this in WebAudioAPI I’m still scratching my head. And I don’t even have a lot of time left. I basically have to get up at 5am tomorrow, which means I have to sleep at 9pm or something today…

(I’ll adjust the vocabulary so that it’s understandable by most OCAD students. But nothing essential is changed. In fact by adjusting the vocabulary it becomes clear why I say the situation is ridiculous.) So what essentially happened in the past couple of days was that I have been banned from a studio. The tech specifically requested that I be banned only from his studio, but what happened was that I seem to have been banned from the entire building, including the elevator. Now this is a serious problem, because there can only be so many reasons how this could even have happened:

1. The person who made the change intentionally made the wrong changes (malice);
2. The person who made the change on the computer made a mistake and did not check their work so they never noticed there was a mistake (carelessness);
3. The person who made the change on the computer did everything correctly but the computer did something else and then lied to the person saying it did what was asked (logic error + bad UI);
4. The computer is incapable of making the requested change and does not provide any feedback as to what it has actually done (software deficiencies + bad UI);
5. The computer does random unexpected things from time to time, possibly when people try to make certain changes (random errors).

Any of these reasons are serious, and with the SU office having moved to 205 Richmond they have become more serious than ever. Just imagine, if a student has been unfairly banned from a studio and needs the help of the Student Advocate, they might not actually be able to get to the SU office to get help. Or students could be banned from the SU food bank. Worse, the entire SU staff could be shut out from their own office for no reason. (Even the second possibility is serious. I have basically been banned for carelessness. But if the person who banned me is as careless as I was they should be banned too =P) I think this needs to be looked into as soon as possible, before the Fall semester kicks in and make this problem one that potentially affects >4000 OCAD students.

So I thought I disabled Roots activation. I was wrong. Activation still caused trouble, and digging deeper I eventually found a way to completely disable it. Ironically, the correct way that I eventually found was my initial gut instinct that I had before I made the fateful mistake of deleting the file instead of doing this correct thing. And what is this “correct thing”? Just replace activation.php with a blank file. (That is, a file with a length of zero bytes if I’m not clear enough.) Yes really. Astonishingly, even with activation completely disabled WordPress is still acting strange. Apparently it gets wonky if you are using more than one menu. Since I need eight to pull off this project, I’m sort of doomed to failure. I’m going to resurrect activation.php to automatically reassign the menus. It’s ridiculous I have to do this but it looks like this is the only way out.

[The information written in this article has proved to be wrong. See the follow-up to this article instead.] Roots is pretty cool, but a major problem is the “activation” page. I’ve lost work more than once because I pressed the “Save” button by mistake, and my latest mistake involves having to ask someone to fix things up by FTP. It seriously provides no benefits at all and it has the potential and is very likely to do a whole lot of harm. So why is this dangerous page in there, and why is there no official way to completely take it out? After breaking a site (by removing activation.php — bad idea), I poked around safely in my dev environment and found out that patching Roots in the following way will completely disable this dangerous “feature”. From WordPress’s point of view the activation page doesn’t even exist any more, even the activation link is gone, so this is perfect:

diff --git a/lib/activation.php b/lib/activation.php
index 4b677d6..a1b7c34 100644
--- a/lib/activation.php
+++ b/lib/activation.php
@@ -2,10 +2,12 @@
 /**
  * Theme activation
  */
+if (false) { // disable the dangerous "activation" page
 if (is_admin() && isset($_GET['activated']) && 'themes.php' == $GLOBALS['pagenow']) {
   wp_redirect(admin_url('themes.php?page=theme_activation_options'));
   exit;
 }
+} // disable the dangerous "activation" page
 
 function roots_theme_activation_options_init() {
   register_setting(
@@ -21,6 +23,7 @@ function roots_activation_options_page_capability($capability) {
 add_filter('option_page_capability_roots_activation_options', 'roots_activation_options_page_capability');
 
 function roots_theme_activation_options_add_page() {
+  return; // disable the dangerous "activation" page
   $roots_activation_options = roots_get_theme_activation_options();
 
   if (!$roots_activation_options) {

This is, of course, not really a piece of adaptive technology, but it’s a reasonable first approximation and this still is, in a sense, perhaps, a segment whose needs should be addressed. (Ok, I didn’t say it. Someone in an AIGA webinar said this a year and a half ago or so.) The easiest way to build w3m on MacOSX is to use the original version of w3m, which has been modified to use GNU configure. The w3mmee package does not compile (without some investigation and fixing, which would take time). Before building the package, one line needs to be patched. The patch for main.c can be found at Qi Hardware’s site. Boehm GC also needs to be installed before building the package. Unfortunately HP has removed Boehm GC’s page. So I grabbed the package from Debian. (You need the .orig package.) So far the browser seems to work.

We really have been introduced only to CapScribe and Amara, the latter of which I was deeply familiar. But is this really the limit of what’s available?

Aegisub

When I was looking for alternatives for our captioning assignment, by chance I found Aegisub after a long unsuccessful search for open-source MacOSX-compatible editors. It is MacOSX compatible. And it is open-source. But for a simple school project the interface looked far too complicated; it’s, however, probably going to be really useful if I learnt how to use it and a real project comes my way.

SubtitleEdit, Jubler, MPC-HC

A few days ago I was checking my site statistics and noticed an interesting backlink, which linked to this post which recommended a few subtitle editors that I didn’t know about:

• SubtitleEdit—open-source, but Windows only
• SubtitleEdit Online—cloud-based version of the above (alternative to Amara)
• Jubler—open-source, multiplatform (Java-based)
• MPC-HC—open-source, but Windows only

Since I don’t have Windows, the only one I can check out is Jubler. I’ll do that some time.

InqScribe

The other day I landed on this post and a poster recommended InqScribe. It supports both Windows and MacOSX, but it’s a commercial piece of software. So there seems to be really quite a lot of options other than just CapScribe and Amara. Maybe some time I’ll try them all and report back what I find.

I should not be doing this at such a time in the semester, but I kept the screen reader running for a few hours today, and I found, to my dismay, that the answer is no. A system-provided screen reader is not necessarily stable. The first program to fall victim to instability was Terminal. It started crashing for no apparent reason, and at one point it repeatedly crashed after less than a couple of minutes of usage. Terminal and VoiceOver do not play well together. The second program to fall victim to instability was Safari. After a few hours of screen reader usage, Safari started to stop responding to tab switching. Turning VoiceOver off immediately fixed the problem. Turning it on caused the problem to resurface after just a couple of minutes. If such is the stability of a screen reader built into the OS, I wonder what kind of stability third-party screen readers on other platforms can really achieve.