The WIDTH/IMAGEWIDTH distinction is not propagated through MOVECHARBITMAP PUTCHARBITMAP GETCHARBITMAP

[rmkaplan]

I am looking at the infrastructure in FONT for moving character bitmaps, as part of the coercion of XCCS fonts to MCCS fonts (dollar, underscore, caret).

MOVECHARBITMAP essentially does PUTCHARBITMAP of GETCHARBITMAP. It appears to me that the bitmap is constructed using the IMAGEWIDTH, which defaults to WIDTH, so the bitmap is valid. But the fact that the IMAGEWIDTH of a character might be different from the (advance) WIDTH is not carried over to the destination. Nor is the leftkern information, if present in the source.

I think this means that e.g. diacritics and italic-advancing would be screwed up if those glyphs were moved from one place to another, even if in the same font descriptor.

So I think that GETCHARBITMAP should return a more complicated structure when the full collection of properties can't be determined just from the bitmap. Maybe a property list that includes the bitmap plus these other properties.

For backward compatibility, perhaps GETCHARBITMAP should take a flag to say that it should provide this information.

Also, these functions have a validity test for the character codes, allowing strings and litatoms and coercing them to their first character. I think it would be better to call CHARCODE.DECODE.

[rmkaplan]

On further thought, it would be better to leave GETCHARBITMAP alone, it just gets the bitmap. But add a higher level function to fetch and store all the information. Maybe an entry MOVECHAR that does everything, keep MOVECHARBITMAP for backward compatibility.

[rmkaplan]

I have written a function MOVEFONTCHARS that takes a code/font mapping and copies all of the relevant information. I have also used an otherwise unused field in FONTDESCRIPTOR to record the FONTCHARENCODING (XCCS, MCCS, ALTOTEXT...).