Re: [cc65] TGI bitmap fnts revisited

Hi!

On Sun, Jul 10, 2011 at 10:23:54AM +0200, Oliver Schmidt wrote:
> 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.

There are two possible views: 

  a) Coordinates increase when drawing fonts

  b) Text should be drawn in the same way, we write

a) means that the top left corner is point zero of the bounding box of the
characters, while b) means that it's the lower left corner. The stroke fonts
use b) and if I remember correctly, this is what the Borland BGI did.

Since bitmap fonts usually don't have a common baseline, I would agree to
ignore it. BGI did it this way.

Please note that the behaviour is different for stroke fonts. For stroke
fonts, the horizontal coordinate is the baseline of the characters.

> @Uz: The current implementation of that cursor movement seems to take
> vertical direction into account but seems to _not_ take text scaling
> into account.

Thanks for the hint. I will fix that.

> 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?

The size parameters are 8.8 fixed point values. For the vector fonts, they're
used directly (as fixed point value). For the bitmap fonts, the kernal will
round the 8.8 value to the next integer and pass this to the drivers. So $280
will become an integer scale factor of 3, $27F will become 2.

> 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

I would still prefer a "full" implementation that also does scaling, but
having bitmap fonts at all is better than nothing.

> 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.

Sounds reasonable.

> - 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)

Since a) needs some unknown amount of memory, b) is probably the way to go.

> 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?

BGI feft them alone and this is what I would do, too.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.