AltME groups: search

Vincent: http://www.fmod.orgwas suggested by Cyphre, but we don't 
know if RT would add it. But who knows, - we now have AGG :-)

Nice Cyphre.  Imaging what it could do with AGG. The first vector 
graphic spreadsheets

With 1.2.106.3.1 and 1.2.107.3.1 : bug with pen color setting in 
draw block:
view layout [box white effect [draw [
	pen none box 10x10 70x20 ; invisible box
	pen black                                ; pen to black
	pen none box 10x30 70x50 ; invisible box
]]]
is ok,  but not
view layout [box white effect [draw [
	pen none box 10x10 70x20 ; invisible box
	pen black text 12x32 "hello" ; pen to black, some text

 pen none box 10x30 70x50 ; without AGG (->1.2.48), invisible box, 
 with AGG (alpha & 1.2.106+), visible box
]]]
Drawing something with a visible pen breaks invisible pen usage.

Another problem with AGG : draw text does not render foreign chars 
:

I wonder what font AGG use ? None of the ASCII 128+ char are displayed, 
 except 251 that show "OBJ" in a box !!

I believe that text rendering will not be included in View1.3 version 
of AGG/Draw. It will come a bit later.

DideC: here is result of the test on my machine: http://www.rebol.cz/~cyphre/agg-ansi.png
It looks normal here imo. But Rebol is not unicode yet so this is 
problematic area. Which version of Windows are you using? What default 
codepage/keyboard/national settings?

Here is what I get with 1.2.48 (standard draw) and 1.2.107 (AGG draw) 
:
http://membres.lycos.fr/didec/images/draw-text-48.jpg
http://membres.lycos.fr/didec/images/draw-text-107.jpg

I have tested on Win2k and WinXP with French Regional settings : 
"French (France)" with "French (France)" keyboard layout.

I don't know the exact code page, 1252 or 850 ? Where can I get it 
?

Vincent, DideC: thanks for the report. I'll try to investigate more. 
But remember the current font handling in Rebol/AGG will be removed 
 for the 1.3 version. (AA and vectorial fonts will be added once 
we found good crossplatform solution for it)

I noticed a crash with rebol 1.2.107.3.1 on win2k with the script 
logo.r (tet program for AGG)  when I resize the windows ...

request : to really test new AGG/draw, we needs a command list. The 
examples helps, but there is now way to tell the presence and purpose 
of optional parameters. Not a full doc, just a simple one line per 
command list, ie : 'line 1st-point [pair!] 2nd-point [pair!] ... 
n-point [pair!]

You can probably figure most of them out with the help of the existing 
AGG docs.

thanks for the draw command list - (time to experiment and crash-test 
draw/agg :-)

This looks like a bug in the AGG compositing engine:

Linux 1.3 Beta -> http://www.rebol.com/view/tools/ad-maker.rAlso 
does strange things to the FOCUS when resizeing... Its indeed correct 
that text in AGG is not displayed...

note: most of the demos do not work because there is no AGG text 
support in this build.

#4149 - Pre AGG, line-pattern had problems. I submitted feedback 
on it long ago, but never needed it badly enough to pester RT about 
it.

gregg, AGG still has issues with line-pattern.

Why not base REBOL/view widgets on GUI4CLI widgets maybe to save 
time it will be easyier to make the same kind of integration in this 
topic that it has been done for AGG integration

Interesting question -what will trigger it? We now will have - newer 
GC, async core, AGG beta soon ... so what will come next? Maybe something 
from following stuff? - rif, rebin, plug-ins, rebservices? But only 
Carl knows his priorities ....

can we do line graphs line this with agg ?  http://www.compkarori.com/vanilla/display/rawlinegraph

Shouldn't be too hard to get a nice result in View with AGG.

is line-width only valid for the agg versions of View ?

Did Cyphre ever release his agg_lite.dll with text rendering as he 
said he was going to do for devcon?

I just downloaded the rebol-agg.zip file and the file dates are still 
June 2004

AGG text rendering is in alpha View too...

