/irc-logs / w3c / #fx / 2014-10-31 / end

Options:

1. # Session Start: Fri Oct 31 00:00:00 2014
2. # Session Ident: #fx
3. # [00:00] * Tav http://tavmjong.free.fr/SVG/tpac_2014.html
4. # [00:00] * Joins: jun (~jun@public.cloak)
5. # [00:00] * smfr changes topic to 'http://tavmjong.free.fr/SVG/tpac_2014.html'
6. # [00:01] * smfr that’s how to do it
7. # [00:03] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
8. # [00:04] * Joins: bradk (~bradk@public.cloak)
9. # [00:10] <dael> Topic: Geometry Interfaces
10. # [00:10] <dael> ed: Let's start.
11. # [00:10] <dael> krit: The idea is that it defines basic geometry interfaces
12. # [00:11] <dael> krit: It uses CSS OM view, SVG DOM. They're DOMPoint, DOMRect, DOMQuad and DOMMatrix.
13. # [00:11] <dael> krit: There's one impl, which is FF..
14. # [00:11] <dael> krit: Most are in Blink, but there's a discussion about how. It's not if, though.
15. # [00:11] <dael> krit: DOMRectList is in there fore legacy.
16. # [00:12] <dael> krit: Some browsers call it ClientRecList
17. # [00:12] <dael> krit: Things that are less controversial are DOMPoint, DOMREct, and DOMQuad. So far they're agreed with.
18. # [00:12] <dael> krit: One issue on DOMMatrix interfaces. There's an issue that was submitted here.
19. # [00:13] <dael> krit: First, it's supposed to be an interface that does everything SVG Matrix and the webkit and trident impl do. This is to unit the interfaces.
20. # [00:13] <dael> krit: There's nothing specified for inverse, which algo it actually takes.
21. # [00:14] <bradk> s/unit/unite
22. # [00:14] <dael> krit: There was a discussion on the ML, but we cannot gaur the inverse givs you the mathematically correct result due tot he biany system. So should we have an algo that we try and follow?
23. # [00:15] <dael> krit: I say we don't. Most things require functions that are trignomic fuctions that aren't precisely speced. Every hardware differes on these so we can't give the same on all platforms.
24. # [00:15] <cabanier> spec: http://dev.w3.org/fxtf/geometry/
25. # [00:15] <dael> krit: Also because invers is supposed to reflect what the impl itself does because the DOMMatrix is reflecting the rendering part of the browsers. So it should be up to each browsers. I suggest not spec an algo, but they should use one part of their engine already.
26. # [00:15] <dael> dino: As long as it does inverse.
27. # [00:16] <dael> cabanier: If it cannot be inverted, we wanted it to return a matrix, not throw.
28. # [00:16] <dael> krit: We agreed on that. So should we have a spec algo.
29. # [00:16] <dael> adenilson: I say no.
30. # [00:16] * Joins: smailus (~smailus@public.cloak)
31. # [00:16] <dael> BlackCatkins: Who requested it?
32. # [00:16] <dael> krit: adenilson.
33. # [00:18] <dael> adenilson: We're on the same page with algo, my sug was in the domain of math. We have an inverse math part of the interface.
34. # [00:19] <adenilson> http://en.wikipedia.org/wiki/Moore%E2%80%93Penrose_pseudoinverse#Existence_and_uniqueness
35. # [00:19] * Joins: BogdanBrinza_ (~BogdanBrinza@public.cloak)
36. # [00:19] * Joins: smailus_ (~smailus@public.cloak)
37. # [00:19] * Joins: dael_ (~dael@public.cloak)
38. # [00:19] * Joins: Rossen__ (~Rossen@public.cloak)
39. # [00:20] <dael_> adenilson: The second property of hte matrix is such that the inverse will be the same.
40. # [00:20] <dael_> ChrisL: So to restrate. The normal inverting has correct, incorrent, or can't. For this you always have an inverse for correct, if you have something else it still gives you an inverse.
41. # [00:20] <ChrisL> so it gives the same result if it was invertible
42. # [00:20] <dael_> adenilson: This is a pseudo inverse for real or imaginare, so if you have non-square you can still calc the pseudo inverse.
43. # [00:21] <dael_> adenilson: I have two alt proposals. The first is could we add a pseudo inverice interface to the DOMMatrix? Second is since we have this mathematical property where the pseudo is the same, why don't we specify so that if there is a cononical inverse you return it and, if not, say you're wroking with non-square.
44. # [00:22] <dael_> adenilson: There's problems with both. Mathematical software has two mathods, one for cononical and one of pseudo. There's one called maple that goes with my second suggestion. If there isn't a canonical inverse you return the pseduo
45. # [00:23] <dael_> Rossen_: How do you know which you get?
46. # [00:23] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
47. # [00:23] * Quits: smailus (~smailus@public.cloak) (Ping timeout: 180 seconds)
48. # [00:23] * Quits: BogdanBrinza (~BogdanBrinza@public.cloak) (Ping timeout: 180 seconds)
49. # [00:23] <dael_> adenilson: If we always return a valid matrix, we may have an attr to let the user know what he is recieving.
50. # [00:23] <dael_> adenilson: To have a better feeling, I'm going to demonstrate the concepts.
51. # [00:24] <dael_> adenilson: I have a matrix, I can calc the pseudo inverse. Since this was well behaved I can calc the inverse.
52. # [00:25] <dael_> adenilson: If neither suggestion sounds right, I would suggest we have the single value composition matrix avail so if you have non-sq you can use SVG to calculate.
53. # [00:25] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
54. # [00:25] <dael_> adenilson: I have a 4x9 can use SVG to calc the inverse. So it would be the same. But there is other algo where you can implement it 3 to 5 times faster than SVG.
55. # [00:26] <dael_> adenilson: If we have bigger matrixes the same algo can be 5 to 7 times faster. So it may sound like this is a silver bullet, but everyone knows that's not possible.
56. # [00:27] <dael_> adenilson: There's an example where you may have numerical instability. It will be slightly different, but it is very close.
57. # [00:28] <dael_> adenilson: I think we have benefits of supporting non-square matrix. The morpin rules have some great properties. So if there is the real inverse it'st he same. If we don't have this, we should have SVG, but there are more performance tradeoffs.
58. # [00:28] <dael_> ChrisL: So you're proposing something that always gives inverse and is faster and gives you the same result or the same if rounded to a decent level of percision.
59. # [00:29] <dael_> adenilson: The morpin rule's inverse of itself will be the martrix itself as expected.
60. # [00:29] <bradk> http://cdn.meme.am/instances/500x/55804757.jpg
61. # [00:30] <ChrisL> s/percision/precision
62. # [00:30] <dael_> adenilson: I think we can have the argument that we can always have perfectly formatted matrix. I think once this is impl we will have people using all kinds of matrixes. I think addressing the non-square matrix would be nice since part of the reason for spec is for contrent authors to have power. A canonical inverse would cover some cases, but this would cover even more cases.
63. # [00:30] <dael_> adenilson: Questions?
64. # [00:30] <adenilson> https://gist.github.com/Adenilson/faddfbf29b5f9dc77d81
65. # [00:30] <adenilson> https://gist.github.com/Adenilson/96354ee274d2864cdcae
66. # [00:30] <adenilson> https://gist.github.com/Adenilson/5ad519e92edb8a5f6041
67. # [00:31] <adenilson> http://cran.r-project.org/bin/macosx/
68. # [00:31] <dael_> adenilson: There are several ways to impl this. We can suggest faster, but the browser impl would have the freedom to impl in whatever way they want.
69. # [00:31] <dael_> adenilson: The last link is the math program referenced.
70. # [00:32] <dael_> krit: I like this algo, but we're not looking for mathematical precision, we're looking for the same answer as impl. If they decide to use this to compute an inverse, that's absolutely fine.
71. # [00:32] <dael_> krit: You also showed us it could be more efficent so it might be used. We want the same result the engine gets for the rendering, not something mathematically interesting. If it's used for rendering, they should use it the same way.
72. # [00:33] <dael_> ChrisL: It's not an algo. You're saying they must calc an inverse. This prop is defining what sort of inverse you should get. They can use whatever algo they want to get the result.
73. # [00:34] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
74. # [00:34] <dael_> shans__: There's matrix we can calc, there's ones the we can't, and it's the ones at the edge that are the problem. Diff impl get different results for those IT would be a shame if the JS inverse and the browser inverse weren't the same. It's making sure of consistency. I think we should try and persuade browsers to switch to this, but it's a diff conversation.
75. # [00:35] <dael_> adenilson: If you phrase the spec that the user by calling the inverse will get a canonical inverse or a morpin rule pseudo, you free up users to work with non-square matrix. How they're impl the algo is up to them
76. # [00:35] <dael_> adenilson: If you say by calling inverse you only calc a canonical inerse, you rule out non-square.
77. # [00:35] <dael_> dino: This is always square.
78. # [00:35] <dael_> adenilson: So you should change the name.
79. # [00:35] <dael_> cabanier: It's the matrix in DOM, it's not a general class.
80. # [00:36] <dael_> dino: What would be interesting is if JS exposed a matrix class that is generic n x m
81. # [00:36] <bradk> http://cdn.meme.am/instances/500x/55804968.jpg
82. # [00:37] <dael_> dino: in this case we're really only talking about exposing the API to what we already have in the impl. It's never designed for general math use, it's really only for transforms and to match the ones don natively in SCG and CSS.
83. # [00:37] <dael_> cabanier: And the inverse is to re-calc the origin or something.
84. # [00:37] <ed> s/SCG/SVG/
85. # [00:37] * Joins: myakura (~myakura@public.cloak)
86. # [00:38] <dael_> shans__: I think this is interesting and I think we should use this internally in Chrome. Maybe as a WG we can pub a technical manual that suggests using this, but I think it's counter-productive to say this is required.
87. # [00:39] <dael_> adenilson: I'm not sure if I made it clear, I'm not recommending an algo, tere's a couple ways to calc this. I think that if we add on the desc of the method that the user agents try and calc canoloical and, if not possible, they can calc the moprin rules we can make it more powerful. It addresses all our current needs and gives room for a case that we maybe cannot image at this moment.
88. # [00:39] <dael_> adenilson: I don't see the need to have an artificial restraint on the matrix class.
89. # [00:39] <dael_> ChrisL: So the matrix in DOMMatrix are always 4x4 but not always invertable.
90. # [00:39] <dael_> shans__: And if they're not invertable the browser behavior is different.
91. # [00:40] <dael_> shans__: I think there's a benefit for browsers to get into this.
92. # [00:41] <dael_> dino: It's worth desc the most common use for the API which is if yu're wrighting script to do a transform we waste a lot of time writing a long string. The idea is you can get a transform out, make the changes, and put it back a lot more quickly. It's supposed to match what you do in CSS.
93. # [00:41] <dael_> dino: And we should discuss, it's still not clear on if we can provide this API or it'll be worse performance since it's jumping from JS to native code.
94. # [00:41] <dael_> krit: The spec describes in JS.
95. # [00:42] <dael_> dino: I mean req that it's impl in JS.
96. # [00:42] <dael_> cabanier: And that's something the spec can't do.
97. # [00:42] <dael_> dino: It does feed into what the API should look like.
98. # [00:42] <dael_> ??: Is the background infomration that it should match what's inside he browser in the spec?
99. # [00:42] <dael_> krit: No.
100. # [00:42] <dael_> dino: Many people read the spec and come to the conclusion it's designed for general things.
101. # [00:43] <dael_> ChrisL: It's not and should say so.
102. # [00:43] <dael_> ??: And maybe this inverse should indicate it doesn't give you mathematically correct because it's floating point.
103. # [00:43] <shans__> s/??/Cyril/
104. # [00:43] <astearns> s/??/Cyril/
105. # [00:43] <dael_> Cyril: The wording is too vague.
106. # [00:44] <dael_> ChrisL: Add the word transformation matrix to start.
107. # [00:44] <dael_> shans__: It says witht he purpose of desc transformation.
108. # [00:44] <dael_> ChrisL: How would yu use a 10x10 matrix?
109. # [00:44] <dael_> ed: It sounds like we're getting toward a conclusion.
110. # [00:44] <dael_> ChrisL: It sounds like the text clarifies but people aren't understanding.
111. # [00:45] <dael_> shans__: If you're looking at the spec you look at background and drop down. Maybe it should be the first sentence of the doc.
112. # [00:45] <dael_> cabanier: It's the first sentence of the section.
113. # [00:45] <dael_> krit: Even the first sentence helps.
114. # [00:45] <dael_> krit: In general this is the last issue for this spec. I think it was pub last time beginning of Oct and no issues since then.
115. # [00:46] <dael_> krit: So do we proceed witht his spec? We've fixed and resolved the mentioned issues.
116. # [00:46] <dael_> krit: I'd like to publish a CR. Do others agree?
117. # [00:46] <dael_> ChrisL: I'd ask if it's okay to close with no change.
118. # [00:46] <dael_> krit: Would you be fine closing with no changes?
119. # [00:47] <dael_> adenilson: I think this is something, the spec as a whole, now so let's go to CR.
120. # [00:47] <dael_> ed: Are we resolved?
121. # [00:47] <dael_> ChrisL: So what will the next version be?
122. # [00:47] <dael_> ChrisL: Is it WD or...?
123. # [00:47] <dael_> krit: It's a WD, I'm asking for CR.
124. # [00:47] <dael_> ChrisL: For you have a full DoC?
125. # [00:47] <dael_> krit: Yes.
126. # [00:48] <dael_> RESOLVED: CR for Geometry Interfaces
127. # [00:48] <dael_> shans__: Can we capture the information on the the computational matrix?
128. # [00:48] <dael_> ed: Should that be Geometry interfaces.
129. # [00:48] <dael_> shans__: It's tc39 that needs to look at it.
130. # [00:49] <ed> s/Geometry interfaces./Geometry interfaces or as an ecmascript type?/
131. # [00:49] <Tav> http://tavmjong.free.fr/SVG/TEXT_IN_A_BOX/index.html
132. # [00:49] <dael_> Topic: fitting text into a box
133. # [00:49] <dael_> dino: Can we do text fill first?
134. # [00:49] <dael_> Tav: decoration?
135. # [00:50] <dael_> dino: Yeah.
136. # [00:50] <dael_> Topic: Text Decoration
137. # [00:50] <Tav> http://tavmjong.free.fr/SVG/TEXT_DECORATION/index.html
138. # [00:52] <dael_> Tav: SVG 1.1 text decoration uses fill and stroke color
139. # [00:53] <dael_> Tav: If you go down a little bit, you can do things like set a section to different for text and decoration, or just part. The decoration is picked up by where you set it.
140. # [00:54] <dael_> Tav: CSS3 text decoration intro line, style, and color. SG can do line and style, but what about color? Do we use fill color, fill and stroke, how does it work?
141. # [00:54] <dael_> Tav: There's no way to do diff fill and stroke using CSS3 Text, but you'd expect that for SVG
142. # [00:54] * shepazooOOoo Tav, 3 new CSS properties? why not 6 new properties?
143. # [00:55] <dael_> [we discover fantasai isn't here and go looking.]
144. # [00:57] <nikos> http://www.w3.org/2014/05/22-svg-minutes.html
145. # [00:58] * BlackCatkins http://www.w3.org/Graphics/fx/wiki/Fill_and_stroke_on_paragraphs
146. # [00:59] <dael_> [we discover she's in HTML and carry on]
147. # [00:59] <dael_> dino: So what's the CSS proposal to do the 2nd link?
148. # [01:00] <dael_> BlackCatkins: There isn't anything written down. We're supposed to, but haven't gotten to it.
149. # [01:00] <dael_> dino: And the idea would be you use pseudos plus some ordering.
150. # [01:01] <dael_> Tav: 3 options. 1) don't allow text decoration color, but need a nested <tspan> hack.
151. # [01:01] <dael_> krit: Can you summarize again, sorry.
152. # [01:01] <dael_> Tav: SVG has the ability to put a differenet color on fill and stronke. How do we do this with CSS3 text decoration because color doesn't allow you to spec those three things.
153. # [01:02] <dael_> ChrisL: So there's not text decoration color. Is that the fill or stroke color?
154. # [01:02] <dael_> fantasai: Fill color.
155. # [01:02] <dael_> Tav: That's color, what if you ant pattern?
156. # [01:02] <dael_> fantasai: 1st option doesn't make sense, we'll have the same problem in CSS. We want to do that going forward, so HTML and SVG should have identical solutions.
157. # [01:03] <ChrisL> s/not text/now text/
158. # [01:03] <dael_> fantasai: text-decoration-color shouldn't set text fill.
159. # [01:03] <dael_> Tav: to text fill.
160. # [01:03] <dael_> fantasai: In SVG can fill be diff between text and text decoration.
161. # [01:03] <dael_> Tav: With nested <tspan>s
162. # [01:03] <dael_> fantasai: And fill can take color?
163. # [01:03] <dael_> Tav: Yes.
164. # [01:04] <dael_> fantasai: I think if we're going to add text-decoration-fill and -stroke we should remove color.
165. # [01:04] <dael_> Tav: Well lovely.
166. # [01:04] <dael_> fantasai: I'm not sure what impl is. Mozilla has a prefixed and I think some printers have things. With Mozilla they can change the name.
167. # [01:05] <dael_> fantasai: That might be one option. WE could als have text-decoration-color default to auto because then you have 3 prop when 2 is fine. We have to do something funny between color and fill for text anyway.
168. # [01:05] <dael_> Tav: If we did option 3 it won't be inconsistant with replacing color.
169. # [01:05] <dael_> fantasai: I wouldn't make it SVG only.
170. # [01:05] <dael_> ChrisL: So CSS# could change without others moving.
171. # [01:06] <dael_> fantasai: Given that it's in CR if we replace we would just do the re-name to fill and have it only take colors. I think tab and I have to define fill and stroke for CSS and so we could add it into 4.
172. # [01:06] <dael_> bradk: Can text-decoration-color be a long hand for *-fill? It won't be as intutitive.
173. # [01:07] <dael_> plinss: Should be for -stroke and -fill. I'm not saying you set it to both, You set -fill and -stroke is set to none.
174. # [01:07] <dael_> fantasai: That might be an option. We have several options.
175. # [01:07] <dael_> ChrisL: Is it in the minutes enough that you'll know what to do?
176. # [01:07] <dael_> Tav: If I impl option 3, it won't be broken in the future?
177. # [01:07] <dael_> fantasai: No.
178. # [01:08] <dbaron> plinss is proposing that we have text-decoration-fill, text-decoration-stroke, and text-decoration-color which is a shorthand that sets t-d-fill to its value and t-d-stroke to none
179. # [01:08] <ChrisL> rrsagent, here
180. # [01:08] <RRSAgent> See http://www.w3.org/2014/10/31-fx-irc#T00-08-27
181. # [01:09] <dael_> fantasai: I think the minutes are roughly alright.
182. # [01:09] <dael_> fantasai: I'll add notes if I need to.
183. # [01:10] <dael_> fantasai: 1 option is have all 3 and have one be a shorthand of the other two, one is have just fill and stroke, the third is have them relate in the same way as color fill and stroke.
184. # [01:10] <dael_> fantasai: We just need to sort through the implications and decide on one.
185. # [01:11] <Tav> http://tavmjong.free.fr/SVG/TEXT_IN_A_BOX/index.html
186. # [01:11] <dael_> Topic: Text in a box
187. # [01:11] <dael_> Tav: We've had a bunch of requests to have text inside a fixed size box so it fits. Right now they use text length in SVG.
188. # [01:12] <dael_> Tav: SVG says this isn't the intended use.
189. # [01:12] <dael_> Tav: Org in so if rnedering is a different font, things stay aligned.
190. # [01:12] <dael_> Tav: So how does on adjust text inside a box. Should this be shared between SVG and CSS?
191. # [01:12] <ChrisL> assuming text ellipsis is not an option
192. # [01:12] <dael_> BlackCatkins: This has been a forever request in CSS.
193. # [01:13] <dael_> ChrisL: This is also common for CAD stuff
194. # [01:13] <dael_> Tav: Diagrams and the like
195. # [01:13] <dael_> shepazooOOoo: There's might be more than one option for adjusting the text.
196. # [01:13] <dael_> Tav: In particular we had a request for an additional value to length adjust that would also spec that the font would be changed so you're shrinking both vertical and hor.
197. # [01:14] <shepazooOOoo> s/There's might be more than one option for adjusting the text./There might be more than one option for adjusting the text: changing the letter spacing, or changing the font-size./
198. # [01:14] <dael_> fantasai: There's more. Adjustment of spacing, changing the font size, doing graphical expansion and compression. There's also that you mgiht want to sub some and have a fallback if you can't substitute.
199. # [01:15] <dael_> Tav: In addition it was suggested to have a length adjust direction so you limit expansions or contractions.
200. # [01:15] * ChrisL don't minute the text-fitting-mode :)
201. # [01:15] <dael_> Tav: There's a limit where you want to maintian legibility.
202. # [01:15] * dael_ ChrisL I'm learning your snark
203. # [01:15] <dael_> Tav: It's not just simple examples with one line.
204. # [01:16] <dael_> BlackCatkins: So you're looking for paragraph level justificatin.
205. # [01:16] <dael_> astearns: No, it's beyond that.
206. # [01:16] <dael_> Tav: I put alternative methods to fit text into a region. You can change font size and take care of moving.
207. # [01:16] <dael_> shepazooOOoo: There should be an easy way to do that, but baseline isn't impl interop.
208. # [01:17] <dael_> Tav: All my examples rely on JS.
209. # [01:17] <fantasai> s/changing the font size/changing the font size, switching to expanded or compressed font, kashida elongation for Arabic, substitution of swash glyphs in other scripts/
210. # [01:17] <shepazooOOoo> s/easy way to do that/easy way to do vertical centering/
211. # [01:17] <dael_> astearns: So yu point out this is JS now, it may be it should continue to be in JS because each app can have different considetations. People will want to fiddle with different controls and that's easiest in script.
212. # [01:17] <dael_> Tav: It would be nice for simple cases without JS.
213. # [01:17] * fantasai notes that vertical centering is in css-align atm
214. # [01:17] <dael_> ChrisL: Ycan do an image tag or something where you don't want script.
215. # [01:18] <ChrisL> archival CAD images for example
216. # [01:18] <dael_> astearns: If you want simple, these complex considerations should maybe be thrown out the window and not change font. Sometimes you want to find a new font ecause the family has a fallback.
217. # [01:18] <dael_> Tav: That's something where they designer may have needed to find the font.
218. # [01:19] <dael_> Tav: Letter spacing has no consistancy and then there's centering horizontally.
219. # [01:19] <dael_> smailus_: Do you have an ex with both width and height?
220. # [01:19] <dael_> Tav: not here, that's what was suggested by the extra option
221. # [01:19] <dael_> smailus_: length-adjust option?
222. # [01:19] <dael_> Tav: Yes.
223. # [01:20] <dael_> ChrisL: CAD can use SVG or CGM historically that does this in a simple way. People who do this can't switch to SVG because it can't do that.
224. # [01:20] <astearns> my suggestion was to expose this as single-line fitting using a graphic transformation
225. # [01:20] <dael_> smailus_: CGM has some options as to how to stretch or desc the restricted text and how the decendors have to fit inside. It's a standardized industry accepted thing.
226. # [01:21] <dael_> smailus_: There are some knobs in CGM and if we can facilite that it would be helpful later.
227. # [01:21] <dael_> ChrisL: If you have time an analysis of what's actually used would be great.
228. # [01:21] <dael_> smailus_: I always think that's easy and find it's hard.
229. # [01:21] <dael_> fantasai: Can you give us a link to those?
230. # [01:21] <dael_> smailus_: I will in IRC.
231. # [01:21] <dael_> Tav: I'm not sure text-adjust is the correct thing to use, but a CSS solution would be good.
232. # [01:22] <dael_> fantasai: It's come up in a lot of contexts. We had text-justify with a min and max before and we have a resolution to create a way to set those in fonts.
233. # [01:22] <dael_> BlackCatkins: I think we can do a simple solution that defaults to graphical and gives a few extra options.
234. # [01:22] <dael_> ChrisL: The use cases for this and for a book are completely different.
235. # [01:23] <dael_> fantasai: I think that would go into CSS Text.
236. # [01:23] <smailus_> CGM text fitting to what is called a Restricted Text (to a rectangular region): https://www.w3.org/Graphics/SVG/WG/wiki/File:SVG_2_ProposalsTechnical_and_Engineering_Graphics.pdf on document page 8
237. # [01:23] <dael_> fantasai: Vertical alignment, I think if you have a two line label you may want to center them together.
238. # [01:23] <dael_> Tav: I agree. That was a hack.
239. # [01:23] <dael_> fantasai: You want the term central, not middle as well.
240. # [01:24] <dael_> fantasai: In CSS we have an alignment spec and it doesn't apply to SVG right now, but if you need it to you can define it to apply.
241. # [01:24] <dael_> BlackCatkins: Just align-content-center and you're done! yay!
242. # [01:24] <BlackCatkins> s/-center/:center/
243. # [01:25] <dael_> astearns: When you're fitting text in a circle, you want multi line jsut fitting in an arbitary shape. If anyone has a solution that's not make it bigger until it overflows and go back one, I'm not aware of it.
244. # [01:25] <dael_> shepazooOOoo: There's adobe.
245. # [01:25] <dael_> astearns: You just do the same thing where you make it bigger until it overflows and go back one step.
246. # [01:26] <dael_> shepazooOOoo: You could basically take the shape and make a slightly smaller shape inside and make it bigger until it intersects the smaller shape.
247. # [01:26] <dael_> astearns: There's content and container fitting and they're both be cool to have, but they're slow on the web.
248. # [01:26] <dael_> ed: So the conclusion?
249. # [01:26] <dael_> Tav: We'll get some CSS to do the simple stuff.
250. # [01:27] <dael_> BlackCatkins: We limit to transforms and letter spacing and it's easy.
251. # [01:27] <dael_> Tav: And multiline in a box, that's easy?
252. # [01:27] <fantasai> Sorry, I'm wrong, there is a middle dominant-baseline. What the difference between that and central is I can't quite figure out from the very confusing 10yr-old CSS spec
253. # [01:27] <dael_> BlackCatkins: No, multi line is harder.
254. # [01:27] <dael_> Tav: A curve might be harder because you shrink stuff.
255. # [01:27] <dael_> BlackCatkins: Line breaking means it's not only your function.
256. # [01:28] <dael_> ChrisL: When you said multi-line were you asking about text with hard line breaks?
257. # [01:28] <dael_> Tav: Ideally flowing. You can think about letter spcing for the individual line.
258. # [01:28] * ed fantasai, the c in css stands for confusing, right?
259. # [01:28] <dael_> ChrisL: We have a bunch of content breaks. You don't have to reflow, we just want to make sure the longest line fits.
260. # [01:28] <fantasai> Found the difference. And I think you do indeed want central. middle takes half the ex-height above the alphabetic
261. # [01:28] * fantasai yes, of course ;)
262. # [01:28] * astearns ed: It's California, actually: https://medium.com/cool-code-pal/a-call-for-web-developers-to-deprecate-their-css-1f6430781393
263. # [01:29] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
264. # [01:29] <dael_> BlackCatkins: Yeah. So if you have multi line with line breaks, are you okay with only one shrinking, or should they all be shrunk. YOu just adjest with letter spacing, one overflows, the others don't. Is it okay if just that one line shrinks or should they all shrink equally?
265. # [01:29] <dael_> Tav: Prob the first.
266. # [01:29] <dael_> bradk: You could do the font size.
267. # [01:29] <dael_> Tav: In the ex it was letter spacing
268. # [01:29] <dael_> fantasai: I think you want evenly
269. # [01:29] <ChrisL> s/content breaks/content with hard breaks/
270. # [01:30] <dael_> smailus_: I can think of a use case where you want to shrink them all evenly.
271. # [01:30] <dael_> BlackCatkins: We can go with if you want it per line, you just put wrappers on this line.
272. # [01:30] <dael_> fantasai: We also have a each line keyword with text indent.
273. # [01:30] <dael_> bradk: Is there a limit to the amount of negative character spacing?
274. # [01:31] <dael_> BlackCatkins: Yeah, ou want browsers to be smart on that.
275. # [01:31] <dael_> bradk: There's not much range where it looks good.
276. # [01:31] <dael_> BlackCatkins: This is why we want to keep as simple as possible so we want to let script libraries be fancy.
277. # [01:31] <dael_> fantasai: You either need a limit in the spec or have the author define the limit and have the UA define more or less infiniate.
278. # [01:32] <dael_> fantasai: Right now you can go negativein impl spec, but you don't hit it before you get ugly.
279. # [01:32] <dael_> bradk: So what about when there's a lot more overlapping text then author antic?
280. # [01:32] <dael_> Tav: How often do you find text that's changed size massively smailus_ ?
281. # [01:32] <dael_> smailus_: Not often. In the CGM world they're sed to stretching or squeezing a bit.
282. # [01:33] <dael_> Tav: So I think the real case is small adjustments.
283. # [01:33] <dael_> bradk: The user can adjust the script themselves.
284. # [01:33] <dael_> Tav: I don't think we need to take care of things like that.
285. # [01:33] <dael_> BlackCatkins: I can start a thread with this on www-style to try and come up with the small set of things we want to expose and we continue there?
286. # [01:33] <dael_> smailus_: So what'st he conclusion?
287. # [01:34] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
288. # [01:34] <dael_> BlackCatkins: I think that CSS should provide some simple knobs that can help. I've run into x problems, but not y.
289. # [01:34] <dael_> smailus_: For us if you have y you have a wiring diagram and a label. If you've shifted too close to one or the other you might assume it's not for both.
290. # [01:35] <dael_> astearns: So if both items have a label, can they have different height to fit, or should they both be the same? So to fit the label can you transform both x and y, or just one?
291. # [01:35] <dael_> smailus_: We want it to transform in both dimensions in out case. You can have 16 stacked and you associate wrong label again.
292. # [01:35] <dael_> astearns: Do two labels need to have approx same font height for consistancy?
293. # [01:36] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
294. # [01:36] <dael_> smailus_: Yes. If you're labeling a bunch of wires you'd want them to look the same.
295. # [01:36] <dael_> astearns: When you reflow the one that is numbered 400073 and you have to shrink to fit, you only want to shrink in x direction.
296. # [01:36] <dael_> smailus_: Yes.
297. # [01:37] <dael_> fantasai: So we'd just be transforming in inline direction so we don't distort relative sizes. When you spec a font size you get that one even if you get a substitute.
298. # [01:37] <dael_> smailus_: The author will pick a font and if you sub you want something close.
299. # [01:37] <dael_> ed: Next step?
300. # [01:37] <dael_> BlackCatkins: I'm writing the e-mail right now.
301. # [01:37] <dael_> ed: Anything further on this?
302. # [01:37] <dael_> smailus_: I don't think so.
303. # [01:38] <dael_> ed: We're almost out of time.
304. # [01:38] <Tav> http://tavmjong.free.fr/SVG/IMAGE_RENDERING/index.html
305. # [01:38] <dael_> Topic: Image Rendering
306. # [01:38] <dael_> Tav: There's some inconsistancy between SVG and CSS3 Images. There's a question as to what to do with SVG.
307. # [01:39] <dael_> Tav: I got some feedback about the spec and it's hard to understand exactly what you would do to impl CSS3 IMages.
308. # [01:39] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
309. # [01:40] * Joins: shans_ (~shans@public.cloak)
310. # [01:40] <dael_> Tav: I got some from JAsper and he thought the spec should focus on what the ideal image should look like. I got some other that was confusing about rotated or pixilated. There was also concern about when you're anti-aliased and when you have large pixals and they have meaning so you might end up with something else showing.
311. # [01:40] <dael_> Tav: The suggesting was going into shape rendering where you could turn off anit-aliasing.
312. # [01:41] <dael_> Tav: Some existing content explotes optimized speed to preserve pixalated. We're almost ready to release a new inkspace. Can optimized speed be aliased to anti-aliasing?
313. # [01:41] <dael_> BlackCatkins: Sounds reasonable.
314. # [01:41] <dael_> Tav: In filter effects spec we have an issue.
315. # [01:42] <dael_> dbaron: Does the spec desc the diff between crisp and pix where one does nearest neightbor for both and one doesn;t?
316. # [01:42] <dael_> BlackCatkins: Spec used to use nearest neighbor in one way, but it was changed to say pixilated needed to be nearest neighbor.
317. # [01:42] <dael_> dbaron: I think we're trying to impl the old. There were good use cases forthe old way.
318. # [01:43] <dael_> Tav: I'm not sure down should use nearest neighbor.
319. # [01:43] <dael_> BlackCatkins: Yes, but plugging it in was non-trivial. People didn't want to have to memorize direction
320. # [01:43] <dael_> dbaron: And we wanted the thing that did up and down scaling differently for our UI.
321. # [01:43] <dael_> dbaron: I'm not sure what dholbert settled on, but he might go witht e old way.
322. # [01:44] <dael_> BlackCatkins: It was argued that you can use nearest for down or a smarter way but you must use nearest neighbor for upscaling.
323. # [01:45] <dael_> BlackCatkins: I thought I edited in that you can do different for downscaling, but I didn't. I'll fix that.
324. # [01:45] <dael_> BlackCatkins: So pixalated can allow prettier.
325. # [01:45] <dael_> Tav: I thnk having some images in there would help.
326. # [01:45] <dael_> BlackCatkins: I can do that.
327. # [01:45] * Quits: kurosawa (~chatzilla@public.cloak) ("ChatZilla 0.9.91 [Firefox 36.0a1/20141029030207]")
328. # [01:45] <dael_> Tav: Giving an example for crispy edges would be good. Also maybe a suggested algo?
329. # [01:46] <dael_> BlackCatkins: I have working about that already. In the explanitory text.
330. # [01:46] <dael_> BlackCatkins: It's in there, just not close to the value name. I can move that.
331. # [01:46] <dael_> Tav: Exponding a bit would be great..
332. # [01:46] <fantasai> Did we mean s/crispy edges/crisp-edges/ ?
333. # [01:46] <dael_> BlackCatkins: I have images. I'll put them in. Something about rotation?
334. # [01:46] <dael_> Tav: What happens when you rotate pixilated art?
335. # [01:47] <dael_> BlackCatkins: It's only applied to scaling only. It doens't have word about rotation. It's not clear if rotation or scaling should go first, but I assume scaling first.
336. # [01:47] <dael_> Tav: That's what I would think.
337. # [01:47] <dael_> fantasai: You have a complication with the transform prop.
338. # [01:47] <fantasai> fantasai: which specifies an ordering of scaling vs. rotation
339. # [01:48] <dael_> dbaron: IN some cases you might do anti-aliasing as a part of the transform. Does image rendering apply to that.
340. # [01:48] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
341. # [01:48] <dael_> BlackCatkins: This is rendering a different width or heigh, I don't make that clear. Are you intending it for transforms?
342. # [01:48] <dael_> dbaron: I feel it would apply
343. # [01:48] <fantasai> s/is/is for/
344. # [01:48] <dael_> BlackCatkins: Well if you rotate and scale what does it mean? How do they apply?
345. # [01:48] <fantasai> s/a different/at a different/
346. # [01:49] <dael_> dbaron: Browsers will also do a transform with different layers and may lead to the property not always being honored. I don't know what's the right thing. It might be a pain to pass down to the level scaling to say if it'st he result of a transform or a size. You end up a request to draw and image at a size if it comes from one place or the other.
347. # [01:49] <dael_> BlackCatkins: I would have expected different code paths
348. # [01:49] <dael_> dbaron: It's one code pat. You don't want to scale twice.
349. # [01:50] <dael_> BlackCatkins: So we need to decide how the applies to a rotation. You said you can't honor in all transforms so I'd like to see examples.
350. # [01:50] <dael_> fantasai: It's scaling, rotation and skewing that we're considering. scaling and roaion should do the same thing, it's all about distortion of lines.
351. # [01:50] <dael_> krit: The worst case if translation off pixel boundries.
352. # [01:51] <dael_> fantasai: You can have an image scaling prop and an mage skewing property.
353. # [01:51] <dael_> BlackCatkins: We need to think about this on the list and I need to talk with people.
354. # [01:51] <dael_> dbaron: I talked to the person responsible for our image code a lot.
355. # [01:51] <fantasai> TabAtkins^: But image-rendering is the legacy name
356. # [01:51] <fantasai> fantasai^: If it does both, it can be a shorthand.
357. # [01:51] <dael_> BlackCatkins: I think everything else I can do myself, this should go to the ML.
358. # [01:52] <dael_> Tav: I think I'm done.
359. # [01:52] <dael_> ed: I guess we have 5 or 10 minutes.
360. # [01:52] <Tav> http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
361. # [01:52] <dael_> Topic: Connectors
362. # [01:52] <dael_> Tav: We've talked about this already today with other groups. The question I have is for syntax.
363. # [01:53] * ed scribe it as "murmurmur...mur..murmur.... up down down...."
364. # [01:53] <dael_> Tav: The way I invisioned this to work is you spec the connector and the points to connect to and you may have some intermediate points for a simple line.
365. # [01:54] <fantasai> s/invision/envision/
366. # [01:54] <dael_> Tav: For symbols you want to use a symbol. HOw can you ref the ports? I want to connec thte output of one to the output of the other. I'm not sure if this should be CSS, but I thought you might know the syntax you want to use.
367. # [01:55] <dael_> BlackCatkins: You want a selector for the ID out
368. # [01:55] <dael_> fantasai: Yeah.
369. # [01:55] <dael_> Tav: WE just added something with selectors.
370. # [01:55] <dael_> fantasai: ou use just an ID or a selector
371. # [01:55] <dael_> Tav: So you just use an ID?
372. # [01:55] <dael_> fantasai: If you do it inline you can make it a selector later. The #out has to be unique the whole time.
373. # [01:56] <dael_> BlackCatkins: The points are associated with each pair. We can make new functions to refer to.
374. # [01:56] <dael_> dbaron: to fantasai comment, that's not nec. true. There's a useID that's endGate1 so the url endGateOut...
375. # [01:57] <dael_> ChrisL: The model is using it to draw.
376. # [01:57] <dael_> BlackCatkins: What we need to do we can mint a point function that points to an element and names and element with points and the other arguement is the name of the point. Some elements have points with names.
377. # [01:57] <dael_> shepazooOOoo: This isn't styling.
378. # [01:58] <dael_> BlackCatkins: I'm using m syntax experience with CSS
379. # [01:58] <dael_> Tav: And that's fine. 'm using them as syntax exerts.
380. # [01:58] <dael_> fantasai: You may want to decide which box you care about and use background positioning syntax to say where in the box ou want and find the nearest point on the border.
381. # [01:58] <dael_> fantasai: So if it's a weird shape it jsut find something.
382. # [01:59] <dael_> shepazooOOoo: I think we should draw some more concrete use cases.
383. # [01:59] <dael_> shepazooOOoo: This is one fine use case, but it's not enough to decide on the syntax. Instead of solving just this case I'd like to see others.
384. # [01:59] <dael_> smailus_: The circles are where the connector ends?
385. # [01:59] <dael_> Tav: They're defined in the space of the symbol.
386. # [02:00] <dael_> smailus_: It's a marker of the connector, right? So gates using a circular market is bad. It's a bad example in logic gates.
387. # [02:00] <dael_> [note, we're discussing figure 5 ont he link]
388. # [02:00] <dael_> BlackCatkins: The first syntax on the connector points is just use bare ideats and then use url when pointing to another element.
389. # [02:01] <ed> s/ideats/IDENTs/
390. # [02:01] <BlackCatkins> url(#AndGate1) Out, Mid1, Mid2, url(#AndGate2) InA
391. # [02:01] <dael_> BlackCatkins: You provide a point name and optionally a url.
392. # [02:02] <dael_> shepazooOOoo: So when you connect to four different things which are the four points, te semantics make me uneasy.
393. # [02:02] <dael_> BlackCatkins: The semantics are it's the first and last point being connected.
394. # [02:02] <dael_> Tav: If you can come up with another way to do it I'd be happy.
395. # [02:03] <dael_> shepazooOOoo: Maybe we should work on this tomorrow. I prefer the syntax I had where the ports are named things that can arbitarily be connected to.
396. # [02:03] <dael_> BlackCatkins: Why are we repeating midone and midtwo?
397. # [02:03] <dael_> Tav: They don't have to.
398. # [02:03] <dael_> BlackCatkins: I don't think you want to skip there.
399. # [02:03] <dael_> dbaron: What if you were connecting 3 things with two points and needed the order.
400. # [02:04] <dael_> BlackCatkins: Do we know how it works if we're doing more than one?
401. # [02:04] <dael_> shepazooOOoo: You only do single in and out.
402. # [02:04] <dael_> BlackCatkins: So if you're connecting 2 you do it as three connectors.
403. # [02:04] <dael_> Tav: It helps. I think we need to look at other poss ways the desc relationships.
404. # [02:04] <dael_> BlackCatkins: Have we thought of ways to do smoothe curves.
405. # [02:05] <dael_> shepazooOOoo: We're avoiding for level one.
406. # [02:05] <dael_> Tav: I'v thought of an r value for a simple curve.
407. # [02:05] <dael_> shepazooOOoo: We'd like some way to easily select one or another network routing algo and apply that and as those bubble up to people using them a lot we can put them in a browser
408. # [02:05] <dael_> Tav: You could overrite a script
409. # [02:06] <dael_> fantasai: Why not bezier curves instead of archs?
410. # [02:06] <fantasai> s/archs/arcs/
411. # [02:06] <dael_> BlackCatkins: I think you can do a lot to offer a swap. You would adjust your points.
412. # [02:06] <dael_> Tav: It's hard to control the curves.
413. # [02:06] <dael_> BlackCatkins: If you're script generated it's hard. You have to have tons of points.
414. # [02:07] <dael_> Tav: The script engine can turn off the simple lines.
415. # [02:07] <dael_> BlackCatkins: So yu can overlay your own path.
416. # [02:07] <dael_> BlackCatkins: I'm fine with that.
417. # [02:07] <dael_> shepazooOOoo: If someone has abetter way of doing this, I wish they would tell us.
418. # [02:07] * Quits: shepazooOOoo (schepers@public.cloak) ("is sleepy")
419. # [02:07] <dael_> Tav: Good feedback.
420. # [02:07] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
421. # [02:07] <dael_> shans_: Thanks eveyone!
422. # [02:08] * Quits: BogdanBrinza_ (~BogdanBrinza@public.cloak) ("Page closed")
423. # [02:08] <ed> RRSAgent, make minutes
424. # [02:08] <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/31-fx-minutes.html ed
425. # [02:08] <dael_> s/shans_/shepazooOOoo
426. # [02:08] * Parts: smfr (~smfr@public.cloak) (smfr)
427. # [02:08] <dael_> [meeting ended]
428. # [02:08] * Quits: dael_ (~dael@public.cloak) ("Page closed")
429. # [02:13] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
430. # [02:14] * Quits: jun (~jun@public.cloak) (jun)
431. # [02:14] * Quits: stakagi_ (~stakagi@public.cloak) (Ping timeout: 180 seconds)
432. # [02:14] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
433. # [02:15] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
434. # [02:18] * Quits: smailus_ (~smailus@public.cloak) (Ping timeout: 180 seconds)
435. # [02:20] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
436. # [02:27] * Joins: stakagi (~stakagi@public.cloak)
437. # [02:28] * Quits: stakagi (~stakagi@public.cloak) (Client closed connection)
438. # [02:37] * Joins: jun (~jun@public.cloak)
439. # [02:54] * Quits: jun (~jun@public.cloak) (jun)
440. # [02:54] * Joins: jun (~jun@public.cloak)
441. # [02:55] * Quits: jun (~jun@public.cloak) (jun)
442. # [02:58] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
443. # [05:46] * Joins: ChrisL (clilley@public.cloak)
444. # [06:14] * Joins: shans_ (~shans@public.cloak)
445. # [06:42] * Quits: shans_ (~shans@public.cloak) (Client closed connection)
446. # [06:59] * Joins: jun (~jun@public.cloak)
447. # [07:12] * Quits: jun (~jun@public.cloak) (jun)
448. # [07:12] * Joins: jun (~jun@public.cloak)
449. # [07:12] * Quits: jun (~jun@public.cloak) (jun)
450. # [07:47] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
451. # [10:47] * Joins: jun (~jun@public.cloak)
452. # [11:24] * Quits: jun (~jun@public.cloak) (jun)
453. # [11:24] * Joins: jun (~jun@public.cloak)
454. # [11:24] * Quits: jun (~jun@public.cloak) (jun)
455. # [14:00] * RRSAgent excuses himself; his presence no longer seems to be needed
456. # [14:00] * Parts: RRSAgent (rrsagent@public.cloak) (RRSAgent)
457. # [15:19] * Joins: Tav (~tbah@public.cloak)
458. # [15:55] * Joins: jun (~jun@public.cloak)
459. # [16:06] * Quits: jun (~jun@public.cloak) (jun)
460. # [16:07] * Joins: jun (~jun@public.cloak)
461. # [16:07] * Quits: jun (~jun@public.cloak) (jun)
462. # [16:34] * Joins: bradk (~bradk@public.cloak)
463. # [16:39] * Joins: myakura (~myakura@public.cloak)
464. # [16:48] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
465. # [16:52] * Joins: kurosawa (~chatzilla@public.cloak)
466. # [16:53] * Joins: bradk_ (~bradk@public.cloak)
467. # [16:57] * Joins: stakagi (~stakagi@public.cloak)
468. # [16:58] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
469. # [17:08] * Joins: jun (~jun@public.cloak)
470. # [17:15] * Joins: shans_ (~shans@public.cloak)
471. # [17:17] * Joins: jun_ (~jun@public.cloak)
472. # [17:17] * Joins: shans__ (~shans@public.cloak)
473. # [17:22] * Quits: jun (~jun@public.cloak) (Ping timeout: 180 seconds)
474. # [17:22] * jun_ is now known as jun
475. # [17:22] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
476. # [17:24] * Joins: Tav (~tbah@public.cloak)
477. # [17:35] * Quits: jun (~jun@public.cloak) (jun)
478. # [17:40] * Quits: bradk_ (~bradk@public.cloak) ("Be back later ...")
479. # [17:47] * Joins: jun (~jun@public.cloak)
480. # [17:52] * Joins: jun_ (~jun@public.cloak)
481. # [17:58] * Quits: jun (~jun@public.cloak) (Ping timeout: 180 seconds)
482. # [17:58] * jun_ is now known as jun
483. # [17:58] * Quits: jun (~jun@public.cloak) (jun)
484. # [17:59] * Joins: jun (~jun@public.cloak)
485. # [18:08] * Joins: dbaron (~dbaron@public.cloak)
486. # [18:09] * Quits: jun (~jun@public.cloak) (jun)
487. # [18:12] * Joins: jun (~jun@public.cloak)
488. # [18:17] * Joins: jun_ (~jun@public.cloak)
489. # [18:18] * Joins: bradk_ (~bradk@public.cloak)
490. # [18:20] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
491. # [18:22] * Quits: jun (~jun@public.cloak) (Ping timeout: 180 seconds)
492. # [18:22] * jun_ is now known as jun
493. # [18:27] * Joins: adenilson (~anonymous@public.cloak)
494. # [18:29] * Joins: shepazu (schepers@public.cloak)
495. # [18:39] * Quits: bradk_ (~bradk@public.cloak) ("Be back later ...")
496. # [18:41] * Quits: jun (~jun@public.cloak) (jun)
497. # [18:48] * Joins: bradk_ (~bradk@public.cloak)
498. # [18:49] * Joins: jun (~jun@public.cloak)
499. # [19:09] * Quits: kurosawa (~chatzilla@public.cloak) (Client closed connection)
500. # [19:14] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
501. # [19:20] * Quits: bradk_ (~bradk@public.cloak) ("Be back later ...")
502. # [19:38] * Joins: bradk_ (~bradk@public.cloak)
503. # [19:44] * Joins: bradk__ (~bradk@public.cloak)
504. # [19:47] * Joins: dbaron (~dbaron@public.cloak)
505. # [19:48] * Quits: bradk_ (~bradk@public.cloak) (Ping timeout: 180 seconds)
506. # [19:51] * Joins: adenilson_ (~anonymous@public.cloak)
507. # [19:52] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
508. # [19:55] * Joins: adenilson (~anonymous@public.cloak)
509. # [19:58] * Quits: adenilson_ (~anonymous@public.cloak) (Ping timeout: 180 seconds)
510. # [19:58] * Quits: bradk__ (~bradk@public.cloak) ("Be back later ...")
511. # [20:08] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
512. # [20:16] * shepazu is now known as shepazoOoOoOo
513. # [20:31] * Joins: bradk__ (~bradk@public.cloak)
514. # [20:32] * Quits: bradk__ (~bradk@public.cloak) ("Be back later ...")
515. # [20:36] * Joins: adenilson (~anonymous@public.cloak)
516. # [20:47] * Joins: bradk__ (~bradk@public.cloak)
517. # [21:01] * Quits: shepazoOoOoOo (schepers@public.cloak) ("is sleepy")
518. # [21:01] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
519. # [21:02] * Quits: jun (~jun@public.cloak) (jun)
520. # [21:02] * Joins: jun (~jun@public.cloak)
521. # [21:04] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
522. # [21:06] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
523. # [21:07] * Quits: bradk__ (~bradk@public.cloak) ("Be back later ...")
524. # [21:08] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
525. # [21:08] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
526. # [21:09] * Quits: jun (~jun@public.cloak) (Ping timeout: 180 seconds)
527. # [21:32] * Joins: bradk__ (~bradk@public.cloak)
528. # [22:01] * Joins: jun (~jun@public.cloak)
529. # [22:07] * Joins: adenilson (~anonymous@public.cloak)
530. # [22:08] * Joins: jun_ (~jun@public.cloak)
531. # [22:09] * Quits: jun (~jun@public.cloak) (Ping timeout: 180 seconds)
532. # [22:09] * jun_ is now known as jun
533. # [22:10] * Joins: Tav (~tbah@public.cloak)
534. # [22:11] * Joins: shans_ (~shans@public.cloak)
535. # [22:11] * Joins: stakagi (~stakagi@public.cloak)
536. # [22:12] * Joins: shepazu (schepers@public.cloak)
537. # [22:12] * BlackCatkins is now known as TabAtkins
538. # [22:14] * Joins: shepazutu (schepers@public.cloak)
539. # [22:19] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
540. # [22:19] * shepazutu is now known as shepazu
541. # [22:24] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
542. # [22:26] * Quits: bradk__ (~bradk@public.cloak) ("Be back later ...")
543. # [22:27] * Joins: dbaron (~dbaron@public.cloak)
544. # [22:34] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
545. # [22:35] * Joins: shans_ (~shans@public.cloak)
546. # [23:03] * Quits: jun (~jun@public.cloak) (jun)
547. # [23:12] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
548. # [23:17] * Joins: bradk__ (~bradk@public.cloak)
549. # [23:37] * Quits: bradk__ (~bradk@public.cloak) ("Be back later ...")
550. # [23:51] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
551. # [23:57] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
552. # [23:58] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
553. # Session Close: Sat Nov 01 00:00:00 2014

The end :)