[brailleblaster] Re: Next steps
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 12 Jul 2013 20:01:27 -0500
I am wondering why methods were removed from Documentmanager. Embossing
was working as far as I know.
EmbosserManager and PrinterManager were intended to manage drivers for
the various devices. I felt that in the interests of clarity embossers
and printers should be separated. These classes don't have to be
retained.
John
On Fri, Jul 12, 2013 at 07:15:56PM +0000, Keith Creasy wrote:
> Vic and John.
>
> Just to follow up on this. Unless I'm missing something it is simply a matter
> of someone putting back one of the methods that was removed from
> DocumentManager and reconnecting it to the menu option. This should be pretty
> easy to get done fairly soon.
>
> Of course, I'm assuming that what was there actually worked.
>
> Also, John, there are a couple of classes that are not being used and are in
> packages all by themselves, EmbosserManager and PrinterManager. Are we going
> to use these?
>
> Thanks.
>
> Keith Creasy
> Software Developer
> American Printing House for the Blind
> KCreasy@xxxxxxx
> Phone: 502.895.2405
> Skype: keith537
>
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Vic Beckley
> Sent: Friday, July 12, 2013 2:20 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Next steps
>
> Keith,
>
> The last time I tried embossing from within BB, it didn't work. Is that
> working now?
>
>
> Best regards from Ohio,
>
> Vic
>
> From:
> brailleblaster-bounce@xxxxxxxxxxxxx<mailto:brailleblaster-bounce@xxxxxxxxxxxxx>
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
> Sent: Friday, July 12, 2013 1:58 PM
> To: brailleblaster@xxxxxxxxxxxxx<mailto:brailleblaster@xxxxxxxxxxxxx>
> Subject: [brailleblaster] Next steps
>
> All.
>
> I am anxious to hear what others think but let me share what I believe our
> next big step in development should be. Right now it is easy to open an XML
> file and one can even edit the content in the text view. Some important
> things that one can't do yet are:
>
> 1. Start a new document and immediately begin adding content. You can
> actually enter text into the text view now but it isn't being added in a
> valid way to the XML and you do not get any braille. We need to finish out
> the code that creates a new document and adds at least one text element where
> a user can enter new text, get braille, and save it back to a valid UTD XML
> document.
>
>
> 2. One cannot yet add braille to an existing document. One of the first
> things we are going to encounter, and we'll soon know if I'm right, is that
> users are going to want to add braille-specific information to the document.
> Transcriber's notes, acknowledgements, braille publication info, and such.
>
> 3. Related to the previous point, users are going to want to make corrections
> to the braille without effecting the print and even make corrections that
> can't be made in the print.
>
> 4. Table of Contents needs to be implemented. For the sake of simplicity and
> to speed this up I'd like to propose that we use the current LibLouisUTDML
> way of generating a braille TOC. Users would just move to the place in the
> document, perhaps in the tree view, and select that as the location of the
> TOC. A locked braille element would then be added with the braille TOC
> generated using the headings. I don't think this is going to be 100% reliable
> in the long term but it might work better than I expect and there's no reason
> to make it more complicated until we know.
>
>
> 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:
