World: r3wp

I believe this will be improved in R3 with better modularity.

Well...after doing some more testing on fonts, looks like it works 
correctly with all TT fonts I've just tested. I used to never set 
the rendering mode for TEXT, maybe that was the cause of my issues.

Doc: the FONT rendering in R2 DRAW should handle all TTF fonts. (at 
least I havent heard about any problems from anyone). The persistent 
text mode can be added IMO even in R2. Text formating won't be probablay 
enhaced as this would take too much effort. But in R3 there will 
be rich-text dialect for that purposes. (Maybe the new rich-text 
dialect  could be backported into R2 later but it all depends...)

Cyphre probably remember I still would like to have bitmap fonts 
(use specified parts of image as font glyphs:-)

eeh, that debate indicates, R3 is at least one year from being findished. 
Other than that - what would be the reason to backport anything to 
R2?

Cyphre - how Carl's decision of where he wants to put draw can be 
valid for R3? Or are you talking about R2 here? I thought that with 
R3 the rather stupid product segmentation vanishes once and for all 
...

Pekr, the reason for backporting is that: 1) there will be high demand 
from R2 userbase for such feature 2) it would be easy to do it. So 
my note above is very hypothetical ;)

well, it is just that we talk about R3 as of a beast, not being compatible 
more than from 30% to R2. If it is going to be nearly 100% compatible, 
than continued development of R2 after R3 release is total vaste 
of resources .....

Pekr: I have no clue about the R3 product line/strategy, yo need 
to ask Carl about this. (I guess from Carl's blogs there will be 
more flexible aproach to build your 'own Rebol' than in R2)

yes, that is also my understanding. So /draw will be module, which 
you will be able to "include" (pack) into your exe. But that alone 
does not probably answer, when/where X-Win is needed?

AGG based DRAW is platform independent so it doesn't need X-Win or 
any other API framework. The only dependent part is TEXT rendering(which 
is not included in the AGG). Currently it supports Win32API and FreeType2 
library to be able render text. So even if you have rebol on Linux 
you only need freetype2 lib, not Xserver in your setup. (the X-win 
dependecies are in the older Text rendering engine of R2 used for 
text in faces which will be eliminated in R3).

I'm curious, what kind of font rendering does View use?

I noticed that View produces pixel artifacts on some letters on my 
PC, but I think that's RAMBO'ed. Those artifacts are not visible 
in DRAW text.

Under what OS?

XP

I think it's only visible with clear type enabled

http://bolek.techno.cz/pix/view-artifacts.png

yep, those

Hmm, iteresting. I have the cleartype turned off so I didn't know 
that. That looks like something is going wrong with the cached glyph 
bitmaps when BOLD text is used with cleartype enabled. I don't know 
the guts of old text renederer so this is just my guess.

clear type is very different in how it treats pixels... it actually 
addresses each individual  R G B channel of each pixel individually, 
so what happens is that on many faces, the anti-aliasing actually 
turns the edges as shades of colors, and not gray.

the downside is that this is optimised for working on white BG in 
all I can see, and is obviously useless unless you have an LCD monitor.

I've only noticed the artifact in rebol when text is bold... don't 
know why.

my guess is that REBOL builds its glyphs once and then any PIXEL 
that has one of the channels to on is set as all on... so we get 
bad aliasing and some dots here and there.

AGG wouldn't have this effect since it does not seem to use clear 
text.  in fact, in general I find AGG font AA pretty ugly... is there 
a way to improve this?  even if its slow?  there are some situations 
which do not mind speed (generating HQ output graphics, for example) 
 or small GUIs or when converting face looks to bitmaps before display.. 
(trades speed for ram)

Maxim, I don't know. The output seems pretty similar to what is output 
with Freetype 2, but the AA is a little uneven, yes.

