On Sat, Apr 02, 2005 at 10:32:36PM +0200, Marcello Perathoner wrote:

Tony Baechler wrote:

...

Really all that needs to be done is to integrate a script into the PG site that calls nfbtrans and generates the .brf file. The .brf can be sent to the browser for downloading. Windows users would probably have to right-click on the Braille links and save the files manually. It would not be much harder for the multiple volumes, just use a split utility on the .brf file and create a temporary page with each piece of the file linked so they can also be downloaded and saved.

Piping the files thru nfbtrans should pose no problem at all.

Question: won't every blind computer user have this program on his PC already? Won't she be better able to tailor the output to her needs if the program is run locally?

I think I corresponded with Tony about this a couple of years ago. I had no less than three programmers working on "conversion on the fly" which would generate formats including Braille, MP3, and others from .txt, .htm or .xml source files. Unfortunately, none of these ever became complete enough to offer on the Project Gutenberg download site. I am still very much able to provide a programming platform (a Linux server, with plenty of space and a copy of the PG collection) to people who might want to develop a CGI, PHP, Web services, or other platform for this type of functionality. Most of the tools already exist (i.e., for .txt to HTML, or Braille), but it's still a complex problem due to the complex nature of our collection. (That is, lots of different files & formats to choose from.) While Marcello is correct that many blind or visually impaired computer users already have nfbtrans (or something similar), I still think a general purpose conversion on-the-fly between formats is useful. And, if we offer this functionality, then an option to convert to Braille via nfbtrans is a very easy addition. There are just a few options for the output....like all of the other transformation programs... Long-timers on this list are getting tired of me talking about conversion on the fly, I know. Plus, this inevitably leads to a discussion of eBooks being "born as" XML, which I have also tried to facilitate. People who are newer (or newly-energized!) are welcome to look at viable methods for delivering some of this functionality. Beware, though: it's a larger and more complex problem than you might guess at first. Some folks will even remember that I offered a "bounty" reward for completely functional applications. This offer still stands. -- Greg

Hi. I can help you with this. Please give me a detailed list of what you want/need tested and I will ask people to look into it. I know of at least two mailing lists that would have blind subscribers interested in looking at this. Remember that we need to keep in mind that many people will use PDAs designed for the blind. There is no real difference except that they don't need formfeeds while embossers do and generally one big file works better than multiple volumes. For embossers, formfeeds are a help, but nfbtrans puts that in automatically once you set the page length. You generally want the page length at 25 lines and 40 columns. If you can put files somewhere for people to download and test or somehow find a way for people to experiment with various kinds of output, that would be best. I think there might be someone on one of the lists that uses nfbtrans and could help more with the switches. Unfortunately, even among the blind it's mostly a Windows world so few people know how to use the command line. At 11:46 PM 4/3/2005 +0200, you wrote: This is a matter of a few hours ... its almost the same as the file recode service.

I just need somebody to work out the nfbtrans command line options that work best for our etexts. Anybody got a braille embosser to test?

Hi Greg. If you corresponded with me, I have no recollection of it. I would like to see this happen, but I don't remember any discussion with you. I am the first to admit that I am not a programmer. I appreciate your offer, and it would be useful for compiling and testing nfbtrans, but I have no idea how to set up a script that would produce Braille files on the fly. Also, you said that it would be very hard to create Braille output because of the many formats involved. I couldn't disagree with you more on this. All Braille needs is plain text. Currently, nfbtrans won't work with other formats except text and a few language source code files. Simply pipe the 7-bit plain text through nfbtrans and don't worry about the format. My understanding is that even a master xml format will still have a 7-bit equivalent. For non-text, just don't offer a Braille option. There is probably a way to translate mathematics, but I am not aware of it with nfbtrans and it would add complexity because the .pdf or .tex would first need to be converted to 7-bit ASCII. I think that if nothing else, PG should offer Braille output just because the motto is that the files should be able to be viewed by anyone with any equipment. In many ways, literary Braille is similar to very old formats in that it is only plain text and is all upper case. Yet that is still what many blind people use, including the US Library of Congress. I have a question. How is it that you come to the conclusion that most blind people already have Braille translation software? I have read stats that no more than 12% of the blind can read at all. Of those, I would guess that not many have the computer knowledge to use a command line program such as nfbtrans. It is still a DOS-based program unless you want to compile the sources under Linux. I am not sure if development is still being done. I am not currently aware of an official download site but I can check into this if this is something that we're willing to move ahead on. I would be happy to look at the Linux server Greg is offering, but again I am no programmer so unless it can be done in a one or two line script, I'm rather helpless. Also, nfbtrans has many, many command line switches. It is designed to format Braille books, so offers facilities for running headers, table of contents, etc.

Hi Robert. I agree with you and I am blind, so I'm glad you finally said it. I listen to text to speech at about 430 words per minute. That is slower than some people. I think it is great that PG has made some audio books available. However, to be blunt about it, I find them awful to listen to. They have low volume so are hard to hear and are very, very slow. I can't stand speech that slow! I know that the sighted public don't do well with computer speech, so I suppose it's necessary for them, but I would much rather have the speed set to at least 300 words per minute at the slowest. I wouldn't necessarily agree with you about raw wave files. I think mp3 is fine. One very big Internet radio station for the blind is ACB Radio. They are online at: http://www.acbradio.org/ They use mp3 exclusively, and at a rather low bitrate. I have no problem listening to it. In general, I don't like mp3. I collect old time radio and refuse to accept anything but raw wave files, but that is because it is of historical value and should be saved in the best audio condition possible. At 08:40 AM 4/4/2005 -0500, you wrote:

I can offer little commentary about Braille, but as far as audio formats are concerned, I can say that the visually impaired persons I have known who listen to substantial amounts of text often listen to it at substantially faster-than-intended speeds, and some do some other transformations on the audio to help them better catch meaning at these high speeds. Such things seem to be idiosyncratic to the individual listener.

A fairly 'raw' format, such as .wav, would I think be useful to such users, but lossy compression formats have been engineered around assumptions about listening conditions that simply aren't true for the practices of those who listen to recorded speech as a way of life, and may be of little practical value.