Open files quickly

[wfree-aph]

As a braille user, I want my electronic braille files to open quickly.

Detail:
Braille files can be very large. With markup, they could get even larger and more complicated. In a marked up braille file, you'd need to read the last closing tag of the file in order to open the entire file. Add in tactile graphics, and the file opening process could be very slow.

Braille can be, at least in some parts of the world, separated into multiple volumes. Volume divisions are decided based on both content and number of pages. The braille file creator tries to add a volume separation where there is a logical break in the content while also not making the volume too large or too small.

Proposal:
A new braille file standard should allow for volume breaks. All volumes could be separate files stored within the same zipped folder, with that zipped folder being the entire braille file. By having the text broken up into smaller volumes, it would allow reading software to potentially open the files more quickly.

Reading software could then handle the multiple volume files as the processing power available to it allowed. If a lot of processing power was available, the software could potentially open the first volume very quickly and then start attaching additional volumes automatically as it processed them- thus allowing the user to navigate and manipulate the whole of the braille file all at once. If very little processing power was available, the software could treat each volume file as a discrete part and not allow the user to interact with another volume without first closing the current volume.

Additionally, embossing software could allow the user to emboss one, all, or a selection of volumes from the one braille file as needed. They may even want to emboss only a range of pages within a specific volume of the file.

[franciscoONCE]

Excellent point. I believe that users would also love the braille reader to remember where they left off when opening a file they were reading. I guess this is more of a hardware problem than of the file format itself, that's why I didn't create a new bullet point for this.

[jrbowden]

Let's consider there are other ways to make semantic markup other than lengthy XML-style tags with open and close components. For low memory situations, one could easily envisage a linear binary file format with no need for closing tags.

I see splitting into volumes as a separate issue to opening the file quickly. Perhaps this is too use cases?

I absolutely agree, opening the file should be quick, whether you are opening to the beginning, or resuming from an arbitrary point.

[avneeshsingh]

@franciscoONCE it would be good to open a new issue for When a braill file is opened enable reader to resume reading from last read position.

Regarding the original issue for splitting braille file in multiple content documents (termed as volumes in this use case), it is important. Should it be high priority use case?

[wfree-aph]

Meeting: logical divisions for file type could be chapters, volumes, or whatever we agree to.

[franciscoONCE]

@franciscoONCE it would be good to open a new issue for When a braill file is opened enable reader to resume reading from last read position.

No problem in creating a new issue if the group agrees, but I still think it's more of a hardware problem than a format problem. Some of the issues here refer to things we'd like the reader to do with this format, but which I don't see as part of the format itself. Same with the error-free Grade 2 German braille - some devices will be able to produce that "Grade 2 to Grade 1" error-free translation on the fly while others may not, depending on the features it provides, not the file format.

Would it help to add yet another classification - "format-related" versus "device-related"?

[mhorspool]

I agree with @franciscoONCE, the reading device opening to the last known point shouldn't require us to do anything in the standard itself, so I would say it is out of scope.

[avneeshsingh]

We are adding issues related to reading systems also in this tracker. For this we have different labels for reading systems related issues. There are three labels content specs, reading systems implementation and authoring tools implementation.

[mattgarrish]

Allowing multiple files is a core part of EPUB and DTBook. We can also build off the publication manifest, as it also defines a default reading order.

Pure HTML would require some other method than a spine. It does have prev/next link relationships, so it's not unachievable there, either.

[wfree-aph]

While the xHTML files are not necessarily broken up by volume, they are able to be split into separate files by the EPUB packaging format recommended in the first draft of the specification. This feature should help ensure that the files can be opened quickly. Other than that, this is a reading system feature. If we discover that there is an issue with the specification that makes opening files cumbersome or slow, we can address it at the time.