| # | User | Message | Date |
| 312 | shadwolf | and what about the text display / font management issues ... and this can be linked to viva-rabol or SVG rendering... Cyphre do you plan or have taken some notes about that area ? | 20-Dec-09 23:19 |
| 311 | Maxim | cyphre... those are incredible test SVG files! | 15-Oct-09 7:30 |
| 310 | Steeve | Well, i have enough sources, don't worry. I just wanted to compare with Henrik's | 14-Oct-09 21:46 |
| 309 | Cyphre | Steeve this was one of my favorite file for testing of the R2 SVG-lite viewer:
http://david.bellot.free.fr/svg-cards/ Good luck! ;) | 14-Oct-09 20:37 |
| 308 | Pekr | just google "SVG icons", plenty of links :-) | 14-Oct-09 14:15 |
| 307 | Henrik | I'm not sure I did. | 14-Oct-09 14:13 |
| 306 | Steeve | * but you | 14-Oct-09 13:51 |
| 305 | Steeve | bug you kept the original svg files, did you ? | 14-Oct-09 13:51 |
| 304 | Henrik | Steeve, sorry, it's a small hack. I grabbed the svg coords from inkscape manually and simply pasted them in a text file, made them pretty for rebol and converted them to DRAW in a simple way. I have no XML parser or anything like that. | 14-Oct-09 13:43 |
| 303 | Pekr | hehe, added first request :-) | 14-Oct-09 12:38 |
| 302 | Steeve | Henrik, have you the original svg files of the signs ? I would like to see what i get with my parser. If they are not public domain, don't give them ;-) | 14-Oct-09 12:26 |
| 301 | Henrik | I think I'll leave it for this page for now. We can split it in multiple pages later. Our discussions seem to criss-cross between DRAW and View anyway. | 14-Oct-09 11:54 |
| 300 | Pekr | I mean - compositing engine ... | 14-Oct-09 11:53 |
| 299 | Pekr | AGG is not only about draw - it is our rendering engine too ... | 14-Oct-09 11:53 |
| 298 | Pekr | Dunno - there can be many various requests, but basically it would be correct, although we do have Effect pipeline too, but I don't know, if it is AGG based, or not .... | 14-Oct-09 11:53 |
| 297 | Henrik | Perhaps we could split it into a View Project and a DRAW Project. | 14-Oct-09 11:51 |
| 296 | Pekr | Is it multicategory? I mean - all draw related stuff goes into Draw section? Or each request should start with blue description name? If you want to divide it into categories, we might need more of them - e.g. where to put stuff like Top Window Transparency, Multimedia Timers (not sure that one belongs there, but I want to have it somewhere) | 14-Oct-09 11:49 |
| 295 | Pekr | cool .... | 14-Oct-09 11:44 |
| 294 | Henrik | Like the Parse Project page, we now have a View Project page: http://rebol.net/wiki/View_Project Please fill in your proposals. | 14-Oct-09 11:41 |
| 293 | Henrik | A View proposal would be good, but we need to compile more information. We already have the GUI proposal. | 14-Oct-09 11:35 |
| 292 | Pekr | So, do we write View/GUI enhancement proposal? :-) | 14-Oct-09 11:35 |
| 291 | Henrik | Cyphre, posting privately. | 14-Oct-09 11:32 |
| 290 | Maxim | for me its not speed as much as massively usefull (and free) functionality. | 14-Oct-09 10:51 |
| 289 | Maxim | "and we can " = "since we can't" | 14-Oct-09 10:50 |
| 288 | Maxim | with two splines and enough information gathering, we can easily render bending geometry and stuff like that... right now... its highly complex, and we can use the internal AGG binary math to calculate all the coordinates to stuff for us... based on the current transforms, and stuff. | 14-Oct-09 10:49 |
| 287 | Maxim | for me the draw stroke persistence, is mainly for allowing interaction between the application and the graphics... text on curves... spline paths for animation, snap to edge, etc. | 14-Oct-09 10:47 |
| 286 | Maxim | (that's bits per channel) | 14-Oct-09 10:45 |
| 285 | Maxim | or even 64 bits, for float or HDRI, shadow maps, etc... image manipulation. | 14-Oct-09 10:45 |
| 284 | Maxim | I would also like tuples with a bigger scale. something like 16 bit color values... | 14-Oct-09 10:44 |
| 283 | Maxim | yep... just noting how to do it currently. | 14-Oct-09 10:43 |
| 282 | Cyphre | Maxim, we could have subpixel precission without the scaling trick. We just need to push Carl to make PAIR! to support decimal values ;) | 14-Oct-09 10:43 |
| 281 | Maxim | its usually better to generate larger shapes and scale them down, this way you have sub-pixel precision when drawing. all you need to do is scale the widths and transform the coordinate space when you draw... | 14-Oct-09 10:41 |
| 280 | Cyphre | ok,no hurry... | 14-Oct-09 10:18 |
| 279 | Henrik | need to get some food, back in about 30 minutes | 14-Oct-09 10:18 |
| 278 | Henrik | That was an SVG converted to DRAW, but I'll see what I can find. | 14-Oct-09 10:17 |
| 277 | Cyphre | can you provide the DRAW data for the octagonal/triangle icon? I'd like to try something.... | 14-Oct-09 10:15 |
| 276 | Henrik | also the triangle is troublesome | 14-Oct-09 10:04 |
| 275 | Henrik | It works for the round .r icon, because it's easy to control the size of each filled circle, but not for the octagonal icon at the bottom. | 14-Oct-09 10:03 |
| 274 | Henrik | http://rebol.hmkdesign.dk/files/r3/gui/094.png | 14-Oct-09 10:02 |
| 273 | Henrik | one second. | 14-Oct-09 10:01 |
| 272 | Henrik | My suggestion was three keywords: hint, hint-x and hint-y. Then you would first provide your scaling transformation, say 0.1. Then you provide your shape, and then add hint, hint-x or hint-y on each coordinate individually. Those would then be hinted to the nearest whole pixel internally. "Well, just turn of Antialiasing" No. The difference between this and turning off AA is that you can't make hinted rounded rectangles with AA and you can't get a pretty hinted rounded rectangle without AA. | 14-Oct-09 10:01 |
| 271 | Cyphre | Henrik, how could gradients for lines help with downsaclin of vector shapes? Can you show me example of the 'downscaled icon'? | 14-Oct-09 10:01 |
| 270 | Henrik | For some reason, hinting is going to be hard to implement for DRAW. I talked this alot over with Gabriele, who felt it was not possible to do. It would still be very nice to have for truly scalable GUIs. | 14-Oct-09 9:58 |
| 269 | Henrik | About having gradients for lines, this for me would be a solution to the problem that complex drawings that scale, can't be hinted properly. I saw this when making some icons for R3 and then scaling them. At 1:1 they look fine, but lots of detail is lost, when they are scaled down. | 14-Oct-09 9:56 |
| 268 | Cyphre | If you are talking about caching of the coordinates....that was my question. For small(simple) datasets this can have almost no effect so bitmap caching would be much efficient in such case. For bigger(complex) datasets there can be performance gain(but this needs to be proved by some experiments). The persistency Maxim mentioned is about caching the previous internal data. But question is if this should be driven by GC(no need to care about it from the prog. POV - but can lead to higher memory consumption) or by developer (programmer have the full control on it - but can be tricky for beginners...but yes, we are talking 'advanced' feature here ;-) ) | 14-Oct-09 9:52 |
| 267 | Pekr | what about caching of results? | 14-Oct-09 9:36 |
| 266 | Cyphre | Maxim, yes, I think this is one fo the ideas we discussed at DevCon in Paris. If we add the DRAW shape->coordinates interface this will be yet another usage of it. The current internal architecture already counts with sort of persistency. Currently we are just discarding all the internal shape paths on every redraw. I fear the main problem is how to handle this efficiently at the REBOL layer, especially GC handling...it can lead to big memory consumption in case programmer won't free all references to the DRAW elements etc. Or maybe a command for manually edstroying the 'DRAW internal context' would be the best solution... Another question is, even if we solve the REBOL high-level access interface to it, how much would direct DRAW element modification at such internal level affect the performance, is it really worth doing that(ie make things more complex)? Because in that case we will be only 'bypassing' the DELECT parser and AGG's internal Coordinate conversion pieline(s)...the rasterizing/rendering pahse needs to be always redone(but we could try to play with some clipping tricks here too). Both parts are already very fast but I agree there can be gain in some large data cases. This needs to be investigated before we decide to add such feature. | 14-Oct-09 9:31 |
| 265 | Maxim | but it means the internals need to have a persistency added to them, which definitely changes the architecture. | 14-Oct-09 3:30 |
| 264 | Maxim | my idea for draw elements was to allow set words in the draw dialect, and then be able to interact with the strokes rather than the whole block... since the conversion to/from AGG-REBOL doesn't need to be done all the time, some time is spared. most of the time, we only need the dialect to create stuff... then, we can just manipulate it. also it would allow us to get information about the strokes ex: [s: spline 50x50 100x100 30x4] print s/length? ; get spline length, in pixels print s/coord-at-length 45 ; get coordinate at 45 pixels down the spline. | 14-Oct-09 3:29 |
| 263 | Pekr | We should put it into View proposal I suggested to create ... | 13-Oct-09 17:15 |
| 262 | Cyphre | I think it should be stored in R3's bug/wish tracker. I don't think graphics is Carl's priority right now. | 13-Oct-09 16:16 |
| 261 | Steeve | Will you transfer the request to Carl ? | 13-Oct-09 16:13 |
| 260 | Cyphre | Ofcourse, the DRAW function wouldn't draw anything in case of using such refinement so no need to worry...I bet Carl will make the last decision about the wording and I know I'm not good at it so...yes something like that ;) | 13-Oct-09 16:12 |
| 259 | Steeve | i would prefer a silent functions which actually doesn't draw anything, but only returns the coordinates of the bounding box, or the coordinates of all pixels de traw (good idea btw). COORDINATES draw-block. return a block of pairs (coordinates) of the pixels to draw Carefull, may be really huge. Perhaps a mask is better (an image or a bitset) COORDINATES/BOUND draw-block return only the min-max coordinates. Well well... | 13-Oct-09 16:06 |
| 258 | Cyphre | Ok, so you need the 'bounding box' , got it. I think this can be added...for example as special refinement of DRAW native command? BTW I remember I also wanted to be able return all generated pixel coordinates of any DRAW defined shape. That can be also very useful. | 13-Oct-09 15:58 |
| 257 | Steeve | re 1/
Well you're right, it's the responsability of the client (parser) to do unit conversions.
But to do so, we need to know where the renderer draw each pixel (i mean the real coordinates) of a given shape, to calculate the bounding box.
Take an arc for example, it's impossible to calculate where the pixels of the arcs are drawn without simulating the complete AGG engine.
There may be various transformations to apply on that calculation (matrix, translation, scaling, rotation, skewing).
To calculate that, we have to simulate exactly what AGG is doing. Mission impossible | 13-Oct-09 15:55 |
| 256 | Cyphre | Henrik, I don't think so. We had some discussions about this long time ago but not recently IIRC. | 13-Oct-09 15:48 |
| 255 | Henrik | Cyphre, Maxim has also had some ideas for manipulating draw elements directly very quickly. Have you been in contact with him regarding those ideas? | 13-Oct-09 15:40 |
| 254 | Cyphre | re 1/
yes, I don't think this is a problem of DRAW but more problem of unit conversion. DRAW works with pixels as it it low level dialect (not only for rendering SVG format). So the higher level code(SVG parser) should be responsible for this until I am missing something. re 2/ gradients for outlines were planned for addition so I hope this will be in the R3 final release ;-) re 3/ transparent outlines are known problem. (BTW is this working properly in other SVG renderers? I'd like to see the results) This is because we are using rasterizer which is drawing one shape over another. IMO solution could be to replace the rasterizer with different one (for example like Flash) which is simulating 'Constructive Solid Geometry'. But this would need major changes in the current internal implementation (and in fact also switch to higher version of AGG). My guess is it could also speed-up the rendering in some cases...I started to investigate this area but it needs more time which I currently don't have :-/ | 13-Oct-09 15:38 |
| 253 | Steeve | yep it would help | 13-Oct-09 15:26 |
| 252 | Pekr | IIRC Henrik requested gradients for lines, so actually 2) might be usefull too? | 13-Oct-09 15:21 |
| 251 | Steeve | My, my, my... I think some features in SVG, are too much work to implement with Rebol. 1/ The "objectBoundingBox" units. Which means, coordinates and lengths are ratio or percentages. And they are converted to real units depending of the bounding box of the shape on which they apply. It's easy to calculate when the shapes are boxes or vectors. But when it comes with arcs or curves, it becomes a pain in the ass. It's not a real problem because Inkscape for example has an option (simplify shapes) to convert all the ratio units in real units (ie. pixel units). So, I don't see the interest to rewrite DRAW from scratch with Rebol. (because it's what it means, to be able to calculate all the bounding box) 2/ Outlines with gradients Those fullishs can specify a gradient for the pen attribute (which draw the outlines). Rebol can only have a gradient to fill a shape. It can be simulated by drawing the related shape 2 times. 1 time with the pen gradient. A second time with the fill-pen attribute (which can be a gradient too). But the second time the shape must be, at first, downsized of the line width. To do so, it means that we need to know the center of the Bounding box of the shape. So, same problem than 1/ 3/ The fill-pen attribute (gradient or color) never apply on the outline of the shape, event if the outline has no color but actually has a width. It allows SVG for example, to have transparent outlines. We can't do that with Rebol. Because the fill-pen attributes (or the gradient) fills all the shape at first. And then the outline is drawed over. If we don't provide a pen color, or we provide a transparent color, we see the fill-pen content instead, at the place of the outline. Perhaps, that can be modified in Draw. A nice request but not a so considerable feature to my mind. (And it can be impossible to implement this in Draw, if AGG doesn't support it at first). | 13-Oct-09 15:13 |
| 250 | Steeve | But... | 13-Oct-09 15:13 |
| 249 | Steeve | Hello Cyphre, good work, you've done with gradients. | 13-Oct-09 15:12 |
| 248 | Cyphre | Nice work Steeve! I'm glad R3 gradient improvements in DRAW were useful. It shouldn't be a big problem to render SVG using R3 draw. Bigger issue is to be able to parse all the possible SVG content you can find on the net ;-) | 13-Oct-09 15:03 |
| 247 | BrianH | (stupid keyboard) | 13-Oct-09 9:06 |
| 246 | BrianH | Fortunately, "or somethoing" includes wrapping a server task around your data. Shared service rather than shared data. | 13-Oct-09 9:05 |
| 245 | BrianH | Unless you do locking or something. | 13-Oct-09 9:04 |
| 244 | Steeve | hmm... | 13-Oct-09 9:03 |
| 243 | BrianH | That reuse is what won't be task-safe. Only non-modifiable series will be sharable. | 13-Oct-09 9:02 |
| 242 | Steeve | not globaly | 13-Oct-09 9:01 |
| 241 | Steeve | no | 13-Oct-09 9:01 |
| 240 | Steeve | n | 13-Oct-09 9:01 |
| 239 | Steeve | but it has to reuse the same block, in a context | 13-Oct-09 9:01 |
| 238 | BrianH | Then you aren't reusing, which is why it will be task-safe. | 13-Oct-09 9:00 |
| 237 | Steeve | or with reuse: copy/deep :reuse | 13-Oct-09 8:59 |
| 236 | Steeve | Obfuscated thing | 13-Oct-09 8:58 |
| 235 | Steeve | To be task safe, the module should reinitiate the function like this: reuse: make :reuse [] | 13-Oct-09 8:58 |
| 234 | BrianH | Yeah, a closure that returns a function is a good pattern. However, a closure by itself won't reuse the block. It's the reuse that is the problem - the block probably won't be task-safe. | 13-Oct-09 8:44 |
| 233 | Steeve | Probably should be implemented with a closure! | 13-Oct-09 8:41 |
| 232 | BrianH | REUSE might run into problems with multitasking. Ladislav has talked about adding a native atan2. | 13-Oct-09 8:37 |
| 231 | Steeve | As far i am, i made some useful tiny mezz, perhaps some could be in R3. reuse: funco [b [block!]][head reduce/into b clear []] ** REUSE, reduce a block, but re-use always the same block ** Actually, 3 time slower than a reduce block, but save memory and GC recycles if used massivly. ** I use it to pass small blocks of coordinates. mulm: func [ {multiply a matrix [a b c d e f] by coordinates x y, return coordinates [x' y']} x y m [block!] ][ reuse [x * m/1 + (y * m/3) + m/5 x * m/2 + (y * m/4) + m/6] ] atan2: func [ {Angle of the vector (0,0)-(x,y) with arctangent y / x. The resulting angle is extended to -pi,+pi} x y ][ if x = 0 [x: 0.0000000001] add arctangent y / x pick [0 180] x > 0 ] Project: func [ {orthogonal projection of a point P on a line AB, return coordinates [x y]} ax ay bx by px py /local sx sy ux uy ratio ][ sx: bx - ax sy: by - ay ux: px - ax uy: py - ay ratio: sx * ux + (sy * uy) / (sx * sx + (sy * sy)) reuse [ratio * sx + ax ratio * sy + ay] ] vector-length: func [x1 y1 x2 y2][square-root add x2 - x1 ** 2 y2 - y1 ** 2] | 13-Oct-09 8:32 |
| 230 | shadwolf | on my computer your annimation is lighting fast ... (maybe too fast) it's a very lively lizar lol | 13-Oct-09 1:34 |
| 229 | shadwolf | congratulation steeve anyway ^^ | 13-Oct-09 1:33 |
| 228 | shadwolf | (and yeah you will say to me but why you don't do your solution os-commerce like based in rebol ?) hum the amount of capabilities in a e-shop web site clients are used to see now in days are big... Stat tools, catalog edition, shiping, card. And then the hosting solution simply doesn't know about rebol so if it's not apache/php/mysql or apache/java/mysql you are fried unless you have full access to the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol etc...) | 13-Oct-09 1:30 |
| 227 | shadwolf | can't anyone shake that area and put rebol in it .... something like a rebol os-commerce all strong and mighty in 200Ko ... Ok you can go to 2Mo last limit... lol | 13-Oct-09 1:23 |
| 226 | shadwolf | why clients wants those shits ???? because they read that apache + php + mysql + ajax/css was the top of art .... yurk ... | 13-Oct-09 1:20 |
| 225 | shadwolf | i'm fighting with several e-commerce solution (free ware) for a client i want to die ... how can web 2.0 without rebol can be such a pain T___T Oscommerce, thelia, virtuemart, prestashop, magento, zencart, OSCC ... have cool back offcie cool functionnalité but when you don't want to fit to the header, menu, left_col, document, right_col, footer design you are face big troubles allmost all the engine in those product is to be remade.... | 13-Oct-09 1:19 |
| 224 | shadwolf | rebol even our splash screen are ass kickers ;P | 13-Oct-09 1:14 |
| 223 | shadwolf | steeve is working on annimated splash screen logo animated in svg for the next version of viva-rebol :P | 13-Oct-09 1:14 |
| 222 | shadwolf | wahoo ... lot to read .. T___T basically there is in Draw/AGG some limitations due to gradient system and matrix translation bugs i don't know if they have been solved since i pointed a them ... | 13-Oct-09 1:07 |
| 221 | Maxim | meant... yeah that's it... | 12-Oct-09 21:51 |
| 220 | Maxim | yeah that its. | 12-Oct-09 21:51 |
| 219 | Steeve | delect | 12-Oct-09 21:50 |
| 218 | Maxim | doesn't DRAW use the other fast dialect making parser? don't remember its name. | 12-Oct-09 21:50 |
| 217 | Steeve | why parse ? | 12-Oct-09 21:49 |
| 216 | Henrik | well, it should do the same in R3. at least it did in earlier builds, but does PARSE have anything to do with that? | 12-Oct-09 21:48 |
| 215 | Steeve | yep it depends... Brian"s heisenbugs are everywhere in draw | 12-Oct-09 21:48 |
| 214 | Maxim | it depends on the error... its the same in R2. | 12-Oct-09 21:46 |
| 213 | Steeve | that's not what i got. i got a blank screen when an error occurs. | 12-Oct-09 21:46 |
| 212 | Henrik | it usually renders up until the error occurs | 12-Oct-09 21:46 |
| 211 | Steeve | blank page, that''s what you got | 12-Oct-09 21:43 |
| 210 | Steeve | There is another problem with draw in Gobs. When there is an error in the commands, nothing is showed but you don't know where it comes from. | 12-Oct-09 21:43 |
| 209 | BrianH | Heisenbugs are the worst :( | 12-Oct-09 21:36 |
| 208 | Steeve | You know it's a problem when you can't replicate the bug and focus clearly what the problem is. Carl put a spell on me because of that (in his last note) | 12-Oct-09 21:36 |
| 207 | BrianH | I know we haven't been focussing on graphics or GUI bugs lately, but you should at least write the graphics bugs down somewhere. | 12-Oct-09 21:34 |
| 206 | BrianH | I'd put a :( on that. | 12-Oct-09 21:33 |
| 205 | Maxim | hehe | 12-Oct-09 21:33 |
| 204 | Steeve | sometimes ;-) | 12-Oct-09 21:32 |
| 203 | Maxim | to image works though? | 12-Oct-09 21:32 |
| 202 | BrianH | They probably call the same code internally, but the draw function may be crashing in a non-shared portion of its code. | 12-Oct-09 21:32 |
| 201 | Steeve | i wonder why it's crashing. I thougth gobs was using the DRAW function in background, but seems not... | 12-Oct-09 21:30 |
| 200 | BrianH | The DRAW function is still there? I really need to pay more attention to the graphics stuff. | 12-Oct-09 21:29 |
| 199 | Steeve | By the way the DRAW function can't render that, it's crashing. | 12-Oct-09 21:28 |
| 198 | Maxim | that was seriously missing in R2 draw.. happy its in R3 :-) | 12-Oct-09 21:27 |
| 197 | BrianH | Cool :) | 12-Oct-09 21:26 |
| 196 | Steeve | but the new grad-pen command of draw is awesome | 12-Oct-09 21:26 |
| 195 | Steeve | not so much ;-) | 12-Oct-09 21:24 |
| 194 | BrianH | Draw should be the same, afaik, which isn't that far. Have the parse improvements helped? | 12-Oct-09 21:23 |
| 193 | Steeve | yes it's R3 | 12-Oct-09 21:22 |
| 192 | BrianH | Seriously? Cool :) | 12-Oct-09 21:22 |
| 191 | Maxim | we should also note that this is in R3 :-) not everyone realizes this IMO. | 12-Oct-09 21:22 |
| 190 | BrianH | It's a good one. It looks identical to yours, though that may be server side in your example link. | 12-Oct-09 21:21 |
| 189 | Steeve | i don't know which renderer chrome uses | 12-Oct-09 21:21 |
| 188 | BrianH | Sorry, got tired of the shouted group name/description :) | 12-Oct-09 21:20 |
| 187 | Steeve | i only checked with google chrome, it was very similar | 12-Oct-09 21:20 |
| 186 | Steeve | ok | 12-Oct-09 21:19 |
| 185 | Maxim | also the anti-aliasing was a result of my browser which rescaled the image minus 5 pixels... so it has nothing to do with your render. | 12-Oct-09 21:19 |
| 184 | Maxim | there seems to be two spots missing on the left left... very faint, but missing or not visible at least. | 12-Oct-09 21:18 |
| 183 | Maxim | if you draw the outlines twice, they should be a bit crisper... is that what you mean? | 12-Oct-09 21:13 |
| 182 | Steeve | Not the problem of the antialiasing, I just think i made a false translation of the command used in the shapes. They use a smouthing curve, me not i guess. I have to verify that. But Rebol can draw smoothing curves too, no problemo. | 12-Oct-09 21:10 |
| 181 | Maxim | the difference in your render and SVG render is mainly the anti-aliasing, which is crisper in the svg renderer.... probably has a better algorythm setup than the one use by R3... this is probably manageable within AGG, but AFAIK there is no control for it within R3. | 12-Oct-09 21:03 |
| 180 | Steeve | Added a litte animation. The bumping lizard !!!! http://sites.google.com/site/rebolish/test-1/lizard.r | 12-Oct-09 20:55 |
| 179 | Maxim | GREAT WORK Steeve :-) | 12-Oct-09 20:54 |
| 178 | Steeve | Basically, you can load the draw block generated for the lizard here. it's handed by the variable PANE. http://sites.google.com/site/rebolish/test-1/lizard.r | 12-Oct-09 20:28 |
| 177 | ICarii | great work steeve! :) | 12-Oct-09 20:18 |
| 176 | Graham | Nice ... | 12-Oct-09 20:05 |
| 175 | Steeve | Guys, i updated the lizard.svg rendered with Rebol http://sites.google.com/site/rebolish/test-1/lizard-rebol.png
To compare with http://sites.google.com/site/rebolish/test-1/lizard.svg. I'm glad to announce that i see absolutly no differences inside Google chrome. All the grandients (linear and radial) are perfectly rendered by Rebol. | 12-Oct-09 16:32 |
| 174 | Steeve | Ok, done | 12-Oct-09 16:14 |
| 173 | Steeve | Gezz... i forget the rotation of the ellipsoid... more work... | 12-Oct-09 16:02 |
| 172 | Steeve | Ok, i finished with Radial gradients (less the impossible feature: 2 different centers) SVG use a matrix transformation to convert a circular radial gradient into an ellipsoid. And you know what ? We can do the same thing with grad-pen which provides 2 scalling factors (grad-scale-x and grad-scale-y) So in that case it's easier than for linear-gradient. 1/ take the focal point of the Radial gradient (fx, fy) 2/ Create 2 vectors starting from this point: 1 vertical and 1 horizontal, using the radius as their length. 3/ apply the matrix transformation on them. 5/ get the component X of the transformed horizontal vector, and the component Y of the transformed vetical vector 6/ grad-scale-x: x / r 7/ grad-scale-y: y / r That's all folks | 12-Oct-09 15:42 |
| 171 | Steeve | By default Inkscape don't use that feature when you design a radial vector. | 12-Oct-09 13:55 |
| 170 | Steeve | i think that feature (2 different centers) is not used that much. In the lizard.svg example i gave, they don't use it, the 2 centers are always equal. | 12-Oct-09 13:54 |
| 169 | Steeve | in fact, i think i could simulate that behavior.
By
1/ rendering the radial gradient in the initial circle.
2/ create an image with that circle and clip it with the shape of the second one.
3/ Use that image as a pattern for the fill-pen attribut But it would be a mess of computing time and of memory, because in the draw block we would have images used as pattern instead of computed gradients | 12-Oct-09 13:52 |
| 168 | Steeve | I'm angry, i don't see why grad-pen in Rebol should allow such stupid feature | 12-Oct-09 13:46 |
| 167 | Pekr | Now the question is - should we adapt, or do we create copy of such functions, to allow being compatible? | 12-Oct-09 13:43 |
| 166 | Steeve | Well i thought SVG 's radialGradients will be easier. I was wrong.
SVG Proposes another stupid feature (yet another one).
Actually they can specify 2 circles.
One where the gradient is really rendered. And another one used as a window which clips the first one.
What the heck is that !!!!
it's why in a SVG's radial gradient, there is 2 different centers (cx, cy) (fx, fy) for the 2 separated circles. When the 2 centers are equals, then there is no prolem to render it whit the rebol's radial gradient, easy. But when they differ, it's impossible. I can't blame Rebol to not allow that, because it's a really stupid useless feature. | 12-Oct-09 13:41 |
| 165 | Steeve | I show you that part of my code... switch type [ linear [ unless x2 [x2: x1] unless y2 [y2: y1] if matrix [ ; ** apply the matrix on the vector rotated of 90°, then rotate it back, give the vector V1 set [y1' x1'] mulm y1 negate x1 matrix set [y2' x2'] mulm y2 negate x2 matrix x1': negate x1' x2': negate x2' ;** apply the matrix on the initial vector, give the vector V2 set [x1 y1] mulm x1 y1 matrix set [x2 y2] mulm x2 y2 matrix ;** project the vector V2 on the line V1 set [x1 y1] project x1' y1' x2' y2' x1 y1 set [x2 y2] project x1' y1' x2' y2' x2 y2 ] angle: atan2 x2 - x1 y2 - y1 if units = "objectBoundingBox" [ x1: box/1/x * x1 y1: box/1/y * y1 x2: box/2/x * x2 y2: box/2/y * y2 ] out as-pair x1 y1 ;** offset out 0 ;** start rng out square-root add x2 - x1 ** 2 y2 - y1 ** 2 ;** stop rng out angle ;** angle ] ... | 12-Oct-09 11:53 |
| 164 | Steeve | This matrix must not be applied on the gradient's vector as-is, but on something else.
And i found what, at least... The documentation of SVG is lacking of a good explanation about this curious matrix transformation. All we can read is that curious sentence: "When the object's bounding box is not square, the stripes that are conceptually perpendicular to the gradient vector within object bounding box space will render non-perpendicular relative to the gradient vector in user space due to application of the non-uniform scaling transformation from bounding box space to user space" What does that mean ????? It means that the SVG gradient must be rendered without using the matrix transformation. And THEN the transformation matrix must be applied on the resulting strips. You see the problem ? The matrix must not be apllied on the gradient's vector, but on the resulting strips produced by the use of the initial gradient's vector. What foolish morons have designed such a complicated way of constructing gradients. Can't they just give a matrix that can be applied on gradient's vector as-is, no they can't, it's to simple. Morons, I said !!! Because of that i had to make more transformations to obtain the REAL vector. step by step I do something like that: 1/ Take the initial gradient vector V and apply the matrix on it, it gives a vector V1 2/ RE-take the initial vector V, rotate it of 90 degrees, apply the matrix on it, and rotate back the resulting vector . It gives the vector V2 3/ Project the vector V1 on the line V2 (orthogonal projection). It gives a third vector V3. 4/ That's all, the REAL vector to use for the gradient is V3. It take me a while to figure that, by analysing the Inkscape rendering. Morons i said !!! | 12-Oct-09 11:29 |
| 163 | Pekr | Steeve - your work is quite impressive! Just don't become demotivated by possible lack of responses :-) If you find some bugs, or you come up with some ideas of how to make View more SVG friendly, write your notes down, we can discuss it with Cyphre. I think that we are still in rather initial phase, so we can e.g. change the way of how e.g. gradient-fills work (I do remember someone reported that you can't translate gradient definitions between /draw and SVG) | 12-Oct-09 8:24 |
| 162 | ICarii | btw the bounding box call in the second sizing mode can be gotten from the size of the canvas you are drawing to. | 12-Oct-09 2:07 |
| 161 | Steeve | Well, i think i got it for the linear gradients... | 12-Oct-09 1:48 |
| 160 | Steeve | when matrix transformations are applied, some are wrong, but hey ! Quite a good result already ! | 11-Oct-09 13:41 |
| 159 | Steeve | the gradients still have the same problem | 11-Oct-09 13:39 |
| 158 | Steeve | And what i got with rebol: http://sites.google.com/site/rebolish/test-1/lizard-rebol.png | 11-Oct-09 13:38 |
| 157 | Steeve | the svg i test currently (public domain) http://sites.google.com/site/rebolish/test-1/lizard.svg | 11-Oct-09 13:35 |
| 156 | Steeve | Well, assuming you got x1,y1,x2,y2 from the Lineargradient I calculate the angle like that: arctangent (y2 - y1) / (x2 - x1) As i said previously, the angle is correct when there is no matrix transformation on the gradient. I compare the rendering with what i see in Inskape. | 10-Oct-09 22:40 |
| 155 | ICarii | what sort of output are you getting for the angle in the grad-pen call? | 10-Oct-09 19:14 |
| 154 | Steeve | To be precise, the resulting vector seems to have the correct position and length, but a wrong angle. | 10-Oct-09 13:26 |
| 153 | Steeve | Currently my problem is with the linear gradients when a matrix operation is applied on them. The linear gradient use a vector v = (x1, y1) - (x2, y2) to indicate his direction and length. grad-pen is defined like this: [grad-pen linear normal xy 0 len angle [... stop colors]] And i calculate his values with: - xy = (x1,y1) - len = length of the vector v - the angle of the vector v When a matrix is associated with the gradient, i multiply the coordinates of the vector v by the matrix before calculating the other values. It's working well when the gradient is vertical or horizontal. But when the gradient is inclined , the matrix multiplication give a wrong vector and i don't know why. | 10-Oct-09 13:19 |
| 152 | Steeve | Icarii, your svg file is too much complicated for me.
It's using both gradientUnits="objectBoundingBox" and gradientUnits="userSpaceOnUse" to render the gradients. "userSpaceOnUse" use real coordinates for the vectors used by gradients (what i do currently). "objectBoundingBox" use % vectors which have to be converted into real unit, depending of the real size of the object (after rendering) where the gradient is applied (what the fuck !!! it's magic). I have enough pain to construct correct gradients in real units for the moment.Your svg file is too much complicated. | 10-Oct-09 12:59 |
| 151 | ICarii | I've been playing with Shadwolf/etc SVG 06 svg renderer today and am at the point where i am working on linking in gradients. The test SVG i am using (because it seems to be a good mix) is http://en.wikipedia.org/wiki/File:SVG.svg | 10-Oct-09 9:11 |
| 150 | Steeve | Oh my, SVG, what a pain... Some strange bugs, i can't figure... As you can see here http://sites.google.com/site/rebolish/test-1/lizard-grad-err.png I've got some problems to map correctly the gradients on the shape they are supposed to cover. i can't figure why the coordinates of the gradients in the SVG file are wrong. It's not clear (http://www.w3.org/TR/SVG11/pservers.html#Gradients) where the gradients should start.... | 10-Oct-09 0:09 |
| 149 | shadwolf | okay thank you for the link in my idea my SVG/REBOL graph render should be easy to use and render basical graphs using a psecial graph dialect but ofcourse it will be enhanced afterward... | 10-Nov-06 18:04 |
| 148 | shadwolf | sur i do ^^ | 10-Nov-06 18:02 |
| 147 | Normand | If any person is interested in developping graphs in Rebol they may find the following links of interest: www.combinatorica.com which have the source code in mathematica for calculating graphs and depicting them. There is also the C library at www.graphviz.org and the many little languages drivers. | 1-Jul-06 17:29 |
| 146 | Pekr | 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." | 20-Jun-06 19:29 |
| 145 | Thør | . | 4-Apr-06 19:01 |
| 144 | shadwolf | would be fun i think | 2-Feb-06 3:01 |
| 143 | shadwolf | graph [ line "apple" red 5 12 12 8 line "banana" green 1 2 3 4 6 ] | 2-Feb-06 3:01 |
| 142 | shadwolf | some thing like | 2-Feb-06 2:59 |
| 141 | shadwolf | you have that in php and in ruby or php for example why not rebol starting from the point that rebol dialectal ability is incredible it's a pitty to not take advantage of it and show ppl hat rebol can apport on this particular application and this gives a good way to compare rebol to the other scripting language | 2-Feb-06 2:58 |
| 140 | shadwolf | as svg or as png in a simple and easy way | 2-Feb-06 2:54 |
| 139 | shadwolf | on a project like an svg graph system save.png take really all it's sens imagine a way to make easyly graphs with your rebol GCI to display graph stats in your web pages for example | 2-Feb-06 2:53 |
| 138 | shadwolf | 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 | 2-Feb-06 2:51 |
| 137 | shadwolf | Anton i discover it recently ^^ | 2-Feb-06 2:50 |
| 136 | Anton | View 1.2.1 has save/png, it's not very new... | 2-Feb-06 2:19 |
| 135 | shadwolf | if some one is interressed to make it and need informations i'm ready to help ^^ | 2-Feb-06 2:16 |
| 134 | shadwolf | hum new rebol/view have save/png hability woooooooooooopy so there is nothing that prevent us to make a graph /AGG/SVG/PNG dialect ^^ | 2-Feb-06 2:15 |
| 133 | shadwolf | surfing around on internet i found another common application for SVG -> graphs representation. The idea is inspired by a ruby project http://www.germane-software.com/software/SVG/SVG::Graph/#N10034. To do this in rebol we need teh ability to save data in an image PNG. The way we can use a thing like this could be to use a simple rebol draw based dialect to write the graphs if we are in REBOL/view application the graph is isealy shown if we need to show the graph in webrowser we can have 2 external sources SVG and PNG. For importing graphs from another application the SVG is the best way. So our REBOL::SVG::GRAPH would be able to import graphi content from a SVG file, output SVG and PNG files, render graphs to REBOL/view draw pane, propose a simple way to implement graphs using a rebol dialect. | 24-Jan-06 20:13 |
| 132 | shadwolf | Joe hum inkscape is not able to show this svgz file that's strange ... I will try to investigate why this happend ... | 4-Jan-06 1:22 |
| 131 | Joe | shadwolf, a good example to use with your svg renderer is the word map with political borders (public domain license) http://www.mappinghacks.com/maps/world_borders.svgz | 3-Jan-06 11:31 |
| 130 | Ashley | When I find some spare time. ;) Next week or two hopefully. | 3-Jan-06 6:13 |
| 129 | JaimeVargas | Ashely when are you updating RebGUI? | 3-Jan-06 3:08 |
| 128 | Ashley | One other big advantage is that there is a lot of high-quality SVG in the public domain, and it's growing fast. | 3-Jan-06 2:58 |
| 127 | shadwolf | 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) | 2-Jan-06 23:48 |
| 126 | shadwolf | but this not means i'm not anymore interrested by the project or that the project is dead. I found like you pretty hudge hopes on the integration of High scalable grphics in rebol ^^ | 2-Jan-06 23:35 |
| 125 | shadwolf | ty ashley ^^ time i wasn't giving notice of my progress but mainly because Gradeint and transform problem where dependent on AGG an not on my script. | 2-Jan-06 23:33 |
| 124 | Ashley | Well done, keep up the good progress! ;) | 2-Jan-06 2:13 |
| 123 | shadwolf | In the futur i hope we will use a lot svg in dynamic drawing composition. | 1-Jan-06 6:03 |
| 122 | shadwolf | I still take as SVG workshop / reference software INKSCAPE pretty good LGPL sofware available for all OS. | 1-Jan-06 6:02 |
| 121 | shadwolf | well last thing i can say is that SVG rendering engine is very high on my task list ( task number one) i worked on the adding of some other new drawing primitive (image rect, circles). I will continue to work on the close support of all SVG datas that can have a meaning in AGG context. SVG rendering engine is a 2 weeks of work only!!! ... until i fall on the gradient and transforms problems so this ensure us advancing on this project will be very fast once we solve bugs in REBOL/View related to AGG (wich is in progress actually) | 1-Jan-06 6:00 |
| 120 | shadwolf | transform problem are on their way to be solve gradient too by cyphre and Carl those two things are the most blockant problems until they are not completly solved we can't expect to have a full working SVG rendering engine -> most of SVG imagines use transform effects and gradients this means that if we want to get a pretty good and reliable SVG engine we have to fixe those two issue. SVR rendering engine is a good and hudge test upon AGG integration to REBOL/View and it allows us to embetter it !!! Once we get a fully working engine with basic human understandable algorithm i will start the optimisation process using parse (but to be franck i don't know how parse will react in front svg row data or how will be the time to dev this parse based SVG engine ... in all cases I think the actual engine have teached me a lot arrounf the SVG to AGG adaptation process so i hope the translation to parse and parse/rules will not be too hard and too long) | 1-Jan-06 5:53 |
| 119 | shadwolf | For ppl interrested in SVG rendering engine. My tonight work and test on the engine is resumed in the AGG topic. To resume before matrix bug as causing bad scale and bad position. Now we have good position but still bad scale i post screen cap samples and we can see that the evolution is good betwin View 1.3.1 and 1.3.2 | 1-Jan-06 5:45 |
| 118 | shadwolf | personnaly I'm working with InkScape a very good SVG software... | 5-Aug-05 11:15 |
| 117 | shadwolf | Good list ;) | 5-Aug-05 11:15 |
| 116 | Robert | FYI: Ed Pegg writes "I did a survey of all available vector-based drawing programs, in anticipation of SVG in the next Firefox. I found 29 different vector drawing programs. Of these, 14 were free or open source. More than I expected. Did I miss any good ones?" http://developers.slashdot.org/article.pl?sid=05/08/02/0117224&from=rss | 5-Aug-05 6:24 |
| 115 | shadwolf | Features still on the work table are: - SVG Transformation translation (mostly matrix) - SVG Gradient translation (linear partern radiant) - SVG drawing primitives (some drawing primitives are not supported actually ) - SVG Animation translation (don't know if this is a usefull and suitable fonctionnality tellme what do you think about it) | 22-Jul-05 9:31 |
| 114 | shadwolf | and I'm close to have found a solution to one of my problems regarding to the transformation matrix | 11-Jul-05 21:58 |
| 113 | shadwolf | I'm hard working on the matrix support .. | 11-Jul-05 21:56 |
| 112 | Ashley | Release 15 of the OpenClipart library is out: http://www.openclipart.org/downloads/index.php ... over 4,000 high-quality *public domain* SVG images! | 11-Jul-05 14:41 |
| 111 | shadwolf | Chanlog:
* Cleaner Code (near 200 lines saved)
* support new draw primitives Ellipse, Path Arc, rect
* recursiv G block parsing have been improved Still not supported * transformation information (matrix,scale, rotate, skew) * gradient information (linear, radiant etc...) * circle, text, line, polyline, polygones | 5-Jul-05 3:29 |
| 110 | shadwolf | http://shadwolf.free.fr/svg-demo-shad05.r | 5-Jul-05 3:24 |
| 109 | shadwolf | here is the new version | 5-Jul-05 3:22 |
| 108 | shadwolf | I have improved the svg rendering engine | 5-Jul-05 3:22 |
| 107 | shadwolf | ************ | 5-Jul-05 3:21 |
| 106 | shadwolf | I improve some more the rendering now the file gnome-keyboard-dev.svg is fully and perfectly rendererd. I put a red pen-fill color for identify all primitives that needs fill:url related gradient | 3-Jul-05 3:06 |
| 105 | shadwolf | corrected ;) | 3-Jul-05 2:12 |
| 104 | shadwolf | I need to handle others drawing primitivs too | 3-Jul-05 2:07 |
| 103 | shadwolf | still lot of work on it gradients and transform handling can be very code consummer | 3-Jul-05 2:06 |
| 102 | shadwolf | my actual code is about 587 lines of code and it's not ended | 3-Jul-05 2:05 |
| 101 | shadwolf | this could be a good promotion point to insert SVG rendering into the rebplug for firefox once it's completed and optimised ;) | 3-Jul-05 2:05 |
| 100 | shadwolf | but what I need are high level information and formation on draw agg and this I know very little people that can respond in this point :) | 3-Jul-05 2:03 |
| 99 | shadwolf | so you have to remaining choice (3 in fact ) 1) using IE but then your not my pal any more, 2) installing Inkscape and relate it to svg file 3) help me finishing the SVG viewer using REBOL !!! ;)) | 3-Jul-05 2:02 |
| 98 | Graham | I got the Adobe plugin to work with firefox eventually. | 3-Jul-05 1:59 |
| 97 | shadwolf | maybe they saw a boggus open door in this plugin and disable it's support (this can be the case for a 1.0.4) | 3-Jul-05 1:59 |
| 96 | shadwolf | GRaham same for me adobe plugin works well with IE but not with firefox | 3-Jul-05 1:58 |
| 95 | shadwolf | so we can see in my code 2 approch for retrieving information one for top level second for g tags (groups can be recursiv) | 3-Jul-05 1:58 |
| 94 | Graham | Firefox is supposed to be able to support SVG ( a subset at least ) without plugins, but I couldn't get it to work. I had to download Adobe's plugin. | 3-Jul-05 1:57 |
| 93 | shadwolf | hahaha ;) | 3-Jul-05 1:57 |
| 92 | shadwolf | oups I make it only for groups ;) | 3-Jul-05 1:57 |
| 91 | shadwolf | now supports rect tag ;) | 3-Jul-05 1:56 |
| 90 | shadwolf | http://shadwolf.free.fr/svg-demo-shad04.r | 3-Jul-05 1:56 |
| 89 | Ashley | No argument here. ;) | 3-Jul-05 1:21 |
| 88 | shadwolf | but you know now my way to work I prefer easy and powerfull /flexible code than hudge monolitic code ;) | 3-Jul-05 1:20 |
| 87 | shadwolf | Handling SVG as REBOL object! tree makes it really really easier to set recursivity and code writing ( as all can be exploded into small fonctions I hope the resulting code once terminated won't be so deficult to read | 3-Jul-05 1:19 |
| 86 | shadwolf | I like the XML primitive draw explorer like a tree view of the compoun of your draw this is particularly good to write SVG renderer | 3-Jul-05 1:18 |
| 85 | shadwolf | I psent lot of time using it (more than 80 hours since this last weeks ) all SVG files that I could found exists | 3-Jul-05 1:17 |
| 84 | shadwolf | I like particularly the capability of generating light weight SVG files (plein text) the drawing tools are simple powerfull very well thinked and pretty good | 3-Jul-05 1:16 |
| 83 | shadwolf | All this to say that it doesn't fall from the sky ;) | 3-Jul-05 1:15 |
| 82 | shadwolf | Inkscape is the successor project of sodipodi (for example you can see reference to sodipodi into teh SVG output files ...) Sodipodi was abandonned by the dev team so some of them retakes it and continue the adventure with inkscape | 3-Jul-05 1:14 |
| 81 | Ashley | I've spent quite a bit of time looking at Inkscape (http://www.inkscape.org/) and it seems to be the only / best SVG game in town (their command-line driven SVG to PNG conversion seems to be particularly well regarded). Looking forward to their 0.42 release as it supports OS/X as well. The Clip Art site that they link to (http://www.openclipart.org/) is also a treasure trove of Public Domain files (which solves the GPL concerns I had with many of the dedicated KDE / Gnome icon sets). I'm also looking forward to their release 15 which seems to be just around the corner. Lots of good news in the SVG world, I wonder how long before mainstream browsers start supporting it? (without plugins). | 3-Jul-05 1:12 |
| 80 | Ashley | Good progress! If you change: "stroke-width" [line-width: to decimal! val] to "stroke-width" [line-width: to-unit val] then it'll run all your sample SVG icon files as well. Wish I knew the answers to your AGG questions, but like you I'm waiting on more documentation / examples. | 3-Jul-05 0:53 |
| 79 | shadwolf | what is not supported are radial / linear Gradient (content and border), transformations (local/global I'm still pending for informations on it) and all other shapes than path (like rect for example) | 2-Jul-05 21:18 |
| 78 | shadwolf | this script support recursive G block (objects /list) and path (object list) | 2-Jul-05 21:13 |
| 77 | shadwolf | try to load all the files that Ashley provides with his svg-demo | 2-Jul-05 21:13 |
| 76 | shadwolf | http://shadwolf.free.fr/svg-demo-shad04.r | 2-Jul-05 21:12 |
| 75 | shadwolf | Okay so here is the first version of my work on SVG to rebol objects tree structure | 2-Jul-05 21:12 |
| 74 | shadwolf | *********** | 2-Jul-05 21:10 |
| 73 | shadwolf | so in Rebol tree object the g block can be a bloc of sub object or an object ;) | 2-Jul-05 16:27 |
| 72 | shadwolf | hum xpdf.svg file shows me a problem with the use of xml-to-object ... if you have serveral g block at the same level all g block are compacted into the same reference | 2-Jul-05 16:26 |
| 71 | shadwolf | I don't know how to treat linearGradient too | 2-Jul-05 15:17 |
| 70 | shadwolf | I still not soleve my matrix problems so until now I don't implement it into the actual code | 2-Jul-05 15:15 |
| 69 | shadwolf | the recursivity treatement for g block are also easier to do | 2-Jul-05 15:14 |
| 68 | shadwolf | I'm still working full time on the S VG renderer. I'm close to be at the same level than the previous code but as I'm working with objects the code seems to be more fast ... | 2-Jul-05 15:13 |
| 67 | shadwolf | *************** | 2-Jul-05 15:12 |
| 66 | shadwolf | at this point code have not drastically change ... like 40% is the same code | 1-Jul-05 10:55 |
| 65 | shadwolf | I solve this issue regarding object retriving information I will enhance this pont to make it recursif retriever | 1-Jul-05 10:55 |
| 64 | shadwolf | and the windows where the draw block is shown | 1-Jul-05 0:02 |
| 63 | shadwolf | in this file we have xml-to-object function load-svg function (mostly empty there is where to put the data conversion and draw block construction) and the widget that start the program | 1-Jul-05 0:01 |
| 62 | shadwolf | http://shadwolf.free.fr/svg-demo-shad03.r | 30-Jun-05 22:32 |
| 61 | shadwolf | wrong adress | 30-Jun-05 22:32 |
| 60 | shadwolf | oups sorry | 30-Jun-05 22:32 |
| 59 | shadwolf | shadwolf.free.fr/svg-demo-shad04.r | 30-Jun-05 22:31 |
| 58 | shadwolf | I give you the code maybe this will be more clear | 30-Jun-05 22:30 |
| 57 | shadwolf | so to build the path we start xml/svg "/ " g or path if g we seek 3 thing transform field and path field or sub g field | 30-Jun-05 22:29 |
| 56 | shadwolf | or maybe build the path xml/svg/path then attribute to a temporary var the foreach ob xml/svg/path [ ob processing ] | 30-Jun-05 22:24 |
| 55 | shadwolf | I I want to interrogate the first shape description on the top level ( out of group blocks) I have to build a path like that xml/svg/path/1/d | 30-Jun-05 22:22 |
| 54 | shadwolf | for example my object is set into xml global variable | 30-Jun-05 22:20 |
| 53 | shadwolf | my point is to make a recursif capapble code | 30-Jun-05 22:20 |
| 52 | shadwolf | and fill the draw block with this data | 30-Jun-05 22:19 |
| 51 | shadwolf | then construc path to get data then translate this data to a draw equivalent exploitable datas | 30-Jun-05 22:19 |
| 50 | shadwolf | this means to interogate the content of the objet a gived level | 30-Jun-05 22:18 |
| 49 | shadwolf | I make a base code but now I have to find a good code to exploit the relevent datas from the object tree | 30-Jun-05 22:18 |
| 48 | shadwolf | this in the goal to improve drastically the performance and be more performant on some key issues like recursivity etc... | 29-Jun-05 20:37 |
| 47 | shadwolf | opkay so we are planning on the opportinity to use a REBOL tree object! structure to represente SVG datas :) | 29-Jun-05 20:36 |
| 46 | shadwolf | it says author hahah ;) | 29-Jun-05 20:35 |
| 45 | BrianW | shadwolf, I'm not the author - just a guy who made it available in the Rebol library :-) | 29-Jun-05 19:36 |
| 44 | shadwolf | okay good stuf in it Vincent and I are planning to use the xml-to-object.r script from Brian Wisti to enbetter and make a more sophisticate support for our actual work upon SVG parsing translation and rendering into a VID window | 29-Jun-05 17:14 |
| 43 | Ashley | Yes, to-unit is called from svg-size; and also from "path d", stroke-width, fill-width, etc ... probably anywhere in SVG where we "expect" an integer or decimal! ;) | 27-Jun-05 3:19 |
| 42 | shadwolf | ?? | 26-Jun-05 20:10 |
| 41 | shadwolf | in svg-size | 26-Jun-05 20:10 |
| 40 | shadwolf | where do I plug the to-unit function ? | 26-Jun-05 20:06 |
| 39 | shadwolf | so you avac primitive(fill:url) ->LinearGRadient (coords) -> LinearGradient (colors order) | 26-Jun-05 20:03 |
| 38 | shadwolf | linearGradient for example are splitted the first one contain the coordonates systeme and tranfromation informations the second one countains the colors involved and their order in the gradient | 26-Jun-05 20:02 |
| 37 | shadwolf | I read most of the documentation but then make the link to AGG data structure is rather difficult | 26-Jun-05 19:59 |
| 36 | shadwolf | see chapter 7.10 | 26-Jun-05 19:59 |
| 35 | shadwolf | http://www.w3.org/TR/SVG/coords.html | 26-Jun-05 19:58 |
| 34 | shadwolf | the page where I found the conversion rules | 26-Jun-05 19:58 |
| 33 | shadwolf | I copy past the conversion units into the script becaus I know that could be usefull but AS I was working on lineargradient and as it's a complicated part of the format SVG I had no time to make a conversion algorithm I glad to see that you make it :) | 26-Jun-05 19:53 |
| 32 | shadwolf | Ashley yes !!! You noticed right I found them deep hided in the SVG format documentation on W3C dedicated pages to SVG format .... | 26-Jun-05 19:52 |
| 31 | Ashley | Noticed you found some conversion numbers (where from?? ;) ), so here's a simple func to make use of them: to-unit: func [s [string!]] [ switch/default skip tail s -2 [ "pt" [1.25 * to decimal! copy/part s -2 + length? s] "pc" [15 * to decimal! copy/part s -2 + length? s] "mm" [3.543307 * to decimal! copy/part s -2 + length? s] "cm" [35.43307 * to decimal! copy/part s -2 + length? s] "in" [90 * to decimal! copy/part s -2 + length? s] "px" [to decimal! copy/part s -2 + length? s] ][ to decimal! s ] ] | 26-Jun-05 1:38 |
| 30 | shadwolf | http://shadwolf.free.fr/svg-demo02.zip | 24-Jun-05 23:00 |
| 29 | shadwolf | if you wants to write the "in" AGG/draw code that is based on my rebol linear gradient list there is the code and a sample file from InkScape | 24-Jun-05 23:00 |
| 28 | shadwolf | I think I handle web the creation of the rebol list of linear gradient | 24-Jun-05 22:59 |
| 27 | shadwolf | how to apply a matrix tranformation only over a grendient definition ? | 24-Jun-05 20:35 |
| 26 | shadwolf | and I have some asks | 24-Jun-05 20:34 |
| 25 | shadwolf | I'm working hard on the translation of the linearGradient informations from SVG files to AGG | 24-Jun-05 20:33 |
| 24 | shadwolf | drawing primitives have a xlink:href field that point to the appropiate main lineargradient (countainer) | 24-Jun-05 12:26 |
| 23 | shadwolf | yes DideC you are right the most problem will be to create tht tree structure to store all the LinearGradient définition and there childs then retrieve the approprieted informations | 24-Jun-05 12:25 |
| 22 | DideC | I suppose 'fill-pen is what you need. Can render gradient in many way. | 24-Jun-05 7:25 |
| 21 | shadwolf | for example the implementation of the LIneargradient I dont have any idea about how to translate it to AGG | 24-Jun-05 1:56 |
| 20 | shadwolf | yes it' quite a nightmare for a AGG newbie as I'm ... | 24-Jun-05 1:55 |
| 19 | Vincent | Thanks Ashley: there's still a lot of work to do - as SVG is quite flexible | 24-Jun-05 1:43 |
| 18 | shadwolf | matrix intervention of cyphre could be very educationnal and help me a lot to see what I'm messing in my code | 24-Jun-05 1:41 |
| 17 | shadwolf | groupe title rename done | 24-Jun-05 1:40 |
| 16 | shadwolf | okay I have imporved matrix support it seems to be good for scale-x: 1 scale-y: 1 if cyphre can see the code of the matrix gestion and makes some fix optimisation it could allow us to advance more with the rest of the SVG word format | 24-Jun-05 1:39 |
| 15 | Ashley | Thanks for taking this up and running with it guys, you're making great progress (far better than I could have). Feel free to take ownership of the code and refactor it as needed. Two minor improvements are: unless closed? [insert tail shape reduce ['move 0x0]] which is Gabriele's fix to the shape close problem, and: feel: make feel [ redraw: func [face act pos] [ if act = 'draw [insert clear face/effect/draw load-svg face/data face/size] ] ] which cleans the sample feel code up a bit. I'd also remove "VID" from the title of this group as DRAW AGG is tied to View. ;) | 24-Jun-05 1:02 |
| 14 | shadwolf | can be found on http://shadwolf.free.fr/svg-demo-shadwolf.r | 23-Jun-05 23:18 |
| 13 | shadwolf | support MLHVCSQT commands | 23-Jun-05 23:18 |