Sorry for the long email, but this will be of interest to several of you about Mozilla + SVG involvments. This is from the Mozilla SVG team meeting log.
-----Forwarded Message-----
From: jon phillips <phillipsjd@...400...> To: jon@...235... Subject: Fwd: mozilla svg meeting log 26.July 2004 Date: Sun, 01 Aug 2004 00:36:09 -0700
---------- Forwarded message ---------- From: Alex Fritze <alex@...488...> Date: Sun, 01 Aug 2004 08:34:18 +0100 Subject: mozilla svg meeting log 26.July 2004 To: phillipsjd@...400...
Jul 26 18:39:50 <afri> anyway, shall we start with item 1) "Criteria for switching on"? Jul 26 18:39:55 <jwatt> is there any way to search for bugs that have patches that modify a given file? Jul 26 18:40:06 <jwatt> oops, never mind, later Jul 26 18:40:17 <Scooter> 1 seems like a good beginning Jul 26 18:40:19 <afri> Anybody got any thoughts? Jul 26 18:40:36 <jwatt> don't we really need a brendan or someone similar here for that? Jul 26 18:40:42 <afri> tor: you had some contact with m.org about this? Jul 26 18:40:45 <jwatt> since they will have a major say in that? Jul 26 18:41:09 <tor> afri: just the normal moz2 meetings Jul 26 18:41:51 <Scooter> Well, lets start with which profile we are shooting for: Tiny or Basic? Jul 26 18:42:01 <tor> turning it on will depend on the feature set and size Jul 26 18:42:11 <tor> 1.2 doesn't have basic, fwiw Jul 26 18:42:11 <jwatt> or should we do Tiny > Basic > Full? Jul 26 18:42:23 <tor> (not that we should be shooting for 1.2) Jul 26 18:42:56 <Scooter> Agreed -- I'm a little uncertain about 1.2. There seems to be a lot of debate surrounding it. Jul 26 18:43:02 <afri> do you reckon that feature set is important? Isn't stability and footprint the issue? Jul 26 18:43:11 <tor> is anyone interested in working on animation or svg fonts, which are a couple of the big points we're short of 1.1 tiny? Jul 26 18:43:30 <tor> stability is definitely important Jul 26 18:44:01 <tor> we need to be featureful enough so that people can start do interesting things Jul 26 18:44:05 <jwatt> I'd be interested in animation in the long run, but feel I'm still finding my feet Jul 26 18:44:28 <afri> who do we need to press for criteria? i guess they are being decided by brendan et al? Jul 26 18:44:52 <jwatt> yeah, an email to drivers would be a good idea Jul 26 18:44:59 <tor> brendan was floating the idea of turning on svg for 1.8, but that causes problems with platform prereqs Jul 26 18:45:03 <jwatt> or should we /invite some folk now? Jul 26 18:45:14 <tor> mail to drivers is likely not to get anywhere Jul 26 18:45:22 <jwatt> oh Jul 26 18:45:51 <Scooter> OK, so it sounds like there are some platform issues that need to be on the list -- what are they? Jul 26 18:46:14 <tor> requiring gdi+ on windows Jul 26 18:46:27 <jwatt> as in for the installer? Jul 26 18:46:30 <tor> (unless maybe we can try dynamically loading it?) Jul 26 18:46:49 <jwatt> I was working on getting the installer script to do the right thing for that Jul 26 18:47:05 <Scooter> So, we have requirement #1 -- we need to deal with gdi+ on windows, right? Jul 26 18:47:11 <afri> IANAL, but i think technically we are allowed to redist gdiplus.dll for older windows Jul 26 18:47:32 <tor> we can't ship libart bits under trilicense Jul 26 18:47:35 <jwatt> for win me, 98, nt and 2000 Jul 26 18:47:44 <jwatt> all others aren't allowed Jul 26 18:47:57 <afri> but we could use cairo for linux, right? Jul 26 18:48:23 <tor> yes, but we'd have to link it in statically given that they're still changing the api Jul 26 18:48:29 <afri> ah Jul 26 18:48:54 <afri> i guess the other problem is the mac Jul 26 18:49:11 <Scooter> Perhaps we should focus on listing the issues and postpone trying to solve them? Jul 26 18:49:56 <afri> so is it fair to say then that the real first hurdle for getting svg switched on is sorting out a backend on each platform? Jul 26 18:50:04 <tor> how about we ask the question another way - ignoring distribution issues, would we be happy subjecting users to our svg at this point? Jul 26 18:51:00 <afri> i guess that comes down to stability... Jul 26 18:51:04 <Scooter> I would really like to see us get closer to *at least* Tiny before we roll this out. Jul 26 18:51:31 <Scooter> Then we can focus on stability. Things are clearly still changing pretty rapidly. Jul 26 18:51:32 <afri> i think the current feature set looks pretty ok for users Jul 26 18:52:14 <tor> once gradients are in things are looking good Jul 26 18:52:16 <Scooter> Even without animation and SVG Fonts? Jul 26 18:52:21 <tor> <use> would be nice Jul 26 18:52:45 <jwatt> yeah, gradients and use I think would be necessary Jul 26 18:53:16 <afri> yeah, gradients & <use> would be nice. animation i think will take quite a long while and svg is pretty useful even without it Jul 26 18:53:35 <Scooter> Fair enough -- what about SVG Fonts? Jul 26 18:54:25 <afri> hmm, it sounds tricky getting it right for several backends... Jul 26 18:55:03 <afri> do you think without fonts, SVG is not really worth much to the end user? Jul 26 18:55:45 <Scooter> Not at all -- I'm just sort of playing devil's advocate here. I'm happy to see it turned on without that. Jul 26 18:55:54 <tor> I think svg fonts were probably added to tiny for platforms that didn't have native scalable/tranformable fonts Jul 26 18:55:54 <Scooter> What about <switch>? Jul 26 18:56:26 <afri> well we have your patch for that, so i guess it will be going in soon Jul 26 18:57:02 <Scooter> OK, so what we have is: Stability, Platform issues, <use>, Gradients, and <switch>, right? Jul 26 18:57:37 <afri> ...of which platform issues are probably the most difficult Jul 26 18:57:51 <afri> i don't have a clue how to go about this Jul 26 18:58:08 <Scooter> Which this? The requirements list or the platform issues? Jul 26 18:58:10 <afri> will cairo work on windows/mac? Jul 26 18:58:25 <afri> Scooter: the platform issues Jul 26 18:58:52 <afri> can we even link to it statically on linux? Jul 26 18:59:04 <afri> wouldn't that mean it needs to be checked into the tree? Jul 26 18:59:29 <tor> the software path of cairo should work on mac Jul 26 18:59:51 <tor> if we're allowed to redistribute gdi+ then that might not be a problem Jul 26 19:00:06 <afri> fair enough Jul 26 19:00:20 <afri> so let's assume windows is sorted for now... Jul 26 19:00:30 <jwatt> as I said, we can only redistribute gdiplus.dll on WinME, Win98, WinNT and Win2k Jul 26 19:00:34 <afri> how do we go about linux/mac then? Jul 26 19:00:43 <tor> jwatt: what else is there? Jul 26 19:00:53 <afri> tor: XP Jul 26 19:00:54 <jwatt> nothing that we need to cater for Jul 26 19:00:57 <jwatt> XP has it Jul 26 19:01:04 <tor> there's a quartz wip backend Jul 26 19:01:18 <afri> wip? Jul 26 19:01:27 <tor> work in progress Jul 26 19:01:32 <afri> ah Jul 26 19:01:57 <afri> i think we'd need to find a developer for that Jul 26 19:02:06 * Lightkey cracks his wip Jul 26 19:02:12 <afri> it seems to have stalled Jul 26 19:02:42 <afri> Lightkey: you are a mac developer? Jul 26 19:02:54 <Lightkey> I am the lowest Jul 26 19:03:02 <Lightkey> internet reporter :D Jul 26 19:03:14 <tor> we have a mac here Jul 26 19:03:18 <Lightkey> no, I'm just a user Jul 26 19:04:14 <afri> so if we have as a working assumption that someone will fix the quartz backend, that still leaves linux... Jul 26 19:04:42 <Scooter> And the issue with Linux is the license restrictions on libart? Jul 26 19:04:52 <afri> with libart not being an option, how would we proceed with cairo? Jul 26 19:04:57 <tor> statically linking cairo is just a build problem Jul 26 19:05:10 <afri> what about the cairo license? Jul 26 19:05:12 <tor> though cairo does feel slower than libart Jul 26 19:05:28 <Lightkey> changing croczillas licenses to the one libart uses? *scnr* Jul 26 19:05:46 <tor> still MIT style, though they keep threatening to change to LGPL (which would sink the static link solution) Jul 26 19:06:35 <afri> is MIT compat with tri-license? Jul 26 19:06:43 <tor> yes Jul 26 19:07:06 <afri> so we could check this into the tree then? Jul 26 19:07:10 <Lightkey> MIT is like FreeBSD Jul 26 19:08:37 <tor> if it gets to that point, yes Jul 26 19:08:51 <afri> to which point? Jul 26 19:09:04 <afri> LGPL relicensing> Jul 26 19:09:07 <afri> ? Jul 26 19:09:15 <tor> where we're going to take the static link approach Jul 26 19:09:23 <afri> ah yeah, ok Jul 26 19:09:34 <afri> well, is there any other way? Jul 26 19:09:44 <lsmith> afri: are those performance issues solved that matthias found afri? Jul 26 19:09:51 <lsmith> (iirc he send you a test case) Jul 26 19:09:54 <tor> not that I can think of offhand Jul 26 19:10:12 <lsmith> those might also be a little showstopper Jul 26 19:10:26 <afri> lsmith: no, we'll get to that later Jul 26 19:10:46 * lsmith nods Jul 26 19:10:49 <afri> so shall we run this past brendan et al then? Jul 26 19:11:23 <Scooter> Makes sense to me. Jul 26 19:11:35 <jwatt> yeah, good to keep him informed if nothing else Jul 26 19:11:50 <jwatt> But do we really have enough contributors to deal with the development cycle that would be imposed on us if SVG was turned on by default? Jul 26 19:12:14 <tor> what development cycle? Jul 26 19:12:43 <jwatt> having to stabalise, etc a1, a2, b, rc, milestone Jul 26 19:13:27 <jwatt> there are certain benefits to not being build by default, and therefore not having to meet the same standards as the rest of the code Jul 26 19:14:41 <jwatt> or is it better that we should start to be forced to those standards? Jul 26 19:15:10 <afri> so is it fair to summarize then: stability, backend are the major issues. course of action: gdi+ on win, quartz on mac, statically-linked cairo on linux? run past brendan et al. find out other criteria from them? Jul 26 19:15:36 * lsmith notes while he doesnt have the know how to contribute code we (my co-worker and I) will definately be willing to help on the testing front Jul 26 19:15:53 <jwatt> lsmith: cool Jul 26 19:15:57 <jwatt> afri: seems right Jul 26 19:16:12 <Scooter> afri: sounds right to me. We should also mention <use>, which is an outstanding feature on the list. Jul 26 19:16:45 <tor> afri: and getting the current features working through reviews (gradient, switch) Jul 26 19:17:11 <Scooter> afri: and font-size Jul 26 19:17:21 <afri> ok Jul 26 19:17:44 <afri> then there is the issue of getting the current code sr'ed... Jul 26 19:17:55 <jwatt> fun Jul 26 19:18:39 <lsmith> may i ask what timeframe you are hoping for? (slap me if i am intruding btw) Jul 26 19:18:41 <afri> so is anyone volunteering to run these issues past brendan et. al. ? Jul 26 19:19:10 <tor> afri: sure, I send something to the moz2 list and talk to brendan Jul 26 19:19:34 <jwatt> where is the moz2 list? Jul 26 19:19:37 <afri> tor: cool Jul 26 19:19:39 <jwatt> is that public? Jul 26 19:19:53 <tor> unfortunately no Jul 26 19:19:57 <jwatt> shame Jul 26 19:20:19 <afri> anybody got an idea what timeframe we are aiming for? i don't... Jul 26 19:20:43 <Scooter> I will volunteer to take on <use> as soon as I can clear out some of the other patches. <use> looks a lot like the some of the gradient reference stuff. Jul 26 19:20:52 <afri> cool Jul 26 19:21:14 <jwatt> afri: no, I'm in no rush, I just wanted to clarify things to aim for in the long run Jul 26 19:21:35 <afri> ok, i guess that's item 1 sorted then as well as we can atm Jul 26 19:21:55 <jwatt> scooter's only here for another 40 min Jul 26 19:21:57 <tor> brendan was floating 1.8 - if we were serious about that, of that list, we might be able to get everything except for
<use> Jul 26 19:22:07 <jwatt> what do we need to discuss while he's here? Jul 26 19:22:32 <afri> cool Jul 26 19:22:59 <Scooter> Do you really think we could get the stability and platform issues worked out for 1.8? Jul 26 19:23:03 <afri> tor: how about if you run this past brendan and we talk about it again next week? Jul 26 19:23:26 <tor> afri: sure Jul 26 19:23:36 <afri> if there's a commitment by mozilla.org to get this in, i guess we could make it Jul 26 19:23:47 <tor> Scooter: do we have serious stability problems? Jul 26 19:24:26 <Scooter> Not sure -- there's a lot of work in progress. Until its all in a single build, we really haven't done much to shake things out. Jul 26 19:24:28 <afri> AFAICS many stability problems on linux are libart-specific Jul 26 19:24:51 <afri> there are issues with very large SVGs Jul 26 19:25:03 <afri> we don't do any culling or clipping... Jul 26 19:25:28 <Scooter> Should clipping be on our requirements list? Jul 26 19:25:37 <tor> oh, speaking of which cairo is in the midst of redoing their trianglization algorithms, so some fills mess up now Jul 26 19:25:39 <afri> so if the SVG viewport is larger than the client area we still build all the paths Jul 26 19:26:14 <afri> i guess visual glitches are one thing...crashing/hanging is another Jul 26 19:27:10 <afri> shall we move to the other items then? Jul 26 19:27:12 <Scooter> I don't know...I guess I'd feel more comfortable enabling SVG right *after* 1.8. That way we could get in at the start of a cycle. Jul 26 19:27:23 <Scooter> Sure, lets move on. Jul 26 19:27:50 <afri> "currentColor" Jul 26 19:28:07 <afri> Scooter: you had a question about the intent of the specs? Jul 26 19:28:35 <afri> isn't "current" just the value of the "color" property? Jul 26 19:29:14 --> shaver (~shaver@...489...) has joined #svg Jul 26 19:29:28 <Scooter> Sort of. The question is, is it the value of the color property of the surrounding elements (i.e. inherited) or just the last set value? Jul 26 19:30:27 <afri> is there a difference? Jul 26 19:31:24 <Scooter> Internally, I think that there is. For example, I could set the "color" property on an HTML element then not set the property again and then use it inside of SVG as "currentColor". Jul 26 19:31:48 <afri> ah, i see Jul 26 19:31:58 <afri> i haven't got a clue Jul 26 19:32:23 <afri> don't the specs say anything about this? Jul 26 19:32:29 <afri> (the css specs) Jul 26 19:32:38 <Scooter> I *believe* that that is the intent of the spec -- a way to maintain color between different document elements. Jul 26 19:33:12 <Scooter> The only example (in the test suite) just sets the color inside of SVG and then references it using "currentColor" Jul 26 19:33:43 <afri> hmm, i guess noone here knows... Jul 26 19:34:09 <jwatt> maybe ask in www-svg, or mail chris/dean directly Jul 26 19:34:10 <Scooter> The css specs (2.1) don't talk about "currentColor". That's supposed to be coming in CSS3 (I'm told). Jul 26 19:34:19 <Scooter> OK, will do. Jul 26 19:34:26 <afri> great Jul 26 19:34:38 <afri> 3. ICC Color - do we do it? Should we? Jul 26 19:34:50 <afri> i don't even know what ICC color is Jul 26 19:35:00 <tor> color profiles for color correction Jul 26 19:35:12 <afri> ah Jul 26 19:35:14 <Scooter> And its part of the SVG spec Jul 26 19:35:40 <afri> i guess we should then Jul 26 19:35:44 <Scooter> My take is to wait for somebody to ask for it. Jul 26 19:35:47 <afri> at some point Jul 26 19:35:51 <tor> somewhat low priority, I woudl think Jul 26 19:35:57 <afri> yeah Jul 26 19:35:58 <jwatt> btw, I found their specs online some years ago, I downloaded them if they can't be found now Jul 26 19:36:19 <Scooter> They are still online. Jul 26 19:36:39 <Scooter> OK, I agree that this should be low priority. Jul 26 19:36:40 <jwatt> cool, anyway, low priority Jul 26 19:36:44 <afri> cool - so ICC color=low priority. 4) patterns Jul 26 19:36:56 <Scooter> Any takers? Jul 26 19:37:00 <jwatt> ugh Jul 26 19:37:17 <afri> i think we need to sort out clipping before patterns Jul 26 19:37:23 <Scooter> Agreed. Jul 26 19:37:27 <afri> that's something i wanted to do next Jul 26 19:38:19 <Scooter> Great! Getting clipping would be really good. Jul 26 19:38:26 <afri> so I guess we wait until clipping is sorted out then Jul 26 19:38:35 <afri> 5. SVG text Jul 26 19:39:09 <Scooter> What's missing besides textPath? Jul 26 19:39:12 <tor> textPath seems hard Jul 26 19:39:36 <afri> selection is only partially implemented atm (i got bored) Jul 26 19:40:23 <afri> i think before we ship in default builds, selection either needs to be disabled or finished Jul 26 19:40:32 <afri> it's kind-of screwy atm Jul 26 19:41:04 <afri> font-size we have Scooter's patch for, so i guess that will go in soon Jul 26 19:41:51 <Scooter> That's sort of minor (although you wouldn't know it by the number of comments). Jul 26 19:41:56 <afri> All the other stuff (textPath, tref, glyphs) would be nice, but does anybody want to work on that? Jul 26 19:42:05 <Scooter> So, I guess we don't have any takers for working on SVG Text? Jul 26 19:42:27 <jwatt> why disable it? I'd prefer not to, even if it doesn't get finished. Jul 26 19:42:58 <afri> disable selection, not text Jul 26 19:43:06 <jwatt> I know Jul 26 19:43:10 <Scooter> So, should we submit a bug for the missing stuff with helpwanted? Jul 26 19:43:30 <afri> it doesn't work - some of the machinery is there, that's all Jul 26 19:43:39 <jwatt> but sometimes it works, and the worst thing that can happen is that the user can't select what they want and files a bug Jul 26 19:43:54 <afri> fair enough Jul 26 19:44:40 <Scooter> If I'm going to do <use> I'll take a look at <tref> also. Jul 26 19:44:45 <afri> cool Jul 26 19:45:08 <afri> tor: text is working on cairo, right? Jul 26 19:45:13 <Scooter> That still leaves textPath (and glyphs) Jul 26 19:45:39 <jwatt> these things are out of my league at the mo Jul 26 19:45:49 <tor> afri: yes, though i18n text doesn't work Jul 26 19:46:17 <tor> afri: font size tends to be off Jul 26 19:46:37 <afri> i guess that's stuff we can live with Jul 26 19:47:29 <afri> so shall we move on to the next then? Jul 26 19:47:30 <tor> probably fixable - I'm using the "wimp api" for cairo fonts Jul 26 19:47:38 <Scooter> So, file a bug for textPath and move on? Jul 26 19:48:09 <afri> cool Jul 26 19:48:17 <Scooter> What's next? Jul 26 19:48:24 <jwatt> item 6 Jul 26 19:48:29 <tor> <defs> Jul 26 19:48:39 <afri> <defs>: why on earth are they stylable? Jul 26 19:48:54 <afri> & transformable? Jul 26 19:49:14 <tor> good batch of crack at the w3c? Jul 26 19:49:24 <tor> I mean, I'm sure they had a good reason Jul 26 19:49:43 <jwatt> another one for chris/dean? Jul 26 19:50:01 <afri> it looks to me as if everything that goes into a <defs> has its style and/or xforms applied whereever it's referenced from Jul 26 19:50:10 <afri> yeah, i'll mail the list Jul 26 19:50:25 <afri> although i usually don't get any answers Jul 26 19:50:50 <Scooter> Maybe all of us can sort of push for answers. I'm on the svg list also (mostly been lurking). Jul 26 19:50:54 <tor> <use> is supposed to use a combined cascade, which makes the style make a bit of sense Jul 26 19:50:57 <jwatt> then follow it up with personal emails Jul 26 19:51:42 <afri> ok, i guess i should take a look at the <use> specs before i complain about anything Jul 26 19:51:56 <Scooter> I've got to go get ready for my presentation. I'll be back in a couple of hours (if you all are still at it), but if not, will somebody summarize via E-Mail? Jul 26 19:52:25 <jwatt> yeah, somebody will Jul 26 19:52:29 <-- lsmith has quit (Read error: Connection reset by peer) Jul 26 19:52:33 <afri> Scooter: have fun Jul 26 19:52:42 <Scooter> Thanks! Talk to you soon. Jul 26 19:52:45 <-- Scooter (~chatzilla@...490...) has left #svg Jul 26 19:53:19 <afri> so shall we carry on ... or wait for scooter to come back ... or leave it for another day? Jul 26 19:53:53 <jwatt> I'm happy to carry on or wait 'til scooter gets back Jul 26 19:54:10 <tor> either is fine for me Jul 26 19:54:17 <jwatt> I'd rather not leave it until another day though Jul 26 19:54:37 <afri> ok Jul 26 19:54:47 <afri> what's next? Jul 26 19:54:48 <tor> no 7 - svg matrices Jul 26 19:55:00 <afri> should they be live or not? Jul 26 19:55:23 <afri> the specs say nothing Jul 26 19:56:02 <afri> does anybody have any strong feelings on this? Jul 26 19:56:18 <jwatt> but it seems that at least dean and the other SVG WG members that work on batik say they aren't Jul 26 19:56:30 <afri> if not, then i'd prefer to leave them as they are now... Jul 26 19:56:34 <jwatt> I would like to maintain compatibility with batik Jul 26 19:56:51 <jwatt> but to be honest I don't understand your reasons in the bug Jul 26 19:56:54 <afri> yeah but i think they just say that because that's how they implemented them in batik Jul 26 19:57:18 <jwatt> does dean work on batik? Jul 26 19:57:24 <afri> i don't know Jul 26 19:58:01 <jwatt> is there no other way of doing what you want them to do? Jul 26 19:58:52 <afri> do you think the compatiblity issue is a real issue? Jul 26 19:59:10 <afri> i mean in 'normal' svg usage this is unlikely to come up Jul 26 19:59:43 <jwatt> it's the kind of thing that I would be likely to come up against Jul 26 19:59:58 <jwatt> but then dom scripting is really what I like to do most Jul 26 20:00:06 <jwatt> I don't know about other users Jul 26 20:00:31 <afri> the way i see it is, the specs don't say anything, so anybody scripting in this area can't make any assumptions about it being live or not Jul 26 20:00:41 <jwatt> what I would be worried about is that people would start to take advantage of the fact that one matrix could be referenced by multiple transforms in mozilla Jul 26 20:01:12 <jwatt> and then it becomes impossible to change it without annoying a whole load of people Jul 26 20:01:15 <jwatt> maybe not, but they will Jul 26 20:01:43 <afri> the thing is I don't see why we should cripple our api because batik implemented something that is outside the specs in a particular way Jul 26 20:01:52 <afri> batik should change Jul 26 20:02:23 <jwatt> heh Jul 26 20:02:32 <afri> also, i think it is really inconsistent with other datastructures that have to be live Jul 26 20:02:35 <afri> e.g. points Jul 26 20:02:37 <tor> what does adobe do? Jul 26 20:02:49 <jwatt> adobe doesn't do that part of the dom Jul 26 20:02:51 <afri> why are points live and transforms aren't Jul 26 20:03:03 <jwatt> afri: yeah, I agree with that bit Jul 26 20:03:46 <jwatt> to be frank this is another WG mess that has no good solution Jul 26 20:03:58 <afri> i really think this is not a big interoperability issue Jul 26 20:04:24 <afri> live matrices are nearly a superset of non-live matrices Jul 26 20:04:46 <jwatt> well for the moment let's leave it as it is, and perhaps come back to it in the future Jul 26 20:04:56 <jwatt> I'll just get on with that bug and ignore the liveness aspect Jul 26 20:04:57 <afri> what i mean is, any code that is coded with non-live matrices in mind is likely to work in Moz as well Jul 26 20:05:06 <jwatt> brb Jul 26 20:05:21 <afri> not vice versa of course Jul 26 20:06:32 <jwatt> back Jul 26 20:06:35 <jwatt> afri: right Jul 26 20:06:37 <afri> so would you guys be ok with leaving it as it is for now? Jul 26 20:07:27 <tor> I'd be curious to hear what others thought about <embed> content Jul 26 20:07:28 <jwatt> for now yes, but I'd like to go over how much of a problem this would be for crocodile-maths with you later Jul 26 20:07:40 <jwatt> so <embed> Jul 26 20:08:03 <tor> oh, thought you were talking about the end of the meeting, not the item Jul 26 20:08:27 <afri> i think we should do <embed> Jul 26 20:08:37 <jwatt> I think we should allow the use of <embed> for svg content in html, but not in xhtml Jul 26 20:08:51 <afri> i don't agree with dbaron's objections Jul 26 20:09:10 <jwatt> I do for xhmtl Jul 26 20:09:10 <tor> is <embed> even in xhtml? Jul 26 20:09:23 <jwatt> actually I don't know Jul 26 20:09:36 <jwatt> come to think of it, probably not Jul 26 20:10:11 <jwatt> In which case I would support implementing it Jul 26 20:10:18 <jwatt> (your patch) Jul 26 20:10:40 <tor> but should we always use the internal svg? Jul 26 20:11:13 <tor> or should we <span class="quiet voice">add a pref</span>? Jul 26 20:11:23 <afri> heh Jul 26 20:11:44 <afri> does the abobe stuff work with moz? Jul 26 20:11:58 <afri> i've never tried it Jul 26 20:12:22 <tor> it did last time I tried Jul 26 20:12:23 <afri> from my point of view, always running native svg would be just fine Jul 26 20:12:57 <afri> it probably depends on how much people use asv with moz Jul 26 20:13:08 <tor> it would be a problem for a customer currently happily using svg beyond the capablities of mozilla Jul 26 20:13:21 <jwatt> does <embed> not have an attribute for specifying the prefered plugin? Jul 26 20:13:33 <afri> but are there customers like that? Jul 26 20:13:49 <afri> in which case, yeah, we'd probably need a pref Jul 26 20:14:30 <afri> sorry i got to go as well in a minute Jul 26 20:14:52 <afri> tor: what do *you* think about embed? Jul 26 20:14:59 <jwatt> afri: will you be back later when scooter gets back? Jul 26 20:15:14 <afri> if we had a pref would dbaron be ok with it? Jul 26 20:15:23 <tor> afri: I think we should handle embed content Jul 26 20:15:28 <afri> jwatt: hopefully Jul 26 20:15:52 <tor> afri: maybe we should check if a plugin can handle it first, then go to the browser? Jul 26 20:16:09 <afri> sounds good Jul 26 20:16:20 <afri> would that be easy to implement? Jul 26 20:16:43 <tor> not sure offhand - have to check the code Jul 26 20:17:27 <afri> ok, sorry gtg - talk to you later Jul 26 20:17:33 --- You are now known as afri_away Jul 26 20:19:49 <jwatt> tor: enumerate the gecko-content-viewers category for supported mime types? Jul 26 20:20:32 <jwatt> practically a quote Jul 26 20:36:44 --> santamarta (juanjo@...491...) has joined #svg Jul 26 20:40:53 <-- shaver (~shaver@...489...) has left #svg Jul 26 21:14:56 <tor> mailed the quartz guy to check the status of that backend Jul 26 21:23:18 <jwatt> cool Jul 26 21:23:23 <jwatt> afri: ping Jul 26 21:23:50 --> Hixie_ (~ianh@...492...) has joined #svg Jul 26 21:24:13 --> rocWork (roca@...493...) has joined #svg Jul 26 21:28:55 <jwatt> tor, we might come short of some aspects of svg tiny, but aren't there things we do that are only in basic or full? Jul 26 21:31:00 <tor> jwatt: yes, gradients are the big one Jul 26 21:31:14 <rocWork> mmm, gradients Jul 26 22:30:29 --> Scooter (~chatzilla@...490...) has joined #svg Jul 26 22:37:11 <-- DaaWk has quit (Ping timeout: 372 seconds) Jul 26 22:37:15 <jwatt> hi scooter Jul 26 22:37:35 <-- Daa has quit (Ping timeout: 372 seconds) Jul 26 22:39:18 <tor> did my mail get through? I haven't gotten the bounce back from drivers, but apparently gila is suffering from spammage Jul 26 22:39:44 <jwatt> tor: that's what my previous comment was about Jul 26 22:46:55 --> DaaWk (daa@...494...) has joined #svg Jul 26 22:48:08 --> Daa (daa@...494...) has joined #svg Jul 26 22:49:19 --- You are now known as afri Jul 26 22:56:21 <jwatt> afri: can you expand on what you mean by: 'Live' matrices that can be shared amongst several transforms come in very handy for things like implementing dynamic canvases where part of the objects should be transformation-invariant. Jul 26 22:57:16 <jwatt> particularly the part about "part of the objects should be transformation-invariant" Jul 26 22:57:29 <-- Scooter has quit (Remote host closed the connection) Jul 26 22:59:52 <afri> jwatt: well e.g. imagine a map where cities are displayed by some icon Jul 26 23:00:20 <afri> jwatt: as you zoom into the map you want the icons to stay at the same size Jul 26 23:01:14 <afri> ... but everything else should zoom Jul 26 23:01:45 <afri> so you need a different xform for the city icons and for everything else Jul 26 23:02:41 <jwatt> afri: I see, that makes sense