World: r3wp

maybe using freetype 2 embeded like gtk+2  does in pango could be 
an help in that behavior

I have Windows 7 running locally, so the next version of R2 will 
run on 7.

maxim exactly and even the linux rebol VM renderise same font from 
same font file in a different way  and the fixed font caracter is 
not kept at all all fonts become unfied like magic and some time 
along the document produce wrong spacing information

as brianH noted yesterday using freetype has some licensing issues 
which might not provide the best looking fonts when compared to OS 
rendered fonts.  but maybe AGG could render the fonts with coordinates 
given by freetype.

Don't know yet whether the current version does though.

yeah that's what is frustrating i can only say this works in those 
case it doesn't in that case

i'm sure  inwindows 7 the fixed fonts that turns to unfixedfont by 
magic is due to some unsuported instruction from win32 API emulator 
in winFX

cause rebol actually doesn't speaks the native vista/seven windowing 
API language it speaks the deprecated win32 API ...

there was no problem in vista that I remember.

strangge cause the lucidana consol fixed font just doesn't works 
on seven

Lucida Console?

yes

i tested even forcing rebol to use the tff file from windows XP  
and that produced the same sizing bug 

all the text motion turns around the idea you don't have much to 
care about each char size in pixel since it's always the same you 
do a size-text call on "MM" only when you change the font size (growing 
the text shrinking it) and that's all if we had to care about the 
rendering of each elements in the texts that woud be a real pain

we would have a draw/text call for with precise sizing for each and 
every char  making the draw block cliped to our area-tc/effect/draw 
a gigantic size

hello word imagine it as text 0x0 "H" text 0x10 "e" text 0x15 "l" 
text 0x17 "l" text  0x19 "o" and each time you have to retreive the 
precise size (an hash table could be done with char => real_pix_size) 
but then you need anyway a good way to retrieve that size in formation 
being sure it's not a wrong information and size-text  doesn't works 
well on char from unfixed fonts

and we are not even speaking of unicode OMG lol

man when i will have to deal with the sizing of chars in chinese/unicode 
my head is going to blow

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

Wow, seems like lot's of work, but maybe not. The nice thing is, 
that sometimes few lines of code might make big difference in the 
end ....

I would like Cyphre to devote 5-10 days to core engine. E.g. transparent 
windows (not absolutly necessary for initial release, just an example) 
is just question of setting particular bit for API call, at least 
under Windows. I would like to see - Unicode, better fonts, cached 
gfx (we don't use bitmap caching yet), eventually switch to AGG compound 
rasterizer, some draw suggestions being implemented - so much for 
a low level ...

Shadwolf - you are too quick on your reactions, you pretty much remind 
me of .... myself :-)

Shad: I complained a lot about unview. It has to take some parameter. 
So Unview none, Unview my-win, Unview 'all .... but - what is a big 
deal? Just type help unview in console ;-)

Shad: as for text, you forgot we have got rich-text. Dunno if usefull 
for your purposes, but I just want to remind you of that ...

http://www.rebol.net/wiki/Text
http://www.rebol.net/wiki/Rich-text

font rendering not taking advantage of AGG i'm completly agree since 
anti aliased doesn't works properly but this should be the time on 
that particular area to see the font rendering area under a new line 
of real time text processing and their is alot  of amazing things 
to be done . 

