07:13:10 RRSAgent has joined #svg 07:13:10 logging to http://www.w3.org/2010/05/26-svg-irc 07:13:12 RRSAgent, make logs public 07:13:14 Zakim, this will be GA_SVGWG 07:13:14 I do not see a conference matching that name scheduled within the next hour, trackbot 07:13:15 Meeting: SVG Working Group Teleconference 07:13:15 Date: 26 May 2010 07:13:50 Zakim, remind me in 8 hours to take a break 07:13:50 ok, ed 07:17:11 AlexD has joined #svg 07:35:56 leonardr has joined #svg 07:36:00 http://www.lyrics007.com/Berlin%20Lyrics/The%20Metro%20Lyrics.html 07:36:11 shepazu has joined #svg 07:46:09 for future reference, computers need to be turned on before they can be used... 07:49:57 fat_tony has joined #svg 07:56:20 jwatt has joined #svg 07:56:55 Topic: SVG 2.0 07:57:10 scribenick: jwatt 07:58:59 PD: the main use cases for SVG we came up with were scalability, high fidelity, printing 08:03:50 Printing - could you perhaps elaborate on use cases? 08:06:34 PD: a printing example: we have a CAD program that outputs SVG, and it's very accurate 08:09:18 ...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 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 PD: it would be good to find out why 08:12:48 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 LR: these types of companies often have their own solutions that work for them already 08:14:12 ED: one thing that worries me is that very detail plans, for example, result in huge files 08:14:50 ...which if you're on a phone or on a slow network is a problem 08:15:41 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 PD: our compliance department has looked into which international organizations require SVG support 08:16:59 ...there are 17 at required, and dozens on the way 08:17:15 ...from recommended to required 08:19:08 PD: AlexD: I'd never thought of them as competing, we use XPS as a print format 08:19:50 LR: yes, once everything settled, nobody wanted XPS as a document format, only as a principle format 08:22:12 PD: SVG allows tooling 08:23:17 ...more easily due to it being an xml format 08:23:24 So Leonard, how do you see the MARS SVG print thing fitting into all of this? 08:24:26 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 s/the Adobe/then Adobe/ 08:27:34 i'll answer that in a sec...in the midst of a separate discussion... 08:29:22 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 (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 LR: Mars is abandoned 08:35:28 LR: we'd be happy to turn it over to anyone who wanted it 08:36:15 DS: it would be nice if Adobe could make that a member's submission 08:37:48 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 ...clipart is a great example 08:38:59 DS: scrapbooking uses crickets (a cutting printer) which use SVG as their format 08:39:22 pdengler has joined #svg 08:39:27 http://dev.w3.org/SVG/modules/integration/SVGIntegration.html 08:39:51 LR: we released FXG 08:39:59 ...which is really close to SVG 08:40:08 ...there are two reasons we didn't use SVG 08:40:35 ...we wanted to throw out all the stuff that's not useful for an exchange format: scripting, effects, etc 08:41:39 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 ...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 ...so rather than have a name converter, it was easier to have different names to SVG 08:43:15 AlexD: yes, we did discuss epub export here, didn't get scribed apparently 08:43:17 DS: so we've been doing work on having profiles so you can disable script, for example 08:44:19 LR: in ePub you may not want scripting, but could want declarative animation 08:47:22 LR: I think graphics interchange format should definitely be a goal for SVG 08:52:59 JW: my main use cases for getting into SVG were to provide more powerful educational material, and data visualisation 08:53:38 ...for example script changing the parameters on a SMIL an engine piston engine diagram 08:54:19 ...and script and animation of vector diagrams makes data visualization so much more powerful 08:55:15 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 ...Mozilla's focus is naturally much more on Web usecases than on data interchange 08:56:19 LR: well for things like your Air equivalent exchange becomes relevant to you too 08:56:54 ...webapps too 08:57:19 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 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 PD: one of the usecases I was thinking of was as image maps 09:09:35 DS: I'm starting to see gradients, filter, transforms and others as more styling things, rather than as SVG features 09:10:23 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 s/glarngly/glaringly/ 09:13:05 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 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 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 ...I think that belongs in our group 09:15:43 PD: yes, what we have is a lot more powerful than what CSS is looking at 09:15:59 ...Doug's SVG Wow demo was amazing 09:16:15 s/filter changes/arbitrary filter chains/ 09:16:24 ...but could those 17 chained filters be written with a tool 09:16:28 ED: yes 09:16:32 DS: yes 09:17:19 DS: canned filters should definitely be defined is CSS though 09:18:04 ...Firefox lets you reference filter chains defined in SVG using CSS to apply to any content 09:18:34 PD: so CSS lets you reference SVG filters 09:20:13 LR: but tools take care of complexity 09:20:15 PD: the vast majority of Web developers are what we call "notepad developers" 09:20:44 ...we've been waiting for them to switch to more powerful tooling, but it's just not going to happen 09:21:08 DS: yes, tools won't really save us 09:21:27 LR: I just don't want us to go completely down the road of view-source'ing 09:22:07 ...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 ...I'm talking high level 09:22:30 ...if it were me, I would throw out all the stuff we don't need any more 09:22:42 ...anything that can go into a more general standard 09:22:57 ...backwards compatibility would not be a priority 09:23:21 ...or rather, a 2.0 consumer would not have to be able to consume 1.x 09:23:40 PD: there are big features I'd deprecate moving forward 09:23:44 ...SVG fonts for example 09:24:01 ...we didn't implement them simply because there are better alternatives now 09:24:27 ...the story around CSS transitions, animations, scripting and SMIL needs to be sorted out 09:24:35 ...I want one method to do animations 09:24:55 ...I want queue's and transitions 09:25:31 ...the transitions is a better spec, but the css animations not so clear 09:25:49 ...we didn't implement filters yet, because of the compeating 09:26:22 ...the SVG filters are powerful, but the web developer is not going to know how to do all the chaining 09:27:48 ED: you can do what SVG filters can do with canvas and pixel ops, but the performance will be terrible 09:28:00 what you really want is something akin to Adobe's PixelBender - http://www.adobe.com/devnet/pixelbender/ 09:28:10 ...for WebGL you can do shaders 09:28:26 ...which is more or less filters, if a different way of specing it 09:28:51 PD: the JS case, is it for wow affects, or putting a simple blur 09:30:05 PD: the XML namespacing needs to go away 09:30:06 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 ...there are benefits and cons 09:30:36 ...there's the user complexity 09:30:54 ...but then there's the benefits of being able to bring in other things 09:30:58 ...such as metadata 09:31:07 ...XLink should definitely go away 09:31:41 AG: I think we should deprecate some things, and agree that things should move into CSS or FX now 09:32:00 ...we should consider making it more clear how the spec is architected 09:32:12 ...the way things happen and their timing 09:32:34 PD: organisation of the spec 09:33:38 DS: I think we need to think about SVG in three different ways 09:33:51 ...things that are applicable to the web platform as a whole 09:34:12 ...platform features, where SVG is just part of the platform 09:34:25 ...in fact it doesn't need to even just be the Web platform 09:34:35 ...it could be any platform 09:35:08 ... so things like compositing, gradients, filters, styling, transforms - things that affect the way things look and are presented 09:35:19 ...another platform feature is animation 09:35:46 ...things that are moderately complex to implement, but applicable across multiple technologies 09:35:54 ...we should have one model 09:36:09 ...but there's potentially room for more than one syntax 09:36:37 ...and we can extend in SVG where things make sense in SVG when they don't make sense in the platform 09:36:46 ...that's the first part 09:36:55 ...the second is architectural features 09:37:00 ...nesting structure 09:37:02 ...use 09:37:04 ...groups 09:37:12 ... 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