nanogui: Thread: Fonts revisited

I've started hacking support for T1lib into MicroWindows/Nano-X now.

First and foremost, my reason for ending up with T1lib instead of Freetype 
is:

  - FreeType may have patent problems (ref: www.freetype.org)
  - When searching for fonts, I found tons of redistributable (as part of
     a commercial package) Type1 fonts, but mostly highly restricted Truetype
     fonts (free for personal use only, etc.), and the few really free Truetype
     fonts I found were fonts intended for logo design - that is, no "classic"
     fonts...
  - T1lib supports ligatures and proper kerning directly.

However, I encountered a problem:

The low level screen device font functions has a *way* to constrained interface
to do proper text handling.

Some of the problems include:

    - GetTextBits() doesn't support returning ascent or descent values.
    - No support (or easy way of faking) kerning or ligatures.
    - No support for drawing multiple characters at a time for font renderers
       that support it.
    - No easy way of adding features like anti-aliasing.
    - GdText() is constrained to narrow fonts (less than 16 pixels wide?)
    - No support for requesting font widths for scalable fonts.

Possible solution:

I suggest to add two calls modelled after GdText() and GdTextSize() to the
screen driver, and only use the generic GdText() and GdTextSize() for bitmap
fonts...

At the same time, being able to set a flag to determine whether or not you
want antialiasing *if provided* by the font renderer would be nice :-) It
is trivial to implement basic antialiasing with T1lib (allthough it will
probably be slow ;)

It would be nice to support setting other flags too, like requested font size,
slanting, modes (italics, bold, underline, overline, strikethrough). Whether or
not the renderer or font supports the misc. modes could be indicated via
a query functions (which will *not* be something I write until I've got the
actual rendering with T1lib working).

I'm ready to write it, including an implementation that uses T1lib instead
of bitmap fonts, but I'd like some feedback first ;) I'll provide compile
time options to turn all of the T1lib support off, of course.

Any suggestions?

Regards,
Vidar Hokstad
Screen Media

Just a quick followup to myself:

On 19 Jan 2000 12:08:30 -0000 "Vidar Hokstad" ####@####.#### wrote:
>Possible solution:
>
>I suggest to add two calls modelled after GdText() and GdTextSize() to the
>screen driver, and only use the generic GdText() and GdTextSize() for bitmap
>fonts...

Of course there already is a call modelled after GdTextSize() :-) in the
screen driver: GetTextSize(), and also a DrawText() that is only used for
unclipped (totally visible) strings, so the change would be use a DrawText()
equivalent that supports clipping directly handle all text rendering.

Regards,
Vidar Hokstad
Screen Media AS

Vidar Hokstad wrote:

> I've started hacking support for T1lib into MicroWindows/Nano-X now.
>

I started looking at fonts too :-) (I'm full-time on this) But started to think
about freetype rather than t1lib mostly because:

- I wasn't correct in my previous E-mail saying that t1lib is smaller than
freetype, actually t1lib is ~360k and freetype is ~270k (these values are for libs
compiled with debugging symbols in, though)

- Freetype was coded mainly for embedded systems, so the code is as fast as
possible (it doesn't use floating point calculations, which is important for
processors without fpu, like  SA1100)

- Freetype 2 (which is beta but seems quite stable) supports adobe t1 fonts with a
new API that abstract the font type loaded (freetype 2 is bigger for this, though)

>
> First and foremost, my reason for ending up with T1lib instead of Freetype
> is:
>
>   - FreeType may have patent problems (ref: www.freetype.org)
>   - When searching for fonts, I found tons of redistributable (as part of
>      a commercial package) Type1 fonts, but mostly highly restricted Truetype
>      fonts (free for personal use only, etc.), and the few really free Truetype
>      fonts I found were fonts intended for logo design - that is, no "classic"
>      fonts...
>   - T1lib supports ligatures and proper kerning directly.
>

I found a good number of truetype fonts on the net but didn't look at licenses ...
will do it now...

>
> However, I encountered a problem:
>
> The low level screen device font functions has a *way* to constrained interface
> to do proper text handling.
>
> Some of the problems include:
>
>     - GetTextBits() doesn't support returning ascent or descent values.
>     - No support (or easy way of faking) kerning or ligatures.
>     - No support for drawing multiple characters at a time for font renderers
>        that support it.
>     - No easy way of adding features like anti-aliasing.
>     - GdText() is constrained to narrow fonts (less than 16 pixels wide?)
>     - No support for requesting font widths for scalable fonts.
>
> Possible solution:
>
> I suggest to add two calls modelled after GdText() and GdTextSize() to the
> screen driver, and only use the generic GdText() and GdTextSize() for bitmap
> fonts...
>
> At the same time, being able to set a flag to determine whether or not you
> want antialiasing *if provided* by the font renderer would be nice :-) It
> is trivial to implement basic antialiasing with T1lib (allthough it will
> probably be slow ;)
>
> It would be nice to support setting other flags too, like requested font size,
> slanting, modes (italics, bold, underline, overline, strikethrough). Whether or
> not the renderer or font supports the misc. modes could be indicated via
> a query functions (which will *not* be something I write until I've got the
> actual rendering with T1lib working).
>

