RATIONALE
The AMB format is, by design, burdened by several limitations. These
limitations might be misunderstood as shortcomings, while in essence the AMB
format's primary objective is to stay as primitive as possible - so it is easy
(and fast) for software to parse and display. Below are listed some of these
limitations, with explanations about the reasons that led to them.
* Line length limited to 78 characters
The hard-coded limit of 78 chars is meant to ensure that the reader will
not have to worry about line wrapping, which highly simplifies the reader's
code thus allowing for faster processing and minimizing potential bugs. It
is also meant to allow the content creator to design his screens in a
deterministic way - that is, without any risk that his semigraphic tables,
ASCII drawings or overall screen disposition will be broken by a reader
that attempts to rewrap the text at an unpredictable width.
The 80-columns width was ubiquitous since the early 80' and seems to be a
reasonable baseline expectation, and a 78-characters limit allows the
reader to use two columns for its own needs (vertical cursor, border, etc).
* No control over style (colors) applied to text
The AMB format defines a set of semantic tags (like "%h" for "heading"). It
does not allow control over the exact colors or attributes that will be
used by the output device to render the document. This is designed on
purpose: AMB documents should be displayable also on monochrome devices.
There may also be devices that allow for text attributes like "underlined",
"bold", etc - it is up to the AMB reader to make sure the semantic tags are
translated into colors/shades/attributes combinations that are nicely
rendered on the target hardware.
* Article size limit of 64 KiB
A single article (AMA file) is limited to a maximum length of 64 KiB (minus
one byte). This limitation makes it easier for MS-DOS readers to load the
content: in real-mode Intel memory models, a single memory segment is
addressable via 16-bit offsets, hence processing content larger than 64 KiB
becomes tricky, as it involves crossing memory segment boundaries, or
relying on some kludges like "huge" memory pointers (slow), or dynamically
reloading parts of the file from disk (very slow). 64 KiB still allows for
more than 30 pages of 80x25 packed text, which should be more than enough
even for very complex subjects (and larger contents should simply be
dispatched into two or more different articles, which can only be
beneficial for readability).
* Maximum number of 65535 articles
An AMB book may contain up to 65535 articles and not a single more, because
the number of articles is written as a 16-bit integer in the file's header.
This allows AMB software to use 16-bit integers when addressing the
articles, which is very convenient (and fast) for platforms with 16-bit
CPUs. And honestly - is that really a limitation? Even the entire Bible has
"only" 1189 chapters, or 31103 verses.
* Short filenames + low-ascii characters only
Filenames inside an AMB container are limited to 12 (8+3) characters so
an AMB container can be unpacked on an old MS-DOS system.
The filenames must contain only low-ascii (7-bit) characters -- for two
reasons: so it is possible to unpack an AMB container on any filesystem,
independently of the codepage said filesystem relies on, and to make it
possible to reliably perform case-insensitive matching of filenames.