[brailleblaster] Re: More on Embosser Drivers
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Sat, 6 Nov 2010 22:00:45 -0500
BrailleBlaster will probably include drivers for most common embossers.
There will be a combo box for the user to select the one she wants. New
drivers can be added as needed. This is the approach of screen readers
for Braille displays. BrailleBlaster will not have drivers for displays
because they are either driven by screen readers or part of notetakers.
I like to translate files using liblouisutdml and then read them in a
text editor with my Elba, which has wi-fi, so I get the advantages of
the big machine along with portability.
It is interesting that compiled C libraries can be included in jar
files. How are these libraries called? I thought they had to be
installed in a specific place. Perhaps it would be possible to include
liblouis and liblouisutdml in a jar file along with the Java bindings. I
am actually planning to have bindings only for liblouisutdml. It will
have enough functionality that BrailleBlaster need never call liblouis
directly.
I've tried decompiling class files. All I got was the names of publicv
methods and public variables. A more detailed examination of a class
file would reveal the byte code, but this is probably no easier to
understand than the instructions for a physical machine. So proprietary
ingormation inside a class file would probably be quite secure.
John
On Sat, Nov 06, 2010 at 12:28:46PM -0700, Alex Jurgensen wrote:
> Hi,
>
> Firstly, there is a plugin framework for Java. I'll look up the name of it,
> but I am heading out the dorr right now, so that will have to wait until I
> return.
>
> On the matter of standard API's for embossers, I use mine under the Common
> Unix Prinint System, A.K.A.. CUPS. I believe that there will be more drivers
> writen by ONCE for CUPS. I'll look up the link.
>
> Regards,
> Alex,
>
>
> On 2010-11-06, at 11:25 AM, Michael Whapples wrote:
>
> > Dealing with the idea of including C/C++ code in a jar file with java
> > bindings, yes this can be done (examples both being SWT and JNA). Now to
> > would this protect those who want to keep things secret? The jar file
> > itself is simply an archive file and is easily extracted. Now if a user
> > were to do this they would find some java class files (these would be the
> > compiled class files not the source) and a DLL or other shared library file
> > (like for any other compiled C/C++ library). So I believe the C/C++ part
> > would be as protected as they may be now without any java bindings. While
> > the C/C++ code may be as secure, a standard java class file I believe can
> > be decompiled, but this probably wouldn't reveal anything top secret as it
> > could simply use their published C/C++ API and so would be just a mapping
> > between two knowns.
> >
> > One thing this does raise in my mind, if drivers are to be done as
> > described by John, BrailleBlaster would need some way to dynamically detect
> > drivers which are installed (may be some sort of plugin system where the
> > user simply has to drop a jar file in a certain directory then next time
> > they start BrailleBlaster that new embosser will be shown). There may be
> > some frameworks already out there to support such a plugin system.
> >
> > Now I do have a slight question, may be the answer is obvious to those more
> > involved in Braille production, why don't embossers use a standard API, may
> > be even the printer API like the tiger printer does?
> >
> > Michael Whapples
> > On 6 Nov 2010, at 11:26, John J. Boyer wrote:
> >
> >> I think the driver interface and the classes which implement it should
> >> be in a package called org.brailleblaster.drivers The interface would be
> >> called driver.java Each class implementing it would be named for the
> >> embosser which it suppoorts, for example, Tiger.java Indexd.java
> >> Everest.java
> >>
> >> As I mentioned previously, the drivers should be written in Java or
> >> converted from other languages to avoid messing around with bindings. A
> >> manufacturer might chose to protect propritary information by supplying
> >> a driver compiled into a C or C++ library. In this case it woulod be
> >> desirable for the manufacturer to also supply the Java bindings and to
> >> incorporate the JNI portion of the bindings into the library containing
> >> the driver.
> >>
> >> Is it possible to put Java code containing proprietary information into
> >> a jar file which can be used by the Java compiler and the JRE but which
> >> the user cannot see inside? That would make it much easier to get Java
> >> drivers from manufacurers.
> >>
> >> John
> >>
> >> --
> >> John J. Boyer; President, Chief Software Developer
> >> Abilitiessoft, Inc.
> >> http://www.abilitiessoft.com
> >> Madison, Wisconsin USA
> >> Developing software for people with disabilities
> >>
> >>
> >
> >
>
> Alex Jurgensen,
> VoiceOver Trainer,
> ASquared21@xxxxxxxxxxxxxxxxx
>
> Visit us on the web at: www.vipbc.org
>
--
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:
