Re: [svg-developers] Converting JPG files to SVG
Just curious...but why are you doing that? On 09/12/2008, at 3:13 PM, Judy Perry wrote: > I use Inkscape a lot. I've been converting some of my jpg files into > svg files (opening the jpg file and save as a svg), but with over 1000 > files to convert, it is going to take me quite some time. > > What I am looking for is a script that I can run that will convert all > the jpg files in a given directory to svg files. I have numerous > directories of jpg files, so being able to convert them one directory > at a time would work. > > I have tried to create this script, but my coding skills are very > rusty, so I am asking for assistance, > > Thanks in advance, > > Judy > [EMAIL PROTECTED] > > > > > > - > To unsubscribe send a message to: [EMAIL PROTECTED] > -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit > my membership" > Yahoo! Groups Links > > > - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [svg-developers] Re: Report on SVG Viewer Performance
On Tue, 09 Dec 2008 03:51:07 - "Frank Bruder" <[EMAIL PROTECTED]> wrote: > --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <[EMAIL PROTECTED]> > wrote: > > > > On Thu, 04 Dec 2008 06:12:30 - > > "Frank Bruder" <[EMAIL PROTECTED]> wrote: > > > > > - Your testing method does not necessarily measure a relevant > > > benchmark. A scripting engine which queues events in such a way > > > that interval and timeout events always are executed in the > > > correct order would get perfect scores, no matter how much time > > > the rendering takes. In the second call to setInterval() you > > > could create a Date object each time and use that for measuring, > > > to account for the possibility that the longer interval might be > > > delayed in accordance with the shorter interval. Furthermore a > > > user agent could switch to rendering only every other frame when > > > the animation speed would otherwise slow down too much. Video > > > player software commonly does this. > > > > I'm not sure I understand your issue here. The interval events for > > the animation and the sampling are two independent timers (or at > > least they appear to be). So the "order of events" doesn't appear > > to have any relevance (unless I'm really misunderstanding you). > > What I mean is this: Consider the following code. > > setInterval(doSomething, 20); > setTimeout(somethingElse, 1000); > > Nominally doSomething() would be expected to be called 50 times before > somethingElse() is called. If the execution of doSomething() takes > more than 20 ms then it can't be executed 50 times per second, but > calling somethingElse() after one second is still achievable. The > script engine could call doSomething() as often as is possible without > exceeding the nominal frequency, and call somethingElse() one second > after the call to setTimeout or as soon as possible thereafter. > > But the scripting engine could alternatively manage the timer events > with respect to the nominal times, meaning doSomething() is called 50 > times, and then somethingElse() is called, and this order is > maintained no matter what. This approach seems reasonable. Looking at > the code, it makes sense to think the author would expect > doSomething() to be executed 50 times before the call to > somethingElse(). Okay, I did understand you then. > > I actually use the Date.getTime() method on each call to the > > sampling routine to measure the actual elapsed time between my > > samples. > > Well then it's fine. Provided, of course, that the times returned by Date.getTime() are correct and high enough resolution for the measurements I'm trying to make. Based on the input from this list, I'm trying to add a section documenting the potential sources of error that I'm aware of and how each might be mitigated. > Another thing to consider is that the browser doesn't have to render > after each event. > Consider a video. If the computer is too slow to render it at the > frame rate it was recorded at, it can still render every frame, > slowing down the video, or it can skip frames in order to try to play > the video at its full speed. Slowing down the video brings the problem > that one then has to either slow down the audio too, or it gets out of > sync and out of context. Both these options are very undesired, so > typically the default setting of media player software is not to show > every frame. I hadn't really considered this one before, but now I'm going to at least document it. Although I can reduce the effect of some errors, I'm not sure there's a way to even detect this from the script. > With audio in SVG becoming available audio synchronized with animation > is a goal, and this would in some cases require frame rates to be > unaffected by scripted update rates. > > > In a > > previous life, I had seen how much the actual interval could vary > > relative to the expected interval. I need to make sure that I am > > clear about this in the text. > > > > You are correct, I can't actually measure rendering in the script, > > so > > I vaguely remember reading about plans for an event which would be > dispatched on rendering. I could be wrong now, but I think this was > going to be an upcoming feature in Firefox. Of course, a browser > specific feature could not be used for comparative testing. That would be nice. we've recently seen that Opera may be providing a way to detect the frame rate. I'd hate to have to do viewer-specific code for looking at this and then try to generate something resembling a useful comparison. So much for the quickie little project I originally started. > > I'm making the assumption that each update is a render. So, this is > > a potential issue that I need to document. I really appreciate the input. Several emails from this list have shaken loose assumptions I needed to document and approaches I had considered and discarded. Thanks to this list, I think the result will be much more useful overall. Thanks
[svg-developers] Converting JPG files to SVG
I use Inkscape a lot. I've been converting some of my jpg files into svg files (opening the jpg file and save as a svg), but with over 1000 files to convert, it is going to take me quite some time. What I am looking for is a script that I can run that will convert all the jpg files in a given directory to svg files. I have numerous directories of jpg files, so being able to convert them one directory at a time would work. I have tried to create this script, but my coding skills are very rusty, so I am asking for assistance, Thanks in advance, Judy [EMAIL PROTECTED] - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[svg-developers] Re: Report on SVG Viewer Performance
--- In svg-developers@yahoogroups.com, "G. Wade Johnson" <[EMAIL PROTECTED]> wrote: > > On Thu, 04 Dec 2008 06:12:30 - > "Frank Bruder" <[EMAIL PROTECTED]> wrote: > > > - Your testing method does not necessarily measure a relevant > > benchmark. A scripting engine which queues events in such a way that > > interval and timeout events always are executed in the correct order > > would get perfect scores, no matter how much time the rendering takes. > > In the second call to setInterval() you could create a Date object > > each time and use that for measuring, to account for the possibility > > that the longer interval might be delayed in accordance with the > > shorter interval. Furthermore a user agent could switch to rendering > > only every other frame when the animation speed would otherwise slow > > down too much. Video player software commonly does this. > > I'm not sure I understand your issue here. The interval events for the > animation and the sampling are two independent timers (or at least they > appear to be). So the "order of events" doesn't appear to have any > relevance (unless I'm really misunderstanding you). What I mean is this: Consider the following code. setInterval(doSomething, 20); setTimeout(somethingElse, 1000); Nominally doSomething() would be expected to be called 50 times before somethingElse() is called. If the execution of doSomething() takes more than 20 ms then it can't be executed 50 times per second, but calling somethingElse() after one second is still achievable. The script engine could call doSomething() as often as is possible without exceeding the nominal frequency, and call somethingElse() one second after the call to setTimeout or as soon as possible thereafter. But the scripting engine could alternatively manage the timer events with respect to the nominal times, meaning doSomething() is called 50 times, and then somethingElse() is called, and this order is maintained no matter what. This approach seems reasonable. Looking at the code, it makes sense to think the author would expect doSomething() to be executed 50 times before the call to somethingElse(). > > I actually use the Date.getTime() method on each call to the sampling > routine to measure the actual elapsed time between my samples. Well then it's fine. Another thing to consider is that the browser doesn't have to render after each event. Consider a video. If the computer is too slow to render it at the frame rate it was recorded at, it can still render every frame, slowing down the video, or it can skip frames in order to try to play the video at its full speed. Slowing down the video brings the problem that one then has to either slow down the audio too, or it gets out of sync and out of context. Both these options are very undesired, so typically the default setting of media player software is not to show every frame. With audio in SVG becoming available audio synchronized with animation is a goal, and this would in some cases require frame rates to be unaffected by scripted update rates. > In a > previous life, I had seen how much the actual interval could vary > relative to the expected interval. I need to make sure that I am clear > about this in the text. > > You are correct, I can't actually measure rendering in the script, so I vaguely remember reading about plans for an event which would be dispatched on rendering. I could be wrong now, but I think this was going to be an upcoming feature in Firefox. Of course, a browser specific feature could not be used for comparative testing. > I'm making the assumption that each update is a render. So, this is > a potential issue that I need to document. > Regards Frank - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[svg-developers] SMIL 3.0 released
W3C's announcement: http://www.w3.org/2008/12/smil3-pressrelease.html Press coverage: Wall Street Journal: http://www.marketwatch.com/news/story/SMIL-30-Advances-Standard-Synchronized/story.aspx?guid=%7BA0336409-96B2-4286-A68F-F8B23C040BA3%7D and also http://in.sys-con.com/node/764284 >From a (very) quick look at the thing, a couple of things caught my eye: 1. a section on smilText -- looks pretty interesting 2. the animation section includes some stuff pertaining to which would seem to eliminate some often redundant scripting 3. there is some stuff on transitions (like wipe and iris and snake) -- For example: I always thought those things were a bit too cutesy to warrant standardization (the class of possible transitions from scene 1 to scene 2 is huge, so why codify any trivial subset?), but some of the syntax they advance is interesting, as I suppose is the set of "transition primitives", which to some extent begin to look like filter primitives. Lying somewhere between filters and SMIL is some very fertile territory for 2.5 + dimensional standards development. It reminds me a bit of the and tags for SVG that I've proposed in http://www.w3.org/Graphics/SVG/IG/wiki/A_place_to_gather_suggestions_and_discussion_of_new_features David [Non-text portions of this message have been removed] - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[svg-developers] Opera 10 alpha
http://www.tgdaily.com/content/view/40472/140/ excerpts from the article: "Opera 10 alpha unveiled: Fully web compliant, 30% faster" "Also new: Opacity modifications through RGB and HSLA for setting the opacity of any web page element, the selectors API, and improvements in scalable vector graphics (SVG) format support that now includes the support for web fonts in SVG format as well." See also http://www.efluxmedia.com/news_Opera_Launches_Opera_10_30691.html David [Non-text portions of this message have been removed] - To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
