I’ve written a manuscript that I’d like to publish next year, both as an ePub and in braille.
Publishing as an ePub is straightforward, with many options available, such as Amazon, that would sell the ePub for a small cut of the sale price, with the rest going to me.
But there doesn’t seem to be any similar sale channels for braille. Amazon KDP, for example, does not support publishing in braille, neither as print braille nor BRF files.
Here’s what I’m looking for.
I would hire a braille transcriptionist to create a BRF file from my MS Word manuscript, much as I would hire a formatter to produce an ePub or a print book for sighted readers. Then I would upload my BRF file to the publisher, much as I would upload an eBook or PDF to Amazon KDP. I should be able to set the price, with the publisher/retailer taking a cut. The buyer would visit the publisher/retailer site just as they do Amazon, find my book, select whether they want to buy the print braille version or the BRF download. If they choose print, the retailer would print and ship it. If they choose BRF, they would download it to their braille display just like a Kindle to their Kindle-enabled device.
I don’t think I’m asking for anything that’s far from what the industry already has in place today for electronic publishing and print on demand. Yet repeated web searches have turned up nothing.
If I can’t do this, then I’m interested in alternatives. For example, is it possible to publish in an ePub format that a buyer could download and read with a braille display? Something other than the Kindle format, obviously.
Thanks for any help, pointers, and information.
Comments
National braille press?
I know that national braille press publishes their own books in braille. I don’t know anything about how they work with other publishers or authors. In case you are not aware of them, the website is nbp.org.
NBP options
Thanks for the NBP suggestion. They were one of the first publishers I considered.
There seem to be three main types of publishing.
You can traditional publish, in which you pitch a story to a publisher and they cover all of the production cost and give you a small royalty. NBP has this for Braille. I pitched my manuscript to them a while ago. They said "no thanks."
There are also boutique publishers, in which you, the author, cover the publisher's costs, but they give you a much larger share of the royalties. Unfortunately, they charge whatever they want, and you have no control over these costs. NBP offers this for braille, and it is rather pricey.
Finally, there is self-publishing, in which you do all the production, and the publisher does little more than provide a platform to sell. This is labor-intensive, but has the lowest cost for the highest potential return.
Unfortunately, NBP doesn't offer a self-pub option, and after several web searches, I haven't found anyone who does. This really surprises me, given that NLS now offers a print-on-demand service. I would think that anyone who could produce a BRF file should be able to publish it themselves. I was hoping I was wrong, and that by posting here, someone would direct me to a braille self-publishing retail service provider.
So, to rephrase my question: If I had my own BRF file and wanted to publish it as a book, where could I do that?
BrailleBookStore
Maybe this would be useful to ya?
http://www.braillebookstore.com/Braille-Printing
Some ideas
I have a few ideas, but none of them are perfect.
eBraille files contain all of the semantic navigation possibilities found in ePub files, which means that users can easily navigate around the file by units such as headings and paragraphs. Other features such as hyperlinks are also supported.
Because eBraille files are so similar to ePub files, I imagine that you'd be able to open them using mainstream reading systems like Apple Books. However, braille display manufacturers will also support the file type, and they're also suitable for embossing. Due to this similarity with ePub files, I imagine that you’d be able to upload them to sites like Amazon. You could tell users to change the file format to open the file properly, but it wouldn’t be the end of the world if they don’t.
Another advantage of eBraille files over BRF files is that the text is reflowable. This means that a person’s reading experience won’t be diminished if they’re using a braille display with fewer cells, and it also means that things like page numbers—which are essential for a hardcopy version—won’t appear when being read on a braille display because they’re irrelevant for that modality.
The only downside I see to this idea is that complicated arrangements would need to be made if a user wanted an embossed copy of the file.
There are quite a few organisations who would be able to do embossing of this nature. I’d suggest avoiding the Braille Superstore though. The number of bad experiences people seem to have had with their products and services seems to greatly outweigh the number of satisfied customers.
The only downsides I see with this idea are the complexities in setting up and maintaining a website and associated online store.
Thanks for the information
Brian, the Braille Bookstore looks like a modified boutique publisher. They let you do the editing and formatting yourself. But they don't print on demand or sell direct to customers. I would need to purchase books in quantity from them, then sell and ship to customers. Ugh.
TJT 2001, is that you Theodore? Hi! ePub and a braille display for reading is probably my best option. Braille displays are much more common now, especially in the US, where braille libraries are loaning them out to patrons.
I've looked into an eCommerce website and would like to avoid it. A simpler alternative is a Wordpress plugin that provides access to digital content (such as a ePub, BRF, or eBraille file) in exchange for a Paypal payment.
I'll investigate what NVAccess is doing. It sounds quite close to the print-on-demand self-pub service I'm after.
E-commerce & Braille Publishing
Hey Paul,
Sorry, I couldn’t find a better alternative for you, however, it sounds like you might have a good starting point based on your last post. Regarding e-commerce sites, you may want to avoid those. They can be a money sink, if you are not careful.
Deleted
Deleted
Thanks Justin
I copied that contact information. Thanks Justin. I suggest you edit your post and remove it so that robots don't scrape it and spam her.
This project slowly plods forward
The book I’m working on has some non-standard content, and I’m unsure that ePub to a Braille display is a viable option. Let me describe the issue.
The content is a solution for the tactile rubik’s Cube. The solution consists of groups of individual rotations called algorithms. The rotations are separated by spaces. Each rotation consists of a cube face letter which might be upper or lower case, an optional numeral 2, and an optional apostrophe or prime symbol. In print, this notation results in a concise description of the algorithm that typically fits on a single print line. Here’s an example, and I invite you to read it with a braille display and let me know what you think:
x R2 F R F’ R U2 r’ U r U2
The optional numeral 2 and optional apostrophe or prime symbol are not a problem. Those display in Braille exactly as I would expect. I love it. Great so far.
One big problem is single-letter contractions. For example, the letter F indicates a front face rotation, but by itself, that’s a wordsign: from. And as a result, the braille display prefixes it with the grade one indicator. Well, the entire algorithm is grade 1, but the braille display isn’t smart enough to detect that. If it were, it could simply start the algorithm with the grade one sequence indicator and save a lot of cells.
The second issue is mixing upper and lower case. Algorithms are mostly caps, so each algorithm typically starts with the 3-cell all-caps indicator. But occasionally, as in the example above, one rotation is lower case, so caps needs to terminate, and then there will invariably be another 3-cell all-caps indicator for the remainder of the algorithm, then finally a caps terminator. This means an all-caps algorithm is a minimum of five cells just to start and stop caps, and if it contains one lower-case rotation, the minimum size has just doubled to ten. This makes using a 20-cell display painful to the point of impracticality. It’s agonizing even with my 40-cell display.
I understand UEB has a custom sequence indicator and terminator, which a braille transcriber would describe in the transcriber’s notes. I could use that to indicate algorithmic notation, which would contain no contractions and invert the meaning of a dot six to indicate lower instead of upper case. It could also drop the numeric indicator, because the numeral 2 is the only number used and it’s always the second symbol. Such a custom notation would produce a very concise braille output. I know, because I’ve tested it with slate and stylus. But there’s no way for an ePub or website to tell a braille display to do something like this, so I’m back to the very expensive method of using a transcriber and producing print braille.
There’s another reason to avoid custom notation. One of my goals with this book is to give blind cubers the knowledge they’ll need to go out and consume other cube content, which would lack this custom notation. It would be better for me to use the same notation that someone would encounter when reading other cube solution guides or website, ugly as it may be.
I don’t know whether anyone has any ideas or not, but many AppleVis readers know way more about braille than me. Simply writing this comment has helped me think through the problem. Post your thoughts if you wish. All ideas are welcome.
My thoughts
I think your idea for a braille code for cubing notation is interesting. I think that I would prefer to use UEB because I would have to get used to it to read algorithms written by other people, but I would be interested in other people's opinions. I personally don't find reading algorithms with automated braille translation unduly cumbersome on my 40-cell braille display.
If you were to use your notation, how would you feel about writing the number 2 using dots 23? This would mean that the number 2 and the prime symbol both use dots only in the lower part of the cell.
The algorithm you wrote occupies 46 cells in automatically translated UEB, 41 cells in correct UEB and 35 cells in your braille cubing notation. I've transcribed it into correct UEB and braille cubing notation below using Unicode braille symbols. To read them on a braille display connected to an Apple product, you may need to switch to computer braille.
UEB:
⠰⠰⠰⠭ ⠠⠠⠠⠗⠼⠃ ⠋ ⠗ ⠋⠶ ⠗ ⠥⠼⠃⠠⠄ ⠗⠶ ⠠⠥ ⠗ ⠠⠥⠼⠃⠰⠄
Braille cubing notation:
⠐⠷⠄⠠⠭ ⠗⠆ ⠋ ⠗ ⠋⠶ ⠗ ⠥⠆ ⠠⠗⠶ ⠥ ⠠⠗ ⠥⠆⠠⠐⠾
Braille cubing notation saves space due to the lack of capital signs and the absence of the numeric indicator. However, it requires six cells for the UEB code switch passage indicators, which is one cell more than the grade 1 indicators required for correct UEB translation.
Thanks for helping me think through this
After sleeping on this a couple of nights, I agree the best path forward is to simply produce an ePub and let the braille display user deal with it, either by reading straight UEB, or possibly switching to another table when they encounter an algorithm.
The bigger problem I face is finding the time to finish this and get it to a formatter. If I can stop going down these types of ratholes, I might actually get this published in the next few months.