================================
  = The SVG Graphics File Format =  - Version 1, draft version: 03.01.1997
  ================================

  File Format Information
  ~~~~~~~~~~~~~~~~~~~~~~~
  Pictures in the "SVG Graphics File Format" consist of two parts:
  a header and an attached xpk-packed or unpacked data file.
  Both parts are put into one single file.

  Construction (all fields in Motorola BYTE order):

  0x00  ID              UBYTE[18]       "SVG Graphics File" + 0-Byte
  0x12  Version         UWORD           always 1 yet
  0x14  GfxDataOffset   ULONG           header length (depends on version)
  0x18  LeftEdge        ULONG           as with e.g. ILBM
  0x1c  TopEdge         ULONG           ...
  0x20  Width           ULONG           ...
  0x24  Height          ULONG           ...
  0x28  ColorDepth      ULONG           used colors as x of 2^x
  0x3c  ViewMode32      ULONG           32 Bit Amiga ViewMode
  0x40  PixelBits       UBYTE           1, 8, 24 (future: 16, 32)
  0x41  PixelPlanes     UBYTE           # of planes with PixelBits
  0x42  BytesPerLine    ULONG           bpl of a PixelPlane
  0x46  ColorMap        UBYTE [256][3]  unused, if > 256 Colors (zero-ed)

  After that either follows XPK compressed data or uncompressed
  data, which can be detected by the leading chars "XPK" or "PP20"
  for packed data at GfxDataOffset (relative to beginning of the file).

  Please note, that with upto 256 colors (Colordepth <= 8) it has
  to be checked, whether the graphics actually is EHB or HAM.
  Use the Viewmode32 field for these assumptions when reading, and
  maybe OR with HAM_KEY or EHB_KEY when saving.

  Note:
  -----
  "Pixelbits" and Planes do allow a lot of combinations.

  Actually used and supported by current software are only the
  following:

     Bits   Planes  Depth  Content
     ---------------------------------------------------------------------
     1      1..8    1..8   (unaligned Bitmaps with 2..256 colors)
     8      1       1..8   (chunky Bitmaps with 2..256 colors)
     24     1       24     (24 Bit RGB Bitmaps with 8:8:8 RGB)

  So 24 Bit Data should not be saved planewise, but as 24 Bit RGB instead.

  If you ever should save any other data, please avoid any planar
  configurations and respect the following rules for RGB data chunks:

     Bits   Planes  Depth  Content
     ---------------------------------------------------------------------
     16     1       15/16  (15/16 Bit Bitmap with 5:5:5:1 RGB0/A)
     32     1       24/32  (24/32 Bit RGB Bitmaps with 8:8:8:8 RGB0/A)
     48     1       48     (48    Bit RGB Bitmaps with 16:16:16 RGB)
     64     1       48/64  (48/64 Bit RGB Bitmaps with 16:16:16:16 RGB0/A)
     ... etc ...

 Note, that an alpha channel can only be correctly identified, when
 "ColorDepth" is handled as an indicator, whether there actually is one,
 or not. Programs not supporting alpha channels should simply ignore
 the color depth and interpret "Bits=16 and Planes=1" as 5:5:5:0 RGB
 and "Bits=32 and Planes=1" as 8:8:8:0 RGB and so on...

 Planar configuration actually only was thought for support of 2..256 color
 Bitmap contents. We all new, that actually 24 or more bitplanes are
 nearly unuseable and actually ugly to handle.
 So please respect the "Planes" variable only being valid for values
 between 1..8 and only, if "Bits=1" has been set, also note, that
 with "Planes=1..8" you must set "ColorDepth=Planes", since other
 than with 8 Bit chunky there is no support of unused planes.