World: r3wp

:(

view is currently swiss cheese and the underlying Core has some large 
gaps that really need addressing before GUI sees the light of day.. 
IMHO..

the presence of holes suggests some underlying substance

the thing that gets frustrating is when something works fine in earlier 
builds then mysteriously dies in later builds :P

thats a great colour example CHris :)

Pretty, is it not?  : )

its one example where the benefits of colour testing over poly testing 
are clear to see.

Doesn't scale well though...

of course.. zooming and SVG night be another method :)

With AA turned off...

with AA on you can do approximation mapping with tolerances

Sounds like it could get complex - it certainly is a useful pattern 
for many situations, especially when you can use graphics programs 
to develop the maps.

Hmm, isn't jus alpha transparency enough? Why to do any shape detection? 
We just need the ability to define level, which will let events to 
go to underlying faces, just like Amiga DE did it. And if you look 
at Cyphre's irregular window shape, you will see, that it simply 
is not rectangular, or is it?

do http://www.rebol.cz/~cyphre/trans-gui.r

Graham - there are no holes in R3. Most of the stuff is just non 
finalised design. Look at latest changes - absolutly necessary Core 
changes to get load, transcode, modules working. Last two days we 
saw two releases - A38, A39 with bunch of fixes. We are slowly getting 
there.

Cyphre can't do nothing yet, as Carl did some changes to the code, 
and Cyphre's version of R3/View is not compatible anymore. Of course, 
rebin isolation should help, and in month or two, we get there - 
modules are bing worked on right now, plug-ins and rebin are next 
one. Then some source-codes get released finally. In the meantime, 
Carl also updates docs - very important ...

Three releases - we're up to A40 now :)

Do we have a deeper text compositing support in AGG ? (woops...)

by deeper and since the number of font is limited the basic thing 
i need would be to get a something like "get-char-size char font-name 
font-size"

this what in text-draw.r (VID3 sources)
font-char-size?: funct [fstyle] [
	gob: make gob! [offset: 0x0 size: 300x100]
	gob/text: reduce [
		'font fstyle/font

  'para make fstyle/para [wrap?: off] ; avoid infinite loop font bug
		'anti-alias fstyle/anti-alias
		"M"
	]
	size-text gob
]

But i don't use this. Useless memory overhead (by creating a new 
gob) each time.

the gob size is important in the wrapping calculations

So what ?

scan-fontset: func [fname fsize /style fstyle /local tmpfnt font-metrics 
charlist n][
	font-metrics: copy []

 tmpfnt: make system/standard/font compose [name: fname size: fsize 
 style: (either style [fstyle][none])]
	charlist: copy ""
	for n 32 126 1 [append charlist to-char n]
	forall charlist [
		append font-metrics size-text make gob! compose [
			offset: 0x0
			size: (as-pair fsize * 2 fsize * 2)
			text: [font tmpfnt size fsize (to-string first charlist)]
		]
	]
	append font-metrics charlist
	return font-metrics
]

probe scan-fontset "Lucida Sans" 24

that will get a basic 32-126 charset of requested font, size and 
style and return the metrics for you under R3.

I really like, how this page is starting to look - that is what I 
call good realease-early, release often strategy - http://www.rebol.net/wiki/R3_Releases

One question towards linux and os-x builds - is it only a Core build, 
or View is included too?

OSX is core only, and I think Linux too.

Icarii, i don't see the interest to do such a mess.

Basically, when i have to get the size of a text , i just do a size-text 
on it.

Steeve - just a simple way to get font-metrics for layout planning 
where you cannot rely on richtext in AGG working (eg it doesnt wrap, 
doesnt do bounds in Draw mode)

personally I doubt i'd go to the trouble to get it precise either.

does size-text in R3 also only return size, or does it now also return 
offset of that size

cause without the baseline offset, you can't really know the overall 
height size of a word.

The best (most-precise) way to deal with this issue, is to calculate 
width char by char, by using the above func, and when you go past 
the width of your box,  you use size-text on the whole line, up to 
that char... but this IS slow.  If doing a multi-line text system, 
you should use font/size anyways for the height.

Guys, there is some missunderstandings since a while.

Size-text is not usable on draw gobs, only on text gobs (that what 
we call rich-text gobs).

A multi-line text system should handle several text gobs (one per 
line).
It's the most simple and fastest system (it's what i do).

So that we don't need to calculate the size or the position of each 
chars in the line. 
And we don't need to manage a text wrapping mechanism.

Another reason im interested in AGG richtext (as opposed to text 
gobs) is that i'm intending to use OpenGL rather than rebol rendering 
once the plugin architecture is finalised.

rendering to draw/image then using the data as textures over GL frames 
requires the individual fontmetrics.

Carl started to solve codecs in R3. What is more, he now seems to 
have some extended ideas :-)

http://www.rebol.net/r3blogs/0127.html

Wrong link, sorry - http://www.rebol.net/cgi-bin/r3blog.r?view=0183#comments

awesome

Heh, the post might not be posted by Carl, the signature reads Sasssenrath, 
with 3 "sss" :-)

I hope the "yellow background" color of Carl's anwers are not only 
due to the poster name. So it's a good hint ;-)

IIRC yellow poster name also indicated your latest visit/read messages, 
but maybe I confuse it with how Altme displays messages .....

... well, except for technical nonsense, the person writing style 
was close to Carl's one. And the mention of Wildman suggests, it 
is some community member or lurking Amiga fanboy knowing what the 
Wildman was supposed to be about :-)

Pekr hunting fish ;-)

The style may be close to Carl's but the spelling and grammar certainly 
aren't up to Carl's standard. He would never normally write so bady 
as "Why not write codec to load source code written in other language 
than Rebol".

Still it could be Carl trying to disguise his writing :-)

I just noticed, R3 version 2.100.40 27-Mar-2009 came to several platforms:

Downloads: View: win/xp, Cores: osx/intel, osx/ppc, linux, linux/fedora

See: http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.40_27-Mar-2009

Hooray! - now have linux console with scroll buffer.

Two new alphas today - release early, release often :)

As of alpha 42 we now can load jpg, bmp, png and gif. The beginnings 
of the general codec architecture are there in the form of ENCODE, 
DECODE and ENCODING? functions. Oh, and LOAD has been rewritten again, 
with LOAD/next and multi-LOAD capabilities that go beyond R2.

Still waiting on DO/next though :(

no Tiff ?