World: r3wp

Presumably that is how it is done.  Divide into radicals, and further 
divide radicals into elemental strokes.

Graham. That's not how it is done. That's why the Chinese TTF file 
is so big, that's why in two chracters with the same radical, their 
radical part are not exactually the same pixel-by-pixel. These is 
a company doing so though. http://www.hifont.com/.

but you can add a scaling factor ..

and a direction

Scaling factor and direction? I am afraid I dont understand what 
you mean. Anyway, I don't really have time to do the font-compression, 
and it's not practical for me for now. I am trying to change my bitmap-based 
text-rendering REBOL/View component to a vector-based one. I hope 
the performance will not cause too much pain. Considering the complexity 
of Chinese font, the rendering performance is what I am worring about.

Guys, that's exactly the way I have done 'embedded font' in the quick-hack.r 
demo I reffered some time ago when talking about the fonts. Yes it 
is possible to make any kind of font that way. And yes, DRAW is really 
good as a 'optimal storage' of vectorial data ;)

Jerry, I think you can implement own 'bitmap cache' when rendering 
the text usng vectorial glyphs. The performace will be much better 
in that case.

how is the tiger demo done?
 Yes, it's just converted SVG file to DRAW dialect, nothing more.

Jerry, what about splitting each chinese character up in strokes. 
Each stroke should just be a number of points giving the position 
of the middle of the stroke from one end to the other. Like when 
a person draw the character with a pen. You start each stroke at 
one point, then you move your hand, sometimes fast, sometimes slow, 
until that stroke is finished. Then the next stroke and so on. The 
rendering engine can then calculate the thickness of the stroke at 
any time from the distance from point to point.

Geomol, you're describing the first version of Knuth's METAFONT :)

afaik it was then changed to just used bezier primitives (like draw) 
instead.

if pieces of the glyphs are the same, then why not just assemble 
them within several draw shapes? and then just draw more than one 
single shape?  the memory tradeoff would be significant, yet the 
speed would likely be almost identical

and there is no "tricks" involved.  no recomputation of the way things 
are drawn.

in any case, a way to automate this is pretty easy IMHO. just do 
drawing and measure the amount of pixels which overlap wrt previously 
defined recurring shapes.  generate a view app which shows the highest 
matches in order and then a simple yes/no to confirm.

in a short amount of time you surely will have a sizeable amount 
of the glyphs reduced to a few recurring shapes!

since draw can reduce words on the fly, this also reduces the actual 
draw blocks used to express the glyphs... again, a sizeable memory 
saver.

Cyphre, the bitmap cache is done. It improves the performance a lot, 
like you said.

Maxim, my idea is just the same as yours. I might just do that after 
what I doing is done.

And even better, I have collected the Chung-Jay code for every Chinese 
character. Chung-Jay can tell us what parts are in a character. I 
plan to use both Chung-Jay code and the pixel-matching method to 
speed up the analysis process.

In the VID area widget, what's the right mouse click used for?  Can 
that be used to trigger an action block?

I want to bring up a context sensitive menu

Graham, sure:

view main: layout [b: box 200x200 [b/color: red show b] [append main/pane 
layout [origin 0 box beige "Context Menu"] show main]]

Graham, ups. I didn't notice, you meant AREA.

New version with AREA:

view main: layout [b: area 200x200 feel [engage: func [f a e] [if 
a = 'alt-down [append main/pane layout [origin 0 box beige "Context 
Menu"] show main]]]]

I ruined the AREA engage function. You have to implement the original 
also. The source can be reached with:
layout [a: area]
e: get in a/feel 'engage
source e

Thanks .. I can work with that.

When drawing, I would like to translate the X to 0 and Y to ( Y + 
28 ). What the Matrix should be? Thanks.

I mean using the Matrix command in Draw, like MATRIX [a b c d e f]. 
The Matrix command would premultiply the current transformation matrix 
with the given block. What should I assign this block to translate 
the X to 0 and Y to ( Y + 28 )?

Forget about my previous question, I am not going to use matrix in 
this case.


For rendering cahracter images, I thought that relative-positioning 
could be a good idea. After drawing a character image, then shift 
(translate) to the next position, and the next character would be 
in the right position. So I made my draw block some thing like [ 
image char1-img translate rp1 image char2-img translate rp2 ]


It worked, but the rendering performance was slow, way too slow. 
So I go back to my good old absolute positioning. [ image char1-img 
ap1 image char2-img ap2 ]. No more "translate", no more matrix.

Do we need a "User Interface Style Guide"? It may be part of the 
wikibood. I came to think of it when revising some of my scripts. 
I often program the key "Q" to be used to quit my scripts. But maybe 
it should be <ctrl>-q to quit, like it is with AltME!? Then I thought 
about, if anyone of you has made a style guide regarding user interfaces 
in REBOL? REBOL/View is made for different platforms, each with their 
own style guides. Should we stick to those guides, so our scripts 
have to use different keyboard shortcuts on different platforms? 
No, probably not! A REBOL script should work the same across all 
platforms, I think. Then we need a "User Interface Style Guide", 
so us developers can stick to the standard when developing REBOL 
applications, shouldn't we?

*wikibook*

Geomol - such an userguide, would be usefull, because first all usage 
schemas would have to exist on the paper first. It would be clear, 
we first have to think, because it would be even clearer, that new 
VID without things like proper focus system, keyboard support, etc. 
- is a no go ....

I several times posted Gnome usage guide as a reference ...

http://developer.gnome.org/projects/gup/hig/

If someone make such a guide, it should be cleared with Carl, I guess. 
He probably has some ideas, and the wanted user interface should 
be within the frame of how REBOL work (and will work in the future).

I can't get this to work under OSX, so I want to know, if it works 
under Windows.

Does this example make the text position change when pressing the 
button?


view layout [button "Test" feel [redraw: func [face act pos] [if 
face/edge [face/edge/effect: pick [ibevel bevel] face/state] face/para/origin: 
pick reduce [face/para/margin + 0x1 face/para/margin] face/state]]]

it seems to change ....

Down one pixel? Try change 0x1 to e.g. 0x4 to better see the change!

yes ... I have small dot effect on my notebook LCD, so I moved text 
to align with it. I can see it really goes down certain amount of 
pixels

LOL this is really strange! I can get the text to move, if I change 
the position more than 0x1. 0x4 works, so does 0x2. Strange!??

Here under OSX, the text doesn't move, if I only tell it to move 
0x1. I'll report it somewhere.

it definitely seems to move even 0x1 under W2K here ...

maybe OS-X uses two pixel precision ;-)

or isn't kind of font antialiasing on OS-X, which can "blur" it?

The text is rock solid here when using 0x1. Using 0x2 moves it one 
pixel down.

geomol, noticed the menu bar in the viewtop? looks like it's the 
same thing.

the first item is sitting a pixel too high.

Just noticed. Weird!

Sounds like a font rendering bug.

wonder if the cursor bug is also related. on OSX the cursor is sitting 
1-2 pixels too far to the right.