AltME groups: search

I believe that's a known issue Anton.

Hum, your script search for the file in our Rebsite index.r file, 
so I must see it in the Desktop, isn't it ?

If yes, I see a %direction-box.r, but no %direction-pointer.r icon.

No. It is not indexed. Actually, quite a lot of my scripts are not 
indexed :-(

Cyphre Great !!!! I'm happy to have found a difficult bug regarding 
MATRIX in AGG/DRAW :) I hope this will be solved as soon as possible. 
I all cases tahnk you to have take the time to scout my problems 
:)

SVG matrix (a b c d e f) -> AGG scale [a d] rotate [b c] translate 
[e f] can I do this ???

like that :
[a c e]
[b d f]
[0 0 1]

where couple AD = scaling BC= rotating EF = translating

Dide, perhaps at work you have not updated your reboltech index.r 
file for a while, and it still points to my old rebsite.
Try this at work:
	load-thru/update http://www.reboltech.com/index.r

it's yet a kind of miracle for me totally noob in AGG and in SVG 
to have arrived to the actual point of the svg renderer. Lot of code 
and ideas have helped me a lot Ashley is trully a idea fountain. 
Those idea only claim to be worked again and again to arrive to a 
very very good and usefull tool

I thought matrix was only a way to merge scale rotate and translate 
values...

Didec work like a layer difinition and manager

Using push the matrix or other trnasformation information are apply 
only on the push  block content. outside the push block the matrix 
informations are not affected

If I use TEXT I can specify the offset. Is there a way to specify 
the size as well and that the rest is clipped?

Hm... but I don't know how big a text will render. And I can't referr 
to the text to clip it.

I have a feeling that draw TEXT is still using old draw code, and 
not merged so well with AGG yet.
I noticed that draw text offset doesn't scale:

More weirdness with scale, line-width and arc:

- a 360 degree arc doesn't quite make it all the way around (small 
section missing at the join)

- arc loses its resolution (arc becomes an obvious polygon approximation 
to an arc)

text-size: you can use size-text. setup a face with /text, font and 
nothing else, get the size, use same text in draw.

rebol [
	date: 24-Jul-2005 
	author: "Anton Rolls"
	comment: {

  Investigating why adding/removing 'merge from effect block seems 
  to change line-width on
		arc, circle etc.:

		ToDo:
		  - try to 

  - It looks like the AGG anti-aliasing is with the default window 
  background color ?

    When MERGE is added, then it's with the actual color that is merged 
    (seems ok and good to me).

    - so try to set b1/color so it's the same as the color anti-aliased 
    against in the merged version

    Perhaps default window background color (200.200.200) is close to 
    the default agg anti-aliasing color ?
		  (do not use custom window color)
		- try a simple LINE
		- report to RAMBO or AGG group
		- submit to RAMBO


  This shows that the addition of 'merge seems to add 0.5... (?) or 
  some scaled factor to the line-width:
	}
]

effect-blk: [
	draw [
		pen black
		line-width 0
		translate 25x25
		scale 1 1 
		circle 0x0 24 ;arc 0x0 24x24 0 270
	]
]
make-2nd-effect: func [/local result][
	result: copy/deep effect-blk
	insert result 'merge

 ;result/draw/line-width: result/draw/line-width - 0.5 ; <- even with 
 this they don't look quite the same

 result/draw/line-width: result/draw/line-width - any [attempt [correction-scr/data 
 * 0.1 + 0.5] 0]
	result
]
refresh: does [
	b2/effect: make-2nd-effect
	show [b1 b2]
	big1/image: to-image b1
	big2/image: to-image b2
	diff/image: xor big1/image big2/image
	same-txt/text: join "same? " big1/image = big2/image
	show [big1 big2 diff same-txt]
]
view/new window: center-face layout compose/only [
	across
	label 80 "scale"
	scroller 200x20 with [data: 1][
		change/dup next find b1/effect/draw 'scale face/data 2
		refresh
	]
	return
	label 80 "line-width"
	scroller 200x20 [
		b1/effect/draw/line-width: face/data * 4
		refresh
	]
	return
	label "line-width correction"
	correction-scr: scroller 200x20 [
		refresh
	]
	return
	b1: box 50x50 [refresh] effect (effect-blk)
	b2: box 50x50 [refresh] effect (make-2nd-effect)
	same-txt: text 200
	return
	big1: image 200x200
	big2: image 200x200
	return
	diff: image 200x200
]
refresh
do-events