what do you mean by text rendering? Text rendering in terms of draw? 
Imo now biggest drawbacks for general View usability are - incomplete 
keyboard handler + non-existance of rich text. I think that Carl 
could come up with some solution, where face/text rendeing could 
be switched to use agg capabilities internally ...

Gabriele, yes, I was aware that text rendering was in AGG view, but 
I wanted to encap, which means using the agg_lite.dll ... unless 
someone can twist Carl's arm to release encap with AGG as well :(

Graham. I stopped developement of agg_lite.dll and switched to AGG 
v2.2 library which is used in Rebol/View alphas. The agg_lite.dll 
was just a proof of concept.

I'm using internally for testing and debugging 'a clone' of the same 
code(which is written for View with agg) as a .dll. But this version 
is not in state of public release.

I guess I can call agg-view.exe to do the graphing that I want

AFAIK the frst version of new DRAW docs will be released together 
with the beta version of View/agg

what does translate 2x2 do in agg-view?  Does it add 2x2 to each 
point until ..a new pen is used?

My opinion is, we shold leave make-doc, bloggger and other topics 
for now, to get Carl's attraction where we really need it ;-) RIF, 
plug-ins, RebServices, Rebin,  AGG beta  are waiting in priority 
list :-)

Hi ashley !! I see your MD2IDE it seems you have open the competition 
with my MDP-GUI hahahaha. Well I like the redering window on right 
of the Window. The bad point is that the previsualisation of the 
texte is not updated until the save action. Updating it dynamicaly 
could be a good thing. There is no button to short cut the insertion 
of the balise like in MDP GUI (feel free to retake from MDP-GUI evry 
thing you need). Personnally Im waiting for the new rebol/view version 
that will speed the drawing engine and be able to use AGG based styles 
like Cyphre showed us to do. what about integrating to your product 
MD2IDE the net releasing support (for example to update quickly a 
blog based   on carl's REBOL script)

I fund very best hope for all this kind of highly advanced features 
with rebol View AGG engine (rendering those kind of advanced widgets 
 that need lot of refresh and quick rerendering to be visually smooth 
and less processor calculation could be very a good thing if we make 
them in AGG) but that's a hudge work ...

maybe I'm over estimating the capabilities of AGG on it's actual 
form too... because it's still depending on View layout rendering 
engine

maybe with AGG cpabilities we will be able to speed rendering enought 
to produce those kind of ticky widgets

Also, the AGG font demos on the desktop appear to be broken.

exactly, to the ttf file (for AGG only, not face/text)

exactly, that should work. refer to Cyphre for more details (i think 
agg text on unix is still somewhat experimental)

Is there support for Type I fonts in Linux and View/AGG ?

here it is http://www.compkarori.com/vanilla/display/AGG

I guess Debian rocks.  The console history works correctly in Debian, 
and so do the fonts in AGG draw.

Talked to Rebolinth again .. he never got AGG fonts working except 
by changing to Debian.

AGG fonts only working under Debian distros still?

libstdc++ is required by AGG

Ashley roadmap: 1) set of widget complet (what widgets are in it 
?)  2) functionnality of this set (what they do how we use them ?) 
3) esthetic of the widgets is dicted by the low people working on 
RebGUI and the nececity to make a simplier set of widgets. The fact 
that AGG was not official have make diffucut to put in line a good 
estetical consept. As REbGUI philosophy is to be light and easy  
we can't make a lot of heavy imge insertion and image drawing

and could be even better if we have a largest use of draw/AGG for 
menu popup scroll down animation

or many other draw effect exploiting capabilities of AGG

now AGG it's official and it would be very cool to use it lightly 
but cleverly to make a sharpen and diferenciable set of widget ...

AGG is fine, but is for rendering something in a face.

You can imagine having only one face and drawing all the UI with 
Draw commands, but you will need to put a BIIIIIIIIIIG function in 
window-feel to handle all the user inputs  at different xy mouse 
positions !!

I'm thinking for example of transparent popupmenu in menu style of 
Cyphre this is an other example of how we could use draw/AGG to enhance 
RebGUI global interaction

