World: r3wp

so see assuming fixed fonts is a global concept is a wrong thing 
it better to say ok font will be not fixed lets handle this properly 
and offer a way to manage them the easier way...

we needed to know the size of the letters displayed on screen because 
first of all in R2 when you call 2 times a text instruction the rendering 
at piled up at same place and not disposed one after another on the 
X axis with natural spacing... so draw [ text 10X10 "a" text "b"] 
renders a "b" over the "A" and not "A" followed by "B". And it's 
logical ... text instruct was then designed to handle a serie a letter 
or several series of letter organised in distinct block we can call 
words... but you see that concept doesn't fit with the need of having 
an interaction anytime with any letter componing the words.

and in the richtext proposition of Carl made 2 years ago (times flyes..) 
we find again this block concept wich is related to the way MakeDoc 
format handle things ...  like in HTML  for example you have flags 
that defines a rendering style. But the things betwin the flags can't 
evolve... they are not supposed to change font style or font size 
or font color. See that's what i would call a we treat text as block 
and not as single element able to singularly evolve on their own 
without affecting the surrounding elements.

ofcourse you still can say a <H1> </H1> instead of the basic regular 
seting will take this font this color this size but that will affect 
all it's content and not only a part of it ...

and then if you want to have an atomical approach then MakeDoc dialect 
becomes too verbous to be efficient... like in HTML more you want 
stylised things more you pile up flags and more you have problems 
debuging and having a direct acces to your raw document content... 
So it's clear that a real design have to be set for this richtext 
even if in the end rendering html or MAkeDoc or makeDocPro  with 
that dialect means a conversion stage.

that's why the proposition of carl to have an open flag system was 
cool ... he presented it years ago as a variable inside draw dialect 
to hold styles ... And i think people didn't see the good points 
in this approach ...

Any reference to this concept?

The idea is that we will have the low-level font rendering stuff 
accessible. Further a standard richt-text dialect will exist. If 
htis doesn't fit, you can change it and use any other concept to 
make richt-text available in apps.

The low-level part won't change.

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

Text now works in hostkit.

ugly as always though

But I know, not the time for such arguing

correct

And be sure I appreciate your efforts to terminate the job.

Great news Henrik. Thanks for posting.

Cool. But those fonts still look kind of terrible :-)

Because it's not pixel precise font. I would like to see support 
for pixel precise font which could be in just a simple bitmap format.

the font handling has not changed, AFAIK

So what's left for 1:1 full View transition? View effect pipeline?

Cyphre hasn't talked about that, but that is probably next. I don't 
know exactly how many parts are left.

Carl is continuing with callback development, which now requires 
an expansion of the event queue mechanism.

(that's all I know about that)

cool info ... on callbacks :-)

Steeve is shorter than me and but ruder than me :)  ... Steeve ....

Because it's not pixel precise font.
 That's absolute nonsense.

but steeve have a point ...  it's ugly ... i don't know if that the 
antigrain thing but on the lower size fonts damn the rendering of 
the font is messed up ... you have on the same letter bigger and 
smaller parts... This was a problem we experienced on R2 too we noticed 
it. People said don't worry R3 is completly deferent etc... and in 
the result -> blured ugly fonts... like on R2  so wher is the gain 
?

shadwolf for the 56743892th time, the font rendering is not properly 
utilized from AGG yet,

I appreciate the effort too ... but when i say this part needs a 
real work that's not to be rude etc... that's true !! damn how can 
i provide a simple functionnality like Zoom + / - for text if bellow 
font-size 14 bold the font rendering is ugly ?

Henrik ... when will it be properly supported ?

when it gets important enough to fix. right now the priority is to 
get things working in the first place. we have an app to build and 
sell.

being properly supported means working that part serriously ... so 
when will that day come ?

I don't know, shadwolf.

When it's done.

yeah so one day eventualy that's not how things should be done but 
that explain many things...

Actually, that is the way things should be done. 1. Make things work. 
2. Make the working things pretty.

shadwolf: if font rendering quality(or whatever else)  is so critical 
for you I think with R3 you have couple of options now:


1) wait until you get it for free (some day) while bitching at AltME 
about it
2) download the HostKit and improve the code yourself

3) pay(or overpersuade or whatever) someone else to improve the HostKit 
for your needs


So it looks you have at least 2 more ways(besides the 1. point) how 
to solve it comparing to R2 situation. Isn't that great?

shadwolf: Take option 2 and send us the code, we will integrate is 
ASAP.

If AGG (or R2) was relying on the OS font rendering, the behavior 
shadwolf decribed could be caused by Cleartype. If Cleartype is turned 
on, but the REBOL renderer isn't rendering with compatible antialiasing, 
fonts would look bad.

They would look even worse if the fonts were being rendered with 
antialiasing, but not the same antialiasing that Cleartype expects. 
Perhaps some rendering options aren't being used?

people often mistake rasterizing and outline generating process. 
  there can be bugs in both steps which affect output.

there can also be some side-effects between the outline generator 
and expected rasterizing process.

MS for example, dosesn't properly typeset its font.  The historical 
reason being that their fonts are very sharp and readle on low dpi 
monitors.


If that is a problem of the outline generation, the rasterizing or 
both is up for grabs but, its possible that we can get better results 
if we "fix" one or both of the problems.

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

:-)