Rotated fonts is a concern to me as well ... ;-)

>
> I'm ready to write it, including an implementation that uses T1lib instead
> of bitmap fonts, but I'd like some feedback first ;) I'll provide compile
> time options to turn all of the T1lib support off, of course.
>

Send me what you have as soon as it renders, I might change my opinion on the libs
issue  .... Still have some doc to read by then ...

Martin Jolicoeur
GVT Project
####@####.####

On Wed, 19 Jan 2000 07:56:37 -0500 Martin Jolicoeur ####@####.####
wrote:
>I started looking at fonts too :-) (I'm full-time on this) But started to think
>about freetype rather than t1lib mostly because:
>
>- I wasn't correct in my previous E-mail saying that t1lib is smaller than
>freetype, actually t1lib is ~360k and freetype is ~270k (these values are for
libs
>compiled with debugging symbols in, though)

My t1lib _without_ debuggin info is about 270kb.

>- Freetype was coded mainly for embedded systems, so the code is as fast as
>possible (it doesn't use floating point calculations, which is important for
>processors without fpu, like  SA1100)

Good point.

>- Freetype 2 (which is beta but seems quite stable) supports adobe t1 fonts
>with a
>new API that abstract the font type loaded (freetype 2 is bigger for this,
>though)

Do you know if Freetype 2 supports direct handling of kerning, and caching of
glyphs?

>I found a good number of truetype fonts on the net but didn't look at licenses
>... will do it now...

Good idea ;) If any of the truetype fonts you've found are redistributable 
with commercial products _and_ "classic" (I'm looking for basic fonts like
times, helvetica, courier etc.), I'd love some pointers - I like truetype
technology a lot more than Type 1...

>Send me what you have as soon as it renders, I might change my opinion on the
>libs issue  .... Still have some doc to read by then ...

I have something that renders now, but with some ugly hacks (hardcoded font
size, for one, and hardcoded color values ;).. I'll clean it up a bit, and make
a diff available ASAP (likely tomorrow).

I ended up doing antialiasing by default - it turned out to be easier to handle
than the non-antialiased call. Of course that makes it slower than it needs to
be, but it should be easy to fix the non-antialiasing code too.

Regards,
Vidar Hokstad

: The low level screen device font functions has a *way* to constrained
interface
: to do proper text handling.
: 

Yep.  It was quick, and it allowed Microwindows to stay
very small by basically treating text as bitmaps, and using
existing entry points (Drawpixel) to draw any color text,
with or without background.

Further, when the in-core font structure was developed, 
it took just the basic informationm, without ascent or
descent values, and stuck it into ram.

I've got no fundamental problem with enhancing text
output quite a bit, but I'd like to try to keep it small
for people that don't care as much, while still allowing
alot of functionality for those that can.  I'll comment on 
this following:



: Some of the problems include:
: 
:     - GetTextBits() doesn't support returning ascent or descent values.

We might want to agree on some additional "basic" values that
could be in every font, and add them.


:     - No support (or easy way of faking) kerning or ligatures.



:     - No support for drawing multiple characters at a time for font
renderers
:        that support it.

This is definitely a speed issue.  High speed text rendering will
require this.  Perhaps the current low level api should be extended
for strings now, instead of  a single character.  This, though, complicates
the internationalization storage format (UTF-8 vs UNICODE)?


:     - No easy way of adding features like anti-aliasing.

This could very easily be added as a g_antialias flag, much like
the g_usebackground flag.  In a future version, I wanted to have
all these global flags placed in the GC structure, and kept
per GC, rather than set before each window draw, as now.


:     - GdText() is constrained to narrow fonts (less than 16 pixels wide?)

This is fixed with a submission I received this morning.  I can 
fwd it to you, but basically, convbdf changed to allow any
input text width, and the stack-based maximum bitmap size
was quadrupled, allowing characters up to 48 bits wide. (this
is very easily changed)


:     - No support for requesting font widths for scalable fonts.

I assume you mean that you want to have the system scale
a font to a specific height/width?


