[brailleblaster] Re: Editing Ebooks for Braille
- From: "Vic Beckley" <vic.beckley3@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Wed, 11 Sep 2013 09:04:20 -0400
John and Keith,
It would be so great if I could bypass the plug-in for Word and open the Word
file directly in ND. I could even save the file in a different format than docx
if necessary, like maybe rtf or the older doc format. Is there any way to use
this capability of liblouisutdml right now?
Best regards from Ohio,
Vic
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
Sent: Wednesday, September 11, 2013 8:52 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Editing Ebooks for Braille
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:
