[brailleblaster] Re: Editing Ebooks for Braille
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 11 Sep 2013 08:26:00 -0500
Vic,
BrailleBlaster needs code to handle docx archives. However,
liblouisutdml can handle the document.xml component of the archives with
the docx.sem file that I have just committed.
The root element of document.xml is document . But several xml flavors
have the same root element, so the semantic-action file must have a
diferent name. In a configuration file or in a configString variable use
the line
semanticFiles docx.sem
John
On Wed, Sep 11, 2013 at 09:04:20AM -0400, Vic Beckley wrote:
> 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
>
>
>
--
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:
