[brailleblaster] Re: Editing Ebooks for Braille
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 11 Sep 2013 07:52:09 -0500
I agree, and I would like to point out that there is no need to use the
Daisy plugin for Word. liblouisutdml can handle the document.xml file in
a docx archive directly. In fact, I have a semantic-action file for
doing that. It does need work by someone who has access to the docx
specifications.
John
On Wed, Sep 11, 2013 at 10:02:33AM +0000, Larry Skutchan wrote:
> Keith, I think you are right on target.
>
> There may still be a need to use an approach in some cases to preserve the
> original content, but I think that most of the time, the software will want
> to change the original document as you point out.
> There is no reason why BB can't be a world class EPUB editing tool that just
> happens to have braille integration.
>
> On Sep 11, 2013, at 4:36 AM, Michael Whapples
> <mwhapples@xxxxxxx<mailto:mwhapples@xxxxxxx>>
> wrote:
>
> I agree with this. Also remember, its not necessarily the person producing
> wrong mark up by using the tool wrong, but sometimes the software itself,
> even if it is due to converting from another format (think of some of the
> problems which have been raised here in the past about the DAISY add on for
> word).
>
> I never quite know what is the best way to solve this: If software allows
> plugins whether one should produce an accessibility checker/correction plugin
> (IE. try and solve the problems at source) or have it as separate
> tools/processes for people to do.
>
> Also I wonder whether using heuristics for automatically finding/correcting
> these common problems might be useful or whether it could turn into an
> annoying feature. Probably something not for now, I think there are plenty
> more important matters to deal with and simply being able to manually correct
> it might be enough.
>
> Michael Whapples
> On 11/09/2013 01:46, Keith Creasy wrote:
> All.
>
> This evening I’ve spent some time reading and pondering the best practices
> and accessibility guidelines for DTBook, NIMAS, and EPub. I’ve thought about
> each item and how it relates to braille production and rendering. It has
> caused me to change my outlook just a bit. The main point is that the reason
> we have to make so many braille corrections is not because the standards are
> insufficient but because creators do not follow best practices nor are they
> likely to in many cases
>
> Up until now I’ve resisted the urge to change the original document because I
> regarded it as the work of the author and publisher. Up to now though none of
> the documents ever go back upstream all the way to the publisher so why not
> make corrections to the original markup so that the braille is correct
> whenever possible? We already have plans to do that in some cases, such as
> adding MathML in place of other, less accessible ways of representing math
> and adding image descriptions.
>
> Another example is the table of contents. All three of these standards have
> very specific ways of representing the TOC of a book or section. If done
> correctly there is no reason LibLouisUTDML should not be able to create an
> appropriate braille TOC automatically. If it can’t it is because the original
> document is not marked up according to the best practices. Likewise, using
> emphasis for only visual presentation is not considered the best practice for
> any of these standards, so why not provide a way to remove it when
> appropriate.
>
> Yet another feature that may or not be used correctly is the “type” attribute
> in XHTML5. Its sole purpose is to provide rich semantic information for,
> among other things, accessibility. Why not use it to add semantic information
> whenever possible and use it in our semantic action files to give
> LibLouisUTDML more information on which to base the braille output.
>
> The advantage of this approach for BrailleBlaster is that it suddenly becomes
> much more than a tool for creating braille, it becomes a tool for producing a
> better EBook that more closely follows best practices, in particular best
> practices for accessibility.
>
> Along with this change to how we “fix” eBooks’ for braille, we need to shift
> the emphasis from DTBook and UTD documents to EPub3 and the content document
> type XHTML5. So, for example, what I’m suggesting is that when a user decides
> to create a new document XHTML5 or EPub3 becomes the default type. Whether we
> support others is another question.
>
> None of this involves any huge change from the current plans and may make
> getting LibLouisUTDML to perform better on complex documents because it gets
> better content to start with.
>
> This is all mostly philosophical at this point but I hope others will think
> about it and comment.
>
> Regards,
> Keith
>
>
>
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
Other related posts:
