🚀 go-pugleaf

re: IFF standard

IFF is an incredibly versatile file format originally introduced by
Electronic Arts and Commodore-Amiga in 1985 (the full name is "EA-IFF
85").  The initials stand for Interchance File Format.  Its purpose was to
stanardize the file format for such things as bitmapped graphics, sound,
music data, formatted text, animations, etc and allow programs to
interchange data.  The standard itself is based on four-letter "chunk"
identifiers.  The parser searches for the chunk IDs that it knows about,
and reads them in a standardized fashion.  This system allows for
incredible future expansion, with programs being able to store their own
data in private chunks, and the file can still be shared among different
programs because there are standard chunks.  In addition, the initital
four-letter ID allows the program to quickly and easily determine what
kind of IFF file it is (ILBM for pictures, SMUS for music scores, 8SVX for
sound samples, etc).

IFF was originally introduced to be a multiplatform thing, modeled
somewhat after Macintosh's four-letter "resource" names.  However,
Commodore didn't make enough marketing noise and nobody really heard about
the Amiga.  Anyway, the IFF standard has become so accepted on the Amiga
(we snicker at people having to translate from one file format to
another), that some PC and Mac programs have adopted it.  For example,
Adobe Photoshop can read and write Amiga-compatible IFF ILBM (bitmapped
graphics).

Please note that the IFF standard is very different from the modern term
"DataTypes".  DataTypes are a new feature of modular file parsing (and
other cool stuff) which were added to AmigaDOS release 3.  DataTypes are
little drivers that you can install on your system disk, and with them
programs can access data through them.  For example, there are several
datatypes of class "PICTURE": ILBM (IFF), BMP, PCX, GIF.  A
DataTypes-aware program which is asking for a "PICTURE" can then parse all
the file formats above, automatically and generally transparent to the
user.  Again, DataTypes are a fairly new thing (AmigaDOS release 3 came
out in September 1992 with the release of the Amiga 4000 and AGA custom
chipset), and many programs have not yet adapted to them.  However, we
expect to see more and more DataTypes-aware programs coming out RSN
because they add so much flexibility to the system.

Anyway, back to localization.  Localization on the Amiga, on system
software release 2.1 and above, is handled at a system level.  A program
called "Locale preferences" allows the user to set his or her locale and a
heirarchal system of "preferred languages".  This is so that if a program
does not have support for the most preferred language, it will use the
next lower down the list, and if it doesn't support that, it will use the
next lower, etc.

Localization on the Amiga is handled through a handful of functions in the
dynamically allocated run-time library "locale.library".  Through this
library, programs can request such things as date/time format, currency
symbol, "thousands delimiter" (comma or period), and language strings, for
the selected locale.  Language strings are handled through an IFF
"catalog" of strings, identifier CAT.  Basically, the program opens
locale.library, then calls GetCatalogStr(), with the ID of the string
desired, and a default string in case the catalog for none of the
preferred languages is available.  The whole operation is quite seamless
and simple, and all the user has to do is select his desired locale and
preferred languages in Locale preferences, and all locale-aware programs
will automatically adapt.

Modularity is the Amiga's middle name, and that is also the case with
localization catalogs.  Each language catalog, for each program is stored
in a seperate file in the LOCALE:Catalogs directory.  Once the program is
set up for localization, adding additional language capability is as
simple as creating another catalog with the same IDs tied to strings in
the new language.  Catalog bug-swatting is also handled in a similar
manner, with no need to recompile the program.  Also, third parties can
create catalogs for programs, and the developer need not release anything
but the executable and the string-ID table.

The Amiga uses the Latin-1 character set (interesting, eh?), and need not
switch fonts for most localizations.  However, the font system is very
flexible also, and the user has control over system default fonts and
screen fonts from Font Preferences.  Also, keymaps are provided for the
various countries in which the Amiga is sold.

Hope this clears up some stuff about Amiga localization.  As most of you
are aware, to say that the Amiga is an underdog in the U.S. is an
understatement.  However, the machine has gained quite a bit of popularity
in Europe (albeit as a "game machine" sometimes), and it was definitely in
Commodore's best interest to provide the Amiga with a flexible, user- and
developer- friendly, localization system.