{'fraction_non_alphanumeric': 0.03158634863973173, 'fraction_numerical': 0.006274000757206988, 'mean_word_length': 4.74223602484472, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 3, 'lorem ipsum': 0, 'www.': 1, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
You’ve translated it, now what?

Humans use document formatting to discover document and section titles, and important phrases. But when machines process a paper–especially documents OCRed from images–these cues are often invisible to downstream processes: words in footnotes or body text are treated as just as important as words in titles. It would be better for indexing and summarization tools to be guided by implicit document structure. In an ODNI-sponsored project, ARLIS looked at discovering formatting in OCRed text as a way to infer document structure. Most OCR engines output results as hOCR (an XML format), giving bounding boxes around characters. In theory, this also provides style information such as bolding and italicization, but in practice, this capability is limited. For example, the Tesseract OCR tool provides bounding boxes, but does not attempt to detect bold text (relevant to author emphasis and specialized fields in e.g. print dictionaries), and its discrimination of italicization is poor. Our project inferred font size from hOCR bounding boxes, and using that and other cues (e.g. the fact that titles tend to be short) determined which text constituted section titles; from this, a document outline can be created. We also experimented with algorithms for detecting bold text. Our best algorithm has a much improved recall and precision, although the exact numbers are font-dependent. The next step is to incorporate inferred structure into the output of machine translation. One way is to embed XML tags for inferred structure into the text extracted from the imaged document, and to either pass the strings enclosed by XML tags to the MT engine individually, or pass the tags through the MT engine without modification. This structural information can guide downstream bulk processing tasks such as summarization and search, and also enables building tables of contents for human users examining individual documents.


Introduction
As you decided whether to read this paper, you probably read the title first, then maybe the abstract. You might have looked at the pictures to see if they whetted your interest, and looked at the title of this section before starting to read the section itself.
You may also have noticed the bolding in the paragraph above, and thought that perhaps those were clues to what the paper is about-which of course would be right.
In short, you will undoubtedly made use of the paper's formatting, both to decide whether reading a paper is worth your time, and if so, to better understand what the paper is about. Now suppose you have a PDF of a paper written in a language you don't know, or an image of a document that has to be OCRed, or a paper document. You extract the text and pass it through a machine translation system, and out comes translated text-and if you're lucky, the translation is both fluent and accurate. But where is the formatting that you found so helpful?

The Problem
Documents are often written using overt or covert markup, where the markup more or less explicitly defines the document structure. Overt structural markup is used in formats like the following: • DocBook (Norman and Hamilton 2010), which defines structural tags for technical documentation, for example <para> (paragraph), <qandaentry> (a question-and-answer, or Q-and-A, entry), and <guimenuitem> (the name of a terminal menu item in a GUI).
• Text Encoding Initiative (TEI, https://tei-c.org), defining tags for texts of interest in the humanities context, for example <front> (front matter of a book), <castList> (a list of actors in a performance), tags for poetry, etc.
• T E Xand L A T E X, providing tags to format documents, such as \textbf (for bold font) or \caption (for the caption of a figure or table).
Other document formats, like Microsoft Word, use covert markup, i.e. markup that the user assigns but which then becomes more or less invisible, so that the document appears to the eye to be formatted without any markup.
Whether markup is overt or covert, the final document contains only a visual display which readers have come to understand: paragraphs are separated by spaces and possibly indented; Qand-A lists are lists of paragraphs starting with a 'Q' or 'A'; lines of poetry use a ragged right margin; section titles are short lines, often in a larger font, and possibly preceded by a section number, and text which is bolded is represented by glyphs whose strokes are thicker.
In general terms, the task we are attempting is to reverse engineer the visual display of a document into an overt markup, by inferring a document's covert structure-the same thing a proficient human reader does when they read a document. We illustrate this problem with a few examples, before turning to some (in-progress) solutions. Figure 1 shows a small snippet from a PDF document. 1 Two terms are italicized, indicating in this particular document that the terms are being defined. But the italicization shows up 1 The image is taken from a pre-print of Bale and Reiss 2018. neither in the plain text extracted by the Tesseract OCR program (figure 2), nor in Tesseract's more verbose hOCR output(figure 3). 2 Figure 1: Excerpt from PDF, showing italicization and information relating to meaning. We call the information relevant to a morpheme's pronunciation its phonological representation, and we call the information relevant to its meaning its semantic representation. Bold text is similarly not tagged as such in Tesseract's output. 3 The implication of this is that the fact that the original author has highlighted something as important, cannot be recovered; structural information has been lost.
Even more problematic is the situation where a textual document represents a highly structured database, and one wishes to reconstruct the structure of the data from the formatting. A common example of this is dictionaries, where lexical information is contained in fields delineated by the formatting. Figure 4 shows an example of this, here a Polish-English dictionary. 4 Notice that some of the fields within this entry are indicated by switching between bold and nonbold, such as the headword and its definition, or between the sub-entry 'z zapartym tchem' and its definition "with bated breath"; other fields are indicated by switching between an italic font and a non-italic font, such as 'bez tchu' and "out of breath." At a higher level in the document, we also wish to infer things like chapters and sections with their titles, itemized lists, sidebars, footnotes, tables and their captions, and a host of other things that make a document structure apparent to the human reader. Figure 5 (intentionally shown small to draw attention to the formatting) is a page from National Security Commission on Artificial Intelligence (NSCAI) 2021 (referred to later as the NSCAI report) shows many examples of this. The red text at the top highlights one of four 'Judgments' in the document; a list of these judgments appears in the blue side bar box to the right. A short paragraph of plain black text introduces a bulleted list, with each list item beginning with a bolded word, and using a dark blue font. More plain black text follows the list. A header and footer appear at the top and bottom of the page. Not readily visible in this image are several footnote numbers, indicated by a raised digit in a smaller font.
This document is about 750 pages. If one wanted to know the committee's judgments, a search for simply the word 'judgment' would pull up both the committee's judgments and 2 Tesseract reports version 5.1.0-72-gb8b6, with correspondingly updated libraries. It was installed as an  all other instances of the word 'judgment', of which there are about 30. Clearly it would be desirable to be able to restrict search to instance of that word in red text, and similarly for other pieces of structurally-delineated information in the report. Structural information based on formatting would also allow one to put together an outline of the document (there is a table of contents, but it includes only the chapter titles).

Previous Work
M. Maxwell and Bills (2017;2018) describes parsing an OCRed Tzeltal-Spanish dictionary (Cruz, Gerdel, and Slocum 1999, similar  Document Image Analysis (DIA) tasks include document image classification and layout detection in images; the technology can be used to convert images of documents into structured data. Early work on DIA involved rule-based approaches, but deep learning (neural net) approaches are now more common. Shen et al. 2021 describes Layout Parser, a trainable deep learning toolkit and model repository for DIA (see also their section on 'Related Work'). They use image processing and OCR to find rectangular boxes of text (and pictures) in document images being processed and label the function of each box; it also provides pre-trained structural models for certain types of documents. But since a given document can have a very different structure from the documents in Layout Parser's existing models, it is desireable to fine-tune a model that is similar to the target documents, or in the worst case to train a new model from scratch. In either case, a set of hand-labeled documents is required for the tuning or training.
Clausner, Pletschacher, and Antonacopoulos 2011 describes the University of Salford's Aletheia, a DIA system including tools for annotating document structure with the assistance of various semi-automated mechanisms. The university also maintains a dataset of annotated documents at https://www.primaresearch.org/dataset/.
In the next section, we describe on-going work in the evaluation and use of DIA tools (including the Layout Parser), while section 5 discusses experiments in improving the detection of bold text.

General Format Detection
We experimented with the Layout Parser on various documents, including the NSCAI report (a partial page of which was shown in figure 5). Our goal was to recognize significant text boxes, join boxes that were broken over page or column boundaries, and if possible label the boxes as to type (body text, footers and headers, section titles, etc.).
We selected a pre-trained model that worked reasonably well with our document's format, but even this best model showed some spurious or overlapping boxes in the output. However, we were able to eliminate most of these spurious boxes without losing valid boxes by ignoring boxes to which the program assigned a low confidence; this in turn eliminated most overlapping boxes. In addition, boxes frequently clipped off pieces of characters at the edges, but we addressed this by adding a small padding to increase the size of each box.
The model classified regions as (body) text, titles, lists, tables or figures; it was however confused by sidebar elements (like the one shown in the upper right-hand side of figure 5).
We experimented with the detection of titles by Layout Parser's PubLayNet dataset and its corresponding model (faster rcnn R 50 FPN 3x) 5 by running this over a set of test samples with 15 images. The aim of this experiment was to estimate the quality of the model performance, including a raw count of three categories: 1. 'Correct Bold Text' (34 instances): Boxes correctly tagged as titles, where the text was bold.
2. 'Incorrect Non-Bold Text' (16 instances): Boxes incorrectly tagged as titles, where the text was not bold.
3. 'Incorrect Bold Text' (7 instances): Boxes incorrectly not tagged as titles, where the text was bold. Figure 6 shows some examples from the test set.
Notice that the raw number of incorrect bold text segments is relatively small compared to the number of bold text segments that are correctly classified. However the number of incorrectly classified non-bold texts is quite high, and another method should be used to lower this number. This model could perhaps be combined with other models or methods to decrease the number of incorrect non-bold text tags (ensemble models), but we did not have time to test this.

The Special Problem of Bold Font Detection
As mentioned, Tesseract does not currently attempt to distinguish between bold and non-bold (or italic) text. Since bolding is often used to emphasize important words, as well as distinguishing between fields in semi-structured data (like dictionary entries), we experimented with

Proceedings of the 15th Biennial Conference of the Association for Machine Translation in the Americas
Orlando, USA, September 12-16, 2022. Volume 2: Users and Providers Track and Government Track Figure 6: Yellow boxes are marks for titles assigned by the Layout Parser (LP). Picture A shows two non-bold text segments that LP correctly tagged as titles. Picture B shows bold text that LP correctly boxed as titles (although it missed some bold text continued on to the next line). Picture C shows short bold texts at the beginning of the paragraphs that LP did not tag as titles, and red but non-bold text that is incorrectly tagged as a title.
methods for detecting bolded words, using for test data a Tzeltal-Spanish dictionary (Cruz, Gerdel, and Slocum 1999) and a Cubeo-Spanish dictionary (Morse and M. B. Maxwell 1999), as well as the previously mentioned NSCAI document.
The initial attempt used unsupervised clustering based on features such as bounding box dimensions, pixel counts and scaling by letter shape, but this unsupervised approach did not work well.
The best performing method used the OpenCV Python library, an open source library for image processing (https://github.com/opencv/opencvpython). We first converted the color image to gray scale, then 'thresholded' it to convert the gray scale into a black-and-white image (where gray turned into white), and finally used CV2's dilation() function to partially erode areas with black pixels. This had the effect of removing most of the pixels for non-bold characters, while leaving enough pixels in bold characters to enable approximate OCR of the bolded words. The result of applying this to the page shown in figure 5 is illustrated in figure 7; running this image through OCR gives the text shown in figure 8.
Clearly the OCR output from this degraded image is not good enough for downstream use by itself, however by using the bounding boxes in the hOCR output (not shown here), it was possible to pick out the spans in the original hOCR output that contained bold text in the original image.
The CV2 dilation() function has several adjustable parameters. The best settings are doubtless dependent on a number of factors (including the particular font and its size). For our experiments, we set these by hand, but for best results the parameter settings should be adjusted for particular documents or document classes based on a sampling of the outputs. 6 Passing Formatting through Machine Translation The output of DIA has several potential uses: 1. Informing search processes as to which text is more important, which can be used to filter search results.
2. Informing summarization processes about important text strings.
3. Enabling translations to emulate the formatting of the original text, making the resulting documents more easily understood.
If search (1) or summarization (2)  XML or JSON) can be stripped before passing the outputs of these processes through MT. However, if search or summarization is instead done on the MT output, or if the MT output is to be formatted according to the input (3) 6 , then the formatting needs to be passed transparently through the MT process.
How this would be done depends on the particular MT engine; one method would be to train the MT system to ignore such text. Much the same issue arises if named entity tagging is done in the source language, and must be transferred into the target language (cf. Hermjakob, Knight, and Daumé III 2008 for some observations on this problem, albeit in the context of statistical rather than neural net MT). Another method would be to only send blocks of text that are entirely inside a discovered box through translation, and to assemble the translated document using the boxes and their translated contents.

Future Work
Clearly much remains to be done before Document Image Analysis can be considered plug-andplay. Too much currently requires manual control: parameter setting (e.g. for the detection of bolding or the choice of confidence-based cutoffs in the boxing of document chunks), choosing pre-trained models, or deciding whether to use an existing pre-trained model as-is or to tune it.
We did not attempt to detect italicization (or underlining, which did not appear in the documents we experimented with). Font size detection is also relevant, e.g. for detecting section headers (which are often in a larger font) or captions or footnotes (often in a smaller font). Font size can probably be inferred from bounding boxes on OCRed text, provided one pays attention to capitalization, and ascenders and descenders.
Finally, some documents may be one-of-a-kind. Figure 9 shows a page from a hand-written Arabic book on Islamic rulings. 7 The page header includes a 'ruling' title on the left, a page number in the middle, and the 'book' (chapter) title on the right. Below the header is the section title, in red. A horizontal rule about a third of the way down the page separates the original text above from the commentary below. A red font has been used in the commentary to refer to words in bold characters above, as indicated by the orange lines I have drawn in. The words in the commentary circled in green are citations to sources from which the commentator drew, like 'Muraqi al-Falah: page 699'. The words circled in brown are someone's explanation of the words they appear immediately under. Whether DIA is relevant for such unusual documents probably depends on the size and usefulness of the document in question, and in this case on whether OCR is even possible on this hand-written Arabic document.
In sum, while tools like the Layout Parser require substantial automated training material, for long documents (such as the NSCAI document) or for many documents of a single type (e.g. medical reports or other standardized documents), automating the Document Image Analysis (DIA) process would pay a return on investment by making it easier for users to make sense of Machine Translation output, enabling parsing of structured data such as dictionaries, and informing search by highlighting "hits" that occur in regions of higher importance.