I just took a look at Zeta (the BeOS clone) and saw that they use 
AGG for the rendering system. Nice.

What's the likelyhood, or possibility of a PDF renderer now for View/Agg 
?

AGG could still be ported to Syllable, but I guess, being a crossplatform 
library, it would have lower performance

Kaj, I was thinking more embedded fonts -- would the author of a 
viewer need to parse the embedded font data before passing them to 
FreeType?

What about pdfs that are the output of scanners and pdf printer drivers? 
 Presumably these are just images wrapped inside a pdf ?

I would like to know when the problem with Agg Matrix will be solved 
and when Carl plans to integrate in REBOL/AGG a radiant function 
that can better feet with SVG datas  ? I started 3 month ago an SVG 
engine and since then I'm stuck because of those 2 problems... SVG 
without transformation matrix and without gradients it's like nothing 
.... ( see greoup SVG renderer for more informations and test code)

It's 1:04AM here, not a time for serious work, so I'm fiddling little 
bit with some eye-candies in new DRAW and I must say it's SO powerful. 
I'm just starting to see the potential...whooo! Thanks

ft: make face/font [size: 60] 
view center-face layout [
	origin 0
	box 400x80 white effect [
		draw [

   fill-pen linear 0x0 0 100 30 1 1 black white black white black white
			font ft
			text 0x0 "Wavin' REBOL" vectorial
		]
		emboss
	] with [
		rate: 0
		n: 0
		feel: make feel [
			engage: func [f a e][
				f/effect/draw/3/x: n: n + 2
				show f
			]
		]
	]
]

that is a very hard question, because in most vector drawing apps 
it doesn't, while it is also arguable that it should.

also, i don't know if AGG is able to scale a line width if the scale 
is not the same for x and y.

That seems like a frustrating issue.

Cyphre thank you for your answer You need more infos on Gradient 
here is the official webpage on the topic hopes it  could help you 
to make a svg gradient complying fonction in draw  ...:)

Cyphre there is no missing thing in AGG  gradient the coordinate 
datas given by SVG gradient data block is different. To make it short 
and simple SVG work with area pourcentage of filling (what ever the 
 size of the area to colorize is you will allways have red 20% blue 
40% black  40% if red blue black are your 3 colors that are used 
to make the gradient effect) Then we have a vectorial information 
that  give the orrientation of the gradient effect. SVG gradeint 
are linear, circular or parterned (in most case linear is applyed 
...). REbol AGG gradient use area offset you have a start offset 
a end offset and the  colors are degraded along this vector  nothing 
more nothing less you have no area coloring infos. This is if  my 
recalls are good the differencies betwin AGG gradient and SVG gradient.

and the proposed solution is? Can we have some helper parameters 
in rebol AGG to allow SVG kind of parameters? Are AGG gradients subset 
of SVG? Is there 1:1 equation, so that we can transform between the 
two? Maybe the problem is a bit more complex?

Pekr yes we can do adaptation but this will enslow dramatically the 
SVG rendering. My goal is to make a SVG widget capable for REbGUI 
 to dispaly graphic content like tool bars, logo etc so faster is 
the render better it's

yes the actual svg render have been made in one week it's pretty 
fast and the code is very tiny ( 400 lines for a svg to AGG/Vid rendering 
engine that not so mutch  ^^)

basically SVG is a XML  structure but for several reasons i choose 
to pass thru a XML 2 Object converstion and then I  treat the SVG 
infos converted to rebol objet structure ;)

