Hi, Quite some months ago we were discussing here some aspects of TGI bitmap font handling. However other aspects were not covered. Therefore I revisited the topic. First let me briefly summarize our results: 1. The coordinate used for text output becomes the bottom left corner of the first character. 2. The bottom left corner refers to the bounding box of the characters, _not_ the baseline of the characters. So all drawing happens above and to the right of the coordinate used. 3. Vertical direction means the text runs upwards. The coordinate used still refers to the same point relative to the first character. So all drawing happens above and to the _left_ of the coordinate used. 4. The TGI cursor is advanced by the TGI kernel beyond the last character in a way that a subsequent text output would result in continuous text drawn. @Uz: The current implementation of that cursor movement seems to take vertical direction into account but seems to _not_ take text scaling into account. The aspects not being covered that I'm aware of are: 1. Do we want to make any statements what the user can expect from setting the first two parameters of tgi_textstyle (<1>, <2>, <3>, TGI_FONT_BITMAP) to anything different from 0x100? Range? Granularity? Minimal value? Maximal value? To be honest this doesn't affect me personally directly as my new Apple II implementation of bitmap font text output will ignore the first two parameters anyway - meaning it won't support scaling at all. The primary reason is the overhead necessary by means of code size - that is always present in the driver even if unused. Now that vector fonts are (close to be) there we might even consider not supporting bitmap font scaling in general - leaving those "advanced" stuff to vector font text output. Two arguments (beside code size): - Enlarged bitmap fonts are ugly - The screen resolution of our target devices are even in "hires" mode so low that there's not much use for enlarged text output 2. Our last TGI discussions lead to the result that the TGI kernel takes care of clipping for about all drawing primitives. However there's currently no clipping for bitmap font text output implemented in the TGI kernel. But for consistency reasons I believe it should be done there. I see very well that this is somewhat difficult for the TGI kernel, but I see two viable options: - Text output not fitting the screen is omitted completely - the TGI kernel just doesn't call into the driver for text output - Characters not fitting the screen are omitted completely a) The TGI kernel creates a copy of the substring fitting the screen (and adjusts potentially the coordinate) b) The TGI kernel creates a single character string for every character fitting the screen and calls into the driver in a loop (leveraging the cursor movement feature) 3. What happens to the pixels not being part of the character glyph but being part of the character bounding box? Are they to be left as-is? Or are they to be set to some value - if yes to which? Regards, Oliver ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Jul 10 10:24:09 2011
This archive was generated by hypermail 2.1.8 : 2011-07-10 10:24:12 CEST