Re: Pre-announce: GraphicFont

Hello Kevin,

Here are a few questions and a few comments to your Java
font implementation.

>	One of the first Java barriers I came up against was the fact
>the developers only have a choice of three or four internal fonts:
>Times, Helvetica, and a system (monospaced, I think) font.

It looks like it is more or less the intersection of the fonts
available on all systems. With a few heuristics, I guess
this could be increased quite a bit. An average PC or Mac
or Unix workstation all have a rather identical set of fonts
due to the use of PostScript printers.


>Frankly, they
>suck, and doing Java things with those fonts is not inspiring at all,
>and any applet you see out there just looks like bad HTML extensions,
>since everything uses the same fonts. Also, if you specify certain fonts
>in Java, they end up looking slightly *different* on different platforms.
>This is no good.

They will look different if you use a CRT or a LCD display, if these
devices have different resolutions, and so on, even if they are
exactly the same bitmaps. Indeed, in some cases, fonts are optimized
for various display devices, and especially for printers (have a
look at what Metafont does in this area). Although I think that
the differences you see are not necessarily of that kind, you
shouldn't damn such differences from the beginning.

>	Well, I've hacked a solution, and I've got working code!
>	Basically, I've made a near drop-in Java Font/FontMetrics class
>replacement, a little class that anyone can incorporate into their Java
>app/applet. I call the class "GraphicFont".
>	Here's how it works:
>
>	1. A bitmap font at a certain size is encoded into the
>	   GraphicFont format. Basically, this means going into
>	   a program like Photoshop and typing out all the letters in
>	   the font in a strip. You could include international characters,
>	   etc. but for now I'm only using standard U.S. keyboard chars.
>
>	   The letters are separated by vertical lines, and leading,
>           descent, ascent, etc. information is encoded as RGB values in
>	   the upper left corner of the image. It doesn't know anything
>	   about kerning, since I don't know how to implement it.
>
>	   The image is saved as a GIF, so it ends up being pretty small.
>	   For instance, a 48-point font is about 9k, and 12-point fonts
>	   are usually around 1k.

Using RGB for metric information has the problem that even if you
have a bilevel (and not a grayscale) font, you will have to spend more
bits per pixel for all the pixels in the GIF. This may not be very
efficient in the long run. Also, as far as I know, GIF is not 24bit
(or 32 bit if you include alpha-values) and so I don't understand
exactly how you can use RGB in that way.

>	Here are some issues I'm working on:
>
>	1) So far I've made fonts of Gill Sans and Gill Sans Bold in
>	   various sizes and am planning to make many more. What is the
>	   legality of using Adobe bitmaps for this project? What about
>	   using fonts like Arial, Espy Sans/Serif, Garamond?
>
>	   I am planning, BTW, to make this code and technology
>	   freely available for any use.

No problem with your technology, as it is yours to share or keep.
But please be careful about the fonts. Font designers are working
on their products for a living, and don't really like their stuff to
be distributed without permission. Due to some pecularities
of US law, distributing bitmaps may be acceptable in the US,
but other countries, in particular Japan and Germany, have much
more strict laws in this area, and there is also an international
treaty on font copyright. This may definitely affect the usability
of solutions such as yours, that of Paul Haeberli, and others.
Things that are not usable world-wide should not become
core parts of the world wide web :-).


>	3) How can I support things like kerning? Is it worth going
>	   that extra mile?

With the resolutions possible on screen, kerning is really not
that much of an issue. That changed dramatically if you want
to go WYSIWYG and print things.

>What about internationalization?

Now that is really an important issue (it's the world wide web,
anyway), and it affects fonts and stuff quite heavily. And in its
core, Java already handles characters as Unicod (16-bit) values,
so a solution should really care about this. For a short
summary, these are the most important issues:

* Rendering logic is needed for many languages. Don't think that
you can map a character one-to-one into a font and then just
put the glyph (in this case a bitmap) you found there on the screen.
This is in particular true for Arabic and all the scripts of South-East
Asia. There are ways to do this in a flexible, object-oriented way
so that ideally, you can just use DrawString without any special
settings, but you can also change something if you want.
Anybody who is more interested in this topic, please drop me a line.
I can send you a paper I have written for last year's Unicode conference.

* Some fonts are bigger than others. A Japanese font in a reasonable
size can easily be 500k or more. Not very much fun if you have to
wait for it. A basic font (or a combination of fonts for the various
scripts) should always be in place, and maybe used to display text
before a more specific font arrives. Splitting up the font in more
convenient pieces and loading it on demand may also be a good
idea. And finally, in many cases, it might be easier to load the text
as a GIF in the first place instead of transmitting each character
in a GIF and then having all the decoding overhead. (of course,
this is not appropriate for interactive applications).

Anyway, the Java team is aware that they have to do something
in this area, and as far as I know they started serious work on it.
I hope they are successful.


Regards,	Martin.


----
Dr.sc.  Martin J. Du"rst			    ' , . p y f g c R l / =
Institut fu"r Informatik			     a o e U i D h T n S -
der Universita"t Zu"rich			      ; q j k x b m w v z
Winterthurerstrasse  190			     (the Dvorak keyboard)
CH-8057   Zu"rich-Irchel   Tel: +41 1 257 43 16
 S w i t z e r l a n d	   Fax: +41 1 363 00 35   Email: mduerst@ifi.unizh.ch
----

Received on Tuesday, 20 February 1996 14:56:56 UTC