World: r3wp

Sure but I'd think there is some font engine inside what solve this, 
or are we writing the font engine from scratch?

Hinting have mainly influence in rendering of "Stems" simplified 
it means all vertical lines will be the same width in my Ailal font 
I,L,M letters at some resolution. Having nothing to do with spaces 
between letters. Kerning is what is for inter letters spaces bussiness.

Pavel, yes, you are right. We switched the terms in the discussion 
above. I've been  mainly refering to this informaiton: http://en.wikipedia.org/wiki/TrueType#Hinting_language


AGG have kind of font manager module. The font manager basically 
takes vectorial glyph data (which are provided by Win API or FreeType 
lib, quartz etc.) then the glyphs are converted to scanlines and 
stored in font cache...

So this way we are depending on the vector glyph data provided by 
platform specific font frameworks.

The problem lies in the fact the hinting language(see link above) 
is patented by Apple so it is not possible to get the correct font 
glyph data without breaking the patents (or paying Apple).

That's the reason why fonts on Linux or FreeType based platforms 
can't look so nicely hinted as on Windows/OSX.

How much is that Apple license?

Any chance we can use this? http://www.antigrain.com/research/font_rasterization/index.html

Brian,
Apple licence cost: I don't know.

the link: I hope we'll be able to use it but it would need some more 
research work.

http://www.mail-archive.com/[fedora-fonts-list-:-redhat-:-com]/msg00879.html

Did it expire?

It should be expiring quite soon. All that started back in the '80s.

Is there any easy fix to trap Control-C in a text field ... so that 
it doesn't kill r3?

cyohre i noticed the glyph engine years ago in AGG C++ version and 
i asked at that time why that wasn't existing in view adaptation

and got never an answer (well that's not the first)

cyphre unfortunatly  win32API is abandonned on vista and  seven (widows 
6 and 7) so the font rendering is not good look at the picture here 
that shows the differences

http://my-trac.assembla.com/shadwolforge/wiki

fyi, I must say I seem to recall having cursor positioning issues 
on XP also in area-tc.

maxim ?

as far i tryed on windows XP area-tc lastest was working perfectly

though I haven't played around with the latest versions...  and its 
been a very long time, so it could be that I tested it just before 
my vista install crapped out.

but the true thing is windows XP have  10  years now it's more than 
deprecated OS. If the font probleme on R2 cant't be solved ok i'm 
ready to wait other year to get a R3 draw/font relation working perfectly 
everywhere. The lessons of area-tc are:

1)

1) it's possible

1) it's possible for AGG to deal text rendering evolved at a low 
level (perf are great  on R2 and that's convincing)

2) Since draw wasn't made to handle such an extensive use of the 
draw/text instruction  in R3 we have to make the AGG mode adapted 
to block of text handelling the first idea and the main  boring thing 
to have to deal in AGG text rendering is the positioning of every 
block of text. We need a way to retrieve the position of a texte 
on screen.  

3) to be better and faster AGG should be less verbose. I know that 
it's possible to save lot of space in the draw block

4) the font system should be able to used every where

I think we just spend our effort on R3

Shadwolf,

re glyph engine in R2: The glyph manager is used inside DRAW dialect. 
But the internals were never exposed at the REBOL laguage level. 
Should I really explain why? I hope not.


R3 text improvements: As I wrote week ago here to you on AltMe there 
are no limits for you to make it happen. You can already build your 
own font engine+dialect in C/C++ or whatever and use it as EXTENSION 
for prototyping your contributions. If I was able to protoype using 
R2 dll interface you have now even more possibilities. So where is 
the problem?

Regarding the XP vs VIsta and 7 issue:

I'm repeating it again. If you are able to see the bug, then please 
give us something more that screenshot or long confusing posts...trace 
log file with the differences in returned values or whatever,  simple 
clear example proving that the error is really in carret handling 
native functions....That would really speed up possible bugfix or 
at least clarify the issue. Is it so hard to understand this?


Hope my words doesn't look rude. I want to help you as much as I 
can...we seems to have just some disconnect here.

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

Maybe it's even possible to mix the current and simple "add action 
to widget" pattern with such a event based system.

I have used such an approach in one of our apps.For example I have 
three tables, that depending on the app state, show different columns 
and data. So, when app state switches this will trigger the change 
of the tables.


And other example is changing the language just where you are. No 
need to re-enter the current GUI etc. There will be just a change-lang 
XY event send.

Wasn't Max proposing a message passing gui in one of his various 
liquid thingies?

liquid is a message passing engine, but its complex to use in guis 
as-is.  it can be done (as I shown a few times) but requires a dialect 
or api over it to manage it.

just to make it simpler to use in real world use.

the advantage is that its a generic engine... and can be used to 
link up any aspect of an app. not just its "actions"

for example, right now, in my pain application, if you replace the 
bg-image of the canvas, it refreshes the whole software on its own. 
 the size of the canvas, the crop bars, image properties and input 
management offsets, etc, etc.

but in this app there is no dialect of api beyond the shape/graphic 
element management.

so its not readily obvious just how much goes on in the application 
without following the links in the code.

this app will be released this week.

no pain no gain

I think we just need to finish R3 GUI as Carl started it (VID 3.4). 
We might think about some by Max proposed enhancements to Draw, making 
GUI kernel more powefull, and let's see, where it leads us, before 
we start to think about another overhaul. Msg passing concept is 
surely interesting, but it imo creates another layer to implement, 
understand, to work with, so I am just not sure, unless I see the 
currently implemented solution does not allow us to easily work/extend 
the GUI.

exactly what I think.  keep it simple for now... once liquid is revamped 
for R3 we can see how I can make a module to add it so view 3.4, 
just like I did for view R2.

by Draw enhancements above, I mean proposal by max, making it "first 
class citizen", so removing the overhead of draw dialect ... but 
that is for gurus to think about :-)

see msg 8-Jan, 15:34

Carl's original goal for the GUI was to make it so a child could 
use it. We should not deviate from that goal. That's part of what 
Rebrowse is meant to do. I don't want to risk a forking of the GUI 
work.

I don't mind advanced features at all, but we must be careful not 
to make the GUI difficult to use from the outset or having to place 
the user into a specific mindset, when starting to learn it.

there is VID and there is View.  we must not sacrifice the later 
for the former.

exaclty. I think that VID3.4 is designed in a good way, let's first 
see, if the architecture provides us everything we need ...

to me VID always very easy to use.  making it pretty & dynamic ... 
well that's a bit (a lot ;-) more painfull.

I think it's possible to make it strong for industrial strength applications, 
without making the usability a hindrance. I also wouldn't want to 
lose the ability to write a GUI in 2 minutes for your boss to use.

We all agree on that, but I just want to raise the point that a lot 
of the short commings in view are based on some serious issues in 
VID.

oops... hehe shortcommings in VID are based on those in View... heheh

view is already much more powerfull now, but I feel that the current 
design is like going half way. 


instead of having a totally open level 1 (gfx engine) on which level 
2 (view) and level 3 (VID) is built, we have level 1.5 and level 
3

and I mean within REBOL, not within C.