World: r3wp

This is not directly AGG's fault, since it might simply expecting 
different outlines for its rasterizer, or its not rasterizing the 
exact same way for which the outlines are expected to be used.

I am  not criticizing the work from the R3 team, far from it, but 
trying to provide a little bit more depth on the issue.

right now, AFAICT, the team is using the known and working solution.


when the actual artifact source is totally understood, I am sure 
steps can be done to improve the final output.

Just discovered: R3 doesn't use the same method for doing its font 
rendering as R2, it uses AGG instead. So it doesn't have the bug, 
and can be further improved.

Finally got some usable fields again:

http://rebol.hmkdesign.dk/files/r3/gui/230.png

Now for some deeper testing of the resizing system.

Fields were not useable before? :-)

the resizing system changes completely broke them. you couldn't see 
what was typed.

http://rebol.hmkdesign.dk/files/r3/gui/231.png

:-)

Very nice!

Woohoo! Congratulations to the team.

That Tibetan script looks hard to read ...

The typographer had poor handwriting.

If you look at the sample here http://www.omniglot.com/writing/tibetan.htm
the script seems to start from just above the top line and drops 
to the bottom with some accents above.

This is a screen shot from the Moscow tibetan OCR project http://www.buddism.ru///ocrlib/OCRLib21_07_2010.png

Again the text looks very different to that in Henrik's image

I guess we need to see what it is supposed to look like :)

And I thought you were being funny. Different baseline logic? I can't 
say.

It just looked different to what I've seen before posted to the OCR 
mailing list I subscribe to.

Doesn't mean it's wrong though!

Hmm, now that you say it. The vertical alignment of the Arabic also 
looks a bit off.

I don't' read Chinese either but there doesn't seem to be any spacing 
between the words

Jerry's console script looks a lot better too but it's traditional 
Chinese http://rebollovesjerry.blogspot.com/2008/03/rebol-30unicode.html

Chinese is a heiroglyph based system so there needs to be spacing 
between each word ...

BTW, the "Chinese" script looks more like Korean or Japanese ...but 
I'm no expert

we are coming to the opinion that what is said to be Chinese is actually 
Japanese...

You're right

That is actually Hiragana -  a Japanese syllabary

Good job we didn't let this error propagate ... otherwise we might 
get 1billion complaints!  :)

Actually, when I looked at the katakana showed here, i felt something 
weird (yeah, back in the time, I learned them)
I couldn't remember the 5th one.
then, I checked (http://fr.wikipedia.org/wiki/Katakana)
Eh ! Right in the spot. (Wi) is not used anymore.

Cool - that is kind of milestone for View apps - finally being able 
to display more than one charset :-) As for spacing needed, that 
is not problem of View unicode support, or is it?

Kerning .. who's responsibility?

and tracking

Hey guys, don't be so picky ;) about the test text strings. I only 
cut'n'pasted random chars from some of these pages http://www.alanwood.net/unicode/#links
that's all.

I personally don't plan to spend time on all the 'unicode normalization' 
and other tricky stuff and details. It seems there is enough linguistic 
experts even for tibetan script! So I'll kindly left that part as 
an exercise to the comunity :-P

OK, and what can be done to get more quality to the font display?

BTW, the "Chinese" example is taken from this http://www.alanwood.net/unicode/cjk_compatibility.html
which should be chinese/japanese/korean. I'm really not expert in 
this(nor I would like to be) so I just hope I haven't created any 
offending word from the random chars in some of the language :)

so, it's all a mixture :)

what can be done to get more quality to the font display?

 I personally would make research about the technique McSeem(AGG author) 
 published in his well known font rendering related article and tried 
 to use the core idea of his demo application for making 'production 
 quality' version which can be then used in the HostKit code base.

How does the baseline get set?

I'm wondering if the Tibetan baseline should be at the top and not 
the bottom

cyphre... seems like the best plan, for the best quality font rendering 
on any platform  :-)

Graham, sorry, I really don't know the rules how code points in Unicode 
should be positioned. That needs to be studied and corrrections being 
made in the text rendering/layouting loop. Just a note, even now 
the text rendering/layouting code ismore than 50Kb of C++ code so 
either someone needs to study all the Unicode rules and make new 
replacement or publish patches to the current version.

oh well, at least it means omeone from tibet can study the C++ source 
:)

Maxim, yes I agree. But currently I have plenty of other tasks with 
higher priority so unles something changes this needs to wait or 
someone else needs to contribute.

So, does this mean these chars render inside a text field and we 
can backspace, del etc?

Graham, teeling the truth I'm glad I can write Czech chars properly 
(yes I'm selfish in that case :)) and I don't care about the details 
of oter scripts unless I need them ;)

But seriously, even if you don't know C++ it should be theoreticaly 
even write own positioning of the chars in the RICHTEXT dialect at 
Rebol level.

yes, all these chars are treated as any other chars in the RICHTEXT 
dialect so you can format it, select, edit.

so where can we download this?  :)

I guess all these gfx changes will be part of the next official HostKit 
release.

font quality code - that will have to be done one day, as the View 
app font quality is really not nice. So let's hope that one day it 
will move up in the priority list :-)

(I still need to do a few changes before handing it over to Carl)