Subject:
Re: New Microwindows font support
From:
"Greg Haerr" ####@####.####
Date:
20 Mar 2000 18:58:17 -0000
Message-Id: <001201bf929c$bd8310a0$15320cd0@gregh>
: > 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:
:
Morten - I would definitely like to take you up on your
offer of writing a conversion function. Why don't you look
at 0.88pre4 engine/devfont.c, and see how the function
currently is performed. I have written a basic function
for conversion in any direction between ascii, uni16, uni32,
and utf8:
GdConvertEncoding(void *istr, int iflags, int cc, void *ostr, int oflags)
it returns the number of new-unit-sized characters in the output
buffer.
Your utf8 conversion would be called by this routine. I'm more
than happy to include any other utility routines, like your
proposed utf8_to_scaler, but all that Microwindows needs
(we want to try to keep it small and fast) is the above routine.
It would be nice to have conversion to and from utf8 to uni16,
as well as ascii, with the provision that non-translatable
characters get translated to a predesignated, say '?' character.
This allows utf8 to try to be displayed on small microwindows
implementations where only ascii output is available, while still
keeping utf8 as a std input text format.
As you will notice, GrText now takes a TF_ flag parameter
which desribes the text data format.
: 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.
yep, exactly. I'm starting to work on this now.
:
: 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.
I will steal your idea and use a struct.
:
: 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.
I'll put together the first round, and then I will enlist your
help for rewriting the 16bpp blitters.
:
: > * 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?
:
RGB could be removed, but I would prefer to keep it. Most
other items I have renamed.
: 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.
I was deep in thought trying to get the font stuff in so that you
and Martin could move fwd, and decided not to apply the
patch without testing. I will apply the patch for the next
pre5 cut, after I have had a chance to thouroughly understand it.
Regards,
Greg
