World: r3wp

control-C to try and copy text in an error causes the console to 
crash

in an area causes console to crash

I wrote this to try and update the area with network trace

			set 'net-log funct [  txt /c /s][
				data: rejoin [ get-face a1 newline txt ]
				if c [ data: join "c: " data ]
				if s [ data: join "s: " data ]
				set-face a1 data
				set-face/field a1 tail get-face a1 'locate 
				wait .1 ; update gui
				txt
			]

but it doesn't work because get-face is async
so I need some callback instead ...

so my area ends up with a row of 

c: s: c: ....
before any real text appears

Could Open Web Font Format be of any use for us, to solve our font 
problems?

http://hacks.mozilla.org/2009/10/woff/

Do we have font problems in R3?

yes, we can't use some techniques as Hinting, no? I thought that 
some open-source cross-platform aproach might cure the situation 
...

I would assume that would simply be an extension of the rich text 
dialect and exposing more options from the AGG font renderer:

[hint 1 "abc" hint 0.8 "def" hint 2 "ghi"]

We are using hinting. But on platforms where FreeType2 lib is used 
the hinting results can be not nice. This is because it depends how 
FreeType lib is compiled (either with the Apple hinter, or with the 
free non-commercialy licenced alternative)

Henrik, yes HINT x y keyword can be added to the dialect. But IMO 
this can be useful only in case you have own vector glyphs and own 
simple font engine. For example the TrueType hinter is kind of language 
for itself so it can be pretty complex.

Hints should be built-in in font definitions (ie hint table or kerning 
pairs table) what Henrik sugest seems to me like kerning information. 
Hints should be active when rendering to "low" resolutions happens, 
acording to standards I've read long, long ago.

Sorry, I was mistaking kerning with hinting.

Hinting should make all rounding to be the sam at distinct resolution, 
ie it solves recomputation vrom vector information (float) to integer 
screen information, trying to make all significant sizes the sam 
at some distinct resolution.

appologize for writing errors

hinting is also important in general in DRAW

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.