IRC log of svg on 2010-05-26
Timestamps are in UTC.
- 07:13:10 [RRSAgent]
- RRSAgent has joined #svg
- 07:13:10 [RRSAgent]
- logging to http://www.w3.org/2010/05/26-svg-irc
- 07:13:12 [trackbot]
- RRSAgent, make logs public
- 07:13:14 [trackbot]
- Zakim, this will be GA_SVGWG
- 07:13:14 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, trackbot
- 07:13:15 [trackbot]
- Meeting: SVG Working Group Teleconference
- 07:13:15 [trackbot]
- Date: 26 May 2010
- 07:13:50 [ed]
- Zakim, remind me in 8 hours to take a break
- 07:13:50 [Zakim]
- ok, ed
- 07:17:11 [AlexD]
- AlexD has joined #svg
- 07:35:56 [leonardr]
- leonardr has joined #svg
- 07:36:00 [leonardr]
- http://www.lyrics007.com/Berlin%20Lyrics/The%20Metro%20Lyrics.html
- 07:36:11 [shepazu]
- shepazu has joined #svg
- 07:46:09 [leonardr]
- for future reference, computers need to be turned on before they can be used...
- 07:49:57 [fat_tony]
- fat_tony has joined #svg
- 07:56:20 [jwatt]
- jwatt has joined #svg
- 07:56:55 [ed]
- Topic: SVG 2.0
- 07:57:10 [jwatt]
- scribenick: jwatt
- 07:58:59 [jwatt]
- PD: the main use cases for SVG we came up with were scalability, high fidelity, printing
- 08:03:50 [AlexD]
- Printing - could you perhaps elaborate on use cases?
- 08:06:34 [jwatt]
- PD: a printing example: we have a CAD program that outputs SVG, and it's very accurate
- 08:09:18 [jwatt]
- ...if for example out building layout software was able to do that, we could create a quick webapp to print building layouts to help with navigation, or office moves
- 08:11:44 [jwatt]
- DS: a CAD company I've talked to has told me they're not interested in SVG, partly because it gets in the way
- 08:11:51 [jwatt]
- PD: it would be good to find out why
- 08:12:48 [AlexD]
- Patrick - years ago I had a slide presentation comparing the feature sets of SVG Tiny vs. XPS. There are many parallels in the graphics model. How would you see XPS vs. SVG as competing/complementary, or XPS failed in the market so it's irrelevant and open standards provide a web compatible print option?
- 08:13:03 [jwatt]
- LR: these types of companies often have their own solutions that work for them already
- 08:14:12 [jwatt]
- ED: one thing that worries me is that very detail plans, for example, result in huge files
- 08:14:50 [jwatt]
- ...which if you're on a phone or on a slow network is a problem
- 08:15:41 [jwatt]
- LR: memory use for large files isn't so much of an issue if you know you don't need a DOM
- 08:16:40 [jwatt]
- PD: our compliance department has looked into which international organizations require SVG support
- 08:16:59 [jwatt]
- ...there are 17 at required, and dozens on the way
- 08:17:15 [jwatt]
- ...from recommended to required
- 08:19:08 [jwatt]
- PD: AlexD: I'd never thought of them as competing, we use XPS as a print format
- 08:19:50 [jwatt]
- LR: yes, once everything settled, nobody wanted XPS as a document format, only as a principle format
- 08:22:12 [jwatt]
- PD: SVG allows tooling
- 08:23:17 [ed]
- ...more easily due to it being an xml format
- 08:23:24 [AlexD]
- So Leonard, how do you see the MARS SVG print thing fitting into all of this?
- 08:24:26 [AlexD]
- We had SVG-print going, it was stillborn the Adobe developed MARS, is this of use and how is it relevant to SVG on the web...
- 08:24:40 [AlexD]
- s/the Adobe/then Adobe/
- 08:27:34 [leonardr]
- i'll answer that in a sec...in the midst of a separate discussion...
- 08:29:22 [leonardr]
- At this time, Adobe has no plans for Mars - we found that there was not enough user interest :(. However, we would be interested in discussions with this committee (or others) about taking it over...
- 08:30:15 [jwatt]
- (general agreement that the WG focus should be on both standalone and integrated SVG, rather than just standalone as it has been historically)
- 08:33:26 [jwatt]
- LR: Mars is abandoned
- 08:35:28 [jwatt]
- LR: we'd be happy to turn it over to anyone who wanted it
- 08:36:15 [jwatt]
- DS: it would be nice if Adobe could make that a member's submission
- 08:37:48 [jwatt]
- LR: one of the usecases we always saw and which we think is now coming into its own is as a graphics interchange format
- 08:37:54 [jwatt]
- ...clipart is a great example
- 08:38:59 [jwatt]
- DS: scrapbooking uses crickets (a cutting printer) which use SVG as their format
- 08:39:22 [pdengler]
- pdengler has joined #svg
- 08:39:27 [shepazu]
- http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
- 08:39:51 [jwatt]
- LR: we released FXG
- 08:39:59 [jwatt]
- ...which is really close to SVG
- 08:40:08 [jwatt]
- ...there are two reasons we didn't use SVG
- 08:40:35 [jwatt]
- ...we wanted to throw out all the stuff that's not useful for an exchange format: scripting, effects, etc
- 08:41:39 [AlexD]
- At the moment ePub is big for pagination. It's basically HTML+SVG and some viewers use XSL-FO to drive the pagination side of things (but not the FO formatting model). So it's a bit more webby - being HTML+SVG. This is where we're heading. Mars was a single SVG file per page, a lot like the SVG Print proposals where it creates final form markup - similar to XPS in fact. So, we need to consider the use cases already put forward for SVG print, the ePub ecosystem and
- 08:41:41 [jwatt]
- ...the other reason was that we were using it for flash graphics, and it made implementation easier to make the object names in the XML to match the Flash DOM
- 08:42:10 [jwatt]
- ...so rather than have a name converter, it was easier to have different names to SVG
- 08:43:15 [ed]
- AlexD: yes, we did discuss epub export here, didn't get scribed apparently
- 08:43:17 [jwatt]
- DS: so we've been doing work on having profiles so you can disable script, for example
- 08:44:19 [jwatt]
- LR: in ePub you may not want scripting, but could want declarative animation
- 08:47:22 [jwatt]
- LR: I think graphics interchange format should definitely be a goal for SVG
- 08:52:59 [jwatt]
- JW: my main use cases for getting into SVG were to provide more powerful educational material, and data visualisation
- 08:53:38 [jwatt]
- ...for example script changing the parameters on a SMIL an engine piston engine diagram
- 08:54:19 [jwatt]
- ...and script and animation of vector diagrams makes data visualization so much more powerful
- 08:55:15 [ed]
- ED: for me, being able to take an SVG and remix/edit the graphic is what the web is about, ties into the whole interchange format discussion
- 08:55:50 [jwatt]
- ...Mozilla's focus is naturally much more on Web usecases than on data interchange
- 08:56:19 [jwatt]
- LR: well for things like your Air equivalent exchange becomes relevant to you too
- 08:56:54 [jwatt]
- ...webapps too
- 08:57:19 [AlexD]
- With web focus/data interchange etc. One of the nice things is that it's XML so you can use a text editor or a graphics tool like Illustrator, InkScape etc. Some of them use proprietary things to mark layers, etc. Should we consider meta-markup to indicate structure to help the graphics interchange stuff perhaps?
- 09:01:38 [pdengler]
- We think that this is what the XML format is for. Doug notes tha the W3C should consider that outside the scope of SVG
- 09:07:17 [jwatt]
- PD: one of the usecases I was thinking of was as image maps
- 09:09:35 [jwatt]
- DS: I'm starting to see gradients, filter, transforms and others as more styling things, rather than as SVG features
- 09:10:23 [AlexD]
- Patrick, one thing that I'd like you to consider. I've done a lot of work on IE unrelated to our plugin in the general area of printing. One thing that is glarngly missing when printing to XPS is a connection between semantic content such as hyperlinks and what gets emitted to the print stream. XPS has the capability to represent hyperlinks in its format. The only thing that generates those is Word with the XPS export function (not the print path). So if IE9 intro
- 09:11:16 [AlexD]
- s/glarngly/glaringly/
- 09:13:05 [jwatt]
- PD: I agree, although SVG introduced and showed leadership with these types of features, I think we need to have a move to develop them more holistically across other formats
- 09:14:13 [pdengler]
- Yes, and as Doug stated we want to think about gradients, filters, transforms and anything that is a 'paint server' as styling, i.e. not a core deliverable of SVG
- 09:15:19 [jwatt]
- ED: as I see it, yes, these belong in the CSS group to some extent, but I'm not sure that that group is interested in defining filter changes
- 09:15:24 [jwatt]
- ...I think that belongs in our group
- 09:15:43 [jwatt]
- PD: yes, what we have is a lot more powerful than what CSS is looking at
- 09:15:59 [jwatt]
- ...Doug's SVG Wow demo was amazing
- 09:16:15 [ed]
- s/filter changes/arbitrary filter chains/
- 09:16:24 [jwatt]
- ...but could those 17 chained filters be written with a tool
- 09:16:28 [jwatt]
- ED: yes
- 09:16:32 [jwatt]
- DS: yes
- 09:17:19 [jwatt]
- DS: canned filters should definitely be defined is CSS though
- 09:18:04 [jwatt]
- ...Firefox lets you reference filter chains defined in SVG using CSS to apply to any content
- 09:18:34 [jwatt]
- PD: so CSS lets you reference SVG filters
- 09:20:13 [jwatt]
- LR: but tools take care of complexity
- 09:20:15 [jwatt]
- PD: the vast majority of Web developers are what we call "notepad developers"
- 09:20:44 [jwatt]
- ...we've been waiting for them to switch to more powerful tooling, but it's just not going to happen
- 09:21:08 [jwatt]
- DS: yes, tools won't really save us
- 09:21:27 [jwatt]
- LR: I just don't want us to go completely down the road of view-source'ing
- 09:22:07 [jwatt]
- ...if the goal is to better integrate SVG with these other standards (and I think that's a good goal), do we have the latitude to throw out stuff?
- 09:22:12 [jwatt]
- ...I'm talking high level
- 09:22:30 [jwatt]
- ...if it were me, I would throw out all the stuff we don't need any more
- 09:22:42 [jwatt]
- ...anything that can go into a more general standard
- 09:22:57 [jwatt]
- ...backwards compatibility would not be a priority
- 09:23:21 [jwatt]
- ...or rather, a 2.0 consumer would not have to be able to consume 1.x
- 09:23:40 [jwatt]
- PD: there are big features I'd deprecate moving forward
- 09:23:44 [jwatt]
- ...SVG fonts for example
- 09:24:01 [jwatt]
- ...we didn't implement them simply because there are better alternatives now
- 09:24:27 [jwatt]
- ...the story around CSS transitions, animations, scripting and SMIL needs to be sorted out
- 09:24:35 [jwatt]
- ...I want one method to do animations
- 09:24:55 [jwatt]
- ...I want queue's and transitions
- 09:25:31 [jwatt]
- ...the transitions is a better spec, but the css animations not so clear
- 09:25:49 [jwatt]
- ...we didn't implement filters yet, because of the compeating
- 09:26:22 [jwatt]
- ...the SVG filters are powerful, but the web developer is not going to know how to do all the chaining
- 09:27:48 [jwatt]
- ED: you can do what SVG filters can do with canvas and pixel ops, but the performance will be terrible
- 09:28:00 [leonardr]
- what you really want is something akin to Adobe's PixelBender - http://www.adobe.com/devnet/pixelbender/
- 09:28:10 [jwatt]
- ...for WebGL you can do shaders
- 09:28:26 [jwatt]
- ...which is more or less filters, if a different way of specing it
- 09:28:51 [jwatt]
- PD: the JS case, is it for wow affects, or putting a simple blur
- 09:30:05 [jwatt]
- PD: the XML namespacing needs to go away
- 09:30:06 [AlexD]
- Don't forget the compositing spec. Those operators map directly to the PDF imaging model as well as Apple's Quartz and play nicer than filters for blending. The filter model is a bit clumsy in hindsight.
- 09:30:18 [jwatt]
- ...there are benefits and cons
- 09:30:36 [jwatt]
- ...there's the user complexity
- 09:30:54 [jwatt]
- ...but then there's the benefits of being able to bring in other things
- 09:30:58 [jwatt]
- ...such as metadata
- 09:31:07 [jwatt]
- ...XLink should definitely go away
- 09:31:41 [jwatt]
- AG: I think we should deprecate some things, and agree that things should move into CSS or FX now
- 09:32:00 [jwatt]
- ...we should consider making it more clear how the spec is architected
- 09:32:12 [jwatt]
- ...the way things happen and their timing
- 09:32:34 [jwatt]
- PD: organisation of the spec
- 09:33:38 [jwatt]
- DS: I think we need to think about SVG in three different ways
- 09:33:51 [jwatt]
- ...things that are applicable to the web platform as a whole
- 09:34:12 [jwatt]
- ...platform features, where SVG is just part of the platform
- 09:34:25 [jwatt]
- ...in fact it doesn't need to even just be the Web platform
- 09:34:35 [jwatt]
- ...it could be any platform
- 09:35:08 [jwatt]
- ... so things like compositing, gradients, filters, styling, transforms - things that affect the way things look and are presented
- 09:35:19 [jwatt]
- ...another platform feature is animation
- 09:35:46 [jwatt]
- ...things that are moderately complex to implement, but applicable across multiple technologies
- 09:35:54 [jwatt]
- ...we should have one model
- 09:36:09 [jwatt]
- ...but there's potentially room for more than one syntax
- 09:36:37 [jwatt]
- ...and we can extend in SVG where things make sense in SVG when they don't make sense in the platform
- 09:36:46 [jwatt]
- ...that's the first part
- 09:36:55 [jwatt]
- ...the second is architectural features
- 09:37:00 [jwatt]
- ...nesting structure
- 09:37:02 [jwatt]
- ...use
- 09:37:04 [jwatt]
- ...groups
- 09:37:12 [jwatt]
- ...<title>
- 09:37:31 [jwatt]
- ...things where their context of their parent mater
- 09:37:51 [jwatt]
- ...these things which are specific to SVG
- 09:38:06 [jwatt]
- PD: you don't think HTML would benefit from <use>?
- 09:38:12 [AlexD]
- Also need to consider the dominant architectures for graphics today. IE9 uses H/W acceleration, i.e. GPU. I did have that debate with Jon about filters at the implementers panel. Some H/W acceleration architectures can't get pixels back efficiently. So this also needs consideration. Pixels and pixel manipulation are bad in a vector format IMHO. So what can we leverage from existing GPU capability that will enhance SVG...
- 09:38:16 [jwatt]
- DS: I think that won't happen
- 09:39:32 [jwatt]
- ...we have styling attributes in general, as opposed to HTML which doesn't have that so much
- 09:41:07 [jwatt]
- ...the third category of SVG is the features of SVG
- 09:41:34 [jwatt]
- ...we need to start thinking more about things that SVG should be good at
- 09:41:41 [jwatt]
- ...connectors, for example
- 09:41:55 [jwatt]
- ...HTML shouldn't have connectors, but SVG should
- 09:42:46 [jwatt]
- LR: WebCGM
- 09:43:16 [jwatt]
- ...SVG doesn't have that many of them
- 09:43:28 [jwatt]
- ...but these things make it so much easier for authors
- 09:44:18 [jwatt]
- s/of them/of this third category/
- 09:45:33 [jwatt]
- ...charts may be one of these features, although that may be going too deep to make primitives for that
- 09:46:03 [jwatt]
- ...although the aria guys may disagree, since they really want the semantics
- 09:46:38 [jwatt]
- ...anyway, we can look at what is specifically graphical/SVG
- 09:47:26 [jwatt]
- PD: are you including raster and video in "graphical"
- 09:47:44 [jwatt]
- ...I don't think you are
- 09:47:56 [jwatt]
- ...maybe just "vector" graphical
- 09:48:12 [jwatt]
- LR: I'd hate to see us adding graphing primitives to SVG
- 09:48:30 [jwatt]
- ...we should definitely have primitives to enable that to be implemented in SVG
- 09:48:37 [shepazu]
- http://www.w3.org/TR/WD-wwwicn.html
- 09:48:58 [jwatt]
- ...but let's keep SVG focused on "vector graphic primitives for the web"
- 09:52:09 [AlexD]
- +1 for Leonard's position
- 09:55:16 [jwatt]
- JW: I'm all for keeping the focus on general purpose primitives that meet a wide range of usecases too
- 09:55:41 [jwatt]
- ED: in SVG 2 I'd like to see us clean up the DOM
- 09:55:47 [jwatt]
- ...clean up some of the primitives
- 09:55:57 [jwatt]
- ...drop things that are not implemented at all
- 09:56:11 [jwatt]
- ...see a focus on maintaining backwards compatibility
- 09:56:21 [jwatt]
- ...as long as the content that's out there continues to work
- 09:56:50 [jwatt]
- ...SVG fonts don't work
- 09:56:56 [jwatt]
- ...vertical text doesn't work
- 09:57:16 [jwatt]
- ...animation I think we should revisit
- 09:57:48 [jwatt]
- ...thinking about the different solutions for animation
- 09:57:57 [jwatt]
- ...thinking about how SMIL interacts with scripting
- 09:58:18 [jwatt]
- ...inserting SMIL elements that have been created using script
- 09:59:10 [jwatt]
- ...I think we can extend parts of SVG, like with vector affects
- 09:59:25 [jwatt]
- ...shape path, like textPath, but for laying out objects
- 09:59:44 [jwatt]
- ...layout
- 09:59:45 [ed]
- s/SVG fonts don't work/SVG fonts, some parts are not implemented, we can probably drop some things there/
- 10:00:14 [AlexD]
- We're seeing strong demand for vertical text from Japan - so "vertical text doesn't work" isn't a good comment. We should fix it or provide via HTML/CSS that capability. The world isn't full of westerners you know! You guys trying to kill my SVG video fonts? Hmmph:-) We had graphical object flow in the 1.2 Full work which seems to have all gone into hiatus. Layout is contentious and IMO bad for SVG.
- 10:00:38 [jwatt]
- LR: doesn't layout tread somewhere between XSL-FO and CSS?
- 10:00:46 [jwatt]
- DS: FO is not a Web format
- 10:01:06 [jwatt]
- ...and I don't think CSS is interested in constraints based layout
- 10:01:12 [AlexD]
- FO is a W3C spec, so if it's not web, then what's W3C doing defining it...?
- 10:02:13 [ed]
- AlexD: I think we need to rethink vertical text in svg, at least make sure it gets implemented interoperably and that it meets requirements of people asking for it
- 10:02:21 [jwatt]
- ...W3C 5-10 years ago, we were siloed into this is HTML and XML
- 10:02:41 [jwatt]
- ...we tried to break that down, but browser vendors weren't on board
- 10:03:04 [jwatt]
- ...now we're seriously taking a look at all the gaps that have been left by doing things in separate silos
- 10:03:41 [jwatt]
- ...but now we are doing a much better job of coordinating between groups
- 10:04:21 [AlexD]
- Interoperability is key, I agree. That's where layout brings you into interoperability hell... Perhaps a sensible way forward is to leverage the HTML5 spec. Subset SVG as the 'efficient SVG' for HTML5 spec and throw out all the things we don't need for stand-alone SVG. Just a thought.
- 10:04:31 [jwatt]
- ED: better integration with HTML and CSS is certainly something we should have as a focus for SVG 2
- 10:05:23 [ed]
- ...this includes rethinking foreignObject, and mixing markup
- 10:05:52 [pdengler]
- scribenick : pdenger
- 10:05:56 [pdengler]
- jwatt: Better focus on interoperability between implementations Tests, Suites, Automation
- 10:06:03 [ed]
- scribenick: pdengler
- 10:06:35 [pdengler]
- ed: I second the automation part
- 10:06:55 [jwatt]
- s/implementations Tests, Suites, Automation/implementations by having a push on shared automated test suites/
- 10:07:00 [pdengler]
- pdengler: I agree that interop is absolutely key for SVG being a practial, useful solution
- 10:07:23 [pdengler]
- shepazu: W3C needs to be pushing the automation test suites, and the SVG WG should not have to worry about this
- 10:08:09 [pdengler]
- jwatt: The automated testing is harder than it looks, especially when it comes to collaborating
- 10:09:08 [shepazu]
- s/W3C needs to be pushing the automation test suites, and the SVG WG should not have to worry about this/W3C needs to be pushing the automation test suites, and the SVG WG should work closely along with them
- 10:09:45 [pdengler]
- jwatt: but it is worth it for the sake of content authors having to avoid the headaches
- 10:14:46 [pdengler]
- shepazu: We spent 2 years doing the Tiny 1.2 test suites
- 10:14:47 [pdengler]
- pdengler: Why?
- 10:15:15 [pdengler]
- shepazu: SVG Tiny 1.2 was not written to easily extract testable assertions; other groups have looked more closey from this perspective
- 10:15:51 [pdengler]
- shepazu: SVG WG in large part created the tests which is highly involved.
- 10:16:28 [AlexD]
- More to the point - Tiny 1.2 was run in parallel to the full work and Tiny is shipped in over 700 million phones so it has more traction than desktop SVG has had so far.
- 10:17:16 [AlexD]
- Test review by the WG is incredibly time consuming and not a great use of WG time.
- 10:17:37 [pdengler]
- pdengler: Have we considered test driven development of a spec?
- 10:17:54 [pdengler]
- (all) Yes. We think this will add a lot of value. No new features without sufficient tests
- 10:20:44 [pdengler]
- shepazu: Would love to see Opera, Firefox, IE coming to us with prototypes of features that are not spec'd yet.
- 10:21:32 [pdengler]
- jwatt: It's incredibily valuable to hve that; test should be written as a feature that we trying to spec, whether or not it is independent of the actual engineering
- 10:24:22 [ed]
- (DS elaborates on svg testfest history)
- 10:26:53 [pdengler]
- pdengler: Should the goal be that all UA's pass 100% SVG conformance tests
- 10:27:04 [AlexD]
- Yes.
- 10:30:02 [AlexD]
- e.g. in the printer industry companies like Quality Logic create test suites. There are a number of different levels of test suite. You can ask for certification and that means passing the test suite 100%. We should have a baseline test set that can be endorsed as an interoperable UI. Not as simple as ACID which is obfuscated features, but a general across the board set of features that will give good graphical fidelity for the most common use cases (like graphics
- 10:30:20 [AlexD]
- s/UI/UA/
- 10:37:01 [pdengler]
- jwatt: What does the goal mean in practice
- 10:39:14 [pdengler]
- shepazu: W3C as a standards body does not make conformance tests, we make implementability tests (testing the spec)
- 10:40:03 [pdengler]
- shepazu: The intention is that spec itself can be implemented interoperabiity
- 10:41:08 [pdengler]
- leonardr: How far does that go? Does tha mean that vendor a and vendor b are interoperable for every test?
- 10:41:52 [pdengler]
- shepazu: No; for every given feature we have a test; and as long as two vendors pass any of these specs, it can be considered interoperable and shippable
- 10:51:43 [pdengler]
- jwatt: we started with finit tests; but unfortunately, that level of granularity led to bugs when thinking in the real world composite tests; let's not forget those
- 10:52:27 [pdengler]
- shepazu: This is why I proposed the tiered test that says "this test required feature foo to use"; this would allow for a no-op instead of a fail category
- 11:31:54 [ed]
- ed has joined #svg
- 11:48:46 [leonardr]
- leonardr has joined #svg
- 13:46:17 [pdengler]
- pdengler has joined #svg
- 13:46:24 [pdengler]
- SVG 2.0 scenarios
- 13:47:00 [pdengler]
- shepazu: dynamically scalable images, including a static graphic, or something interactive like an image map
- 13:47:26 [pdengler]
- shepazu: technical drawings, engineering diagrams, floorplans, etc
- 13:48:02 [pdengler]
- shepazu: animated or interactive illstrations (such as mouse over) or the example piston engine
- 13:48:18 [pdengler]
- shepazu: scriptable webapps, whether integrated with HTML or standalone
- 13:48:21 [ed]
- wrt to the discussion on svg fonts, some examples/use-cases here: http://dev.opera.com/articles/view/seven-web-fonts-showcases
- 13:48:30 [pdengler]
- shepazu: re-usable component graphics
- 13:48:41 [pdengler]
- shepazu: games
- 13:49:21 [pdengler]
- shepazu: things we should look at as features : connectors, parameters and improve the DOM, and more specifially a shared API with <canvas>
- 13:49:47 [pdengler]
- shepazu: and seriously consider a math engine and/or physics engine
- 13:51:27 [pdengler]
- anthony: the ability to author UI's for standalone apps and to control audio/video etc
- 13:51:40 [pdengler]
- anthony: star wars credit text effect
- 13:52:37 [pdengler]
- anthony: psuedo 3d (2.5D)
- 13:53:59 [pdengler]
- anthony: basic animation on text and glyphs (like the a glyph on fire)
- 13:56:47 [pdengler]
- pdengler: A developer wishes to use SVG as an image interleaved thorughout web pages where scalability or image size (where possible) can improve
- 13:58:00 [pdengler]
- pdengler: A Developer wishes to create a richer, more graphic intensive webapps where HTML does not suite the needs well to creating the graphic experience, using a comomn programming model or framework which increases the productivity of the developer, user experience and satisfcation improve, and is interoperable
- 13:58:28 [pdengler]
- pdengler: A web site hosts interactive vector graphic diagrams mixed with HTML such as org charts, calendars, graphs and maps
- 13:58:35 [pdengler]
- pdengler: games like on OneMoreLevel
- 14:02:49 [pdengler]
- jwatt: Dynamic and interactive display of information :educational material, data visualization (graphing, orgcharts), documentation
- 14:04:09 [pdengler]
- ed: User interfaces
- 14:05:49 [pdengler]
- ed: audio/video : educational material, tv station
- 14:07:03 [pdengler]
- ed: progressive rendering and streaming : for a long running animation, and discard portions as they are utilized
- 14:09:39 [pdengler]
- ed: advanced text effects (change fonts dynamically)
- 14:12:44 [shepazu]
- http://www.fiestagrill.us/FGname.jpg
- 14:14:41 [pdengler]
- http://ie.microsoft.com/testdrive/Performance/12ScrollingText/Default.xhtml
- 14:28:07 [f1lt3r]
- f1lt3r has joined #svg
- 15:13:51 [Zakim]
- ed, you asked to be reminded at this time to take a break
- 15:14:37 [ed]
- Zakim, remind me in 2 hours that we should stop talking
- 15:14:39 [Zakim]
- ok, ed
- 15:55:11 [ed]
- rrsagent, end telcon
- 15:55:11 [RRSAgent]
- I'm logging. I don't understand 'end telcon', ed. Try /msg RRSAgent help
- 15:55:34 [ed]
- trackbot, end telcon
- 15:55:34 [trackbot]
- Zakim, list attendees
- 15:55:34 [Zakim]
- sorry, trackbot, I don't know what conference this is
- 15:55:35 [trackbot]
- RRSAgent, please draft minutes
- 15:55:35 [RRSAgent]
- I have made the request to generate http://www.w3.org/2010/05/26-svg-minutes.html trackbot
- 15:55:36 [trackbot]
- RRSAgent, bye
- 15:55:36 [RRSAgent]
- I see no action items