Subject:
Re: New Microwindows font support
From:
Morten Rolland ####@####.####
Date:
20 Mar 2000 11:50:53 -0000
Message-Id: <38D61C4B.94929669@screenmedia.no>
Greg Haerr wrote:
>
> After an _extremely_ lengthy weekend, I have now
> got both TrueType and Adobe Type 1 font support
> integrated into Microwindows. Release 0.88pre4 is
> available at:
>
> ftp://microwindows.org/pub/microwindows/microwindows-0.88pre4.tar.gz
Thanks!
> Support for ascii, unicode-16, and unicode-32 is completed,
> allowing text to be supplied from applications in these formats.
> UTF8 support is almost supported, but we need a non-LGPL
> version of a utf8 to unicode-16 converter.
It should not be much work to put one together from scratch, we
also have a library with these functions from IBM, that has a
relaxed license, but it may be incompatible with MPL. Do you want
me/us at Screen Media to write this function? Please suggest
function prototypes, I can suggest this for starters:
int utf8_to_unicode16(char *utf8, *unicode16);
Return number of characters converted, or -1 if UTF8 contains
illegal (non-minimal) sequnces (recomended by standard).
In addition, a function like:
int utf8_to_scalar(char **utf8)
Could be usefull to parse a UTF8 string, both to the function
above, and any operation that needs to identify a single
character with a single value.
> There is still some work to do in GdArea, which I will start
> rewriting soon, as the alphablending and transparency blitting
> are not performed at the driver level yet, so the antialiasing
> only works well when you know the final destination color.
> The plan is to implement two new low level blitters that the
> font renderers can use, one for alphablending and the other
> for transparent blitting.
The code in psd->drawarea has support for both alpha-blending
of an image with a separate alpha map, and alpha blending with
a uniform coloured image, e.g. use the output from T1 etc. as
the alpha map and specify the foreground color.
In order to merge the image+alpha function into the blitter,
there is a need for two source arguments, both pointers; one
to the image and one to the alpha map.
How does it sound to adopt the driver_gc_t concept from
psd->drawarea into the blitter? Periodically adding new
parameters to the blitter will be frustrating as there are
so many places where it is called and the parameter list
needs to be updated. With a struct, this is not needed.
For some operations, like clipping large images, the
driver_gc_t or similar can be set up with its general
values once and for all, and then only update the
coords when blitting the rectangles of the image.
Having void * in the interface is also not a good idea imho,
as you loose out on typecheking PSDs and other (which was
suggested in a previous mail IIRC). I suggest having:
typedef struct {
PSD dstpsd;
COORD dstx;
COORD dsty;
COORD w;
COORD h;
PSD srcpsd;
void *image;
unsigned char *alpha;
COORD srcx;
COORD srcy;
} blit_args_t;
And feeding the op-code to the blitter directly so it can
switch on the opcode right out of the argument list:
void linear16_blit(int opcode, blit_args_t *args)
{
switch ( opcode ) {
case BLIT_COPY:
blit_copy(args);
return;
case BLIT_AREA:
blit_area(args);
return;
....
As I have said before, I think this would be a very clean way
to implement the blitter, and very easy to extend - but it will
requre a few things:
a) Good documentation on the various blitter opcodes (what
variables in the blit_args_t is used, and for what)
b) Rewriting all the places that uses the current API to
use the new one.
I would be glad to help out on both these issues if the added
work of converting would be a problem for its implementation.
Please give feedback.
> * renamed min/max to mwmin/mwmax
For opera, there was also a conflict with the RGB() macro, but
this may be part of the win32 api that microwindows try to
emulate, so it needs to be there?
My patches for the nano-X protocol problem had one small
problem; in certain situations, the loop in GrServiceSelect:
while ( GrPeekEvent(&ev) )
fncb(&ev);
Would not terminate. Removing this loop lets other clients
wake up an do their things and it all seems to calms down
after that.
So, please remove this loop from the async patch when it is
applied, which I hope will be soon as nano-X is not reliable
without it. Thanx.
Regards,
Morten Rolland, Screen Media
