20:27:38 RRSAgent has joined #svg 20:27:38 logging to http://www.w3.org/2015/01/08-svg-irc 20:27:40 RRSAgent, make logs public 20:27:40 Zakim has joined #svg 20:27:42 Zakim, this will be GA_SVGWG 20:27:42 ok, trackbot; I see GA_SVGWG()3:30PM scheduled to start in 3 minutes 20:27:43 Meeting: SVG Working Group Teleconference 20:27:43 Date: 08 January 2015 20:28:31 stakagi has joined #svg 20:28:40 GA_SVGWG()3:30PM has now started 20:28:46 +[IPcaller] 20:28:55 Zakim, [IP is me 20:28:55 +ed; got it 20:29:50 +[IPcaller] 20:29:51 Zakim, [ is me 20:29:51 +heycam; got it 20:30:49 +??P5 20:30:53 +Doug_Schepers 20:31:05 zakim ??P5 is me 20:31:17 zakim, ??P5 is me 20:31:17 +stakagi; got it 20:32:02 BogdanBrinza has joined #svg 20:32:42 + +1.425.463.aaaa 20:33:06 Agenda: http://lists.w3.org/Archives/Public/www-svg/2015Jan/0009.html 20:33:10 Chair: Cameron 20:34:05 +[IPcaller] 20:34:27 -[IPcaller] 20:35:20 Zakim, pick a scribe 20:35:20 Not knowing who is chairing or who scribed recently, I propose +1.425.463.aaaa 20:35:40 richardschwerdtfeger has left #svg 20:35:44 +[IPcaller] 20:35:51 richardschwerdtfeger has joined #svg 20:36:19 +krit 20:36:30 shans_ has joined #svg 20:36:36 ScribeNick: BogdanBrinza 20:36:51 +Rich_Schwerdtfeger 20:37:02 First topic: transform on svg / ed 20:37:07 http://lists.w3.org/Archives/Public/www-svg/2014Dec/0003.html 20:37:08 +cabanier 20:37:37 +??P13 20:37:39 +??P10 20:37:41 The link clarifies the transform as a property 20:37:51 Zakim, ??P13 is me 20:37:51 +nikos; got it 20:37:57 though not clear how it should be applied 20:38:12 Zakim, ??P10 is me 20:38:12 +Tav; got it 20:38:13 how to put this on fragment for example 20:38:30 birtles: So how to apply it to fragments? 20:38:46 ed: Few option - apply inside/ outide svg 20:38:59 if that's defined in style - apply this as part of normal SVG layout 20:39:16 Firefox currently the only who does that as part of layout 20:39:33 birtles: Useful distinction of style transform vs property 20:39:53 ed: suggestion - so we need to describe in SVG spec how that is supposed to work 20:40:08 2. we need to agree how it's supposed to work 20:40:23 e.g. attribute should work the same as style transform 20:40:49 have we discussed before the viewbox and the order of transforms on the element 20:41:17 for example everybody agrees that porperty should apply as the attribute 20:41:30 but if one has viewBox and transform - which order do those apply 20:41:57 ed: Would expect transform spec should define this 20:42:10 jdaggett has joined #svg 20:42:26 Dirk: can add this as it's currently does not mention SVG element 20:42:32 * element 20:43:16 SVG embedded in HTML is normal HTML element and outer transform would apply first then viewbox would apply to root element inside 20:43:40 birtles?: that is easy way to describe this 20:43:57 s/birtles?/tav 20:44:15 Dirk: is special because it has viewbox attribute 20:45:04 Dirk: but transform does nothing to element 20:45:18 and for that might be confusing 20:45:37 So if I have a style on svg root that says transform: scale 20:45:53 in HTML context that would be scaled and in standalone context wouldn't be? 20:45:58 Tav: right 20:46:20 but from authoring perspective it's inconsistent when it applies vs when it doesn't 20:47:26 Tav: consider svg as a viewport on the other content, so transforms would apply outside 20:48:16 We should do whatever html is doing for the root element - so should act as if transform is applied as to outside element 20:48:40 Smailus has joined #svg 20:48:52 and panning and zooming should be described in the same sense - not as changing viewport, but as a transform on the root 20:49:29 Apologize... stuck in another meeting; will be on shortly. 20:50:05 ed: the order of the transform does matter and there were some equations how we're supposed to zoom 20:50:35 Eric do you know what implementation supports transform on svg element? 20:51:05 As attribute only Firefox currently supports that, as style property - other browsers 20:52:21 http://jsfiddle.net/6pnnkoz3/5/ 20:52:24 +Thomas_Smailus 20:53:03 -nikos 20:53:43 20:53:43 20:53:43 20:54:48 http://lists.w3.org/Archives/Public/www-svg/2014Dec/0013.html 20:55:30 +??P13 20:55:59 Zakim, ??P13 is me 20:55:59 +nikos; got it 20:56:27 ok 20:56:30 next week it is 20:56:41 richardschwerdtfeger has left #svg 20:56:50 -Rich_Schwerdtfeger 20:56:52 Bogdan: looking at the sample IE is the same as Chrome and Eric mention other browsers as the same 20:57:06 ed: the follow up is to agree that transform should apply from outside 20:57:22 and both cases html/standalone should work the same way 20:57:58 ed: would like to fix those resolutions 20:58:29 Any objections to have property and style attrubute work the same on element and apply outside? 20:58:39 (no objections) 20:59:20 RESOLUTION: transform property applies conceptually to the outside of element and there is no difference between prsentation attribute and style property 21:00:07 we can be more clear in SVG spec to call this as new feature 21:00:15 also might be in transform spec as well 21:01:02 ACTION: ed to call out transforms working the way we resolved as new feature 21:01:03 Created ACTION-3691 - Call out transforms working the way we resolved as new feature [on Erik Dahlström - due 2015-01-15]. 21:01:30 #svgVIew(viewBox(...)) 21:02:49 ed: If you specify svg viewBox as attribute in style and transform all on root element 21:03:00 how would that apply - in what order 21:03:53 http://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.html 21:03:56 this came as complaints from some old testsute 21:04:51 correction: the above combination is of transform and fragment, not style attribute 21:05:11 if you give transform fragment syntax and make this apply inside svg element 21:05:21 this might be confusing on how this is supposed to work 21:05:43 ed: the spec doesn't clarify how this is supposed to work especially in combination with viewBox 21:06:24 currently if you specify fragment that would override transform you had, same should apply to viewBox 21:06:48 what implementation support tranform on the root? 21:07:31 ed: I would guess this would work like html root 21:08:21 we need to know implementations that support transforms in fragment declaration and how this interacts with attribute 21:08:45 ed: the worry is real usage - transform + svgView syntax 21:08:53 how likely we'll see somthing like this? 21:09:58 shepazu has joined #svg 21:09:58 so we'd like to see what we all are doing here at the moment 21:10:36 ACTION ed: get tests that would show what implementations are doing with transforms in fragments now 21:10:37 Created ACTION-3692 - Get tests that would show what implementations are doing with transforms in fragments now [on Erik Dahlström - due 2015-01-15]. 21:10:56 Scribe: Cameron 21:10:56 -nikos 21:11:00 ScribeNick: heycam 21:11:15 Topic: SVG 2 assessment 21:11:16 +??P0 21:11:23 Zakim, ??P0 is me 21:11:23 +nikos; got it 21:11:44 BogdanBrinza: I have a document that I want to put somewhere 21:11:57 ... Rossen and I put this together 21:12:03 ... we spent some time looking at the issues/actions 21:12:17 ... we tried to put some "readiness" of different parts of the spec 21:12:30 ... I want to put this document in front of us soon 21:12:55 ... there are some big parts that have more problems/instability than others 21:13:02 ... so I'd like to get some more attention to them 21:13:14 ... the first chapter with the most issues is the Document Structure chapter 21:13:18 q+ 21:13:21 ... specifically, , , and Conditional Processing 21:13:26 <heycam> ... looks like it has lots of issues 21:13:45 <heycam> ... the next one is Text, and specifically shape-inside property 21:14:06 <heycam> ... next is Painting chapter, particularly dashing 21:14:20 <heycam> ... it looks like the new properties added have some issues that need resolving 21:14:49 <heycam> ... the second last big one is Paint Servers; it doesn't have any particular area that sticks out, but the first half has a bunch of open issues 21:15:25 <heycam> s/second// 21:15:30 <heycam> ... I can put this spreadsheet on the wiki 21:15:49 <heycam> ... it would be worth looking at the specific issues and working to resolve them 21:15:52 <heycam> ... around 50 issues 21:16:18 <heycam> ... I'll follow up with specific issues on the mailing list 21:16:30 <heycam> Zakim: ack 21:16:48 <heycam> shepazu: I have some experience with wiki tables, if you send me the document I'll convert it into a wiki table quickly 21:16:53 <krit> q+ 21:16:58 <heycam> Zakim, ack shepazu 21:16:58 <Zakim> I see krit on the speaker queue 21:16:58 <ed> q+ 21:17:24 <heycam> BogdanBrinza: off topic, we also made some progress on SVG Hinting 21:17:29 <heycam> ... with some specific proposals 21:17:51 <heycam> Zakim, ack krit 21:17:51 <Zakim> I see ed on the speaker queue 21:18:01 <heycam> krit: I added/opened some issues on the GitHub page for the spec 21:18:04 <heycam> ... so that's also an option 21:18:17 <heycam> shepazu: yeah, I think it's a good idea to have this spreadsheet that summarises everything. but we should break it out. 21:18:25 <heycam> ... those things we all agree, we should break out to individual issues on the spec 21:18:30 <heycam> Zakim, ack ed 21:18:30 <Zakim> I see no one on the speaker queue 21:18:53 <heycam> ed: Bogdan, you went through the spec; did you mostly look for issues called out in the spec? or were you looking for reviewing / finding issues outside of those already mentioned? 21:18:54 <heycam> BogdanBrinza: both 21:18:59 <heycam> ... we looked at the spec with fresh eyes 21:19:30 <heycam> ... there's a correlation; if there were issues called out on a section, then there were concerns we had already 21:19:39 <heycam> ... this came up particularly in the Painting chapter 21:19:43 <heycam> ... those comments will be in the spreadsheet 21:20:03 <heycam> ed: to the group: how do we want to handle FIXMEs in the spec? issues in the spec, or a bug tracker? 21:20:56 <heycam> heycam: I put issues inline in the spe 21:20:58 <heycam> spec 21:21:05 <heycam> ... but I don't mind them being tracked in GitHub issues or whereever 21:21:17 <heycam> Tav: I like them being in the spec 21:21:31 <heycam> krit: that's fine, but for issues discussion it's not good 21:21:35 <heycam> s/issues/issue/ 21:21:45 <heycam> ed: the issue numbers change too 21:22:07 <heycam> heycam: we can keep the inline notes and link them to whereever we're having the discussion 21:23:02 <heycam> Tav: I'll be spending more time on spec editing over the next month 21:23:19 <heycam> ACTION: Get the SVG 2 issues document on the wiki with Doug's help 21:23:19 <trackbot> Error finding 'Get'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>. 21:23:24 <heycam> ACTION: Bogdan Get the SVG 2 issues document on the wiki with Doug's help 21:23:24 <trackbot> Created ACTION-3693 - Get the svg 2 issues document on the wiki with doug's help [on Bogdan Brinza - due 2015-01-15]. 21:24:11 <shans_> shans_ has joined #svg 21:24:20 <heycam> Topic: SVG Hinting 21:24:55 <heycam> BogdanBrinza: one thing Chris Lilley mentioned was how implementations depending on scale factors, non-integer pixel scaling issues 21:25:09 <heycam> ... one of the way to improve that was making sure paths/lines end up at integer pixels when you start or end the line/path 21:25:16 <heycam> ... that by itself would address a large body of the feedback 21:25:29 <heycam> ... likewise, we do want to prototype something to better align shapes 21:25:47 <heycam> ... including nearby shapes 21:26:27 <heycam> ... using some simple heuristics, e.g. if the shapes are grouped together with <g> you might try harder to ensure they're rendered at the same pixel 21:26:41 <Zakim> -nikos 21:26:44 <heycam> shepazu: for example if there are two states with a common border, you want to signal that they share a common border if they're transformed 21:26:56 <heycam> BogdanBrinza: instead of signalling, you could know this by the document structure and ordering 21:26:57 <Zakim> +??P0 21:27:01 <nikos> Zakim, ??P0 is me 21:27:01 <Zakim> +nikos; got it 21:27:08 <heycam> ... so an implementation detail on how we can improvde the rendering without requiring additional markup 21:27:41 <heycam> shepazu: you're saying do it automatically. would that be implementaiton specific? or would we specify that when things are grouped/transformed together, you should use this algorithm to make sure the pixels align 21:27:46 <heycam> BogdanBrinza: the latter is definitely preferable 21:27:57 <heycam> ... before speccing, prototyping would be good to see how well it works 21:28:33 <heycam> shepazu: speccing for interoperability, which would be great, in addition to implicit signals we should have an explicit signal because when you're structuring a document you're structuring for different reasons 21:28:43 <heycam> ... you could need to have shapes in different groups for certain reasons 21:28:47 <heycam> BogdanBrinza: I would agree with that, yes 21:28:58 <heycam> ... we've been looking at a look of CSS/HTML compat issues 21:29:39 <heycam> ... authors are trying to align things but don't get it exactly right 21:29:49 <heycam> ... but yes some authors might want explicit control for this 21:30:02 <heycam> shepazu: or just optimise according to different signals than the default 21:31:10 <heycam> Tav: would be good to have before and after images 21:31:29 <Zakim> -Thomas_Smailus 21:31:53 <Zakim> -cabanier 21:31:56 <Zakim> -ed 21:31:58 <Zakim> -nikos 21:32:00 <Zakim> -heycam 21:32:00 <Zakim> - +1.425.463.aaaa 21:32:05 <Zakim> -birtles 21:32:06 <Zakim> -Tav 21:32:07 <Zakim> -krit 21:32:09 <Zakim> -stakagi 21:32:12 <Zakim> -Doug_Schepers 21:32:14 <Zakim> GA_SVGWG()3:30PM has ended 21:32:14 <Zakim> Attendees were [IPcaller], ed, heycam, Doug_Schepers, stakagi, +1.425.463.aaaa, birtles, krit, Rich_Schwerdtfeger, cabanier, nikos, Tav, Thomas_Smailus 21:32:21 <heycam> RRSAgent, make minutes 21:32:21 <RRSAgent> I have made the request to generate http://www.w3.org/2015/01/08-svg-minutes.html heycam 21:33:05 <shepazu> PDF on kindle is terrible 21:33:08 <heycam> :) 21:33:18 <shepazu> HTML is much better 21:33:48 <shepazu> and I can always go back to the computer for images and diagrams, which (nikos is right) are terrible on kindle, too 21:34:02 <heycam> I did a bunch of manually sizing and laying things out to the page when it didn't come out right in the PDF 21:34:12 <heycam> especially for things like page top/bottom floated figures 21:34:16 <Tav> How did you convert HTML to PDF? 21:34:20 <heycam> so not sure how they would turn out 21:34:23 <heycam> Tav, I used Prince 21:34:47 <shepazu> y u no SVG?!?!? 21:34:55 <heycam> I used SVG for the figures :) 21:35:00 <shepazu> :D 21:35:22 <shepazu> (and the code samples...) 21:35:48 <shepazu> heycam, if you could pass on the HTML, that would be great 21:36:12 <heycam> shepazu, sure, I'll see if I can get it in a form that works 21:36:20 <shans__> shans__ has joined #svg 21:36:27 <shepazu> thanks! 21:37:30 <heycam> shepazu, do you mind if it's XHTML? :p 21:37:41 <ed> docbook? 21:37:56 <shepazu> heycam, no, I'm going to convert to MOBI anyway 21:37:56 <heycam> hopefully should parse as normal HTML just as well 21:37:59 <heycam> ok 21:39:05 <Tav> I can't imagine writing a thesis in HTML.... Did my thesis in latex and book in docbook (latex was far easier). 21:39:18 <birtles> shepazu: can you pass on the MOBI when you're done? (Assuming heycam doesn't mind) 21:39:50 <heycam> I don't mind 21:40:00 <heycam> are you having trouble sleeping at nights birtles and need something to help? 21:40:30 <birtles> I just got a kindle and started reading again :) 21:40:43 <heycam> so actually the HTML looks kind of OK. you might want to fix the margins. and the bibliographic reference numbering seems to be broken. apart from that looks good. 21:40:54 <birtles> and a couple of times recently I thought, "If only I had cSVG!" 21:41:00 <heycam> ha :) 21:41:08 <heycam> a few cases of figures overlapping text 21:41:11 <heycam> I'll let you deal with that though 21:41:49 <shepazu> birtles, will do! 21:41:53 <birtles> thanks! 22:06:40 <jcraig> jcraig has joined #svg 22:23:58 <jcraig> jcraig has joined #svg 22:54:03 <jcraig> jcraig has joined #svg 22:59:10 <jcraig> jcraig has joined #svg 23:30:23 <jcraig> jcraig has joined #svg 23:30:50 <jdaggett> jdaggett has joined #svg 23:47:45 <shans_> shans_ has joined #svg