zinricky
/
gempub
mirror of https://codeberg.org/oppenlab/gempub.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Added language describing ZIP structure. Should allow us to close #2, #9, and #15.

This commit is contained in:
Raph 2021-05-26 07:45:53 -07:00
parent 54727b3ee3
commit 2c298b68dc
1 changed files with 45 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
README.md
View File

@ -53,18 +53,14 @@ Gempub files end with the extension ".gpub" and their mime-type is `application/
### 2.2 Directory Structure
Gempub files are zipped directories of Gemtext ".gmi" files plus an optional metadata file:
Gempub files are `zip` archives that contain a Gempub index file (see "Gempub Index", below), a collection of `text/gemini` (`.gmi`) files, any supporting files such as images (see "Images", below), and an optional metadata file containing the title, author and any other optional fields (see "Metadata", below).
• metadata.txt - a file containing the title, author and any other optional fields. See "Metadata", below.
This file enables Gempub to act as a full eBook format. Gemini capsules can also be simply zip compressed without the metadata file to act as a Gemini archive/offline format - when operating as an archive there must be an index.gmi in the root directory.
Example:
#### Example
```
//Example with index.gmi in a sub-directory, specified by the index value in metadata.txt
// Example with index.gmi in a sub-directory, specified by the index value in metadata.txt
//.gpub contents:
// .gpub contents:
book_title.gpub/
metadata.txt
cover.jpg
@ -76,14 +72,18 @@ book_title.gpub/
images/
illustration.png
//metadata.txt:
// metadata.txt:
title: book title
gpubVersion: 1.0.0
cover: cover.jpg
index: book/index.gmi
```
### 2.3 Metadata
A Gempub container can be created by simply zip-compressing a capsule directory. This allows the Gempub container to serve as both an e-book container and as an offline Gemini capsule archive. In either case, however, the root of the zipped Gempub container must have either a Gempub index file named `index.gmi` or a metadata file named `metadata.txt` with an `index` value that points to the location of a valid Gempub index file. (See "Example", above.)
### 2.3 The `metadata.txt` Metadata File
The `metadata.txt` file enables Gempub to act as a full e-book format by allowing the author to specify data such as a title, a cover image, copyright information, a book description, and author information.
The metadata.txt file contains key-value pairs separated by line. Values start after the first colon and are trimmed (e.g., `author: Olaf Stapledon` and `author:Olaf Stapledon ` are equivalent). All values are optional apart from `title` and `gpubVersion`. Order does not matter. If no index path is specified there must be an index.gmi in the directory root.
@ -100,9 +100,9 @@ The metadata.txt file contains key-value pairs separated by line. Values start a
* `copyright`
* `license`
* `version` - human readable only, not meant to be parsed
* `cover` - a JPG or PNG image which can be anywhere in the directory structure. For accessibility, and also because clipping will occur when maintaining the aspect ratio of the image - do NOT use text in the image.
* `cover` - a JPG or PNG image which can be anywhere in the directory structure. For accessibility, and also because clipping may occur when maintaining the aspect ratio of the image, authors should NOT use text in the image.
This metadata is intended so readers can display a useful catalogue of multiple .gpub files and display a cover for individual books. Metadata must never be used to specify flags for content rendering. Content should always be simple Gemtext. Reader applications must ignore custom parameters.
This metadata is intended for readers to use to display a useful catalogue of multiple `.gpub` files and display covers for individual books. Metadata must never be used to specify flags for content rendering. Content should always be plain Gemtext. Reader applications must ignore custom parameters.
Example:
```
@ -112,20 +112,44 @@ index: ./capsule/index.gmi
gpubVersion: 1.0.0
```
### 2.4 Content
### 2.4 The Gempub Index File
All content must follow the [gemtext specification](https://gitlab.com/gemini-specification/gemini-text/-/blob/master/specification.gmi).
The Gempub index file is a `text/gemini` compliant UTF-8 file that consists primarily (or solely) of a list of links to `text/gemini` content.
Reader implementations should use the index.gmi to determine what to display next when the user reaches the end of a chapter.
This file is a required file, and must either be located in the root directory of the archive and have the name `index.gmi`, or must have its name and location in the archive specified in the `index` entry of the `metadata.txt` file.
### 2.5 Images
If a reader application cannot find a valid Gempub index file in either the root of the archive or the location pointed to by the `index` entry of the `metadata.txt` file, the reader application must display an error indicating that the archive is not a valid Gempub archive. The reader application may then either (a) refuse to open the archive, or (b) display the contents of the `zip` archive's root directory and allow the user to choose a file to use as the Gempub index file.
The Gemini Protocol doesn't allow auto-loading of images for various reasons, none of which are applicable in an eBook. Gempub implementations can choose to handle images:
When opening a Gempub archive, Gempub reader applications shall use the Gempub index page as the archive's table of contents, and shall display the archive's Gempub index page in accordance with the text/gemini specification. Gempub authors are expected to build the Gempub index page by adding links to content pages contained elsewhere within the archive. Remote links (links to remote resources that are not contained in the archive) are permitted within the Gempub index page, but reader applications must ignore remote links when creating an application-specific representation of the table of contents (see below) and when determining reading order (see below).
The Gempub index file may include content other than links. For example, the Gempub index file could include introductory text, or brief summaries of each chapter next to the link pointing to the chapter's content.
There are no other requirements with respect to the Gempub index file. Simple reader applications may display the page as the table of contents, with no additional work required, and archival Gempubs may use the "root" file of the capsule as-is.
More complex reader applications may use the Gempub index file to generate an application-specific representation of the archive's table of contents and to determine automatic reading order, as follows:
An application-specific representation of an archive's table of contents must be generated by assembling links to local resources (items contained within the Gempub archive itself) and displaying them in the order in which they are listed in the Gempub index file (from top to bottom). In other words, the first link in the application-specific representation of the table of contents must be the first local link in the Gempub index file.
If a link within the Gempub index file has a user-friendly link name, the Gempub reader application must display the user-friendly link name in the application-specific representation of the table of contents without prepending or appending any numbering or additional text. This permits Gempub authors to use their own chapter numbering and naming conventions. On the other hand, if a link within the Gempub index file has no user-friendly link name, the Gempub reader must display the link URL, and may prepend or append a number or other short descriptive text to the URL.
During the reading process, the user should be able to begin with the first item in the table of contents and seamlessly advance through the contents of the Gempub archive by instructing the reader application to display the next page. The Gempub reader application must automatically advance through the contents of the Gempub archive in the order in which links are listed in the Gempub index file. For example, in the case where a user has completed reading the text of the file pointed to by the first link in the Gempub index file, and the user then instructs the reader application to advance to the next page, the reader application must automatically load and display the beginning of the file pointed to by the second link in the Gempub index file.
This automatic load-and-display behavior is only permitted with respect to local links that point to files contained within the Gempub archive. Per the `text/gemini` specification (section 5.4.2), clients must not automatically make any network connections as part of displaying [remote] links. Transparently loading a remote file in response to a user's "display next page" request would violate this prohibition. Therefore, in response to a "display next page" request by the user, Gempub reader applications must automatically skip over links to remote resources, and instead must load and display the contents of the next link in the Gempub index file that points to a local resource (i.e., a file contained within the Gempub archive).
The automatic load-and-display behavior must be performed only for top-level links that are directly listed in the Gempub index file. In other words, the reader application must not recursively descend through linked files to determine reading order. In the case of an e-book, for example, the first chapter displayed to the user must be the contents of the first link in the Gempub index file. When the user asks the reader to "display next page" at the end of the first chapter, the reader application must display the contents of the next link in the Gempub index fie.
### 2.5 Content
All text content must follow the `text/gemini` specification.
### 2.6 Images
The Gemini Protocol does not allow auto-loading of images for various reasons, none of which are applicable in an eBook. Gempub implementations can choose to handle images:
* Inline: any links that end in an image extension can be automatically inlined, retaining aspect-ratio based on available screen width.
* Linked: for implementation simplicity a clicked image link could take the user to a separate in-app image viewer (or even pass to the OS to display).
* Linked: for implementation simplicity a clicked image link could take the user to a separate in-app image viewer (or even pass the link to the OS to display).
Supported formats are PNG and JPEG as they're common and included on most/all platforms.
Supported formats are PNG and JPEG as they are common and included on most platforms.
Images must always include a description for accessibility:
@ -141,7 +165,7 @@ Images must always include a description for accessibility:
As well as including appropriate alt-text for images make sure screen readers are able to correctly interpret Gemtext. Gemtext has syntax for 3 different header types which may handled differently by screen readers. E.g., on Android, a text view may have the accessibility heading attribute `setAccessibilityHeading(boolean)`.
Images should never include text unless it's repeated as text content immediately above or below.
Images should never include text unless the text is repeated as text content immediately above or below the image.
## 4 Recommendations