Subject:
Re: Scalable font support ...
From:
Morten Rolland ####@####.####
Date:
15 Mar 2000 18:03:12 -0000
Message-Id: <38CFDC2F.7CB5367C@screenmedia.no>
Hello,
Greg Haerr wrote:
>
> : I've been working on supporting Truetype fonts for microwindows for
> : awhile now (through freetype lib) and i'm proud to say I now support
> : truetype fonts with kerning, antialiasing and even rotated fonts ! I
> : also support multilanguage with utf-8 encoding (I have been able to
> : display chinese and japanese text, so anything's possible).
>
> Fantastic.
Me Too! :-) We will have to provide unicode support as well, so that you
support UTF-8 allready is amazing and encouraging to our own efforts
in the same area - thanks Martin!
> : The FONT structure will need to be modified in such a way that
> : characteristics will be different according to the font type. So It
> : should be something like this:
> : where FONT_TYPE could be BITMAP, TRUETYPE or TYPE1, ...
> : and "data" will be a structure cointaining data pertaining to the
> : different types:
> :
> It would be nice to have a larger common hdr, IMHO. The FONT
> struct really only buys us use for the upper level routines. The lower
> level routines coming from T1 or FreeType won't be using this
> structure, right?
A void * is probably a bad idea in a user API. If we need a struct, it
will have to contain all (usefull) information for all fonts supported.
Maybe it should have a bitfield for capabilities, or at least a well
defined set of values that indicate that the value is N.A. ?
Personaly I'd like to see a set of functions that hides all the
details as much as possible and provides a set of functions
suitable for the applications no matter what kind of
font we are using (The new font API should be able to handle the
old bitmapped fonts as well, for small systems BTW)
> : FONTID should be changed to be a pointer to such a structure, so that
> : when loading a font, we will return a FONTID
>
> Yes. The name should be changed to MWFONT for the struct,
> and PMWFONT for the pointer.
Am I right in assuming that this font structure can be handeled by
a numeric FONTID wrapper in Nano-X of some sort?
> I just finished changing all RECTs
> and POINTS to MWRECT and MWPOINT for portability
> reasons with other projects...
Thanks, this is good news!! How about the min/max macros - can we
toss'em out too? :-)
> : void GdFontSetPath(char* path)
> : FONTID GdFontLoad(char* filename)
> : void GdFontUnload(FONTID font)
This is a kind of administration that should or could be
automatic, as a client app don't want to mess around with
details like path/file-names (think of portability
between different architectures). I don't want *my*
applications to have to do this, at least.
One reason: If opera hard-codes font paths and font-names
into their application, people will hate them for it.
Another: Dynamic loading/unloading will be able to meet
a given memory usage level, at the expense of speed.
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.
So increasing the level of abstraction is probably a
good idea here.
> : void GdFontSetAntialiasing(FONTID font, BOOL aa)
> : void GdFontSetKerning(FONTID font, BOOL kern)
> : void GdFontSetSize(FONTID font, int ptsize)
> : void GdFontSetAngle(FONTID font, int degrees)
> : void GdFontSetPalette(FONTID font, PIXELVAL[] palette) /* For
You may want to include stretching of fonts for the
esthetically bewildered...
The 'SetAngle' function; will it specify slanting of
individual characters, or rotation for the entire
rendered string? (I could use all of 90, 180 and 270
degrees rotation - also handeling anything inbetween
is acceptable too:-).
> Do each of these routines just store some member in a FONT struct,
> or do they end up calling a low level font driver? If they
> don't call a low level driver, perhaps all these calls could be handled
> with a single struct, and a single call to GdFontSetCharacteristics...
> Comments?
For selecting fonts, how about:
PMWFONT = GdSelectFont("bitstream","Times","bold","italic",16,...);
I can have a talk with the font experts at Opera to discuss what is
nice and what is not so nice WRT CSS1 on the web.
> : GdText will probably have to be modified too ... It is currently using
> : GetTextBits & GdBitmap but wouldn't it be better using the new drawarea
> : driver ? It is currently only implemented for 16bpp but I will need it
> : for fonts with the operation PSF_HAVEOP_COPY with transparency
> : (mandatory for rotated fonts)
>
> The drawarea routine needs to go away, both Morten and I agree.
> Basically, the new architecture wants to use the blit routines to perform
> the different functions, with the function passed in the "op" parameter.
> We've now got ROP_SRCCOPY and ROP_CONSTANTALPHA
> implemented. I can fairly easily add ROP_TRANSPARENTCOPY
> to get the transparent blitting that you need for all bpp values.
>
> Do you require any other specific function from the 16bpp drawarea
> routine? It's basically a [transparent]blit that you need, right?
Basically, all of the functions from 16-bit DrawArea should be merged
with the blitter and used for fonts. The reason for this is that you
may want to handle fonts different based on size: You don't want
to do antialiasing with very big glyphs, as this eats memory (and adds
little to the percieved resolution), so the optimized pixmap is needed
for this, for example.
I will work this out with Greg, and what will probably happen is that
there will be GdArea support that the font renderer can call for
optimized operations. Or maybe there will be a different version
that supports alpha transparency. Having to set up a memory
target for each rendered text is a bad idea IMHO, so I'd like to
continue to use GdArea for this. It also performs clipping very
nicely. It is the psd->DrawArea that needs to be merged with
the blitter at a low level, agreed?
> : GdText would draw differently according to the type in the font
> : structure ...
>
> My idea is that it would call a screen-driver dependent font drawing
> routine, and pass the PMWFONT to that driver, along with the
> struct with the font characteristics.
Where would clipping be done, then?
Regards,
Morten Rolland, Screen Media