main reaseon to act like that xas svg recursion structure is a nightmare 
if you use parse or xml-parse

Okay! :-) I'll contact you privately. I got some questions, if you 
have a little time.

I think, there's a bug with colour keying in DRAW, when doing an 
IMAGE. Grey-tones seems to work, and also the green colour 0.136.0, 
but most other colours don't work!?

cyphre :

here you have a tiny example of gradient representation taken from 
the webpage http://www.w3.org/TR/SVG/pservers.htmlwitch explain 
the gradient format for SVG 
Simple linear gradient commented by me  ^^
<g>
    <defs>
# LinearGradient definitions 
        <linearGradient id="MyGradient">
#first color using 5% of the space to color
            <stop offset="5%" stop-color="#F60" />
# second color using 95% of the space to color
            <stop offset="95%" stop-color="#FF6" />
     </linearGradient>
  </defs>

# HERE you have the rect definition using the LinearGradient witch 
id is MyGradient

   <rect fill="url(#MyGradient)" stroke="black" stroke-width="5" x="100" 
   y="100"  width="600" height="200" />  
</g>    

So as you can see the color pourcentages

Regarding the gradients: Thanks for the examples. Anyway, I've already 
known that you are missing the gradient color ratios so it is just 
a matter of time and priorities when this will be added so please 
be patient ;-)

Draw SVG/AGG have progress so far that I cannot catch up with what 
it supports currently.


Does anyone have a quick feature overview of this? either a link 
or point form will do.

would it be possible to create a /view version for linux w/o need 
for an x server?

I'm quite reluctant to install X on a _web-accessible server_ just 
for /View, tho (and, hopefully, so is everyone else). Even the Java 
folks got that right, eventually - Java can run in "headless" mode, 
and yet allows people to access graphics functionality like Java 
2D &c.

maybe vnc is a compromize? i guess rebface wants x too, for fonts?

any change ever of a native pdf browser ?

a way to view PDFs from Rebol without using anything else.

than writiting to VID a performant  PDF renderer engine ...

I was cleaning my FTP accound and I found AGG Animation engine I 
wrote year ago. It's probably not finished, but there's a small working 
demo. >> do http://krutek.info/rebol/aggregator-cleaned.r

Cyphre, do you have any news about, when we'll see your different 
fixes in a release?

Geomol, please be patient, lot of cool things is happening right 
now ;) I think Carl is planning to build a new View with updated 
AGG very soon.

it's probably depending on the graphics driver, but it doesn't really 
matter what I do, whether its rebcode, AGG or VID, things slow down 
to a crawl when going full screen. I did some time profiling which 
showed that SHOW takes up probably more than 75-90% of a drawing 
cycle, much depending on resolution. removing that obstacle or making 
SHOW more intelligent will speed animation up a lot.

thee is a switch for anti-aliasing. Do not know if it is by default 
on or of though.

Huh!? I'm using DRAW to resize a brush in Canvas, if AA is on. Try 
paint a one pixel line with AA off, then turn AA on and hit 'h' to 
halve the size. Isn't it doing it, like you want?

scale is a direct DRAW command?

shadolf i dead waiting lol  ... Well SVG renderer widget  for RebGUI 
is not a urgent stuff at all ... Well yes if the 2 needs i have are 
integred to next rebol/view AGG  release it would be really nice 
this will allow us to enlight  rebGUI look with scalable graphics 
^^. next thing once the 2 needs i have are available will be to work 
on the renderer engine widget to make it as fast as possible to allow 
a lot of  SVG content to be rendered without impacting rebgui performencies.

we have to fixe too the usuabilitie of SVG content into RebGUI too 
but i think this is a last issue to discuss .Ashley propose the idea 
of a svg renderer widget to be included into RebGUI. I took his code 
and propose a more advanced version and this work allow me to pop 
out some needs to perfectly comply  the rendering task. But the main 
discution on what we are going to do ith the renderer once we have 
it is not started yet. I think many things can be expected from a 
SVG renderer widget in REBGUI  but then  it depends too on the quality 
to the resulting renderer.

