World: r3wp

You can define it when you create a REBSER string, but a character, 
I don't know

Doesn't REBCHR refer to an internal format?

Yeah, I don't think I've seen it anywhere

The extensions use u32 for a character

Yes... but AGG requires multibyte. Probably. At least I can display 
gob with non ansi string like:
	g_text: make gob! [size: 100x20 text: "èøž"]
but not:
	g_text: make gob! [size: 100x20 text: "crz"]

If text is needed in a different format, you have to convert it somehow

Multibyte will always need to be multibyte. The question is what 
sort of multibyte

AB
 = "^(41)^(00)^(42)^(00)"

As Kaj says, that just means that there needs to be a conversion 
step in there somewhere. R3's internal character format is supposed 
to switch amond UCS-1, UCS-2 and UCS-4 in theory, but in practice 
might just be UCS-2 all the time (haven't checked lately).

There must be easy way... for example to check the RMA's source :)

Sounds like it's configured for Windows UCS-2

I'd be surprised if AGG couldn't work with UTF-8, and that wouldn't 
be the default on Unix

I can only test on Windows at the moment, so I don't know how it 
behaves on other platforms.

It would also be very useful if the Amiga patches were incorporated 
into the host kit

They probably use UTF-8

That might also require some conversion, but at least then the conversion 
would be there to use. R3 uses UCS for strings internally for speed 
and code simplicity, though strangely enough words are stored in 
UTF-8 internally, since you don't have to access and change words 
on a character basis.

R3 uses both, single-byte by default and multi-byte if needed.

Windows uses UTF-16 for its APIs, not UCS-2, so by using UCS-2 R3 
is limited to the BMP codepoints.

Good to hear that the UCS-1 to UCS-2 autoexpansion is still there. 
We don't have the UCS-4 expansion supported yet though.

Is UCS-2 sufficient for Chinese?

I don't know, but know that I need wchar at this point and don't 
have it:

https://github.com/rebolsource/r3-hostkit/blob/f331c6a46947e6e5afedc90f3d375bcd3f7ad8a1/src/agg/agg_truetype_text.cpp#L696

Yes, I think so.

(to Kaj)

I must dig deeper.. the solution is visible even with the Carl's 
version as I can see the text using draw... it's like solving a puzzle...:)

The BMP should cover most stuff, but there is a whole supplemental 
plane dedicated to more obscure asian ideographic scripts, and some 
of those might come up in Chinese language eventually.

It's still an ongoing issue, as many asian nations don't like each 
other very much, so commonalities in their character sets are often 
controversial.

I've found it.. rich-text is doing the conversion here:

https://github.com/rebolsource/r3-hostkit/blob/f331c6a46947e6e5afedc90f3d375bcd3f7ad8a1/src/os/win32/host-graphics.c#L714

The question is, how to use RL_GET_STRING if I already have REBCHR 
instead of REBSER.

Also isn't it REBOL's week spot if we need so much text manipulations? 
At least for international languages?

For example the CMD_TEXT_TEXT command is called on each mouse move 
event (redraw).

It is not a REBOL-secific weak spot. All programming languages have 
to deal with Unicode issues in some way or another, and every means 
of dealing with it has its good and bad points. Any cross-platform 
language will run into a little difficulty if it has to interact 
with the platform-specific Unicode APIs, because different platforms 
deal with the problems in different ways.

REBOL-specific

Mistake - extensive ansi text will be affected as AGG is using widechar, 
each ansi string which we want to display in view must be converted 
to wchar on each redraw!

It could be fixed if we could change the ansi string to unicode and 
store it for later use.. I'm just a C newbie, but I don't think it's 
how it works now.

Does AGG have separate 8bit and 16bit rendering APIs or is it always 
one or the other?

I think it has only 16bit.

But I'm not so far to be sure.

If it is UCS-2 or UTF-16, then all that would need to be done is 
to convert UCS-1 model R3 strings to UCS-2 mode somewhere before 
rendering. (He says glibly, having not analyzed the AGG sources or 
APIs.)

I'm still guessing this only applies to AGG on Windows, using UTF-16. 
On other platforms, AGG uses FreeType, and I guess that would accept 
UTF-8

Submited it to CC http://curecode.org/rebol3/ticket.rsp?id=1814so 
Carl could answer eventualy.

I think the file you're looking at is not really part of AGG, but 
written by Cyphre as a bridge between AGG and Windows

I know. But it does not solve the issue.

The issue is we have to wait for the Amiga patches, which should 
constitute the bridge to FreeType systems

Also I'm not sure REBOL is using UTF-8 internally, I think it has 
only ANSI or UCS2

No, as Brian says, it's using fixed width vectors internally. You 
get UTF-8 only from conversions

which means that FreeType will be affected as well.

Yes, we knew since the Unicode epic that we would need conversions

But for each redraw? The conversion is fine, if is only one.

That can be cached

The text conversion is actually a minor matter. Code points also 
need to be converted to pixel glyphs, and heavy caching is always 
used there to arrive at usable performance