DideC My idea is not to make rebgui complicated but only to make 
it wither but thinking of it the scrolling down effect can be made 
without AGG in fact

Not with a pre-1.3 SDK. %rebgui-widgets.r uses some 1.3 specific 
words such as case, unless, etc. Once it starts making greater use 
of AGG-specific draw commands there will be no going back.

AGG License 


Anti-Grain Geometry is an Open Source, free library. You can use 
this software in any commercial or non-commercial projects, free 
of any charge. However, we encourage you to let us know about your 
projects and applications based on Anti-Grain Geometry.

Below is the complete formal text of the license.

Anti-Grain Geometry - Version 2.0
Copyright (C) 2002-2004 Maxim Shemanarev (McSeem)


Permission to copy, use, modify, sell and distribute this software 
is granted provided this copyright notice appears in all copies. 
This software is provided "as is" without express or implied

warranty, and with no claim as to its suitability for any purpose.



Please mention the authors in any work derived from Anti-Grain Geometry.

this means RT have to warn the author before to integrate AGG to 
REBOL this way the AGG author keep the control of his creation and 
can participate to it ...

From the AGG Group: "Having our own SVG icons is a good idea as we 
don't have to worry about licence / distribution issues and we can 
tweak the generation to make it as AGG compatible as possible. To 
do that we need to settle on *one* tool so as we generate consistent 
SVG code, and we should generate SVG that uses a single unit of measure, 
preferably pixels, as it's a real pain trying to handle multiple 
units of measure within the same file."

shadwolf - the question is, if AGG is capable enough to allow all 
possible renderings. But let's hope it is. Mozilla foundation is 
going to use Cairo library. Hopefully Maxim will stil improve on 
AGG ...

How can I handle in DRAW/AGG the transform matrice ability ?

better changing to AGG groupe sorry

I think that's because technologie issue (graphics libs that would 
be used to normally render SVG files to screen are different from 
AGG ) then you have plenty of possibilities SVG can be seen as a 
VID  widget tree where youonly get relevent informations but the 
structure have some recusing consept

for example the path tag that describes a shape (AGG/draw word) have 
obligatory a d field but then to handle the rendering options you 
have lot of ways to handle it

so maybe AGG is not originally designed to work with SVG? OK, we 
can integrated Cairo library then too :-)

Pekr I don't think so if you see the AGG library web site you will 
see lot of example of you to use AGG with SVG ... But there we are 
working in C++ and not in REBOL ...

so you have an XML  struture we transforme it to a REBOL Object! 
tree then this tree must be glanced and translated to have the AGG 
draw block ;)

so what you are trying to say is, that AGG itself allows easier SVG 
rendering, but our Rebol wrapper is not so flexible?

and in AGG we have differencies in the liearGradient definition that 
what we have in SVG

Robert, I'm waiting for a few things in the REBOL world to stabilize 
a bit before proceeding. Specifically:

1) The new REBOL/View system documentation
2) The new OS X version of REBOL/View
3) New SDK builds
4) Couple of AGG fixes

The two big design issues I'm grappling with at the moment are:


1) Look & feel, especially in light of the availability of View on 
OS X

2) Whether to revert to View 1.2 compatibility (and not use AGG) 
given the lack of a 1.3 SDK

yes, after all he has some experience by helping RT to integrate 
AGG, so .... :-)

Cyphre: "How to use AGG to forget Flash" :-)

for me to be honnest the advantages of  using SVG instead of images 
 are a lot this is a quick list of my thoughts on what can be done 
with  SVG format.
 - easier embeding of graphical content
- resizing auto ith not grphics quality loss
- cheap but sharp skining 

 - graphical content of an  User  Interface  very low because rebol 
 is pretty able to  work with compression of text content ( compress/decompress)

A little sample to enlight this  compressed SVG file with blender 
logo ->  less than 500 octets (any size can be applyed with no graphic 
loss (aliasing, color loose, blur, pixelisation etc..) )  a fixed 
jped for same content will use  around  50ko. This means less datas 
in memory to as graphic pixel tables are very heavy in VM memory