: 
: Possible solution:
: 
: I suggest to add two calls modelled after GdText() and GdTextSize() to the
: screen driver, and only use the generic GdText() and GdTextSize() for
bitmap
: fonts...

This presents some big issues, although it's generally a good idea.
First, how will the low level GdText actually output it's dots?  If
it uses psd->DrawPixel and other psd-> routines, then it's probably
not a big problem, except for the clipping.  Now, we could add
the clipping routines to call as additional psd-> routines, so they
could be up-called by the low level driver.  My biggest concern
is that the low-level driver try to bypass the psd-> routines when
drawing.  If this happens, then you just broke all offscreen drawing
and blitting...  and we can't do that.




: 
: At the same time, being able to set a flag to determine whether or not you
: want antialiasing *if provided* by the font renderer would be nice :-) It
: is trivial to implement basic antialiasing with T1lib (allthough it will
: probably be slow ;)

Add g_antialias to the devdraw.c globals and have another
SetGC call to set/unset it.  This value can be passed to the
low level drivers.




: 
: It would be nice to support setting other flags too, like requested font
size,
: slanting, modes (italics, bold, underline, overline, strikethrough).
Whether or
: not the renderer or font supports the misc. modes could be indicated via
: a query functions (which will *not* be something I write until I've got
the
: actual rendering with T1lib working).

Strike my above comment.  Perhaps we need a "standard" font
description structure, that includes things like height, width,
slanting, modes, character set, antialias, etc.  Then, this structure
is filled in with defaults and possibly modified by other SetGC
calls, and passed to _every_ font routine, instead of just a font
number.  So essentially a font number (handle) can be used
to dereference one of these structures.



: 
: I'm ready to write it, including an implementation that uses T1lib instead
: of bitmap fonts, but I'd like some feedback first ;) I'll provide compile
: time options to turn all of the T1lib support off, of course.


Cool.  Take a shot at it.

Regards,

Greg

On Wed, 19 Jan 2000 13:38:18 -0700 Greg Haerr ####@####.#### wrote:
>: Some of the problems include:
>: 
>:     - GetTextBits() doesn't support returning ascent or descent values.
>
>We might want to agree on some additional "basic" values that
>could be in every font, and add them.

This would help, but wouldn't solve all the issues with libraries like T1lib,
since we would still loose the (very good) support for ligatures and kerning
etc., that improve rendering quality a lot.

>:     - No support for drawing multiple characters at a time for font
>renderers
>:        that support it.
>
>This is definitely a speed issue.  High speed text rendering will
>require this.  Perhaps the current low level api should be extended
>for strings now, instead of  a single character.  This, though, complicates
>the internationalization storage format (UTF-8 vs UNICODE)?

I suggest that GdText() is changed to use a low level function for drawing
strings in whatever encoding the font uses, and that any i18n support is
added in GdText() or above, so that the low level function doesn't have to
bother about those issues at all.

>:     - No easy way of adding features like anti-aliasing.
>
>This could very easily be added as a g_antialias flag, much like
>the g_usebackground flag.  In a future version, I wanted to have
>all these global flags placed in the GC structure, and kept
>per GC, rather than set before each window draw, as now.

That isn't the main issue. The main issue is that GetTextBits() return
a monochrome bitmap, while antialiasing with 2x2 or 4x4 subsampling require
either 5 or 17 colors. I got around this rewriting GdText() to not use
GetTextBits()... See below.

>:     - No support for requesting font widths for scalable fonts.
>
>I assume you mean that you want to have the system scale
>a font to a specific height/width?

I want the font renderer to scale it *if it supports it*. Whether anyone
wants to support scaling for bitmap fonts or not is another issue ;)

>: Possible solution:
>: 
>: I suggest to add two calls modelled after GdText() and GdTextSize() to the
>: screen driver, and only use the generic GdText() and GdTextSize() for
>bitmap
>: fonts...
>
>This presents some big issues, although it's generally a good idea.
>First, how will the low level GdText actually output it's dots?  If
>it uses psd->DrawPixel and other psd-> routines, then it's probably
>not a big problem, except for the clipping.  Now, we could add
>the clipping routines to call as additional psd-> routines, so they
>could be up-called by the low level driver.  My biggest concern
>is that the low-level driver try to bypass the psd-> routines when
>drawing.  If this happens, then you just broke all offscreen drawing
>and blitting...  and we can't do that.

I suggest that we require the low level renderer to use the psd->*()
functions or the Gd*() functions. My T1lib support now uses GdArea()
(since I use antialiasing, and T1lib can return something that works
with GdArea(), that was the easiest ;)

