RISCOS Ltd RISCOS Ltd -------------------------------- TECHNICAL NOTE: THE FONT MANAGER -------------------------------- Document: 20000320-004 Version: 1.00 (05 Oct 1999) JRF: Initial documentation written 1.01 (10 Jan 2000) JRF: Updated slightly for release 1.02 (08 Mar 2000) DPT: Updated with revised font file format details. Author(s): David Thomas Justin Fletcher Matthew Bullock 1) FONT_SCANSTRING: CLARIFICATION OF INTER CHARACTER SPACING IN EXTENSION BLOCK Applicability: All FontManager versions Description: The 'additional offset for each letter' in the PRMs is slightly unclear. The actual wording should be 'additional offset for each character' - spaces are also included in these calculations. Thus if you have both space and letter offsets in use, BOTH are added to each space. Recommendation: Be aware of the circumstances in which this occurs. 2) FONT_SCANSTRING: FAULT IN ADDITIONAL CHARACTER SPACING Applicability: All FontManager versions to 3.40. Description: The additional offsets to each character spacing is NOT added to the last character of a string when calculating the size of a string. Versions of the FontManager after 3.40 will probably have this corrected. Recommendation: None. 3) FONT_SCANSTRING: FAULT IN ADDITIONAL SPACE SPACING Applicability: All FontManager versions to 3.40. Description: The additional offsets to each space spacing does NOT obey the right to left flag. This flag is not widely used and should not be an issue in most legacy software, but you should be aware of this problem. Recommendation: Require a later version of the FontManager if you need this feature. 4) FONT FILE FORMAT: CORRECTIONS TO DESCRIPTION OF CHARACTER DATA Applicability: PRM description is ambiguous and incorrect. Description: From discussions with a developer it has become apparent that the description of the font file format character data given in the PRM (all versions) is incorrect. It should read: (page 4-480) " Character data Size Description 1 character flags: bit 0 set => coordinates are 12-bit, else 8-bit bit 1 set => data is 1-bpp, else 4-bpp bit 2 set => initial pixel is black, else white bit 3 set => data is outline, else bitmap if bit 3 is clear: bits 4-7 = 'f' value for char (0 => not encoded) if bit 3 is set: bit 4 set => has composite base character bit 5 set => has composite accent character bit 6 set => character codes within this character are 16-bit, else 8-bit (not yet implemented - must be zero) bit 7 reserved (must be zero) if character flags bit 3 is set (outlines): if bit 4 is set (composite base): Size Description 1 or 2 character code of base character if bit 5 is set (composite accent): Size Description 1 or 2 character code of accent 2 or 3 x,y offset of accent character Note: bit 5 is not dependent on bit 4, therefore one can define a character that is simply a shifted version of another. if bit 4 and bit 5 are not set: Bounding box and data follows (see below) else if character flags bit 3 is clear (bitmap): Bounding box and data follows (see below) Bounding box and data Size Description 1 or 1.5 x0 } bounding box for character (8- or 12-bit signed) 1 or 1.5 y0 } bottom-left (x0,y0) is inclusive 1 or 1.5 x1 - x0 } top-right (x1,y1) is exclusive 1 or 1.5 y1 - y0 } all coordinates are in pixels or design units ? data: (depends on type of file) 1-bpp uncrunched: rows from bottom to top 4-bpp uncrunched: rows from bottom to top 1-bpp crunched: list of (packed) run-lengths outlines: list of move/line/curve segments Word aligned at the end of the character data. " The previous description indicated that accented characters should have a base character (this isn't necessary if you want one character to be a shifted version of another) and indicated that character data could be present in that case. Recommendation: Use the above information in preference to the PRM's description. -- Comment: FontManager technote 1.02 Part: 20000320-004