I am not sure if comparing to wordpad is a good thing, surely they have very different goals. It may even be unhelpful.
WordPad is aimed for sighted people viewing "print" documents, with the only intent being for it to be used for "print" documents. They want the document to look how it will on paper, they want documents they are sent to look the way the author intended, they want to be able to send people documents and for it to look the way it did on their screen.
In contrast, as I have said before, BrailleBlaster is focussed on creating documents which will translate into Braille. The print view is purely so they know what the document contains, this includes what the structural elements are. Does it visually need to be accurate to the visual presentation of the authoring tool? I am probably thinking of the separation of structure and presentation, a similar thing might be html and CSS, does BrailleBlaster really need to be concerned with the presentation (CSS if going with the HTML example) side of the document?
Wordpad will have features not needed by BrailleBlaster, setting font size being one example. How would setting font size actually contribute to BrailleBlaster's goals?
Equally BrailleBlaster might benefit from features not in wordpad, for example a feature like "insert heading" or "Mark selection as heading".
I feel it may be much more productive if we actually agree what features should be present rather than using a comparison which may not be fully relevant.
Michael Whapples On 14/10/2012 16:09, John J. Boyer wrote:
Yes. Something like WordPad is what I have in mind. liblouisutdml already implements the formatting rules for U.S> Braille through the preferences.cfg file. Peoplein other countries have probably tweaked it for their own rules. They are not standard across countries and languages. As discussed somewhere in the thread on the block diagram, it turns out that most of the things I thought should go in BrailleBlaster configuration files actually belong in the UserSettings file or in the semantic-action file for a particular flavor of xml. I'll be revising the block diagram acordingly. Michael pointed out that somebody might misuse the facilities of an xml flavor by indicating a heading with a font change, for exxample. That is something we will have to watch out for. Another example is documents containing more than one language, where authors usually don't use markup to indicate which language is being used. The specification does need to be updared with what we have learned form experience and what APH requires. Let's take a rest on this Sunday. John B. On Sun, Oct 14, 2012 at 07:49:46AM -0700, John Gardner wrote:Hello all, I am in the middle of an actual vacation and am trying to spend as little time as practical doing anything else for a few weeks. I have skimmed the BrailleBlaster communication and think it is time to go back to the specification document and update/expand it. That document was written largely by me with contributions from John Boyer and severl others. It is intended to say what BrailleBlaster should be from the point of view of the end user. It does say that one should be able to create simple documents and to import a variety of document types. It does not say that it should be a full-featured word processor, but it does list a number of standard functionalities it needs. Crudely speaking, it does not need to mimic MS Word, but it does need to have most features of WordPad. So let's go back to that spec document and work through it line by line until we all understand the goals. John G ________________________________ John Gardner | President | ViewPlus 541.754.4002 x 220 | www.viewplus.com ________________________________ PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with it may be proprietary and are intended solely for the use of the individual to whom they are addressed. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited; please notify the sender and delete the message. ViewPlus Technologies, Inc. accepts no liability for damage of any kind resulting from this email.
