Higher-Order Perl: The Quest for an Accessible Version, Initial Impressions (Long)

  • Thread starter Veli-Pekka Tätilä
  • Start date

Veli-Pekka Tätilä

This time a less technical post. Briefly put I managed to get a screen
reader accessible version of Higher-Order Perl, yes. For those of you who
are interested, including sight-impaired posters, here's the full story.
Please snip heavily if you do feel like replying. Here we go:

In a past thread about emulating generators in Perl the book Higher-Order
perl was mentioned. Having been interested in functional programming for a
while, and growing to like Perl more and more, I thought I'd give the book a
try. The table of contents convinced me that this is a book I'll definitely
want to read, if at all possible.

On some Googling the first promissing thing I hit was the Amazon product
page at:


It listed an electronic PDF version as being available for download.
However, I was a bit sceptical initially. AS long as a book is
programmatically accessible to a screen reader, there's nothing preventing
you from copying it by say writing a custom speech synthesizer or another
screen reader. This is a good enough reason for many e-publishers to
sacrifice accessibility for security.

So to make sure I wouldn't be wasting my money for nothing, I posted to this
group and alt.comp.blind-users asking if anyone would know about the
accessibility of this book or could try it out with some screen reader. I
didn't get too many replies but some off-list posts urged me to contact
Amazon which I did. They replied promptly if a little vaguely saing that
most of their e-books are not screen reader accessible at all, sorry. They
didn't mention Higher-Order Perl in particular but being a bit of a
pessimist, I thought I daren't risk it.

Another thing I did meanwhile was browsing the Higher-Order Perl Web-site


I saw the author's e-mail address on the site and wrote him about the
accessibility as well. He didn't know if the Amazon e-book was accessible
but told me that his publisher, Morgan Kauffman, has got a standard policy
of helping out sight-impaired people.

After this clue the rest was pretty easy. I ended up contacting the
publisher using the info that Mark gave me and told them about my situation.
Figuring out that my chance of getting an accessible copy was good enough, I
also ended up ordering a physical copy from a Finnish on-line bookstore at:


After negotiating with the publisher things went pretty smoothly. I got the
physical book I had orddered as expected and sent the publisher a scanned
copy of the receipt, though my initial mail would have been good enough,
too. In the end, they actually sent me a CD via postal mail containing an
accessible PDF version of the higher-Order Perl book. Mark, the book author,
also told me this is the version from which they print the book in the first
place. As a bonus, shipping the CD only took some days which is certainly
much shorter than what an ordder at Amazon's to Finland would have taken,

The last issue I had to deal with was formatting. Acrobat Reader's plain
text conversion is still pretty poor, especially in terms of getting the
heading contents just right and preserving indentation. Both are important
aids in reading code magnified or doing regular expression searches based on
the TOC, which is something I do a lot.

I discovered two solutions for the formatting problem. The first was to get
the example code on the Higher-Order Perl Web-site in a zip archive. WHere
as the alternative was about running the textual PDF file through OmniPage
and saving the re-recognized text as formatted plain text. Formatting here
refers to preserving indentation which the OCR:ed version did marvelously in
addition to not messing up the chapter headings occasionally, like the
straight plain text conversion does.

So in the end I was delighted to get an accessible version rather easily,
and I can still keep the physical copy, too, for my sighted programming
friends, for example. By the way, I would also warmly recommend other books
by Morgan Kauffman publishing as it is finally possible to get accessible
copies, without hours of manual scanning or painfully slow reading using a
CCTV. I myself am definitely going to support accessible publishers in the
future. It is too bad not many of them tell you officially, about their
policies on accessibility. Services like this for the sight-impaired
community are pretty rare, as far as I can tell. Some individual Web-sites
do come to mind.

Finally, though far from a full review, I'd like to say a word or two on the
book itself:
I've now read the first three chapters and the book is even better than I
anticipated. Concepts such as caching and recursion are delt with
extensively and clearly, compared to the text book definitions that are easy
to find. I usually don't like books that make heavy use of example code to
get the point across, preferring to experiment on my own. Again this one is
an Exception. The examples are more useful and generic than most Ive seen,
the K&R C-book comes to mind, and they start out simple so that the basic
concepts communicate well. Another thing I like in the examples is the fact
that the bits of code and their explanations, with no reference to the line
numbres, are often closely related on the page and thus easy to read with

Lastly, I've noticed that a key part in learning is often the style in which
the material is presented. It just so happens that the author's style
resonates well with me. One useful technique employed in the book, is
starting out with a concrete example and then dealing with the consequences
more abstractly and generally later on. This works great. The alternative of
starting out very abstractly and going concrete afterwords, is something I
often find mentally taxing, as the abstract stuff will then usually make
sense on second reading, if at all.

One example of not making things too abstract unless you have to, and using
rather informal language where it makes the whole thing clearer, is this
snippet related to an HTML processing algorithm:

Quote concrete definition:
Each text in the file is either a "keeper," because we know it's inside an
<h1> element, or a "maybe," because we don't. Whenever we process an <h1>
element, we'll promote all the "maybes" that it contains to "keepers." At
the end, we'll print the keepers and throw away the maybes.
End quote.

Going in the other direction, I'm on a Uni course about Component Based
Software Production and sometimes the abstractions are very hard to swallow.
Here's one of the most complex definitions I've come across so far. I seem
to lose the thoughts I did have by the second half of the sentence (mind you
the output is linear speech, and pretty fast, too):

Quote abstract example:
Prediction-enabled component technologies exploit the relationship between
structural restrictions and assumptions of analysis models to compute
properties of assemblies based on trusted properties of the assembly's
constituent components.
End quote.

DJ Stunks

Veli-Pekka Tätilä said:
Another thing I did meanwhile was browsing the Higher-Order Perl Web-site


I saw the author's e-mail address on the site and wrote him about the
accessibility as well. He didn't know if the Amazon e-book was accessible
but told me that his publisher, Morgan Kauffman, has got a standard policy
of helping out sight-impaired people.

Did he mention the current state of his MediaWiki or an ETA?



Veli-Pekka Tätilä

DJ Stunks wrote:>>
Did he mention the current state of his MediaWiki or an ETA? <snip>
Well, actually I noticed the bit about the Wiki and that in the future, once
the Whole thing is ready, he will publish a free on-line version as well. I
did ask about the Wiki and whether it would be possible to get a plain text
version of it, as far as I can remember. I think Mark skipped that
particular bit, liekly thinking that people ought to wait for the official
launch, but instructed me in getting an accessible version as I mentioned.

On a side note, I just wread the chapter on Iterators and it is very good. I
found the passage on the different kinds of exhaustion values enlighthing,
thinking with a Java background that a separate method or returning some
kind of null value (undef, that is), if feasible, Would be the only
sensible choice. But the book lists several other tricks. The explanation of
closures is one of the best I've read so far, too.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Latest member

Latest Threads