[brailleblaster] Re: Next steps
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 15 Jul 2013 07:52:41 -0500
Well, the emboss menu item is supposed to call EmbosserManager and the
print item is supposed to call PrinterManager. I'm not really
interestedd how it is set up, as long as it works.
John
On Mon, Jul 15, 2013 at 11:45:50AM +0000, Keith Creasy wrote:
> Hi John.
>
> It was removed from DocumentManager along with a lot of other stuff that
> didn't belong there, and in my opinion that didn't belong there either. We'll
> put it back somewhere. In the current implementation how do you know an
> embosser from a printer?
>
>
> Keith Creasy
> Software Developer
> American Printing House for the Blind
> KCreasy@xxxxxxx
> Phone: 502.895.2405
> Skype: keith537
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Friday, July 12, 2013 9:01 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Next steps
>
> 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@freel
> > ists.org> [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
>
>
--
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:
