Subject:
Re: Scalable font support ...
From:
Morten Rolland ####@####.####
Date:
16 Mar 2000 09:57:51 -0000
Message-Id: <38D0BBF9.68CBAD95@screenmedia.no>
Martin Jolicoeur wrote:
> How & when would you load font files then ? Through a "database" text file
> mapping IDs, names and font files ?
Yes. It should be possible to add to this list, but for my
application, I don't want 3rd parties to mess with the standard
font repository or the naming convention they use. I would
prefer a config file that the Nano-X server reads, and functions
to extend the standard configuration. I think X11 is too
dependent on the applications to make good font choices for
its own good.
> > Another: Dynamic loading/unloading will be able to meet
> > a given memory usage level, at the expense of speed.
>
> I agree. I understand that in your case you can't do that since a web page can
> come up with any/many font faces.
> But in my case, I know that I will use, say, only 3 font files in the
> application. So I can load these fonts at boot time without any speed cost ...
> See ?
Yes. I think our ideas are the same; the application asks for
a certain font (a handle), and the font is available for use
until it (the handle) is freed. If the Nano-X server (in my case)
has to flush caches, reload files and render multiple times while
the font handle is still valid must be OK so that memory usage can
be controlled.
> > Another: When we move to unicode, we will have to use
> > several physical font files and a mapping table to handle
> > things well (e.g. when we select an underlined italic
> > courier font, chinese should still come out as
> > chinese, although there may be no font(s) with
> > underlined italic monospaced chinese glyphs in it...)
> >
> > I think it would be much better with centralized
> > configuration and a standardized set of font-names.
>
> How do you see this ?
We would have to pick glyphs from the fonts that best suits
the face that was selected for the character that needs
rendering. We need tables to solves this problem, mapping
from
(unicode-range,foundry,family,weight,slant)
=> (physical-font,mapping-table)
> With truetype fonts, we could use what is called "the postscript name" embedded
> in the file to name the font. But since you abstract the font technology behind
> that, what would happen if you have, say, times.ttf AND times.pfb in the font
> path and you specify GdSelectFont("Times" ...) ?? Will it choose the truetype
> one or the postscript one ?
If the application does not specify a foundry, the configuration file
is consulted (as always) to resolve this, and it may as Greg suggested
select one or the other depending on size. It may even select bitmapped
fonts for the smallest sizes if this turns out to look best!
> And where would you take the font name if the font
> is a bitmap font ?
We obviously have to name them first, then no problem. You will
not even notice, going from bitmapped to outlined or back, except
for quality. The bitmapped fonts can be explicitely asked for
through the foundry parameter (e.g. foundry=bitmapped, family=times).
> Also, in truetype technology, stuff like bold and italic specify different font
> files, not just different font rendering. Ex: times.ttf timesb.ttf, timesi.ttf,
> timesbi.ttf respectively for times normal, times bold, times italic, times
> bold-italic .... It can't be properties of the same font name ...
I may have used wrong words when explaining:
The font *family* is Times with different properties. When
selecting a font, you thus have
foundry,family,weight,slant
This is taken from xfontsel as I'm no expert in this field. The
characterization of fonts in X11 is probably correct, It is how
it is used that I'm not too happy about.
The fact that some implementations put the data into different
files (or everything in the same file) should be of no concern
to the application.
The fact that there probably is no standard way to name
font files, I think this is a good example why we have to abstract
away the ugly implementation details imho. Otherwise we would
have problems switching between comercial and free fonts
transparently:
The application should allocate fonts without specifying foundry
unless absolutely needed (like for symbol fonts etc.). This way,
we can say that "OK, Times is adobe" when licensed, and something
else when we don't have a license.
I'm not sure if using the word "times" is a violation of adobe
rights in itself, probably is. In that case we may have to be
inventive and come up with alternative names. But this is only
for the configuration files and the naming convention selected
(different users of microwindows may settle for different
naming conventions that or OK to their own use).
> You have to
> change the font file each time... If you don't handle font loading/unloading by
> hand in the app. , it could mean a real mess for the middle-layer engine in
> managing font filenames, the way you specify it ...
Yes, but I don't expect it to be easy. I'm prepared to rewrite
quite a lot in T1 to make it more memory efficient and force
cache rotation in a much more precise way than is implemented
now to make it run reliably in a tight spot. This means we have
to be able to suspend a font or parts of it to make room for
the task at hand right now (another font). I can't trust swap
space to save my ass at a speed penalty, as there is no such thing.
I have to solve the memory problem myself, also at a speed penalty.
Regards,
Morten Rolland, Screen Media
