openglean-devel

[openglean-devel]Font support.

[Richard R. <sf...@ol...>]

I've been fiddling a bit with the gleanfonts genfonts program and
compile.sh which runs genfonts.

One thing that I've more or less decided, for the near term, is
to try to fill out a a fairly useful set of basic fonts at various
uniform sizes, with bold, italic, and bold-italic versions at
each resolution.

There are a few things on my mind:

 * Eventually, I want to redo the font API to work in model
   space for all fonts.  (Bitmapped fonts will then become
   textures.)  At that point, only a few actual font sizes
   would be built into the library (probably about 3 sizes),
   with mipmapping.  Since the bitmapped fonts are presently
   blitted into the graphics area, however, I think that
   a large set of sizes is presently called for.

   This is just a heads-up both about the addition of new
   sizes coming soon and that those sizes will likely
   be replaced by textures.

 * It turns out that using the genfonts program, some
   fonts (e.g., TimesRoman) are available in "italic" form but not
   "oblique", while others (Helvetica) are in an "oblique" form
   but have no italicized version.  The difference between italics
   and obliques is that obliques are just slanted, while italics
   tend to be a little curly.

   I am undecided if I should try to retain the two different
   modes.  Opinions?  I'm inclined, for simplicity's sake,
   to use italicized typefaces where I can, and where no italics
   exist, use obliqued typefaces and just call them "italics".

 * Italics and obliques, by virtue of slanting, bring a new
   aspect into issue.  In most fonts, you have an origin
   of the letter and a distance to advance the origin (cursor)
   after rendering---but the character is permitted to use some
   space to the left of the letter.  Basically, italics and slanting
   can mess up horizontal spacing.


The upshot is that adding new fonts to the library should be
difficult, but making a good API for using the fonts properly
will bring some new issues.

For today, I am content to expand the font set, and I already
planned to overhaul the API anyway.  But I thought that I'd
toss this out for anyone to discuss.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Font support.

[varol k. <var...@gm...>]

Nice coincidence! As part of looking into using OpenGLEAN as a basis
for a GUI I was also looking at way to use nice looking (antialiased +
kerning) fonts. I think that everybody agrees that textured fonts are
the way to go. Right now I have a way to automatically generate
textured fonts from freetype2 (on the fly, precompute and embed into C
source or save in a specialty format (subset of BDF + extensions)).

  Some questions that come to my mind are:

1. Do you want all the fonts to be embedded into OpenGLEAN (as they
were in GLUT) or do you want to be able to provide external fonts as
separate files? (I have mixed feelings about this, maybe a
well-defined set of embedded fonts + ability to load extra)

