World: r3wp

I'd like to have better font support (most of Windows TT fonts seems 
to not work), better font objet support (things like 'offset and 
'valign doesn't seem to work), persistent Draw settings (like Text 
rendering mode). These font issues may be due to my lack of experience 
with the new Draw/AGG, did other ppl had the same issues on windows 
?

Oldes: you could make a REBOL wrapper around the GD library (used 
by PHP for image processing).

Oldes: I meant image filter with resampling so when you downscale 
image the result is much better(but costs more CPU time) than using 
bilinear filtering.

I cannot. As I have only Pro licence. Cyphre - if it's not working 
on server - it's useless for me. At home I can use image magic. But 
I know, that's not your fault.

running DRAW without Xserver. This is quite possible but it all depends 
on Carl's decission in which product he want to have it. AFAIK the 
DRAW native command is in Rebol/Command(which can be run without 
Xserver) at the moment.

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