20:12:03 RRSAgent has joined #svg 20:12:03 logging to http://www.w3.org/2011/03/01-svg-irc 20:12:05 RRSAgent, make logs public 20:12:07 Zakim, this will be GA_SVGWG 20:12:07 I do not see a conference matching that name scheduled within the next hour, trackbot 20:12:08 Meeting: SVG Working Group Teleconference 20:12:08 Date: 01 March 2011 20:12:12 Zakim, room for 4? 20:12:13 ok, heycam; conference Team_(svg)20:12Z scheduled with code 26631 (CONF1) for 60 minutes until 2112Z 20:12:46 Team_(svg)20:12Z has now started 20:12:53 anthony_nz has joined #svg 20:12:53 + +1.649.363.aaaa 20:13:28 +tbah 20:14:05 birtles has joined #svg 20:14:09 jun has joined #svg 20:15:19 eseidel has joined #svg 20:19:32 Chair: Cameron 20:20:19 karl has joined #svg 20:21:06 SCRIBENICK: dholbert 20:21:12 RRSAgent, this meeting spans midnight 20:21:50 TOPIC: Compositing 20:21:57 Zakim, who is on the call? 20:21:57 On the phone I see +1.649.363.aaaa, tbah 20:23:07 http://dev.w3.org/SVG/modules/compositing/master/Overview.html 20:23:21 AG: That has the latest version 20:23:31 AG: Doug originally merged the language and the primer 20:23:51 AG: It was originally in 2 parts, each property had 2 sections. I've merged it all together & added a few examples to it 20:24:06 AG: I also had a few coments from people on the mailing list; addressed those 20:24:40 ... I also put simplified versions for the blend mode equations. Equivalent to more complicated earlier forms 20:24:58 + +1.425.868.aabb 20:25:04 i'm in 20:26:06 AG: I believe this is ready for last call for publication & we should take it to CR 20:26:21 AG: Doesn't have a test suite, but the examples can be used as (to make) tests 20:27:15 CM: So we've got enable-background - is that same definition as in 1.1? 20:27:30 AG: No - it's different from filter enable background, if that's what you're asking 20:28:02 CM: Ah, so it only applies to filters in 1.1? 20:28:34 AD: This new rewording is meant to clarify that a bit 20:29:02 CM: Have there been many changes since we last looked at it? 20:29:11 AG: Not really - some of the equations have been tweaked 20:30:06 jwatt has joined #svg 20:36:42 AG: (asks AD about accumulate w/ enable-background) 20:37:22 AD: The big problem w/ integrating porter-duff w/ svg enable-background accumulate is you have to do a removal step 20:38:01 AD: Only matters in porter duff modes other than "over" 20:38:53 AD: Once we worked out that you needed that technique, it required a lot of math to work out how that works for all of the modes 20:38:57 CM: Is that in the spec? 20:38:58 AD: Yes 20:39:31 AG: What about accumulate? 20:39:33 AD: You only need to worry about accumulate if you're applying porter-duff to that group 20:39:45 Is someone scribing 20:39:45 CM: I'm happy for this to go to last-call 20:39:57 ED: One little thing - it's normatively referencing 1.2 20:40:04 CL: 1.2 tiny? 20:40:07 pdengler_home has left #svg 20:40:08 ED: No, 1.2 full 20:40:18 AG: I can make that 1.1 instead 20:40:52 CL: Yeah, do that 20:40:57 pdengler_home has joined #svg 20:41:05 shepazu has joined #svg 20:42:21 DS: So this in itself is sufficient for anybody to do compositing? 20:43:01 AD: From an author's point of view, they only really care about the blend modes, since they're in photoshop & illustrater. The porter duff modes being in there help it work with Java 2D 20:43:14 CM: Do you have some examples of cool stuff you can do with porter duff? 20:43:32 AD: Original paper has some - e.g. plus lets you smoothly blend between two videos 20:43:39 CL: It'd be handy to have those sorts of examples in the spec 20:43:47 AG: Can I reference Second Edition? 20:43:59 CL: Yes, you can't not do that 20:44:01 RRSAgent, pointer? 20:44:01 See http://www.w3.org/2011/03/01-svg-irc#T20-44-01 20:44:46 CL: In the references section, it mentions PDF, but that's not actually used/cited anywhere 20:44:58 CM: Actually none of those references are used/cited anywhere 20:45:11 AG: Yeah, I should go through that 20:45:41 CM: Do you know if the spec builds properly? 20:45:50 AG: Yes, I think we got that working 20:45:55 ChrisL has joined #svg 20:46:02 AD has joined #svg 20:46:06 AG: So with the references ... 20:46:16 CM: If you're going to have a normative reference, it'd be SVG 1.1 20:46:37 CM: If you wanted to include an explicit actual reference/citation in the spec, just do it the first time you mention SVG 20:47:25 RESOLUTION: Move compositing spec to last-call, after references have been fixed 20:47:47 DS: There's a couple of things you'll need to fix in the images - some are missing xlink:href namespace decl 20:47:54 ACTION: ChrisL to request puiblication of compositing spec 20:47:55 Created ACTION-2982 - Request puiblication of compositing spec [on Chris Lilley - due 2011-03-08]. 20:48:27 DS: Also, some of the images are using a raster as the background, and when it blows up, it looks really bad. 20:48:37 DS: I'll make a SVG version of that background that you can use 20:48:56 ACTION: Doug to fix the images in the compositing spec 20:48:57 Created ACTION-2983 - Fix the images in the compositing spec [on Doug Schepers - due 2011-03-08]. 20:49:38 DS: As a general rule, where we have images in the spec, I'd like to have SVG with a fallback to the PNG, rather than having a PNG that links to SVG 20:50:05 CL: That's good if it's using SVG 1.1, but if it's using something newer... 20:50:24 DS: for newer features, we can make a mockup using SVG 1.1 20:50:35 CM: Might have to use a PNG for mocking up some things 20:50:44 DS: Sure, we can do that if we need to 20:51:27 - +1.425.868.aabb 20:52:22 roc has joined #svg 20:53:36 RO: Main issue I have w/ enable-background is (with filters) -- if you have an input image bigger than the viewport, and you're filtering it, you might need to sample regions of the image outside of the viewport. What that means is, when you've got enable-background operating, you can't apply normal viewport clipping 20:53:58 CL: Can't you calculate how far out you'd need? 20:54:19 RO: You can, but some filter primitives require that you'd draw the whole background 20:54:37 RO: Normally the natural thing to do is to clip to the viewport at the beginning 20:54:51 ... it's possible to have things that are infinite in extent, like a tiled CSS background 20:55:21 ... so no one has implemented it correctly yet, so it's not clear that it's implementable 20:55:28 (anthony, the following files need an xlink namespace declaration, in http://dev.w3.org/SVG/modules/compositing/master/examples/ : compop-porterduff-examples.svg, compop-blend-examples.svg, clip-to-self-examples.svg ) 20:56:06 AG: w/ references - did we write a requirements doc for compositing? 20:56:22 CL: Normally you don't need to reference that from within the spec 20:57:25 AG: I'll work on those references today and have it ready by next week 20:57:43 DS: Can you fix those xlink:href's too? and I'll work on the background thing 20:58:00 -tbah 20:58:47 +tbah 20:59:47 RO: Ah, so the issue that I talked about w/ clipping doesn't come up with this spec. But do we need enable-background? 21:00:33 AS: So the standard blending modes are just using alpha compositing - don't need to worry about enable-background for those 21:00:36 *AD 21:01:04 AD: ... but with the more complex ones, it's important 21:01:24 RO: So with the new rectangle thing, do we need that, or can we infer that? 21:01:40 RO: We can probably optimize that automatically 21:02:07 AG: It's an implementation hit, and I'd put it in because someone requested it 21:02:30 CL: Let's keep it in the spec, but later add a comment saying that it's not mandatory and can be dropped 21:02:41 ... for last-call 21:03:10 RO: It adds extra work for us to do that clipping, when it's not always necessary/useful 21:04:01 RO: In the clip-to-self property, it talks about whether you use bounded vs unbounded operators 21:04:25 ... it talks about the shape of the object. But is that well-defined for all shapes? e.g. circle with stroke of dashes - what do we clip to? 21:04:56 ... so if it's dashed with opacity 0, do we consider that part of the shape of the object? 21:05:15 CM: If it's fill:none, it wouldn't be included, but if it's opacity 0, it would 21:05:30 AD: This is partly for compatibility with Java 2D 21:05:40 RO: We had similar issues with canvas 21:06:01 RO: I think this needs to be clarified - all these edge cases, whether pixels are affected or not 21:06:16 AD: yeah, which pixels have been 'touched' 21:06:24 RO: We need to define what 'touched' pixels means 21:07:05 CM: spec says -- "for filled and stroked shapes and text, the object is directly converted to a clipping path" 21:07:17 CM: Perhaps that means 'if you stuck it in a '? 21:07:27 CL: No, it's clipped as if it _was_ a clipping path 21:08:17 ACTION: Anthony to clarify clip-to-self behavior 21:08:17 Created ACTION-2984 - Clarify clip-to-self behavior [on Anthony Grasso - due 2011-03-08]. 21:08:39 RO: I think it'd be useful if it matched clipPath behavior 21:08:56 AD: but clip-to-self works with antialiased edges 21:09:18 RO: We can say the shape is the same, but the edges are up to the implementation 21:09:50 CL: We shouldn't use wording that suggests that anything magical happens with an anonymous under the hood 21:10:15 CM: Maybe we should express it in terms of a mask instead? 21:10:55 AG: so it's just 'whatever pixels are painted'? 21:11:03 RO: That's still not entirely clear 21:11:45 RO: It has to be precise, but we shouldn't so much suggest how to implement it 21:11:56 AG: So are we still happy to publish, then? 21:12:15 CM: So we've got note about enable-background new, the references, clip-to-self -- is that all that's required? 21:14:02 RO: So we don't leave last-call until there are 2 implementations & tests? 21:14:13 DS: No, candidate-recommendation is where that happens 21:14:41 DS: (and you might go back to last-call after being in CR) 21:15:48 topic: Advanced Gradients 21:16:21 http://www.w3.org/Graphics/SVG/WG/wiki/images/f/fc/SVG_Advanced_Gradients_Requirements.pdf 21:16:25 AG: So this was discussed last year - making some sort of feature better than the current gradients that we have, because they're fairly basic 21:16:38 AG: I drafted some use-cases & requirements for some advanced gradient feature 21:16:52 AG: I think SVG 2 would look a bit poor with just the basic gradients that we have 21:17:01 CM: Given how often people have been asking for advanced gradients 21:17:21 AG: I've left the draft pretty open-ended in terms of focusing on specific tech 21:17:43 AG: Some of the input that went into this came directly from authors & usability specialists - the people who actually do the drawing 21:17:53 eseidel has joined #svg 21:17:56 AG: I haven't committed it yet since I don't really know where to stick it 21:18:37 AG: (The wiki wouldn't let me upload an HTML document, so that's why it's a PDF right now.) 21:21:26 Alex has joined #svg 21:21:42 AG: (puts spec on projector) 21:22:15 AG: The first part is just boilerplate. The bits that are different from the template are the introduction... 21:22:28 ... So 'usage scenarios' is the first bit that I added. 21:22:40 CM: So are these what your designers said they wanted? 21:23:05 AG: Yeah - they wanted to be able to produce naturalistic images in a pretty simple way, with a compact representation 21:23:31 ... they're used to it in photoshop, where it works but is difficult to lay down all the mesh points 21:23:54 ... They want something between that and what they can do in illustrator. 21:24:10 DS: Would be nice to somehow combine gradients 21:24:37 AD: Tav had some demo page. I had to implement some of that and it was quite hard 21:25:38 http://tavmjong.free.fr/SVG/MESH/Mesh.html 21:25:41 ... I did a lot of investigation. What you'd have to do is provide a triangular mesh and at each mesh point provide a normal 21:25:57 DS: suboptimal from an author's point of view 21:26:23 CL: I'm wondering if you could lay out your mesh, and at each point use luminance to get a height, and then calculate normals based on that 21:28:08 AD: The phong formulas assume light reflection, and that requires an angle of incidence w/ triangle, which you need the normals up-front for.. I guess the conclusion is it's non-trivial 21:28:22 DS: So it's non-trivial to author? 21:28:31 AD: It's trivial with authoring tools like Maya, etc 21:28:47 AG: But what about hand-authoring to tweak something? 21:29:12 CM: What about animating it? 21:29:21 AD: If you define the syntax right, it wouldn't be too hard 21:29:48 AD: Making the object move might be tricky - but making it look like the light is moving would be trivial (by animating the normals) 21:30:07 CM: Can you do that with filters, too? 21:30:33 AD: Yeah 21:30:51 AG: So -- I put a few examples in there of the usage scenarios 21:31:43 AG: (opens an artistic effect demo) At the moment, to do this in SVG is nontrivial / impossible 21:32:08 CM: Do you have a summary of tools & which kinds of gradients they can do? 21:32:14 AG: No, not yet 21:32:32 CM: If mesh gradients are tricky, they might still be worth it if people are familiar with them 21:34:04 AG: (scrolls to 'special considerations for advanced gradients') 21:34:15 AG: So there's a section for memory & processor requirements 21:34:51 DS: We should ask other authoring tool companies what they think about this 21:35:11 ED: Scribus has mesh gradients, and they export SVG, but I don't know what syntax they use 21:35:51 TB: Now that Cairo has support for mesh gradients, there's a lot of interest in them 21:36:38 AG: I noticed you have a lot of good information on that link you dropped in - would it be possible to put that into advanced gradients use cases/requirements? 21:36:45 TB: Sure, you can take anything you want 21:36:57 AG: Yeah, it'd be nice to just take that research and put it into a W3C document 21:37:34 DS: In a Google-search for cairo gradient mesh, the fifth link is Tav's document 21:37:44 TB: mm hm 21:38:12 CM: Anyone know if other graphics libraries like CoreGraphics have advanced gradient support? 21:38:23 AlexD has joined #svg 21:38:36 DS: So it sounds like gradient meshes are certainly of interest - regardless of what else we do, we should probably have gradient meshes 21:39:09 AG: One of the things designers want is to control how far color spreads out from a point 21:39:20 DS: More like an ellipse or like a circle? 21:39:41 CM: so normal gradient meshes do color interpolation between the three points 21:40:14 TB: tensor meshes have extra control points - that is implemented by cairo 21:40:28 DS: We should talk to the cairo guys 21:40:35 RO: We can look at the code & documentation 21:40:49 AG: I added animatability as one of the requirements 21:41:22 AG: Also, 'syntax can be easily authored by hand', or at least easily understood by authors 21:41:52 AG: also, I added a requirement that we maintain compatibility with CSS where possible 21:42:10 DS: They'll likely follow whatever this spec does 21:42:27 A new CAD mesh segmentation method, based on curvature tensor analysis 21:42:28 DS: There was an action on Tav to talk to Tab Atkins 21:42:29 Computer-Aided Design 21:42:29 Volume 37, Issue 10, 1 September 2005, Pages 975-987 21:42:36 TB: Haven't done that yet 21:42:38 Guillaume Lavou�Corresponding Author Contact Information, E-mail The Corresponding Author, Florent DupontE-mail The Corresponding Author and Atilla BaskurtE-mail The Corresponding Author 21:42:52 CM: Easily authoring by hand will be tricky - even authoring paths by hand is difficult 21:43:19 AG: I meant more that it's easy to follow. With paths, you can look at it and see "cubic bezier, etc". 21:43:30 CM: Ah, yeah - so just 'not a binary blob' I guess 21:43:34 -tbah 21:43:47 DS: So RE animation -- the gradient itself must be animatable, I guess 21:44:00 BB: So what about diffusion curves? 21:44:33 AG: Authors like that concept, but they have some problems - e.g. how they interact with each other. They'd like more control over how the color diffuses and what the color stops are 21:44:43 ... and they'd like to make it so only one side will diffuse 21:44:48 I just got cutoff and the access code is "restricted" at this time. 21:45:00 ... so it has things they like, but they have issues with it 21:45:11 shepazu: cairo's "mesh patterns": http://cgit.freedesktop.org/cairo/tree/src/cairo-pattern.c#n801 21:45:17 - +1.649.363.aaaa 21:45:19 Team_(svg)20:12Z has ended 21:45:21 Attendees were +1.649.363.aaaa, tbah, +1.425.868.aabb 21:45:54 (break) 21:46:26 OK, I'll probably just head off to lala land. Thanks. 22:14:22 AG: so I'll make the suggested changes, and then we can publish at some point 22:14:51 ACTION: Anthony to fix advanced gradients spec 22:14:51 Created ACTION-2985 - Fix advanced gradients spec [on Anthony Grasso - due 2011-03-08]. 22:15:46 Scribe: Cameron 22:15:53 ScribeNick: heycam 22:15:56 Topic: WOFF in SVG 2 22:16:15 CL: [summarises history of downloadable fonts] 22:19:27 AD has joined #svg 22:20:32 ... [summarises why SVG fonts were devised, and what WOFF does] 22:20:55 ... so coming into SVG 2 we have WOFF which is everywhere now 22:21:02 ... we can do nicer things in svg now that we have this font format 22:21:09 ... it's way better internationalized than svg fonts 22:21:22 ... i looked at using graphite with svg fonts, but there'd be a lot of work for that 22:21:29 ... and it's not the direction the industry is going 22:21:36 ... so my proposal is to mandate woff in svg 2 22:22:45 ... i'd like to see it in batik 22:23:03 ... it's already in firefox since 3.6, and opera since 11.1 or so 22:23:09 ... in ie9 since preview 2 22:23:41 ... the only format that mobile safari used to support was svg fonts 22:23:49 ... which is why fontsquirrel etc. output svg fonts 22:23:57 ... i believe the new mobile safari supports woff 22:24:13 ED: are there any other formats that should be mandated? and reason to just require woff? 22:24:22 CL: if you've got a ttf/otf font you can convert it to woff easily 22:24:35 ... some browsers support linking to native ttf/otf, some don't 22:24:43 ... most of hte font vendors hate the idea of link to tt/otf 22:24:52 ... even though they know it's trivial to convert between them and woff 22:25:09 ... it's the difference between picking up a wallet on the street, and taking it out of a car 22:25:26 ... we've been careful in the fonts wg to not require any browser enforcement 22:25:51 s/and reason to just/any reason to just/ 22:26:04 ... so the font guys are happy to license fonts for desktop (otf) or the same font in woff for online 22:26:18 ... it's a big deal. there's a whole new font industry now. 22:26:25 ... and the free font industry too, the open font library 22:26:42 ... if we require it that you're linking to raw otf then it's going to ruffle a lot of feathers 22:26:59 RO: ie9 does allow linking to raw ttf fonts, if they've got the correct permissions bits set 22:27:14 CL: right, and also enforces a same origin restriction 22:27:29 DS: but nobody objects to requiring woff? 22:27:39 (no) 22:28:00 JF: what is the current status with html5 and woff? 22:28:08 CL: html5 doesn't mention woff, because it doesn't talk about formatting as such 22:28:13 ... it's css that talks about formatting 22:28:25 ... currently it's completely separate. the css3-fonts spec which says how to link to fonts. 22:28:37 ... the woff spec references css3-fonts, but there's no requirement in css3 to support woff 22:28:54 JF: you are suggesting svg2 to reference directly to woff, not just css3-fonts? 22:29:01 CL: right, because css3-fonts doesn't require any particular font format 22:29:10 karl has joined #svg 22:29:14 ... if that requirement moved to css3-fonts, we wouldn't need to have it in our spec 22:29:23 ... for the moment i think it makes sense to put it in there 22:29:29 ... we can take it out later if css3-fonts starts to require woff 22:29:40 ... we should also link to css3-fonts instead of css3 in svg2 22:29:47 ... which also gets us the cool new features 22:30:28 JF: if we mandate the use of woff in svg, does that mean html5 implementations also need to support woff? 22:30:33 DS: svg support is not required by html5 22:30:42 ... but an html5 & svg user agent would be required to 22:30:56 CL: the implementaitons of html5 already have woff support, mostly 22:31:12 JF: i'm just wondering if we should align with html5 22:31:32 CL: we can suggest that html5 requires that, but i suspect it won't, because it's css's job to do the rendering 22:31:38 ... but i notice that epub3 requires woff 22:32:01 RESOLUTION: We will mandate WOFF support in SVG 2. 22:32:14 AD: should we consider being able to encode it inline just like in svg fonts? 22:32:20 ... so we can have self contained files with font data? 22:32:25 ... that's a major benefit of svg fonts 22:32:31 CL: something other than using a data uri? 22:32:40 AD: something like data uri 22:32:47 CL: yes that would already work 22:33:19 RO: how abotu the size of a woff font compared to an svg font? 22:33:32 CL: svg fonts have not much overhead, once gzipped is reasonable 22:33:49 RO: MB-sized data uris work fine in gecko 22:34:15 AD: it's be nice to have a better encoding for data uris 22:34:27 CL: that's a general thing for binary stuff, xml isn't very good at including binary stuff 22:34:39 AD: base64 was designed in an old era that doesn't really apply 22:34:56 ... for an era when you only had 6 guaranteed bits 22:35:13 DS: just write an rfc for it 22:35:42 CL: you could an extra encoding, other than ",base64" to data uris 22:35:49 AD: base64 decoding is slow 22:35:59 ... if the encoding was simpler... 22:36:07 ... so something similar to base64 but using more bits 22:36:25 ... base64 requires a lot of bit shifting 22:37:47 CL: feel free to have at it. it's not for this wg to do, though. 22:38:51 Topic: SVG Fonts 22:38:57 ED: i wrote up a short page 22:39:03 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/SVG_Fonts 22:39:19 ... this will require SVG 1.2 Tiny Fonts for SVG 2, but to leave out the complex fonts for a separate module 22:39:35 AD: i think that's a sensible thing, since so many devices already implement 1.2T SVG Fonts 22:39:51 ED: SVG Tiny 1.1 defined it too 22:39:55 ... but better defined in 1.2T 22:40:05 CL: the tiny fonts are simpler, you don't have any content as a glyph 22:40:25 ... so all the cool stuff you can't do in opentype, you can't do in Tiny SVG Fonts 22:40:30 ... but you can build it on the fly with script 22:41:26 ... some things tiny svg fonts can do that opentype can't do 22:41:51 ... various path shapes aren't allowed in opentype, like self-intersecting curves, and many requirements on curve control point positions 22:41:57 BB: is that an extra feature? 22:42:06 DS: it's ease of use 22:42:26 CL: it's extra stuff that you have to do with an opentype font 22:42:36 ... you can mix cubic/quadratic curves in the same glyph, whatever you want 22:42:49 ... producing something on the fly, or draw a handwriting font, is more tractable using svg fonts 22:43:44 ED: altGlyph isn't part of TIny fonts 22:43:47 s/TIny/Tiny/ 22:43:58 DS: i think we should be looking at a variety of possible options for SVG2 22:44:11 ... one of them is allowing a to be inline, so it doesn't have to be associated with a font parent 22:44:17 ... could just be a glyph inline 22:45:13 homata_ has joined #svg 22:48:56 (some discussion about y-up coordinate systems) 22:50:42 BB: i want to know what we get by requiring 1.2T fonts in SVG2 22:50:50 ... so we get access to the path data, and it's easier to author 22:50:56 DS: and also it's embedded in one file 22:51:06 BB: which you can already do with data uris 22:52:22 AD: there are 100s of millions of devices with Tiny fonts out there 22:52:35 ... and there's lots of content on mobile that supports it. all the ipad stuff is using Tiny fonts. 22:52:38 data uri kitchen http://software.hixie.ch/utilities/cgi/data/data 22:52:53 BB: by the time svg2 out those devices will have woff support 22:52:59 AD: it's a backward compatibility thing 22:53:25 ... you can write some script to modify the font on the fly 22:53:41 CL: another concrete benefit is that it's already widely implemented on some desktop platforms, and almost all mobile platforms 22:53:44 BB: so backwards compat 22:53:49 DS: authoring tools too 22:54:13 AD: corel draw e.g., you can click export and it will subset system fonts and turn them into svg fonts 22:54:19 CL: since corel draw 8 22:54:25 CM: inkscape can generate svg fonts too 22:54:38 DS: it's fairly lightweight, not particularly difficult to implement 22:54:48 ... there are lots of tools that already do it, it solves some use cases that woff doesn't, why not do it? 22:55:07 JF: i'd like to talk about use cases in the japanese market 22:55:16 ... in the epub wg we talked a lot about the use of svg fonts and woff fonts 22:55:22 ... we found important use cases for svg fonts 22:55:30 ... the first is to use svg fonts to support emjoy characters 22:55:36 s/emjoy/emoji/ 22:55:43 s/emojoy/emoji/ 22:55:47 ... which are part of unicdode 6.0 22:55:52 ... they can be animated 22:56:08 ... opentype cannot support emoji characters, but svg fonts can 22:56:34 ... emoji is very important for japanese, since there are many mobiles targetted towards keitai users 22:56:42 RO: but that's full fonts, not tiny fonts? 22:56:47 JF: yes 22:57:06 ... the other use case includes in japan we need to support variation characters 22:57:23 ... the current implementation of browsers and ereading systems does not support IVS yet 22:57:41 ... but that's easy with svg fonts. you can easily define variation characters using the svg font mechiansm. 22:58:00 ... you can just use the variation selector, so that text content is a proper unicode sequence 22:58:08 ... you can use svg font defined variation characters 22:58:19 BB: for emoji, is that a bounded set? 22:58:20 JF: yes 22:58:31 BB: do you ever have e.g. novels where they want to use a new character that's not in the set? 22:59:46 JF: also there can be one or two special characters in a novel that are not covered in unicode 22:59:55 BB: with the unicode variant, is this a backwards compat issue? 23:00:03 ... i believe in firefox we allow variants to be selected from fonts 23:00:11 RO: why wouldn't the variant selectors work with opentype? 23:00:35 JF: because some leading systems, their OSes don't support variation selectors 23:00:41 ... and it's sometimes difficult to implement on those systems 23:01:03 BB: so it's a compatibility issue there. it is possible to do that with css3 and opentype, but some of the devices don't support that? 23:01:05 JF: yeah 23:01:11 ... it's a kind of lightweight workaround 23:01:27 BB: with the emoji, if there are new ones publishers want to use, it sounds like we need another feature 23:01:43 JF: we think that is not that important, and it can just be a user defined feature 23:10:51 CM: (shows some examples on the board)_ 23:10:53 s/_// 23:13:14 JF: i have one suggestion for svg fonts 23:13:28 ... fonts in tiny do not support vertical alignment 23:13:48 ... we'd like to see that supported by svg fonts in svg2 23:14:06 CL: i'm hearing a proposal that it should be tiny fonts as implemented, but possible with alyGlyph and adding the vertical stuff 23:14:29 ... i think we may have removed vertical font support because vertical text wasn't supported in tiny 23:14:38 AD: the people doing the tiny font subset weren't interested in vertical text 23:14:52 ED: opera has the horiz-adv-y for svg fonts as well 23:14:55 ... it's a small addition 23:15:20 DS: the proposal is svg2 includes that starts with 1.2T SVG Fonts with a couple of additions 23:15:44 ED: and dividing it in to an optional module for svg full fonts 23:15:57 DS: pushback? 23:16:05 BB: i just want to be clear what the benefits are 23:16:20 ... we should be arguing why we need it, not why not 23:16:24 DS: there are arguments from both sides 23:16:42 RO: i have a question 23:16:54 ... one that i'd like to understand is... 23:17:02 ... let's assume there are good use cases supported by tiny fonts 23:17:14 ... we know that we basic or nonexistent shaping in tiny fonts 23:17:27