>Strike my above comment.  Perhaps we need a "standard" font
>description structure, that includes things like height, width,
>slanting, modes, character set, antialias, etc.  Then, this structure
>is filled in with defaults and possibly modified by other SetGC
>calls, and passed to _every_ font routine, instead of just a font
>number.  So essentially a font number (handle) can be used
>to dereference one of these structures.

I agree. We need to sets of attributes: The font attributes, which include
things like whether it's fixed or not, what size it has (if it isn't scalable),
whether it is a normal, bold, italics etc. font (some fonts come in separate
versions for each style), and the font family. In addition we need the current
rendering parameters, which ought to include the scaling factor (if a scalable
font), the current style, etc. The latter set could go in the GC.

We then need a function to query, with wildcards, for fonts matching a specific
set of font properties.

>: I'm ready to write it, including an implementation that uses T1lib instead
>: of bitmap fonts, but I'd like some feedback first ;) I'll provide compile
>: time options to turn all of the T1lib support off, of course.
>
>
>Cool.  Take a shot at it.

I have, and I can assure everyone that it looks *great* - the antialiasing 
makes the fonts look much better than it does with my X Windows setup :)
I'll clean it up a bit, and make a patch available.

Regards,
Vidar

: I suggest that GdText() is changed to use a low level function for drawing
: strings in whatever encoding the font uses, and that any i18n support is
: added in GdText() or above, so that the low level function doesn't have to
: bother about those issues at all.

My point here was that, if strings are to be passed as parameters, rather
than characters, then we have to decide now whether they're 8 bit or
16 bit strings...  TrueType uses UNICODE, IIRC, but also has
provisions for an 8-bit codepage index to unicode to be carried
with the font so that 8-bit glyph indices can be used.




: I suggest that we require the low level renderer to use the psd->*()
: functions or the Gd*() functions. My T1lib support now uses GdArea()
: (since I use antialiasing, and T1lib can return something that works
: with GdArea(), that was the easiest ;)
: 

Super.  I like that.  Someday GdArea can be sped up with two
planned improvements:  breaking up the clipped area into multiple
GdArea() rectangles, and having GdArea use blit for max speed.
Actually, Morten should be working on the former.  This method
also doesn't require getting involved with the clip code.



: >Cool.  Take a shot at it.
: 
: I have, and I can assure everyone that it looks *great* - the antialiasing 
: makes the fonts look much better than it does with my X Windows setup :)
: I'll clean it up a bit, and make a patch available.

Are you going to include T1lib?  Or should we pull it down and
compile it separately?  I can't wait to see the antialiasing...  Hopefully
you'll have a good demo ;-)

Regards,

Greg

Hello,

Greg Haerr wrote:
> 
> : I suggest that we require the low level renderer to use the psd->*()
> : functions or the Gd*() functions. My T1lib support now uses GdArea()
> : (since I use antialiasing, and T1lib can return something that works
> : with GdArea(), that was the easiest ;)
> :
> 
> Super.  I like that.  Someday GdArea can be sped up with two
> planned improvements:  breaking up the clipped area into multiple
> GdArea() rectangles, and having GdArea use blit for max speed.
> Actually, Morten should be working on the former.  This method
> also doesn't require getting involved with the clip code.

I'm on it, yes.

> Are you going to include T1lib?  Or should we pull it down and
> compile it separately?  I can't wait to see the antialiasing...  Hopefully
> you'll have a good demo ;-)

If I where to decide, I'd say bundle T1lib with the microwindows source
for two reasons:

 * Downloading separate products gets messy - and risk running into
   version conflicts when one product is updated more often than the
   other.
 * We may have to modify T1lib to make it more memory friendly, which
   may take a while before being accepted into the T1lib core, if at
   all.  Better have a 'microT1lib' than a reference to a version and
   a patch file...

Just my 0.50 NOK,
- Morten

: If I where to decide, I'd say bundle T1lib with the microwindows source
: for two reasons:
: 
:  * Downloading separate products gets messy - and risk running into
:    version conflicts when one product is updated more often than the
:    other.
:  * We may have to modify T1lib to make it more memory friendly, which
:    may take a while before being accepted into the T1lib core, if at
:    all.  Better have a 'microT1lib' than a reference to a version and
:    a patch file...

I'm going to suggest in the beginning that the microwindows ftp
site carry known working source tarballs of jpeg and T1lib, which
are (soon) used with Microwindows.  This will allow folks
to get everything they need (one stop shopping?).

If and when the libraries are hacked to support Microwindows
(hopefully this won't be the case), then we should include them,
or patches for them, with the Microwindows source.

Comments?

Regards,

Greg