-
Notifications
You must be signed in to change notification settings - Fork 5
ZIP packaging comparison
Note that this page considers the packaging issues from the perspective of distribution to end users. For exchange between organizations, any packaging could be used to move the ebraille file set.
- Packaging: EPUB container (ZIP with file rules)
- Extension: .epub
- Supported by EPUB reading systems and eBraille reading systems
- Unzippable for browser reading
This option would have the widest out-of-the-box support as both mainsteam and ebraille-specific reading systems would be able to open the files without modification. As with all the scenarios, mainstream epub reading systems would not support any custom extensions for ebraille, but the all standard HTML and CSS rendering instructions would work.
The one complexity with this approach is EPUB's zip rules - specifically, that the mimetype file has to be the first in the zip container. Publishers typically do not perform this step manually, but either have tools that generate the correct zip file for them (e.g., Adobe inDesign and custom workflows) or use epubcheck's built-in option to save out an epub from a file set.
A downside to this approach is that an ebraille file would be indistinguishable from a regular epub file until the user loads the file in their reading system. Users will typically know what they are downloading when they obtain the file, however. By keeping the same extension, it would also be more difficult for users to open the different publication types in different reading systems (i.e., only one application could be the default for .epub files). If the user knows the file is an ebraille, they could manually select the application to open the file with (e.g., through a right-click "open with" context menu).
As with all the following scenarios, the content is unzippable to read in a browser but users will have to know they can unzip the files and how to do it (e.g., sending the file to an unzip program using an "open with" option).
- Packaging: EPUB container (ZIP with file rules)
- Extension (example): .ebrl
- Supported by eBraille reading systems. If extension changed, also by EPUB reading systems.
- Unzippable for browser reading
This scenario is similar to the first with only the file extension changing.
The positive of changing the extension is that it avoids collisions with mainstream epub files. Each could be associated with a different reading system, for example.
The negative is that the files won't be supported by EPUB reading systems unless the user knows the change the file extension. This will mean adoption of ebraille will have to wait on compatible reading systems, or users will have to change the extension back and forth to be able to read in mainstream reading systems during development.
- Packaging: ZIP (no rules)
- Extension: .zip
- Supported only by eBraille reading systems unless extension is changed
- Unzippable for browser reading
This scenario does away with EPUB's packaging rules and extension. An ebraille file would just be a plain old zip file.
The positive of this approach is that it makes it simple for anyone to zip up an ebraille file for distribution to users. All you need is any zip program.
The negatives are a combination of those described above. Mainstream EPUB reading systems would not open the file unless the extension is changed to .epub. Even then, this takes advantage of processing looseness in many reading systems (i.e., they support incorrectly zipped epubs even though that's not part of the standard). It's not clear how many reading systems are this permissive (testing showed that Apple, Google, Adobe, and Kobo would all open invalidly zipped epubs, but that's a small subset of all reading systems).
By using the common .zip extension, it also wouldn't be possible to differentiate a default application to use to read ebraille files. They would have to use manual "open with" options. Users may also not be aware that the file contains ebraille and isn't just for unzipping.
- Packaging: ZIP (no rules)
- ZIP complexity: Low
- Extension (example): .ebrl
- Supported only by eBraille reading systems unless extension is changed
- Unzippable for browser reading
This scenario is similar to scenario 2. It requires no special zipping.
The custom extension will differentiate ebraille files from regular zips and epubs, providing the advantages of identification and specifying a default application to open the files with.
Like with scenario 2, the custom extension will also prevent the file from opening in mainstream epub reading systems unless it is changed. It also requires the user to know the file can be unzipped. If the extension is changed to .epub, at least some epub reading systems will open the file.