A little survey for DRAW programmers here in this world::

We are thinking about a possible  separation of the gradient functionality 
from FILL-PEN command as this command is going to have too much argument 
combinations. What do  you think about this? Any better ideas? Or 
are you satisified with only two pens(for fill and for stroke)  in 
DRAW?

FYI.. here's what the latest Flash player is doing with grads.. 

Enhanced stroke properties

Select from a variety of cap and join 
types. Apply a gradient to a stroke as well as a fill. Render stroke 
intersections better with stroke hinting.
Advanced gradient control

Tighter 
control over gradients such as changing the focal point of a radial 
gradient and selecting from different overflow modes. 

2 weeks ago I have intorduced Rebcode(some alphaversion in those 
days) to Oldes who is doing the Rebol to SWF dialect and know very 
well internals of Flash 8. He converted in a few hours one simple 
Flash demo to Rebcode and was amazed about the speed.

The way I see it, without an IDE, it's a lame duck.

If AGG is incorporated into Rebol, isn't there a need to mention 
that in the license?

If without then RT doesn't have to mention anything. As it is, REBOL 
is mentioned on AGG's website as a user.

Since View 1.3 is just a binary right now, a string hidden in the 
binary would be sufficient. It doesn't even have to be readable to 
count for this clause, although that is getting iffy.

Most of the time that info is put in a ReadMe file or an About dialog, 
but since View has that info online, online docs are where it needs 
to be. And the online docs related to Draw do mention AGG (I think). 
That clause is less restrictive than you think.

AGG is definitely a win for Rebol (compare it to old draw, right?) 
and it provides us with professional grade vector graphics .... Look 
at Canvas RPaint - very good example of what is it capable of ...

the only problem right now is SHOW, which seems to slow things down 
a lot... but I think I've mentioned that before :-)

well, I'm not really sure what goes on, but if I use cyphres rebcode 
demo it runs fine in a small window, but if I set up the display 
size to twice or three times the original size, the framerate really 
slows down. The drawing routine itself shouldn't care about the resolution, 
so I think it's something in SHOW

The following code demonstrates this. Comment / uncomment the draw 
effect line to see the difference a simple draw command makes.

count: 100

do-test: func [label info /local img-size start end] [
	img-size: to-pair label/text
	img: to image! layout [

  origin 0 box img-size blue reform ["Testing" img-size ". . ."] font 
  [size: 24]
	]
	view/new/options center-face layout [
		origin 0 i: image img img/size
		;effect [draw [circle 100x100 100]]
	] [no-title no-border]
	;	test loop
	start: now/time/precise
	loop count [show i]
	end: now/time/precise
	;	display result
	info/text: form to-integer count / (to-decimal end - start)
	show info
	unview
]

view layout [
	title "Resolutions"
	across la: label 100 "800x600" ia: info 100 center
	return lb: label 100 "1024x768" ib: info 100 center
	return lc: label 100 "1280x1024" ic: info 100 center
	return btn "Run" [do-test la ia do-test lb ib do-test lc ic]
]

Cyphre: if your question is "should we create a FILL-PEN-PERCENT 
command to not overload FILL-PEN with percent values?" I say YES. 
(but the name is here as an example)

But overwhise I don't really understand what you mean.

DIDEC you get the point ...  the ask is un precise. My case is particular 
a gradient iss that take in charge percent and vertorial orientation 
to feet SVG datas would be a plus. I think gradient the way they 
are yet implement in Draw/AGG are better than the SVG way. SVG is 
huum less natural less close to human way of thinking and in that 
philosophy it feets perfectly with the REBOL .