I find the issue is mostly with thin lines where the aa will be quite 
spectacular in its variations  especially if you look at the difference 
from 45 angle and near 0 or 90 degre angles. I know that AA should 
be an energy based repartition, which is not linear.  (gamma) such 
that two pixels at 0.5 are actually a quarter as bright as one full 
1.0 brightness pixel to our vision (obviously subjective to user 
response, applied monitor gamma and superwhite levels, etc).

for example, if you want to slide a picture of a stars, you must 
first boost the gamma of the picture by 2, do the move and then apply 
a .5 gamma.  then, the AA will have spread out according to energy 
rather than color.  which means that the 2 side-by-side pixels will 
be at much more than 0.5 of the original 1.0 single pixel brightness.

so I guess a similar operation is needed for fonts (I have no concrete 
bg in fonts, only view a similarity)

I also know that apple, quantel, adobe, MS and others have patents 
in font, and AA algorythms, which might actually prevent people from 
performing proper AA or Font rendering... even if they know how.

The AA is the reason, why I want bitmap fonts. With such a bitmap 
it would be very easy to create pixel fonts. If you take a look at 
Flash you can see, that most of the sites is using pixel precision 
fonts, which are made for fixed height but anyway are much more smaller. 
http://fontsforflash.com/

and if I can use such a image http://box.lebeda.ws/~hmm/rebol/projects/font-tools/latest/fonts/idea.png
to create glyphs which I can use in flash: http://box.lebeda.ws/~hmm/rebol/projects/font-tools/latest/fonts/idea.html
it would be nice to have a chance to use such a bitmap (or the vectorized 
glyphs) in Rebol as well

Is carl going to release a linux sdk with agg enabled?

before R3 comes out ?

agg font support ie.

Graham: I think the linux SDK will have agg enabled once we solve 
the font path identification thing.

How to rotate ARC?

this code draws nothing: 
view layout [
	box 400x400 effect [draw [
		rotate -90
		fill-pen red    arc 200x200 90x90 0   108 closed
		fill-pen green  arc 200x200 90x90 108 252 closed
	]]
]

use 'transform instead. you need center point woith rotation and 
it's not clear where it is with 'rotate keyword (0x0 probably?)

never mind, I already used my rebol/flash dialect to make the chart. 
I just wanted to say, that there is probably a bug, because this 
is working:
view layout [
	box 400x400 effect [draw [
		rotate 15
		fill-pen red    arc 200x200 90x90 0   108 closed
		fill-pen green  arc 200x200 90x90 108 252 closed
	]]
]

Ach... ok my fault - the center point is in zero - that's why it 
was not visible - so it's probably not a bug

that's what I wrote :)

I was just looking for some Rebol/draw (agg) manual and found this 
interesting project made using AGG (not Rebol related) http://www.contextfreeart.org/gallery/

what about a library of draw snipsets handled by rebol.org ?

they could be indexed like scripts, with keywords and other usefull 
tricks

so we could download them into draw tools using rebservices

we could think too about a standardized form for draw animations

yes we should...

90+% of what you need to do that, Steeve, is already in the Library:

[1] we could (in minutes) add extra valid domains or types so a script 
could be categorised as draw-snippet


[2] the LIbrary doesn't use rebservices for an API. It has an API 
called LDS that predates rebservices (basically, the library team 
got there first). You can use it to download any script (among other 
things too)

http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=lds-local.r#toc-50


[3] using LS to download a snippet every time it is needed would 
be slow and wasteful.....But you could easily write get-draw-snippet 
that caches results locally.
****

That would not be perfect as it would be good to have a page/pages 
showing the images the snippets produce. But if there were enough 
snippets, we could add that.....And, before we do someone else could 
beat us to it on their own website -- they could use LDS to get all 
the snippets and display the images. It'd be a neat bit of Community 
interaction.

====> Perhaps switch to Library for any detailed discussion.

Steve, I am about to release in the next few weeks a dataflow draw 
engine called glob.  its allows selectable layers of assembled draw 
blocks, can VERY easily animate too.

Oldes, I also love that app.