The graphics requirements are indeed greater then PEF supports. It is not my intension to extend the PEF standard in any way.
I was more thinking in the direction of upgrading the BrailleUtils API to support UTDML, in particular for the embossers that actually benefit from it (first of all: the Tiger embossers).
Most other embossers are not capable of handling more complex things than a PEF, so for those embossers, going through PEF seems like the obvious solution, at least until a proper UTDML processor has been written.
I understand that you want to avoid involving an additional file format when it is not absolutely necessary, but the conversion from UTDML to PEF seems really straightforward in comparison to the work that would have to be done if you start from scratch. I think it's to simplistic to assume that the liblouisutdml output can be sent to most embossers just like that, or with only a little processing.
Bert On 17/07/2011 23:05, John J. Boyer wrote:
Right. BrailleBlaster will use the printer window provided by the platform for actually selecting the driver. However, it may need to do some processing to prepare the input that the driver needs. In the case of the Tiger this would be a bit image. I would much rather just go from UTDML to this bit image directly, rather than going through PEF. For users who don't want graphics, liblouisutdml already generates files that can be sent to most embossers. A bit of processing can be used for embossers with special reaquirements. I have downloaded the source for brailleutils and will look at it to see if there is something we can use. I would want to produce PEF only if the user wanted a PEF file. John B. On Sun, Jul 17, 2011 at 12:32:05PM -0700, John Gardner wrote:John, BrailleBlaster will need to work with the standard OS printer driver interface on all OS. If so then everything is automatic. The only "special" information will be to "special" printer drivers. ViewPlus printer drivers will be standard ones for all OS. I see no reason we cannot deal with this PEF interface when users want braille only. If one wants graphics and/or in, then they must choose to use hardware that support it. John G John -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer Sent: Sunday, July 17, 2011 10:47 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Co-ordinating work on the BrailleBlaster code Well, unless brailleutils can be upgraded to include adequate tactile graphics support we won't be able to use it in BrailleBlaster. Excellent tactile graphics capabilities are a basic design objective. Although ViewPlus provides a printer driver for the Tiger, BrailleBlaster will still have to provide the input that the driver needs. If I remember right, this is a gif image. So BrailleBlaster will still need a Tiger choice on its embosser driver menu. John B. On Sun, Jul 17, 2011 at 10:00:14AM -0700, John Gardner wrote:No John, PEF does not support graphics. I suggested during thedevelopmentof PEF that graphics should be included, but I was told to go mind my own business. Which of course I was already doing. So if we are going to support graphics, we'll need to use graphics-knowledgeable printerdrivers.ViewPlus embossers support graphics as well as ink. BrailleBlaster doesnotneed to include them, because any ViewPlus embosser user gets anappropriateprinter driver with her embosser.They are accessed through the standard Windows printer driver interface. I know that other embossers can do graphics, but they also use proprietary drivers. I hope that these other embosser manufacturers can make their drivers accessible to BrailleBlaster users. But never through PEF. John G -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer Sent: Sunday, July 17, 2011 9:51 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Co-ordinating work on the BrailleBlastercodeBert, NIce to see a message from you on the list. I was just going to write to you about extensive testing of the liblouisutdml Java bindings. But that is for another message. I am downloading brailleutils. liblouisutdml will need code to convert UTDML to PEF, but that was in the project plans anyway. However, our graphicsw requirements may be greater than PEF supports. We need the ability to place tactile graphics anywhere on a page and to include both Braille and graphics on the same page. This wasn't supported the last time I checked. John On Sun, Jul 17, 2011 at 01:44:13PM +0200, Bert Frees wrote:Hello everybody, I'd like you to consider using brailleutils (brailleutils.googlecode.com), a Java API for embossing and converting braille. I think I mentioned it before. It was written by Joel Hakansson from TPB and I've been working on the project the last couple of months. It now contains about 50-60 embosser models (from Index, Braillo, Interpoint, Tiger, Enabling Technologies, Cidat& Mountbatten). The Tiger models currently use the Tiger driver in Legacy (generic) mode. This means that images& ink + braille interlined are not possible yet. brailleutils is being used in Daisy Pipeline 2 and odt2braille. It would be neat if it was used in BrailleBlaster too. No double work would be done, and any improvements that are made would benefit all 3 projects. I would be happy to help you guys with this if you are interested! Bert Op 16-jul-11, om 22:22 heeft John J. Boyer het volgende geschreven: Now that some people are interested in the BrailleBlaster code, perhaps we can discuss assigning different packages and classes to particular persons. I have already assigned the localization package to my on-site computer tech. The wordprocessor package will be revamped when I have a good grasp of JFace. For now, I want to stick with the present setup, so I can activate some menu items and actually get ?BrailleBlaster to do something. The Main class doesn't need much attention. It just gets things started and shuts them down. BBIni.java gets things set up. I want to keep that for my own work. Subcommands.java is just a skeleton that implements the translate subcommand and the emboss subcommand. Someone might like to flesh it out, using the apache.cli package to process commands. Someone might also like to look at the embosser package. It will contain drivers for each embosser. These will be co-ordinated by the EmbosserManager.java class.ifferent people might write drivers for different embossers. The genreic embosser is already taken care of by the classes in the daisy branch of the Java hierarchy. We need a driver for the Tiger, with appropriate saveguards for proprietary information. John
