World: r3wp

Cyphre, was has to be done for R3 IMHO is a way for us to probe values, 
just like a 3d package allows you to get point, edge, curvature info 
out of transforming and deforming geometry.

although some will argue this is slow, its actually VERY fast, since 
the slow part is usually the calculation and drawing.  once that 
is resolved, probing is insignificant.

using liquid I am already able to build a draw network, which recycles 
values and allows multiple elements to cooperate.  but I can't get 
that within each element itself.

Maxim, there will be some possibility to access/modify the internal 
representation of DRAW shapes in R3 so you can 'bypass' the DRAW 
parser and just rerender what is already in the 'pipeline'. This 
could be handy especially when reusing big and/or complex DRAW shapes 
etc.

nice!

Cyphre - is "featureset" of R3 already defined?

I mean R3/View ...

Yes, we have the 'basic features' defined. It will be surely refined 
during the implementation process. I believe Carl will write more 
at the right time in one of his blogs.

hmm, reading some of license related answers, GPL seems to prove 
itself being a cancer once again :-(

One developer was tryting to prepare AGG as an replacement to Mozilla 
Cairo vector engine. So we would get AGG in browsers too :-) ... 
unfortunatelly, licence change ruins the effort

We can assume, Cairo is distributed under LGPL, right? If so, it 
becomes 
really incompatible with the GPL. For now I'd suggest you 
to keep using AGG 
2.4, at least until we can come up with a better 
legal solution. Basically, 
I want to prevent some 
commercial monster corporations" from free use of 

AGG. But I do want the Linux world to keep using it for free. I'm 
not quite 

sure how well LGPL protects from uncontrolled free commercial use; 
if it 

does, I may re-think and switch to the LGPL. But I'm not willing 
to keep 

using totally free, BSD-like licences in future versions. Ideally, 
I'd like 
to come up with some kind of a QT-like licensing scheme."

but he also adds:


We are working on a legal solution that allows us to prepare special
releases 
of AGG under a commercial license along with GPL. Currently you can
keep 
using AGG 2.4 for free, but I'll stop supporting it soon.
We are 
also working on different fee plans, to make it as flexible as
possible. 
It's hard to tell you concrete values right now, but there won't
be 
anything extraordinary. Depending on the projects and your revenue
we 
can even provide you a 
free commercial license".
We will inform you soon about possible options.

McSeem"

... so there is still chance, that 1) we will be ok with 2.4 for 
quite some time 2) community extends old 2.4 branch 3) Maxim comes 
with some good licensing, so RT can afford to buy commercial license 
for Rebol ....

is the issue with non anti aliased lines of 1 pixel width being fixed 
for the next View?

Not sure if in the next beta but it should be fixed in the new 'final 
release'.

what is the issue?

Does someone have a demo-script with agg-fonts on debian? I have 
no deep clue how to use 'draws deper features and dont want to spend 
some hours figuring that out^^

there is the AGG Draw test in the viewtop. it uses both VID and AGG 
fonts

i read it does not work beacuse of absolute font-pathes. i give it 
a try

I thought you wanted to see it not working :-)

No, wrong this time^^

No fonts, neither native nor wine

Yes, I have a demo that Cyphre gave me.

http://www.compkarori.com/vanilla/display/AGG

Is there a performance-difference in using the old face/image or 
 drawing images in the draw-block?

using face/image is definitely faster

Is there a way in Draw/AGG to globally set TEXT rendering mode (aliased, 
antialiased, vectorial) instead of setting it each time you  call 
TEXT ?

The ANTI-ALIAS command doesn't seem to have any effect on TEXT rendering. 
Odd, the docs says otherwise : "The ANTI-ALIAS command currently 
affects the entire DRAW effect; the last value you set it to is what 
will be used for all draw commands in the block".

IIRC anti-alias affects only  vectorial text, not the standard one

Dockimbel: You have to always specify the TEXT rendering mode. Maybe 
the text mode could be set by separate command in later versions? 
The ANTI-ALIAS command works for all vectorial shapes and doesn't 
affect TEXT in other than vectorial mode. (the docs needs to be fixed 
in this case)

Cyphre, can you tell us what changes will bring the next Draw/AGG 
releases ? Wider font support ? Dialect improvements ?

Once the Rebol/View code merge will be at the level of View1.3.2 
we can add some bugfixes from RAMBO. I'm not sure how much new features 
would Carl like to add to R2 DRAW but I believe there will be at 
least improved and enhaced gradient support. What  else DRAW changes/features 
would you like to see in the upcomming R2 releases?

(ah, I forgot that we might also add new image filter so you can 
make hi-quality thumbs ;-))

yes!

What filter?

I would like to be able to work with images on linux server without 
X server running

without that I'm still forced to use PHP for image uploads

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 .....