viewport 100x100 300x150 [font myfont text 150x50 "this is a large 
line of text..."]  ;here the text would use the viewport as its origin 
and screen size

Why not have a viewport which can be of any shape ?

in my svg render i use push to make a drawing layer order and that 
work pretty good

SVG support the element  in a stackable way so it's good to be able 
to reproduce that feature with draw/AGG push

for example  you draw a black cirle and on top of it you put 2 spots 
yellow and a yellow line  SVG keep the track of that and rebol drew/AGG 
is abe re produce it perfectly...

IS ther a good description of AGG somewhere?

Rebolek's AGG demo called "Cyphre" reminds me a bit of Tempest 2000 
- anyone planning on a Tempest 2000 clone ?? :)

Here is a little somthing i was working on some month ago when the 
 Ritchtext edit  topic pops out -> RTE ...

REBOL [
 Author: "Shadwolf"
 Starting_Date: 21-05-2005
 Purpose: {Research work on rebol draw capability to be 
 used to write a Ritch text editor} 
]

stylize/master [
	rte: box with [
		color: gray 
	    tampon: ""
	    buffer: []
	    line-index: 0
	    char-sz: none
	  	current-text-offset: 0x0
	  	cursor-text-offset: 0x0
	  	max-text-offset: 0x0
	  	text-color: black
	  	pane: []
	  	
	  	set-font-style: func [ font-s [word!]] [
	  		switch font-s [

      bold [insert tail buffer compose/deep [[ [size: 11 style: [(font-s)]] 
      (either cursor-text-offset/x <> 0 [cursor-text-offset] [as-pair 0 
      (line-index * 20)]) "" ]]]

      normal [insert tail buffer compose/deep [[ [size: 11 style: []] ( 
      either cursor-text-offset/x <> 0 [cursor-text-offset][as-pair 0 (line-index 
      * 20)]) "" ]]]

      underline[insert tail buffer compose/deep [[ [size: 11 style: [(font-s)]] 
      (either cursor-text-offset/x <> 0 [cursor-text-offset][as-pair 0 
      (line-index * 20)]) "" ]]]

      italic [insert tail buffer compose/deep [[ [size: 11 style: [(font-s)]] 
      (either cursor-text-offset/x <> 0 [cursor-text-offset][as-pair 0 
      (line-index * 20)]) "" ]]]
	  		]
	  	]
	  	
		feel: make feel [
			engage: func [f a e] [
				switch a [
				   
					key [ probe e/key
						switch/default e/key [
							#"^M" [
							line-index: line-index + 1

       f/current-text-offset: as-pair 0 f/current-text-offset/y + 20]

       insert tail f/buffer compose/deep [[ [size: 11 style: [(font-s)]](as-pair 
       0 (line-index * 20)) "" ]]
							
						][
							f/tampon: rejoin [f/tampon to-string e/key]
							draw-text: []
							print "f/buffer:"
							probe f/buffer
							foreach line-to-draw f/buffer [
								print "line-to-draw"
							;line-to-draw: f/buffer/1
								;probe line-to-draw
							;set [font-style start-offset text-to-show ] line-to-draw
							
								font-style: line-to-draw/1
								start-offset: line-to-draw/2
								line-to-draw/3: rejoin [line-to-draw/3 to-string e/key]
							;probe font-style 
							;probe start-offset
							
								font-obj: make face/font font-style
							;probe font-obj 
								text-to-show: line-to-draw/3
								;probe text-to-show

         insert tail draw-text  compose [ font (font-obj) pen (f/text-color) 
         text (start-offset) (text-to-show)]
							] 
							;print "draw-text:"
							;probe draw-text
							

       ;draw-text: compose [ pen (f/text-color) text (f/current-text-offset) 
       (f/tampon)]
				    		f/effect: make effect reduce [ 'draw draw-text  ]
				    		draw-text: none 
				    		;probe f/current-text-offset

       f/cursor-text-offset: as-pair (f/cursor-text-offset/x + 9) f/current-text-offset/y 
				    		;show f
						]
						f/pane/1/offset: f/cursor-text-offset 
						show f
					]
					down [
						;insert f/buffer compose [(as-pair 0 (line-index * 20)) ""]
						focus f show f
					]
					
				]
			]
		]
		append init [

   insert buffer compose/deep [[[size: 11 style: []] (as-pair 0 (line-index 
   * 20)) ""]]
			probe buffer

   insert pane make face [ color: red size: 2x20 offset: cursor-text-offset 
    ]
			show self 
		]
	]
]