2. Do you want any dependencies like freetype or do you prefer an all
home-cooked solution with the minimal amount of external dependencies?
(I assume you don't want external dependencies, right?)

3. Do you want to support stuff like Unicode, left-to-right or
top-to-bottom scripts like chinese, arabic and japanese? (I would not,
it is just too complicated to do right. But the API or internals can
be designed to make it easy to implement later)

Varol Kaptan

P.S. I attached a test screenshot for amusement and the generated
texture. The font is Vera at 16 pixel height.

On 9/17/05, Richard Rauch <sf...@ol...> wrote:
> I've been fiddling a bit with the gleanfonts genfonts program and
> compile.sh which runs genfonts.
>=20
> One thing that I've more or less decided, for the near term, is
> to try to fill out a a fairly useful set of basic fonts at various
> uniform sizes, with bold, italic, and bold-italic versions at
> each resolution.
>=20
> There are a few things on my mind:
>=20
>  * Eventually, I want to redo the font API to work in model
>    space for all fonts.  (Bitmapped fonts will then become
>    textures.)  At that point, only a few actual font sizes
>    would be built into the library (probably about 3 sizes),
>    with mipmapping.  Since the bitmapped fonts are presently
>    blitted into the graphics area, however, I think that
>    a large set of sizes is presently called for.
>=20
>    This is just a heads-up both about the addition of new
>    sizes coming soon and that those sizes will likely
>    be replaced by textures.
>=20
>  * It turns out that using the genfonts program, some
>    fonts (e.g., TimesRoman) are available in "italic" form but not
>    "oblique", while others (Helvetica) are in an "oblique" form
>    but have no italicized version.  The difference between italics
>    and obliques is that obliques are just slanted, while italics
>    tend to be a little curly.
>=20
>    I am undecided if I should try to retain the two different
>    modes.  Opinions?  I'm inclined, for simplicity's sake,
>    to use italicized typefaces where I can, and where no italics
>    exist, use obliqued typefaces and just call them "italics".
>=20
>  * Italics and obliques, by virtue of slanting, bring a new
>    aspect into issue.  In most fonts, you have an origin
>    of the letter and a distance to advance the origin (cursor)
>    after rendering---but the character is permitted to use some
>    space to the left of the letter.  Basically, italics and slanting
>    can mess up horizontal spacing.
>=20
>=20
> The upshot is that adding new fonts to the library should be
> difficult, but making a good API for using the fonts properly
> will bring some new issues.
>=20
> For today, I am content to expand the font set, and I already
> planned to overhaul the API anyway.  But I thought that I'd
> toss this out for anyone to discuss.
>=20
> --
>   "I probably don't know what I'm talking about."  http://www.olib.org/~r=
kr/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your ver=
y
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> openglean-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openglean-devel
>

Re: [openglean-devel]Font support.

[Richard R. <sf...@ol...>]

Sorry for the length of this.  I've batted around font ideas for
a while, so this is kind of a core-dump of everything that is
currently in my head.


On Sat, Sep 17, 2005 at 02:19:37AM -0500, Richard Rauch wrote:
 [...]
> The upshot is that adding new fonts to the library should be
> difficult, but making a good API for using the fonts properly

...err, should NOT be difficult.  (^&


Varol: I can't reply directly.  Your initial email had the appearance
of an administrative request, to SourceForge (I'm not sure why).
After I approved it, it was marked with an invalid tag by SourceForge's
own spam-filter, because of the way SourceForge handled the email,
so it got rejected at olib.org.  So I can't directly see, or reply
to, it---I can only read it on the SourceForge list archive.

Nor can I see the screenshot that you attached, since the archive doesn't
include those.  Maybe you can put it up somewhere on the web and post
a URL?


To answer your specific questions:


1. I think that some more embedded fonts are a plus, so that the library
can guarantee certain fonts will be there, without the application having
to burden itself with font files, etc.  Whether the font data is physically
in the main library or is in a well-known file that is shipped with the
library is not so crucial.  But as I think that the number of fonts that
should be guaranteed makes a small set, I don't think that it hurts so
much to have them in the core library.  But I also think that the ability
to access extended fonts is essential (more than just whatever is included
with the library).  More on that below.  (^&

2. I want to avoid hard dependencies such as on freetype.  I think that an
interface to something like freetype would be nice.  And to TeX fonts, etc.

3. Yes, Unicode support and right-to-left rendering are desirable.  I do
not know these areas well, but I want to permit it.


Font support has been discussed before in other forums for extending a
GLUT like library.  Here are my thoughts:

 * A relatively small number of guaranteed fonts that are always with
   us is useful.  The past couple of days, I implemented part of an
   old API proposal, cowritten with others, which called (among other
   things) for the 14 Adobe PDF fonts to be added in certain common
   sizes.  I was unable to readily get three aspects covered:
   The fonts are all ISO-8859-1.  The "ZapfDingbats" font is not
   available.  The size 36 version of the fonts was not available in
   a way that I could extract with the current tool.

 * No pre-defined set is going to be sufficient for everyone.  There
   needs to be a way to access both "system" fonts and application-
   specific fonts.

   I do not intend to put all of the thousands of fonts from XFree86
   or X.Org into the library, much less to start harvesting other
   font libraries.  But clients should have access to whatever
   fonts the user has on their system.

 * I think that switching to a string-based font identification scheme
   is best.  The string should encode some basic things about the font
   (size/resolution if bitmapped; character set; whether bitmapped or
   stroked; ...).  The basic things may not uniquely identify the
   font, but should allow one to determine some characteristics about
   the font.  The string name would also encode a source of the font,
   and a unique id within that source (e.g., a "system" font on X11
   could have the X11 font specification string).

   One virtue of the naming scheme is that it would let you search
   for a font such as "helvetica" and see if any font in the system
   had such a name.  "The" Helvetica may not come in the size that
   you want, but there may be another Helvetica that is better
   suited to your needs.

   Perhaps more importantly, it provides a way for a user to guide
   a program to find fonts that may only exist on their computer,
   and which in any case the core library has no reason to know about.

 * I'm currently leaning towards the idea that a "font" would be
   handled as a collection of functions (or function-pointers---think
   callbacks for client fonts; (^&) that are tied together under some
   identifier.  Something vaguely like this, perhaps:

    my_font = gleanfontCreate ("whatever my font is called");
    gleanfontDrawFunc (cb_my_font_draw);
    gleanfontDrawStrFunc (cb_my_font_draw_str);
    gleanfontWidthFunc (cb_my_font_width);
    gleanfontWidthStrFunc (cb_my_font_width_str);
     /* ... */

   The core library could be smart enough to say "To draw a string,
   if there's a string-drawing function, call it directly; if there
   isn't, then call the single-character function in a loop.  So it
   would not be necessary to provide all callbacks for every font."

 * Extending this idea a little, a font repository could be another
   collection of functions that manage an interface to multiple fonts
   organized and accessed in a particular way.  This lets us define
   a library with old-style fonts, then wrap a font-repository layer
   around it that uses the same callbacks for every font in the library.
   Then another (very different) wrapper could be put around freetype.
   And another around TeX.  Etc.  The wrappers themselves would have
   a standard interface.

   These "layers" can be separate shared libraries that are explicitly
   loaded.  This way we avoid building knowledge about TrueType (for
   example) into the library, avoid forcing one to have (for example)
   freetype installed to compile/use the basic library, and still allow
   one to use (for exaple) freetype to access (for example) TrueType
   fonts.



As you can see, I've thought about it a bit.  I hope that some of
my thinking has been productive.  (^&

I would welcome: Ideas, critiques of any of the above ideas, and
actual code.  In code, I'd like to avoid hard dependencies on
external libraries such as freetype.

What I've done up to this point has been an incremental extension
of the basic fonts to a couple more typefaces and more sizes (and
more uniformly populating the available sizes).

I have not at this time put Unicode support into the library, but
I suspect that if I changed the X font identifier name that I pass
to specify the ISO-10646 character set for some of the fonts, we'd
have unicode.  I haven't done that partly because I didn't want to
embed *that*much* data into the library.

And, too, I think that proper Unicode support will mean modifying
the core API (right-to-left, top-down support).


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Font support.

[Richard R. <sf...@ol...>]

Varol:

I've been looking at your code a little more this morning.  It
looks like you only read characters in the range 0..255.

Have you given much thought yet to supporting large character sets?
I'm inclined towards the idea of reading font glyphs more or less
on-demand, rather than reading the entire font at once.  The
difficulties are in finding where as-yet-unread glyphs begin and
in rapidly finding glyphs in memory after loading.  (Allocating
pointers to all possible glyphs in a big array and filling unloaded
ones with NULL is probably not a very good solution; even for 16-bit
Unicode, on a 32-bit system, that's a quarter of a MB of pointers
for every font...)

I'm thinking of some kind of hash approach.  Take a sequence of
primes, where the Nth prime is approximately 2^N.  Take the glyph
number mod by the prime table size  That would be the primary
location for already-loaded glyphs.  As the table fills, reallocate
and re-hash.

For unloaded font glyphs, some kind of sparse array could be
used to locate known places in a font.  For example, after reading
the font glyph for 'a', you would know the location of 'b'.  (Well,
maybe not.  I am not sure if BDF files are necessarily presented
in the order of the glyph encoding.  But in most, if not all, cases
you will probably be better off to start searching for 'b' right
after 'a', I suspect.  (^&)

Additionally, perhaps loading up to 8 or 16 glyphs at a time
might be good.  If you need the Latin 'a', the chances are pretty
good that you'll need 'b' before too long.  (But for languages
like Chinese, I don't think the odds are so favorable.)


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Font support.

[varol k. <var...@gm...>]

Dear Richard,

Sorry for the late reply. I had to go to a place (conference) with no
email access and stuff like that.

On 9/30/05, Richard Rauch <sf...@ol...> wrote:
> Varol:
>
> I've been looking at your code a little more this morning.  It
> looks like you only read characters in the range 0..255.
>
> Have you given much thought yet to supporting large character sets?

Well, one of the reasons that the current bdf subsystem is a hack is
because supporting unicode/etc the right way is difficult. If you want
to support unicode then you have to be much more careful.

> I'm inclined towards the idea of reading font glyphs more or less
> on-demand, rather than reading the entire font at once.  The
> difficulties are in finding where as-yet-unread glyphs begin and
> in rapidly finding glyphs in memory after loading.  (Allocating
> pointers to all possible glyphs in a big array and filling unloaded
> ones with NULL is probably not a very good solution; even for 16-bit
> Unicode, on a 32-bit system, that's a quarter of a MB of pointers
> for every font...)

I completely agree with the "not reading the whole font at once". Some
fonts out there are huge! As you noticed, the current bdf subsystem
design is not adequate at all (on purpose, to make things simple).
There are other things that are not working properly, like kerning or
calculations for proper string dimensions/extents which I plan to fix
when everything else is more settled down.

> I'm thinking of some kind of hash approach.  Take a sequence of
> primes, where the Nth prime is approximately 2^N.  Take the glyph
> number mod by the prime table size  That would be the primary
> location for already-loaded glyphs.  As the table fills, reallocate
> and re-hash.

hmm ... I am not sure about the hash thing. Unless carefully done, the
hash may turn out to be bad. We'll have to look at the occupation
characteristics of unicode planes ... there may be a better (easier)
approach. Special attention should be taken to make sure that the
common cases run fast.

> For unloaded font glyphs, some kind of sparse array could be
> used to locate known places in a font.  For example, after reading
> the font glyph for 'a', you would know the location of 'b'.  (Well,
> maybe not.  I am not sure if BDF files are necessarily presented
> in the order of the glyph encoding.  But in most, if not all, cases
> you will probably be better off to start searching for 'b' right
> after 'a', I suspect.  (^&)

I don't think that this is a good idea (too complicated). I would go
with something like this: make an API to let the library know which
parts do you want supported (latin1 + latin2 + latin5, or even a UTF-8
encoded string with all the characters that you will be using) and
then when you load a font, it will load only those characters. After
all, it will be the user who knows best. I can see, though, that your
approach is more transparent.

> Additionally, perhaps loading up to 8 or 16 glyphs at a time
> might be good.  If you need the Latin 'a', the chances are pretty
> good that you'll need 'b' before too long.

Incremental loading? I am not sure it is a good idea. The BDF format
is not designed for random access. You will have to scan through most
of the BDF each time to get to what you want. The BDF specification
does not seem to require that the characters are presented in order.
Not to mention that the encoding can be different too. While it is
true that 'b' follows 'a' is true for english, it is not necessarily
true for other languages (in turkish, 'c' is followed by '=E7' which is
nowhere near 'c' in the encoding, for example).

> (But for languages like Chinese, I don't think the odds are so favorable.=
)

I'll have to check with my chinese friends :-)

Varol