World: r3wp

Yes, of course

Any idea why we do not receive key up events? It should be supported 
according the source code.

Not directly related to R3, but an example how MorphOS guys aproach 
using LUA as a system language extension (AREXX replacement). It 
might be interesting to compare for those, who plan to integrate 
R3 to other systems - http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=32945&forum=28

When I build R3A110 and use text in view, the text is invalid. It's 
valid only if I provide it as UCS2, like:  g_text: make gob! [size: 
100x20 text: "^(41)^(00)^(42)^(00)"]

Does anybody (except Cyphre, who is not here) know, what can be wrong? 
I build it with CodeBlocks.

The problem is related to the graphics part only as I can use text, 
even with czech chars, correctly in the console.

I wonder how much differ the RM-assets' host-kit from the latest 
Carl's one.

Has Unicode support been added to R3 Graphics yet?

It is in the Rm's binary release.

That's great news.

If RM want more people to join the GUI development, they should sync 
the host-kit with Carl.

Our release is more advanced as the official one from Carl. As our 
changes are merged into the offical version from time to time. We 
move forward with our branch.

advanced WRT to the graphics & GUI stuff.

Isn't it possible to provide your version as well?

It's available from www.rm-asset.com

I mean the source of course.

fine... I've found that the text must be bound to the text extension 
context.. this works:
ext-text: import 'text
g_text: make gob! [size: 100x20 ]
g_text/text: bind [
	;bold true
	text "AB"
] ext-text


The question is, what is changed in RM's version that it works without 
such a hack.... I have no problem to hack just the official A110 
version so far as I'm trying to understand how the internals work, 
but I really think that we need synced source repository ASAP.

Is there a way how to force REBCHR to be in multibyte format? Because 
the problem for the above issue is at this line:

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

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!