On 25 Jul 1999, Ersek, Ted R wrote:
> When would one want to use
> Hierarchical Data Format
This would be used if you wanted to interchange arrays of numerical or
character data that correspond to certain data types, like a character or
a 32-bit real number.
> MAT matrix format
Hopefully when migrating from Matlab to Mathematica :-). The MAT format
is the format that was used by Matlab up to version 4 for saving matrices
to a file. Matlab 5 uses a proprietary format for which there is no
published spec, only an API for I/O.
> PNG format
At one time this was thought to be a replacemnt for Compuser GIF format
after Unisys started demanding royalties from developers of software that
read or wrote GIFs. The point of contention was that they have a patent
on the algorithm (Lempel-Ziv-Welch) that is used to compress the image
> portable graymap format, portable pixmap format, portable anymap
The lowest common denominator formats -- portable bitmap (PBM), portable
graymap (PGM), and portable pixmap (PPM) are referred to collectively as
portable anymap (PNM). These are often used as interchange format when
writing graphics converters. The most prevalent example is the netPBM
toolkit, which is a collection of shell tools that can be used in tandem
to translate between bitmap formats. This allows developers to write 2N
instead of N^2 converter programs.
> Mathematica system-independent raster graphics format
This is the format in which the front end stores bitmap caches of
PostScript graphics cells and any cell that has been converted to a
bitmap. It is not really of interest to an end user unless one is trying
to generate notebooks that store bitmaps in a programmatic manner from the
> Look at al the flavors of PostScript available:
> Encapsulated PostScript
Intended to be embedded within part of a larger PostScript document.
> Mathematica abbreviated PostScript
This is the PostScript that is understood by the notebook front end and is
generated by the Mathematica kernel when it is asked to display a graphic.
It contains a lot of abbreivated PostScript operators to reduce the size
of the PostScript string stored by the front end. In order for PostScript
interpreters to understand Mathematica-generated PostScript, some
translation must be done that adds all of the macro definitions. In the
old days, this was done by the shell script psfix and the DOS program
RASTERPS.EXE. Nowadays, both the front end and the kernel have ways of
doing this directly.
> Encapsulated PostScript with device independent preview
> Encapsulated PostScript with TIFF preview
If you've ever inserted a raw EPS file into a word processor like
Microsoft Word, you might find that all you see in the document is a dummy
box that marks off the space occupied by the graphic. This is because
most document preparation systems do not have built-in PostScript
interpretation programs. The Adobe specs allow for a bitmap preview to be
added to the EPS file so that an application can show the preview on
screen instead of the dummy box. These are just two examples of such
preview formats. On the Macintosh, PICTs can be stored in the file's
resource fork, and under Windows, a Metafile preview can be supplied.
> When would I want to use the various sound formats ?
> They include:
> AIFF format
This is understood by Macintosh systems, I believe.
> nu law encoding (.au)
I think it's mu-law. On Unix systems that support sound, you can play .au
files by a simple shell command.
The TIFF format allows for multiple images to be included in a single
file, but I don't think there are any animation (timing, looping, etc.)
parameters supported by the base spec. It would be up to the displaying
application to handle the timing of the graphic switches.
Mathematica Programming Group paulh at wolfram.com