- Dynamic graphical content. some thing like text scrolling or efffect 
like Flash ones but with  a  reduction of  1000  of the data and 
memory use SVG use a labeling system for  each graphical content 
that compose the image we can provided a tiny system to handle easy 
animation and show/hide of graphical content using raw rebol commands 
-> this will make pretty easier the realisation of dynamic animations 
in rebol ViD content and  as any REBOL/View face is DRaw/AGG capable 
the effects that we can create isn the futur with this idea will 
have no limits  -> this means too to have a pretty fast and ell designed 
SVG engine (that's my actual path on research)

hum new rebol/view have save/png hability woooooooooooopy so there 
is nothing that prevent us to make a  graph /AGG/SVG/PNG  dialect 
 ^^

so for me it's new lol but more serriously until AGG was not available 
i think the use of save/png to-image was really not meaning

would following news help us to get AGG - SVG compatible gradients? 
It regards AGG 2.4, new branch of AGG, and I am sure we will get 
it ported to REBOL too ...


New utility class template is added, gradient_lut. It allows you 
to easily create a color LUT for gradients from a set of color stops 
as they are defined in SVG, section Gradients and Patterns.

Vector? AGG related?

AGG 2.4 released - some things redesigned, it is major version update. 
It now allows to render Flash path curves data directly - http://www.antigrain.com/news/index.html

Does it mean we can use Flash IDE tools to do animations, save them 
as curves and then possibly render it using AGG 2.4 in View? :-)

how much of AGG does DRAW take advantage of currently?

IMO old draw C code was all replaced by AGG equivalent ...

... and for new Rebol (but Cyphre or Carl could confirm), IIRC someone 
said, even compositing engine will be replaced, just dunno if by 
the one in AGG ...

not sure .... dunno how AGG is integrated, maybe AGG compositing 
is not used at all? Difficult to say ... but I expect radical redesign 
of View - at least we can be sure there is new event system placed 
inside, hopefully libevent .... so I expect even some compositing 
system changes and also face concept redesign ....

word wrap queries (like in the old amiga api) within AGG draw would 
be cool too... as in, what would the size of this text (or any gfx 
element, for that matter) be with current font/drawing settings. 
 and how many letters from a string fit within this box ? wrapped 
or not.

I got the impression that AGG draw is skewed a little to assist producing 
SVG graphics .. but there's a strong case to support postscript better 
instead.

unless you want to rewrite AGG in rebol ;)

Draw is AGG is it not?

the AGG translation etc works differently from PS.

hmm, my opinion was based upon SVG dialect, which we were able to 
render, using translation into AGG ...

I like the look of DRAW! :-) (Of course it's due to AGG.) I still 
miss a version of REBOL for Mac with full DRAW, as the Windows version 
has it.

Henrik - would it be difficult to create AGG based preview?

the problem is coordinate systems and that fonts do not scale linearly 
in AGG.

gob is a ptr to the AGG structure with a an abstraction layer.

Henrik - from what I know from Cyphre, new View will use full AGG 
compositing (AGG contains compositing engine), so maybe so ...

Question now is can coordinates of arbitrary points on curved lines 
in agg be accessible in rebol.

well AGG still has to do the rasterizing and its CPU based... so 
not million times faster.. but less REBOL collision trying to MANAGE 
the internal C data.

no C++ in rebol except for AGG

agg gadgets we can't see :(

AGG has an issue on every aliased stroke, btw.... just look at a 
red circle on blue bg and then a blue bg on red, and you will see 
there is a 1-2 line offset in the circle.  


There is no way to fix this in R2 AGG and I think that part of the 
problem is based on similar gamma assumptions.  also RGB pixels will 
affect left/right edge too, which is probably just amplifying the 
problem.

Max, I tried to compare the circles example as you described and 
I don't see any offset here. Can you clarify?
Also you can set the gamma correction for AGG antialiasing in R2.

But yes, it looks the AGG filters(which are separated from the AA 
code) have the same gamma issue as described in the article. I believe 
we can fix that (hope it won't slow down things).

It would probably be easier to get AGG to output stuff in a form 
GDI would like though, with more overhead from pushing around all 
of that bitmap data of course.