[cc65] TGI bitmap fnts revisited

From: Oliver Schmidt <ol.sc1web.de>
Date: 2011-07-10 10:23:54
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