in the end my request is simple i want my users to choose their own 
font they like on any ot the main OS brands and get the same result 
everywhere (even on online editing for example imagine the rebol.org 
integrating viva-rebol thrue rebol3 webrowser plugin  to allow the 
script sumiters and owner to share editing of a script with bunch 
of select people. That's the qualité we should aim for.)

when you talk about layer that means interfaction a visual area with 
extern library rendered visual contents ?

like cliping a video or a opengl/direct 3D rendered area to a vid 
box.

Pekr can we still keep win32 15 years old kid as base for VID  on 
windows plateform on a middle term  (5 more years) won"t it be better 
to start right now to support winfx enhancement and use part of the 
hardware acceleration in rendering?

Layers are just separate layers of gobs. That's all.

i feel  like this being focused on too many targets ( OSes where 
VID exists) make you loose from your sight what are the real interrest 
in coding on one particular OS among the others ..  wanting to be 
too much generic and too few specific gives a bad image to your product 
(that's my own opinion)  if you see port of  other libraries like 
GTK+ or OPEngl  they are ported to act the same way but they include 
 to some very specific plateform related obtimisations and functionalities. 
this should then mean the guy that need a basic set of instruction 
to quick to interfaces GUI forms to a database then rebol crossplatform 
 abilities will allow him to just don't care where his program runs. 
But in some high level area  optimising is 90% of your task  and 
it's a constently evolving task . If we want to bring rebol and VID 
to the Guru level to a solution that make people considere it serriously 
and not like another freak toy for freak kids then it's  obvious 
that area have to be digged up and brought to rebol too

rich-text is read only spécific rendering  based on a specific markup 
language... since we are not talking about the same goal ( i want 
real time text edition (read and write) and the hability to create 
extend or change the rendering process to feet not only colorize 
text but any kind of tet rendering with high performances and simplicity 
of code writing. area-tc is just the first step in that process it's 
just  a proff to show that VID and most largely rebol concept can 
bring to that area. But there is still alot of work to do and that's 
normal initially VID and draw were not designed to handle such duties 
and the tricks we had to use to achieve that goal in R2 only showed 
us the limitation of the existing. So what we do do we evolve to 
chase that area or do we just try to redo again a limited R2  version)

then i think ritch text is based on an old idea replaced by a more 
powerfull one....  based on area-tc way to work redoing the richt-text 
area to bring in it the write cncept is not impossible to be done. 
and what better way for a user to use a markup language not knowing 
you use it (MS word and all other advanced tet editing tools does 
that constently. from RTF to PDF)

and wysiwyg interfaces are the best ones for regular users

you have your wysiwyg tool you write your documentation you push 
a button to generate the documents and store it then you do a view 
[ doc load %./data/doc.mdp ] and that's all

you gained alot of time you absolutly don't care what is MDP liking 
like all you see is the document you created is rendered the properway 
exactly as you created it in your creation tool.

rich text is the internal specification, all your tool has to do 
is create the rich text block based on your desired looks.  rich 
text isn't meant as an output or an exported format.

yes but that's still read only

that's thinked to render help documentation in your own GUI  software 
that's not thinked as a document writing tool. you have to use an 
external way to easyly create large formated documentation without 
having to keep in mind the over all markup language

Shadwolf, no, rich text in R3 is also writable. there was a bug a 
while ago that would let you unintentionally edit parts of the DOC 
style. We are just missing parts for logical control of the cursoe 
between different styles in the text and text selection across styles.

that's true of any layout engine.  if you look at pdf.. it actually 
doesnt include any text layout algorythms.. those must be built externally. 
 all pdf does is display vectors where you tell it to.

When I showed it to Carl, he was surprised it worked. :-)

maxim i already long time ago worked in the Markup document creation 
tools with ashley MDP-GUI  and one of the limitation was that you 
could not create the markup data and the at same time see the rendered 
result at same time you had to use 2 separated boxes one for rendering 
the other for "scripting the document"

R2 doesn't have any rich text you can direct.  which means you have 
to do all of the layout work manually.  as long as we have sizing 
examination of rich text atoms, then we can tell it to position things 
like we want and measure the result in order to properly convert 
the data to other formats.

yeah but anyway markup had another conversion stack wich would be 
better to be done directly to draw dialect. and i'm not sure the 
markup language doesn't imposible limitations that will not allow 
you to go out of the box.

i read the scrip it speak to draw directly hading the conversionn 
to markup layer since it's not thought for that purpose will had 
a delay to the engine. I really need to speak directly to draw. that's 
all

you must realize that the format  of a document (encoding of the 
layout) isn't directly  tied to its content.

basically the rich text dialect looks alot like what you are doing 
manually... all its missing is better analysis of its rendering results, 
IMHO.

it will be much faster, since much of the heavy lifting is done in 
binary rather than interpreted code.

as long as you can detect what word is under the cursor at a given 
 coordinate using specified scrolling, you could use the rich text 
directly.  and then output to whatever format you want... as long 
as you can predermine how all the coordinates map in both systems. 
 This last part is what just about every importing/exporting out 
there tries to get just right... but in the end, its never exact 
because coordinate systems are different, font rendering engines 
don't use the exact same algorythms, etc, etc, etc.

in R3, all text is rich text, but you don't notice that, since it's 
only really taken advantage of in a few styles.

cool.