[liblouis-liblouisxml] Re: Capital/Emphasis update
- From: Bert Frees <bertfrees@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Wed, 25 Feb 2015 14:17:13 +0100
Dear Susan,
I agree with all your points. Yes, in the end we're stuck with what the braille
authorities decide, and we should strive to support it all. The non-essential
stuff (what you would call recommendations and not requirements), i.e. for
creating "beautiful braille", could indeed be considered out of scope for
liblouis. E.g. things that rely on special markup or advanced text analysis such
as sentence detection.
The DAISY Pipeline effort for identifying additional markup needed for braille
has stalled (for some years now). AFAIK some markup got in DAISY 4, but DAISY 4
was mostly ignored and now a lot of people are moving to EPUB3. So yes, maybe
this exercise should be taken up again, but mapped to EPUB3.
Bert
Susan Jolly writes:
> Thanks so much Bert for the feedback.
>
> I agree with you that it would be nice if braille systems could avoid
> context-dependent rules. However, I expect that achieving that would be a
> much more difficult problem than it might appear for both braille-specific
> and general reasons. Braille systems have many constraints given that they
> are intended to be human-readable which I believe to be the reason for at
> least some of the context-dependent rules. New braille systems also have
> some obligation to be both backwards compatible and future proof in order to
> avoid unnecessary difficulties for already-fluent braille readers.
>
> As for general reasons think of what we've learned about the complexity of
> digital encoding of documents. The history of the Text Encoding Initiative
> (TEI) illustrates this as does the fact that even DocBook has been under
> development since 1991. Recent examples of the discovery that problems can
> appear more complex the more we learn include I18n, ePub, and the Semantic
> Web.
>
> It is important as far as understanding the current situation to remember
> that many braille systems were defined long before the possibility of
> automatic translation became a reality. Also, at least here in the US, many
> early transcribers enjoyed manual transcribing and were very proud of their
> skills even sometimes to the point of hindering the development of automated
> translation.
>
> From a historical perspective braille transcription was sometimes viewed as
> publishing. So just as a quality print book requires a human editor, it
> shouldn't be surprising that a quality braille book would as well. My own
> feeling about certain rules, such as the definition of a passage, which are
> intended to make braille reading more efficient and/or enjoyable is that
> these rules should be tagged as recommendations and not requirements.
>
> And, of course, I'm sure we could never get universal agreement on what
> makes a transcription more or less readable. Just remembering that there
> were riots in the UK when they decided to require braille capitalization
> indicators in all contexts underscores this. In my opinion some of the
> arguments both against and for that change were very well-reasoned.
>
> I do think it extremely unfortunate that UEB wasn't designed with
> considerable input from persons experienced in modern digital encoding.
> Here was an opportunity for a new braille code that looked toward the
> future; instead we are ending up spending huge resources changing to a
> system little different from what was originally proposed as UEBC back in
> 1991.
>
> However, given that we seem to be stuck with UEB, I think it would be a
> worthwhile exercise to determine what, if any, additional markup would need
> to be added to the latest ePub specification in order to support fully
> automatic transcription to UEB translation plus some standard formatting
> prescription. (Or has the DAISY Pipeline effort already completed this
> exercise?) I have two reasons for this suggestion.
>
> First is that there is growing expertise outside the braille community for
> producing rich ePub documents including developing efficient methods for
> generating information not present in the starting electronic document.
> Second is the standard argument for separation of concerns. There is more
> than enough braille-specific detail for braille table designers and software
> developers to handle without having to compensate for avoidable deficiencies
> in input.
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
