Yes docx.sem needs a lot of work. It was generated by liblouisutdml as a starting point. Itg will provide something readable, but it is not intended as the final version. There is a comment at the beginnning saying that it needs editing to give good output. John On Wed, Sep 11, 2013 at 01:26:06PM +0000, Keith Creasy wrote: > I was looking at that. Once we have the archiver package in BrailleBlaster > you won't even have to extract the document file, just open the Word archive > (.docx) file directly. > > Maybe someone who has a special interest in Word support can take this on > once the archiver interface is finalized. > > I think the SEM does need some work, a lot actually. > > > > -----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