University of Glasgow

Roderic Page

::: {style="padding:1em;border:1px solid #DDD;border-radius:0.2em;"}
How to cite: **Page, R. (2023). Document layout analysis.
<https://doi.org/10.59350/z574z-dcw92>**
:::

Some notes to self on document layout analysis.

I'm revisiting the problem of taking a PDF or a scanned document and
determining its structure (for example, where is the title, abstract,
bibliography, where are the figures and their captions, etc.). There are
lots of papers on this topic, and lots of tools. I want something that I
can use to process both born-digital PDFs and scanned documents, such as
the [ABBYY](https://www.abbyy.com),
[DjVu](https://en.wikipedia.org/wiki/DjVu) and
[hOCR](https://en.wikipedia.org/wiki/HOCR) files on the Internet
Archive. PDFs remain the dominant vehicle for publishing taxonomic
papers, and aren't going away any time soon (see Pettifer et al. for a
nuanced discussion of PDFs).

There are at least three approaches to document layout analysis.

## Rule-based

The simplest approach is to come up rules, such as "if the text is large
and it's on the first page, it's the title of the article". Examples of
more sophisticated rules are given in Klampfl et al., Ramakrishnan et
al., and Lin. Rule-based methods can get you a long way, as shown by
projects such as [Plazi](https://plazi.org). But there are always
exceptions to rules, and so the rules need constant tweaking. At some
point it makes sense to consider probabilistic methods that allow for
uncertainty, and which can also "learn".

## Large language models (LLMs)

At the other extreme are Large language models (LLMs), which have got a
lot of publicity lately. There are a number of tools that use LLMs to
help extract information from documents, such as LayoutLM (Xu et al.),
[Layout Parser](https://layout-parser.github.io), and VILA (Shen et
al.). These approaches encode information about a document (in some case
including the (*x*,*y*) coordinates of individual words on a page) and
try and infer which category each word (or block of text) belongs to.
These methods are typically coded in Python, and come with various tools
to display regions on pages. I've had variable success getting these
tools to work (I am new to Python, and am also working on a recent Mac
which is not the most widely used hardware for machine learning). I have
got other ML tools to work, such as an Inception-based model to classify
images (see [Adventures in machine learning: iNaturalist, DNA barcodes,
and
Lepidoptera](https://iphylo.blogspot.com/2023/07/adventures-in-machine-learning.html)),
but I've not succeeded in training these models. There are obscure
Python error messages, some involving Hugging Face, and eventually my
patience wore out.

Another aspect of these methods is that they often package everything
together, such that they take a PDF, use OCR or ML methods such as
[Detectron](https://ai.meta.com/tools/detectron/) to locate blocks, then
encode the results and feed them to a model. This is great, but I don't
necessarily want the whole package, I want just some parts of it. Nor
does the prospect of lengthy training appeal (even if I could get it to
work properly).

The approach that appealed the most is VILA, which doesn't use (*x*,*y*)
coordinates directly but instead encodes information about "blocks" into
text extracted from a PDF, then uses an LLM to infer document structure.
There is a simple demo at [Hugging
Face](https://huggingface.co/allenai/vila-scibert-cased-s2vl). After
some experimentation with the code, I've ended up using the way VILA
represents a document (a JSON file with a series of pages, each with
lists of words, their positions, and information on lines, blocks, etc.)
as the format for my experiments. If nothing else this means that if I
go back to trying to train these models I will have data already
prepared in an appropriate format. I've also decided to follow VILA's
scheme for labelling words and blocks in a document:

- Title
- Author
- Abstract
- Keywords
- Section
- Paragraph
- List
- Bibliography
- Equation
- Algorithm
- Figure
- Table
- Caption
- Header
- Footer
- Footnote

I've tweaked this slightly by adding two additional tags  
from VILA's [Labeling Category
Reference](https://docs.google.com/document/d/1frGmzYOHnVRWAwTOuuPfc3KVAwu-XKdkFSbpLfy78RI/edit?usp=sharing),
the "semantic" tags "Affiliation" and "Venue". This helps separate
information on author names ("Author") from their affiliations, which
can appear in very different positions to the author's names. "Venue" is
useful to label things such as a banner at the top of an article where
the publisher display the name of the journal, etc.

## Conditional random fields

In between masses of regular expressions and large language models are
approaches such as [Conditional random
fields](https://en.wikipedia.org/wiki/Conditional_random_field) (CRFs),
which I've used before to parse citations (see [Citation parsing tool
released](https://iphylo.blogspot.com/2021/07/citation-parsing-released.html)).
Well known tools such as [GROBID](https://github.com/kermitt2/grobid)
use this approach.

CRFs are fast, and somewhat comprehensible. But it does require [Feature
engineering](https://en.wikipedia.org/wiki/Feature_engineering), that
is, you need to come up with features of the data to help train the
model (for the systematists among you, this is very like coming up with
characters for a bunch of taxa). This is were you can reuse the rules
developed in a rules-based approach, but instead of having the rules
make decisions (e.g., "big text = Title"), you just a rule that detects
whether text is big or not, and the model combined with training data
then figures out if and when big text means "Title". So you end up
spending time trying to figure out how to represent document structure,
and what features help the model get the right answer. For example,
methods such as Lin's for detecting whether there are recurring elements
in a document are great source of features to help recognise headers and
footers. CRFs also make it straightforward to include dependencies (the
"conditional" in the name). For example, a bibliography in a paper can
be recognised not just by a line having a year in it (e.g., "2020"), but
there being nearby lines that also have years in them. This helps us
avoid labelling isolated lines with years as "Bibliography" when they
are simply text in a paragraph that mentions a year.

Compared to LLMs this a lot of work. In principle with an LLM you "just"
take a lot of training data (e.g., text and location on a page) and let
the model to the hard work of figuring out which bit of the document
corresponds to which category (e.g., title, abstract, paragraph,
bibliography). The underlying model has already been trained on
(potentially) vast amounts of text (and sometimes also word
coordinates). But on the plus side, training CRFs is very quick, and
hence you can experiment with adding or removing features, adding
training data, etc. For example, I've started training with about ten
(10) documents, training takes seconds, and I've got serviceable
results.

::: {.separator style="clear: both;"}
[![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi02en_43jWD45tsJ9bVqrJFcVG_NYr_obOmFGzT2PuW-3AbvwMbtt7y43TaGYqaQL4tURGVA0Bm_e6DvmN6kGiROtqFYj_Tjco0KeXnCwUr2ASqewCNjbunTa7nmMVp8jKPWk0B6BHLSbZrz85mzq6d78XNRgG1G3g9MupScfxBbO14B89kfMS/s400/Screenshot%202023-08-31%20at%2011.54.13.png){border="0"
height="400" original-height="855"
original-width="596"}](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi02en_43jWD45tsJ9bVqrJFcVG_NYr_obOmFGzT2PuW-3AbvwMbtt7y43TaGYqaQL4tURGVA0Bm_e6DvmN6kGiROtqFYj_Tjco0KeXnCwUr2ASqewCNjbunTa7nmMVp8jKPWk0B6BHLSbZrz85mzq6d78XNRgG1G3g9MupScfxBbO14B89kfMS/s855/Screenshot%202023-08-31%20at%2011.54.13.png){style="display: block; padding: 1em 0; text-align: center; "}
:::

Lots of room for improvement, but there's a constant feedback loop of
seeing improvements, and thinking about how to tweak the features. It
also encourages me to think about what went wrong.

## Problems with PDF parsing

To process PDFs, especially "born digital" PDFs I rely on
[pdf2xml](https://github.com/rdmpage/pdf2xml), originally written by
Hervé Déjean (Xerox Research Centre Europe). It works really well, but
I've encountered a few issues. Some can be fixed by adding more fonts to
my laptop (from [XpdfReader](http://www.xpdfreader.com/download.html)),
but others are more subtle.

The algorithm used to assign words to "blocks" (e.g., paragraphs) seems
to struggle with superscripts (e.g., ^1^), which often end up being
treated as separate blocks. This breaks up lines of text, and also makes
it harder to accurately label parts of the document such as "Author" or
"Affiliation".

Figures can also be problematic. Many are simply bitmaps embedded in a
PDF and can be easily extracted, but sometimes labelling on those
bitmaps, or indeed big chunks of vector diagrams are treated as text, so
we end up with story text blocks in odd positions. I need to spend a
little time thinking about this as well. I also need to understand the
"vet" format pdftoxml extracts from PDFs.

PDFs also have all sorts of quirks, such as publishers slapping cover
pages on the front, which make feature engineering hard (the biggest
text might now be not be the title but some cruff from the publisher).
Sometimes there are clues in the PDF that it has been moodier.! For
example, ResearchGate inserts a "rgid" tag in the PDF when it adds a
cover page.

## Yes but why?

So, why I am doing this? Why battle with the much maligned PDF format.
It's because a huge chunk of taxonomic and other information is locked
up in PDFs, and I'd like a simpler, scalable, way to extract some of
that. Plazi is obviously the leader in this are in terms of the amount
of information they have extracted, but their approach is
labour-intensive. I want something that is essentially automatic, that
can be trained to handle the idiosyncracities of the taxonomic
literature, and can be applied to both born digital PDFs and OCR from
scans in the Biodiversity Heritage Library and elsewhere. Even if we
could simply extract bibliographic information (to flesh out the
citation graph) and the figures, that would be progress.

## References

Déjean H, Meunier J-L (2006) A System for Converting PDF Documents into
Structured XML Format. In: Bunke H, Spitz AL (eds) Document Analysis
Systems VII. Springer, Berlin, Heidelberg, pp 129--140
<https://doi.org/10.1007/11669487_12>

Klampfl S, Granitzer M, Jack K, Kern R (2014) Unsupervised document
structure analysis of digital scientific articles. Int J Digit Libr
14(3):83--99. <https://doi.org/10.1007/s00799-014-0115-1>

Lin X (2003) Header and footer extraction by page association. In:
Document Recognition and Retrieval X. SPIE, pp 164--171
<https://doi.org/10.1117/12.472833>

Pettifer S, McDERMOTT P, Marsh J, Thorne D, Villeger A, Attwood TK
(2011) Ceci n'est pas un hamburger: modelling and representing the
scholarly article. Learned Publishing 24(3):207--220.
<https://doi.org/10.1087/20110309>

Ramakrishnan C, Patnia A, Hovy E, Burns GA (2012) Layout-aware text
extraction from full-text PDF of scientific articles. Source Code for
Biology and Medicine 7(1):7. <https://doi.org/10.1186/1751-0473-7-7>

Shen Z, Lo K, Wang LL, Kuehl B, Weld DS, Downey D (2022) VILA: Improving
Structured Content Extraction from Scientific PDFs Using Visual Layout
Groups. Transactions of the Association for Computational Linguistics
10:376--392. <https://doi.org/10.1162/tacl_a_00466>

Xu Y, Li M, Cui L, Huang S, Wei F, Zhou M (2020) LayoutLM: Pre-training
of Text and Layout for Document Image Understanding. In: Proceedings of
the 26th ACM SIGKDD International Conference on Knowledge Discovery &
Data Mining. pp 1192--1200

> Written with [StackEdit](https://stackedit.io/).


A System for Converting PDF Documents into Structured XML Format

Unsupervised document structure analysis of digital scientific articles

Header and footer extraction by page association

Ceci n'est pas un hamburger: modelling and representing the scholarly article

Layout-aware text extraction from full-text PDF of scientific articles

VILA: Improving Structured Content Extraction from Scientific PDFs Using Visual Layout Groups

How to cite:
<strong>
 Page, R. (2023). Document layout analysis. https://doi.org/10.59350/z574z-dcw92
</strong>
Some notes to self on document layout analysis. I’m revisiting the problem of taking a PDF or a scanned document and determining its structure (for example, where is the title, abstract, bibliography, where are the figures and their captions, etc.). There are lots of papers on this topic, and lots of tools.

Document layout analysis

A while ago I posted [BHL to PDF
workflow](http://iphylo.blogspot.com/2012/06/bhl-to-pdf-workflow.html)
which was a sketch of a work flow to generate clean, searchable PDFs
from Biodiversity Heritage Library (BHL) content:  
  
![Workflow](http://lh6.ggpht.com/-KWASs15P3SM/T9thCN9SkxI/AAAAAAAABa4/ajJH8yZPzk8/workflow.png?imgmax=800 "workflow.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="550" height="510"}  
I\'ve made some progress on putting this together, as well as expanded
the goal somewhat. In fact, there are several goals:  

1.  BioStor articles need to be archived somewhere. At the moment they
    live on my server, and metadata is also served by BHL (as the
    \"parts\" you see in a scanned volume). Long term maybe PubMed
    Central is a possibility (BHL essentially becomes a publisher).
    Imagine PubMed Central becoming the primary archival repository for
    biodiversity literature.
2.  BioStor articles could be more useful if the OCR text was cleaned up
    and marked up (e.g., highlighting taxon names, localities,
    extracting citations, etc.).
3.  If BioStor articles were marked up to same extent as *ZooKeys* then
    we could use tools developed for *ZooKeys* (see [Towards an
    interactive taxonomic article: displaying an article from
    ZooKeys](http://iphylo.blogspot.com/2011/12/towards-interactive-taxonomic-article.html))
    for a richer reading experience.
4.  Cleaned OCR text could also be used to generate searchable PDFs,
    which are still the most popular way for people to read articles
    (see [Why do scientists tend to prefer PDF documents over HTML when
    reading scientific
    journals?](http://www.quora.com/Why-do-scientists-tend-to-prefer-PDF-documents-over-HTML-when-reading-scientific-journals)).
    BioStor already [generates
    PDFs](http://iphylo.blogspot.com/2010/04/biostor-gets-pdfs-with-xmp-metadata.html),
    but these are simply made by wrapping page images in a PDF.
    Searchable PDFs would be much friendlier.

  
For BioStor articles to be archived in PubMed Central they would need to
be marked up using the [Journal Archiving and Interchange Tag
Suite](http://jats.nlm.nih.gov) (formerly the NLM DTDs). This is the
markup used by many publishers, and also the tag suite that
[TaxPub](http://www.ncbi.nlm.nih.gov/books/NBK100351/) build upon.  
  
The idea of having BioStor marked up in JATS is appealing, but on the
face of it impossible because the all we have is page scans and some
[pretty ropey OCR](http://iphylo.blogspot.com/2010/12/bhl-and-ocr.html).
But because the NLM has also been heavily involed in scanning the
historical literature they are used to dealing with scanned literature,
and JATS can accommodate articles ranging from scans to fully marked up
text. For example, take a look at the article \"Microsporidian
encephalitis of farmed Atlantic salmon (Salmo salar) in British
Columbia\" which is in PubMed Central
([PMC1687123](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1687123/)).
PMC has basic metadata for the article, scans of the pages, and two
images extracted from those pages. This is pretty much what BioStor
already has (minus the extracted images).  
  
With this in mind, I dusted off some old code, put it together and
created an example of the first baby steps towards BioStor and JATS. The
code is in [github](https://github.com/rdmpage/biostor-jats){<="" a=""},
and there is a live example
[here](https://dl.dropboxusercontent.com/u/639486/65706/65706.html).  
  
![Jats](http://lh4.ggpht.com/-eSgZZX6ZNts/Up83my8dReI/AAAAAAAADMw/YJMSXlgipLU/jats.png?imgmax=800 "jats.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="550"}  
The example takes BioStor article
[65706](http://biostor.org/reference/65706), converts the metadata to
JATS, links in the page scans, and also extracts images from the page
scans based on data in the ABBYY OCR files. I\'ve also generated HTML
from the DjVu files, and this HTML includes hOCR tags that embed
information about the OCR text. This format can be edited by tools such
as (see Jim Garrison\'s moz-hocr-edit discussed in [Correcting OCR using
hOCR in
Firefox](http://iphylo.blogspot.com/2011/07/correcting-ocr-using-hocr-firefox.html)).
This HTML can be processed to output a PDF that includes the page scans
but also has the OCR text as \"hidden text\" so the reader can search
for phrases, or copy and paste the text (try the [PDF for article
65706](https://dl.dropboxusercontent.com/u/639486/65706/65706.pdf)).  
  
I\'ve put the HTML (and all the XML and images) in github, so one
obvious model for working on an article is to put it into a github
repository, push any edits made to the repository, then push that to a
web server that displays the articles.  
  
There are still a lot of rough edges, and I think we can buld nicer
interfaces than moz-hocr-edit (e.g., using the \"contenteditable\"
attribute in the HTML), althogh moz-hocr-edit has the nice feature of
being able to save the edits straight back to the HTML file (saving
edited HTML to disk is a non-trivial task in most web browsers). I also
need to add the code for building the initial JATS file (currently this
is hidden on the BioStor server). There are also issues about PDF
quality. At the moment I output black and white PNGs, which look nice
and clean but can mangle plates and photos. I need to tweak that aspect
of the process.  
  
One application of these tools would be to take a single journal and
convert all the BioStor articles into JATS, then make it available for
people to further clean and markup as needed. There is an extraordinary
amount of information locked away in this literature, it would be nice
if we made better use of that treasure trove.  
  


A while ago I posted BHL to PDF workflow which was a sketch of a work flow to generate clean, searchable PDFs from Biodiversity Heritage Library (BHL) content: I've made some progress on putting this together, as well as expanded the goal somewhat. In fact, there are several goals:BioStor articles need to be archived somewhere. At the moment they live on my server, and metadata is also served by BHL (as the "parts" you see in a scanned volume).

Towards BioStor articles marked up using Journal Archiving Tag Set

[![](http://photo.blogpressapp.com/photos/11/09/07/s_1908.jpg){border="0"
width="128" height="128" align="right"
style="margin:5px"}](http://photo.blogpressapp.com/show_photo.php?p=11/09/07/1908.jpg)  
Since I won\'t be able to be at the [Biodiversity Heritage
Library\'s](http://www.biodiversitylibrary.org){target="_blank"} Life
and Literature meeting I thought I\'d share some ideas for their [Life
and Literature Code
Challenge](http://www.lifeandliterature.org/p/code-challenge.html){target="_blank"}.
The deadline is pretty close (October 17) so having ideas now isn\'t
terribly helpful I admit. That aside, here are some thoughts inspired by
the challenge. In part this post has been inspired by the [Results of
the PLoS and Mendeley \"Call for
Apps\"](http://www.mendeley.com/blog/developer-resources/what-the-scientific-community-wants-computers-to-do-for-them-the-results-of-the-plos-and-mendeley-call-for-apps/){target="_blank"},
where PLoS and Mendeley asked for people (not necessarily developers) to
suggest the kind of apps they\'d like to see. As an aside, one thing
conspicuous by it\'s absence is a prize for winning the challenge. PLoS
and Mendeley have a [\"API Binary
Battle\"](http://dev.mendeley.com/api-binary-battle){target="_blank"}
with a prize of \$US 10,001, which seems more likely to inspire people
to take part.  
  
**Visual search engine**  
I suspect that many BHL users are looking for illustrations (exemplified
by the images being gathered in BHL\'s [Flickr
group](http://www.flickr.com/photos/biodivlibrary/sets/){target="_blank"}).
One way to search for images would be to search within the OCR text for
figure and plate captions, such as \"Fig. 1\". Indexing these captions
by taxonomic name would provide a simple image search tool. For modern
publications most figures are on the same page as the caption, but for
older publications with illustrations as plates, the caption and
corresponding image may be separated (e.g., on facing pages), so the
search results might need to show pages around the page containing the
caption. As an aside, it\'s a pity the Flickr images only link to the
BHL item and not the BHL page. If they did the later, and the images
were tagged with what they depict, you could great a visual search
engine using the Flickr API (of course, this might be just the way to
implement the visual search engine --- harvest images, tags with PageID
and taxon names, upload to Flickr).  
  
**Mobile interface**  
The BHL web site doesn\'t look great on an iPhone. It makes no
concessions to the mobile device, and there are some weird things such
as the way the list of pages is rendered. A number of mainstream science
publishers are exploring mobile versions of their web sites, for example
[Taylor and Francis](http://www.tandfonline.com){target="_blank"} have a
[jQuery Mobile](http://jquerymobile.com/){target="_blank"} powered
interface for mobile users. I\'ve explored iPad interfaces to scientific
articles in previous posts. BHL content posses some challenges, but is
fundamentally the same as viewing PDFs --- you have fixed pages that you
may want to zoom.  
  
**OCR correction**  
There is a lot of scope for cleaning up the OCR text in BHL. Part of the
trick would be to have a simple use interface for people to contribute
to this task. In an earlier post I discussed a [Firefox hOCR
add-on](http://iphylo.blogspot.com/2011/07/correcting-ocr-using-hocr-firefox.html){target="_blank"}
that provides a nice way to do this. Take this as a starting point, add
a way to save the cleaned up text, and you\'d be well on the way to
making a useful tool.  
  
**Taxon name timeline**  
Despite the shiny new interface, the [Encyclopedia of
Life](http://www.eol.org){target="_blank"} still displays BHL literature
in the same clunky way I described in an [earlier blog
post](http://iphylo.blogspot.com/2009/09/visualising-biodiversity-heritage.html){target="_blank"}.
It would great to have a timeline of the usage of a name, especially if
you could compare the usage of different names (such as
[synonyms](http://iphylo.blogspot.com/2009/10/biodiversity-heritage-library.html){target="_blank"}).
In many ways this is the BHL equivalent [Google Books Ngram
viewer](http://ngrams.googlelabs.com/){target="_blank"}.  
  
These are just a few hastily put together thoughts. If you have any
other ideas or suggestions, feel free to add them as comments below.  
  
- Posted using BlogPress from my iPad  


Since I won't be able to be at the Biodiversity Heritage Library's Life and Literature meeting I thought I'd share some ideas for their Life and Literature Code Challenge. The deadline is pretty close (October 17) so having ideas now isn't terribly helpful I admit. That aside, here are some thoughts inspired by the challenge.

Suggested apps for BHL's Life and Literature Code Challenge

Quick post on a little tool I came across,
[moz-hocr-edit](http://jimgarrison.org/moz-hocr-edit/). This Firefox
add-on lets you proofread Optical Character Recognition (OCR) output.
Given my interest in [OCR and the Biodiversity Heritage
Library](http://iphylo.blogspot.com/2010/12/bhl-and-ocr.html) I decided
to take it for a spin.  
  
**moz-hocr-edit** uses the [hOCR](http://en.wikipedia.org/wiki/HOCR),
which is a format for representing the output of OCR software, and is
used by tools such as [OCRopus](http://en.wikipedia.org/wiki/OCRopus)
(you can see the public specification for hOCR
[here](http://docs.google.com/View?docid=dfxcv4vc_67g844kf)). Basically
it\'s a microformat, that is, it\'s HTML with some additional tags.
Given some hOCR, **moz-hocr-edit** enables you to edit the OCR output
line-by-line.  
  
**Demo**  
I\'ve created a simple demo based upon [Case 3368 Eatoniella Dall, 1876
and EATONIELLIDAE Ponder, 1965 (Mollusca, Gastropoda): proposed
conservation](http://biostor.org/reference/80780). For the demo to work
you will need to use the Firefox web browser with the
[moz-hocr-edit](https://addons.mozilla.org/en-US/firefox/addon/11067)
installed.  
  

1.  Go to <http://dl.dropbox.com/u/639486/hocr/80780.html>
2.  You will see a simple HTML representation of the OCR text from
    \"Case 3368 Eatoniella Dall, 1876 and EATONIELLIDAE Ponder, 1965
    (Mollusca, Gastropoda): proposed conservation\". I created this HTML
    from the original [ABBYY
    FineReader](http://en.wikipedia.org/wiki/ABBYY) XML from the
    Internet Archive.
3.  On the bottom right-hand of the Firefox browser window you should
    see **hOCR**. Click on it and select \"Edit this hOCR document\":  
    ![Statusbar](http://lh6.ggpht.com/-UvG_XpBDCgw/Th2LnwmpZtI/AAAAAAAAA6g/VMW6guACy5U/statusbar.png?imgmax=800){style="display:block; margin-left:auto; margin-right:auto;"
    border="0" width="397" height="130"}
4.  Firefox will open a new tab that will look something like this:  
    ![Screenshot](http://lh5.ggpht.com/-W1g4z7-IiDY/Th2Lo2GMvJI/AAAAAAAAA6k/_P49tsGwSUU/screenshot.png?imgmax=800){style="display:block; margin-left:auto; margin-right:auto;"
    border="0" width="400" height="289"}
5.  You can now edit individual lines of text, and see your edits
    applied to the HTML below.

**moz-hocr-edit** is a neat little tool. With appropriate web server
settings (and, as the tool\'s author Jim Garrison suggests,
autoversioning) it could the basis of a great tool for correcting OCR
errors in BHL.  


Quick post on a little tool I came across, moz-hocr-edit. This Firefox add-on lets you proofread Optical Character Recognition (OCR) output.

Messages de Rogue Scholar

Document layout analysis

Towards BioStor articles marked up using Journal Archiving Tag Set

Suggested apps for BHL's Life and Literature Code Challenge

Correcting OCR using hOCR in Firefox