view layout [
  across
  	btn "bold" [test-rte/set-font-style 'bold]
  	btn "underline" [test-rte/set-font-style 'underline]
  	btn "italic" [test-rte/set-font-style 'italic]
  	btn "normal" [test-rte/set-font-style 'normal]
  return
  	test-rte: rte 300x300
]

shadwolf, well, it's a start :-)

i will be really glad if  some AGG guru could have a look on this 
script and modify enhace it and maybe make a tiny lib  ^^

what we need for text  to begin is bold/italic/underline/normal/color 
 If you have 10 more minutes to pend on it  images  would be a plus 
 ^^

my main idea was to use draw and use a cursor /input output similator 
but i'm not really a specialist in that kind of motion

I'm intending to move flounder to AGG when i get a spare moment

by extension i was planing this to be once a short and full working 
solution will be found to insert it to RebGUI as a basic widget  
of this set  ^^

but then i have a abnormal bug witch means nothing ...

how can a widget in external context mode works better than a widget 
internal context mode

Svg  works need a dubeged matrix  -> scaling problem  and  gradients 
that feet ratio  information and   not  fixed area  ^^ those things 
can be script coded but this will complicate the SCV rendering engine 
and makes it slower for nothing ...

I'm trying to isolate a possible bug having to do with 'line-pattern 
.  I don't think using a negative number should cause rebol to lock 
up the CPU

I don't know why someone would use a negative number, but this shouldn't 
happen if they do

May be a hard thing to check for without hitting performance too 
much, because of the late binding in REBOL. I can live with it.

BTW, I've got a solution to the late-binding issue. I plan to write 
a blog about it soon.

I thought I submitted a RAMBO ticket earlier for it, but now I can't 
find it

josh hum does it work with sp: -2 ? ( joking lol ) Cyphre thank you 
very mutch  and carl too for your hard work i'm a little far those 
last month from rebol ... but  i still have lot of  wants i will 
restart to work on the SVG rederer once all will be set /fixe if 
you have suggestions  about the svg engine make them to me i ill 
try to  add them too. ( a less 1000 lines SVG engines this will be 
very nice and flexible ...)

josh negative size for a line .... the issue no one would imagine. 
 lol but a good debug  lol this kind of issue can be really annoying 
for an miss parsing of the SVG data content for example -> crash 
so you  stend lot of hours trying to see if the crash comme from 
your SVG renderer engine from the SVG file or from rebol or from 
the engine or rebol/view VM ^^ you are right a message comming fromt 
the VM like "Error the size entrer for the lline is negative  " isntead 
of the vm crash would be nice  ^^

arg  this email adress doesn't work any more <[cyphre-:-volny-:-cz]>:

I make a  zip archive SVG renderer  script lastest  + svg file for 
 blender  on my  ftp

Is is possible to deform an image into a triangular shape ?


I tried the following .... but specifying the 3rd & 4th co-ordinates 
as the same produces no image at all ....
view layout [

    box 100x100 effect [draw [image logo.gif 10x10 90x10 90x90 10x90]]

    box 100x100 effect [draw [image logo.gif 10x10 90x10 60x90 40x90]]

    box 100x100 effect [draw [image logo.gif 10x10 90x10 51x90 49x90]]

    box 100x100 effect [draw [image logo.gif 10x10 90x10 50x90 50x90]]
]

It looks like the algorithm always takes four points, so specifying 
two coincident points means a point at infinity, which means the 
image is infinitely stretched out. Mmmm....

try them a pixel apart

The reason for the question is I want to stretch the image into a 
triangle .... just wondered if this were a bug or a feature of the 
algorithm.
Is there another way of doing it using draw ?

a pixel apart still has the same problem - it is tending towards 
infinity.