Answered
Hi All,
I'm having an issue with Acrobat reading items without periods as one flowing block of copy. For example, I have section titles, subtitles and lists that Acrobat is interpreting as continuous flowing text. I want the reader to recognize the title as a separate pieces of copy and pause before reading the list below. And I want the reader to pause at the end of each list item before reading the next item in the list.
I've fixed this before by adding periods at the end of everything. But I don't really want to do that because it changes the look of the layout.
Any ideas?
Thanks!
Acrobat's Read Aloud pulls from the logical structure framework of a tagged PDF rather than the visual layout you authored. From my read of the PDF Reference documentation it would seem, to me, that a heading element's ending at the line break would constitute a word break. But, as you have observed, for Read Aloud, this is not the case. Thus the run in vocalization from end of heading into the subsequent text.
For lists, I would suggest proper sentences be used. This gives the punctuation Read Aloud can recognize as a word break. Use of sentence fragments or text strings/sentences with no period as list items is telling the agent/consumer (Read Aloud, text-to-speech applications, or screen readers) that the text in the list items is contiguous. The agent/consumer is merely processing what we the authors have created, bagged, and tagged.
fwiw - some observations
A key point to remember is that Acrobat's Read Aloud is not a replacement for a high end text-to-speech application or an assistive techology application (screen reader).
Reflecting back to the text-to-speech applications I played with on Atari 1040ST and Amiga computers I find Read Aloud to be a rather nice basic tool. It lets me get a sense of how my content would be spoken by a more "fully featured" application.
Yes, Read Aloud rolls right into a heading's subsequent text. If one needs something more sophisticated then it is time to purchase the high end text-to-speech application or a full fledged screen reader.
Trying to get Read Aloud to do more than it is currently designed to do by debasing the authoring file with a work around does not seem, to me, to be a success path.
Regardless, any of the three (Read Aloud, text-to-speech, screen reader) will provide unsatisfactory results if the document author fails to adhere to two fundamentals.
1. - For the language involved adherence to rules of the language. Poor grammar, punctuation, spelling,
and so forth make reading difficult. Sentence fragments or a sentence with no period at the end are commonly used in lists. Ignoring the language's "rules of the road" can result in no word breaks or inappropriate word breaks being identified by the software.
2. The document must be authored in adherence to some established hierarchy. This "order" must be consistently applied and, via formally declared tags/styles, consistently identified. No "overrides" or toolbar format usage.
From these two, the author can (with the appropriate authoring application) provide a tagged output PDF.
While some post-processing must be done to the PDF the fundamentals of the tag structure are in place.
It is this structure that an screen reader (for Section 508 accessibility) is going locate and use. The person using the screen reader will now be able to navigate the document's structure to locate and harvest the content of interest. The better text-to-speech applications will be able to parse the content with more refinement and deliver the Bard's lines respectfully.
Another variable to consider. Mac vs Windows vis-a-vis generating tagged output PDFs. My sense, from posts to the AUG forums, is that there is less for the Adobe products to "grab onto" when output is from Mac authoring applications. Having no interest in any huba-huba Mac vs. Windows (had enough of that nonsense back in the Atari 1040ST/Amiga days) I stress that this is just an impression I have. So, perhaps a close look at the structure tree of your tagged output PDF file(s) might help. Compare what is there to what you authored. Compare that to what is described in the PDF Reference documents (see Chapter 10).
Are there any discrepancies?
Playing with authoring files (FrameMaker & MS Word) I, like yourself, have identified no clean approach to Read Aloud's run on from a heading's text entry to the subsequent text.
However, you may find the following useful.
--| en space/em space/thin space at the end of an autonumber format (or before the terminating tab of the format) precludes a run on from the autonumber prefix to the subsequent text. I have been able to use this in trial files from FrameMaker and MS Word. However doing so for MS Word styles is rather cumbersome.
--| Something that did not prevent the Heading to subsequent text "run on" is the placement of an en space, em space or thin space as the last character in a heading's text string.
Be well...
Be well...