If you have ever wondered why the Microsoft Dynamics GP Report Writer limits you to 32Kb (32,767 bytes) when adding images, this post should hopefully explain the reasons.
The most important point to note is that the 32Kb limit is for an uncompressed bitmap version of the image. So if you have a compressed image (gif, jpg, etc.) that is 32Kb, it is not going to fit as it will be larger than 32Kb once uncompressed. This is because Dexterity stores the resource as an uncompressed bitmap when it is pasted into the system.
Perhaps the answer can be found by looking at history of Microsoft Dynamics GP (Great Plains).
Since the earlier versions supported Macs as well as Windows, it had to natively support the underlying instruction set. The following extract on the story to the Mac Toolbox and resource manager gives us one explanation:
“The Macintosh was built around the Motorola 68000 microprocessor, which was an amazing chip for its day, but it did have a few problematic limitations. The instruction set was missing a way to specify a long relative branch, and absolute branches were forbidden since we needed our code to be position independent. This meant that the maximum size of a hunk of code was limited to the range of a relative branch, which was 32K bytes.“
I discussed this theory with one of the original Dexterity developers and they thought that the 32Kb restriction was a file handler page size restriction.
“You couldn’t store any data, picture or otherwise that spanned two logical pages. I don’t recall if it was a c-tree or Btrieve limitation, but we based the limit on the lowest common denominator.“
I believe that the explanation is probably a combination of both issues as the c-tree file handler which worked on both Macintosh and Windows probably faced the address limitation caused by the 68000 processor.
The following Knowledge Base (KB) articles discuss how to add images and how to ensure they don’t get pixelated when printing to the printer: