15100 2011-12-07 16:11:05 +0000 Right-aligning a numeric table column is much more work than it should be 2013-02-06 23:57:31 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor eoconnor brian davidc eoconnor ian jackalmage mike plh public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 61093 0 contributor 2011-12-07 16:11:05 +0000 Specification: http://www.w3.org/TR/html5/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: § 4.9 Today, right-aligning a numeric table column is much more work than it should be. Most browsers honor the alignment specified for the col element, but Mozilla seems to have drawn a line in the sand, claiming the HTML standard and the CSS standard conflict, leaving bug 915 unfixed for 13 years (and presumably forever). This means the best we can currently do, cross-browser, is to add a class to every numeric td element (in environments where the CSS is modifiable) or add alignment styling to each numeric td element, crazily bloating the size of large tables either way. One possible solution to the problem could just be the introduction of a tn (table numeric datum) element, with the expectation that the content be right-aligned. This makes cross-browser tables with a great deal of numeric data much smaller, and has the potential of allowing Mozilla & lightweight & mobile browsers (that have trouble rendering cells that inherit style from two parents) a simpler way to display tables using pure markup. Posted from: 216.229.170.227 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0 61094 1 brian 2011-12-07 16:15:01 +0000 (I am the original reporter.) To clarify, bug 915 in a Mozilla bug number: https://bugzilla.mozilla.org/show_bug.cgi?id=915 61148 2 ian 2011-12-07 23:02:30 +0000 Right-aligning a numeric column is easy — typically one line of CSS. Do you have a concrete example of a Web page with a numeric column so I can show that it is easy? 61157 3 brian 2011-12-07 23:07:48 +0000 OK, try this one: http://webcoder.info/test/sqldata.html Can you show me how to accomplish this in a cross-browser way? The col element won't work in Mozilla. The :nth-child pseudo-selector won't work because of the rowspans. 61221 4 jackalmage 2011-12-08 09:04:10 +0000 This behavior is a consequence of the CSS table model: http://www.w3.org/TR/CSS2/tables.html#columns I have no idea where you got your information that "most" browsers honor text-align on columns - *no* current browser does, to the best of my knowledge. I believe the last browser that did was IE6, because its table model wasn't based on CSS. The problem that you cite is being solved in Selectors 4 with the :col() and :nth-col() pseudoclasses: http://dev.w3.org/csswg/selectors4/#table-pseudos Thus, there is nothing for HTML to do. 61222 5 davidc 2011-12-08 09:14:16 +0000 without commenting on how col alignments should work, I'd note that html5 already introduces another markup suitable for highly numeric tables, namely <math><mtable>.... 61243 6 brian 2011-12-08 16:12:28 +0000 (In reply to comment #4) > I have no idea where you got your information that "most" browsers honor > text-align on columns - *no* current browser does, to the best of my knowledge. > I believe the last browser that did was IE6, because its table model wasn't > based on CSS. I stand corrected (I thought WebKit did this as well), but we're both a bit wrong on this point. Current Opera, and IE (at least through version 8) both support the align attribute on the col element (IE also honors the text-alignment of the col element for the cells in that column). > The problem that you cite is being solved in Selectors 4 with the :col() and > :nth-col() pseudoclasses: http://dev.w3.org/csswg/selectors4/#table-pseudos I hadn't seen that yet. That, if supported, should be a big help in a few years. > Thus, there is nothing for HTML to do. The CSS selector approach works well enough when new style rules can be injected into content. For bug comments or forums or other environments that may not allow new styles, a markup solution that provided a semantic clue of a column's broad data type would still be more practical. (In reply to comment #5) That seems a bit like an abuse of MathML that may not be terribly reliable, though I could be wrong. 61245 7 davidc 2011-12-08 16:20:31 +0000 > That seems a bit like an abuse of MathML Not sure why you'd consider that abuse. Putting numeric data, including numeric tables, into web pages is its main reason for existing. I edit that spec and I wouldn't feel abused if you used it that way:-) > that may not be terribly reliable If you mean that it may not be implemented everywhere, that's true but its implementation status is known/detectable and any new markup has a greater problem that it isn't implemented anywhere. 61246 8 1050 brian 2011-12-08 16:53:21 +0000 Created attachment 1050 Column alignment test/example 61248 9 brian 2011-12-08 16:54:40 +0000 (In reply to comment #7) > If you mean that it may not be implemented everywhere, that's true but its > implementation status is known/detectable and any new markup has a greater > problem that it isn't implemented anywhere. Fair point. However, if I'm going to display a list of financial transactions, it seems reasonable to provide semantic clues to the renderer that the transaction description and amount columns are of fundamentally different types, and have different rendering expectations. Does MathML provide a way to render the description column left-aligned and the amount column right-aligned? Even if it did, I've already got a pragmatic (though suboptimal) solution that has a better reach (decorating each cell). Honestly, I'd like to see a C printf-style (or .NET String.Format or XPath format picture) format specifier supported by the col element (or at the CSS level), so each table datum could be separated from the presentation entirely, and provided in a more compact/direct way, though I doubt there's much appetite for this. I'm guessing a simple semantic number cell element would have broad appeal, though. 61336 10 ian 2011-12-09 22:14:22 +0000 (In reply to comment #3) > OK, try this one: http://webcoder.info/test/sqldata.html Which cells do you want right-aligned? 61385 11 brian 2011-12-10 07:06:18 +0000 (In reply to comment #10) > Which cells do you want right-aligned? In this case, the rightmost two, but examples for each could be useful. 61515 12 ian 2011-12-14 00:29:37 +0000 Well with the way the table is done right now, the following rule would do what you want: td + td + td + td { text-align: right; } That doesn't seem like "much more work than it should be". And it'll be even easier once CSS selectors for tables are implemented. The reason I asked is that honestly, I wouldn't have thought you'd want the dates right-aligned, and I would have thought you'd want the numbers in the fourth column right-aligned but no the text. To get that effect would need classes on each cell; a <col> attribute wouldn't work. 61522 13 1051 brian 2011-12-14 00:51:12 +0000 Created attachment 1051 A more complex alignment challenge Try and align the the last two columns in all current browsers without decorating each cell. 61524 14 brian 2011-12-14 01:06:43 +0000 The columns I was talking about were for the URL I gave, not the simplified test file I attached later. I've attached the original (more complex) alignment challenge. As you can see, the rowspans make selecting by sibling position (td + ... + td or td:nth-child(n)) impossible. The proposed future CSS selector :nth-col() could simplify this for situations where CSS selectors may be applied, but there isn't really a way to add that to a forum post or a wiki or other user-contibuted content (or CMS body content) that only allows markup, so that reduces it's viability. > To get that effect would need classes on each cell; a <col> attribute wouldn't work. That depends on the browser (Opera and IE do align by column), but you are correct, as a cross-browser solution, it fails. Which is my point. Decorating each cell is a pretty suboptimal solution. Since we are already decorating each cell, why not provide a semantic element that at least provides a hint to the renderer as to the fundamental type of the data. A semantic element would be far more concise (<tn> rather than <td class=n>), and wouldn't require an external style rule to work. Not only would this achieve the practical goals of reducing the size and allowing the browser to align the column correctly, it might also allow for more appropriate sorting of that column or other operations that require better type awareness. 63226 15 ian 2012-01-28 18:07:00 +0000 (In reply to comment #14) > > I've attached the original (more complex) alignment challenge. If you just want the last two columns right-aligned, the CSS I gave above would still work, even with the rowspans in that example. I agree that it's theoretically possible that there be tables where you'd need something more complicated where if you could just style columns directly it would be more convenient, but my overall point is that the cases where simple CSS can't handle it are far and few between, rare enough that it doesn't make sense to optimise the language for those cases. > The proposed future CSS selector :nth-col() could simplify this for situations > where CSS selectors may be applied Indeed. It could also be extended to support classes or other selectors, as in: col.numeric // td { text-align: right } I recommend contacting the CSS WG if that's something that is of interest. (The '//' combinator has in the past been proposed for "has a semantic relationship to".) > but there isn't really a way to add that to > a forum post or a wiki or other user-contibuted content (or CMS body content) > that only allows markup, so that reduces it's viability. In such a context you can just define a class value for the styles you want and let users use that. This is the same as how HTML doesn't offer a way to change the colour of text, even though sometimes the preferred way to indicate a particular semantic is colour. > > To get that effect would need classes on each cell; a <col> attribute wouldn't work. > > That depends on the browser I was specifically talking about the case where you wanted the numbers right-aligned but not the dates. <col> can't even do that theoretically. > Since we are already decorating each cell, why not provide a semantic element > that at least provides a hint to the renderer as to the fundamental type of the > data. A semantic element would be far more concise (<tn> rather than <td > class=n>), and wouldn't require an external style rule to work. There's a number of ways of doing this within a site (e.g. class values, data-* attributes, the <data> and <time> elements); if this is something that gets a lot of adoption, it would make sense to provide a more formal solution. But in practice I haven't seen this kind of thing much. More objective research would be useful. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The provided examples can be handled easily with CSS. Adding a feature to HTML to do this would be non-trivial and isn't justified by its cost-benefit ratio. 63267 16 brian 2012-01-28 23:28:48 +0000 (In reply to comment #15) Reopening because I believe there was some misunderstanding. I'll try to clarify. I see that your CSS does work for the example, but it would be particularly fragile. Adding a column between or after those two, with any differing alignment needs, would break it. :nth-col() would be more durable in the face of rowspans, but still requires keeping the CSS in perfect sync with the markup. The '//' combinator allows some decoupling of presentation from position, but requires CSS support, and provides no numeric semantics, by which I mean potential support for localized presentation (commas & decimals), numeric sorting, database import, advanced indexing & querying, &c. > In such a context [user-generated content] > you can just define a class value for the styles you want and > let users use that. This is the same as how HTML doesn't offer a way to change > the colour of text, even though sometimes the preferred way to indicate a > particular semantic is colour. I was speaking as a user, not as the sysadmin. All of these solutions require nontrivial CSS control. User-authors of forum posts, wikis, other user-contributed content, and even emails, rarely have access to directly manage the CSS. > > Since we are already decorating each cell, why not provide a semantic element > > that at least provides a hint to the renderer as to the fundamental type of the > > data. A semantic element would be far more concise (<tn> rather than <td > > class=n>), and wouldn't require an external style rule to work. > > There's a number of ways of doing this within a site (e.g. class values, data-* > attributes, the <data> and <time> elements); if this is something that gets a > lot of adoption, it would make sense to provide a more formal solution. Decorating each cell is exactly the "work" I'm referring to: <td align=right> - The only one that works in user-contrib contexts, WYSIWYG editors, and most emails. Presentational markup. No built-in numeric semantics. <td class=n> - The current solution for site admin contexts. Verbose, and no built-in semantics. Requires add'l CSS support. <td data-type=n> - No built-in semantics. Requires add'l CSS support. <td><data value=999.99>999.99 - Still no semantics, and redundant. vs. <tn> - Built-in numeric semantics AND formatting. Efficiently terse. Would the benefits of a more formal solution (supporting highly granular datatypes such as various date and time levels, booleans, durations, &c.) to support localized presentation and sorting be worthwhile? I'm not sure the expectations for those types are as consistent. > But in practice I haven't seen this kind of thing much. More objective research would > be useful. I'm a bit incredulous that you haven't seen much use of numeric data in tables that the author (who may not control the CSS for the site) wishes to be right-aligned (is this culture-dependant?), with the hope that the browser will be just aware enough of the broad datatype to better display it (and maybe more). It's possible I've misunderstood your statement. More objective research would certainly be useful, especially if it presents any statistical findings as tabular data with numeric columns! ;) As always, thanks for your time! 63350 17 ian 2012-01-30 20:07:00 +0000 > I see that your CSS does work for the example, but it would be particularly > fragile. Adding a column between or after those two, with any differing > alignment needs, would break it. Show me a site where this is a real problem. Unless there's a compelling case to be made that this problem exists a lot, we shouldn't address it. > :nth-col() would be more durable in the face of rowspans, but still requires > keeping the CSS in perfect sync with the markup. The '//' combinator allows > some decoupling of presentation from position, but requires CSS support, and > provides no numeric semantics, by which I mean potential support for localized > presentation (commas & decimals), numeric sorting, database import, advanced > indexing & querying, &c. The "numeric semantics" are already present in the page, by virtue of the data being numeric. That's machine-detectable. I don't see "keeping the CSS in perfect sync with the markup" as being a problem. If you really find this difficult you can just put the CSS in a scoped <style> block before the table. > All of these solutions require nontrivial CSS control. We're talking here about a few lines of CSS to set classes on TD elements. That _is_ trivial. > User-authors of forum posts, wikis, other user-contributed content, and even > emails, rarely have access to directly manage the CSS. They don't need to manage it, they just need to know the classes that site has available. > Decorating each cell is exactly the "work" I'm referring to: > > <td align=right> - The only one that works in user-contrib contexts, > WYSIWYG editors, and most emails. Presentational markup. No built-in numeric > semantics. Only "works" as far as you can style the alignment. In practice, what you really want is decimal alignment, precise control over padding, etc. In non-CSS environments, UAs can already automatically style numeric cells, so it doesn't help them. In CSS environments, CSS gives you more control for less work. > <td class=n> - The current solution for site admin contexts. Verbose, and > no built-in semantics. Requires add'l CSS support. No more or less verbose than align="", and yet gives more power in CSS environments, without taking anything away from non-CSS environments. > <td data-type=n> - No built-in semantics. Requires add'l CSS support. Same as class="". > <tn> - Built-in numeric semantics AND formatting. Efficiently terse. The backwards-compatibility story here is terrible (it wouldn't work in any existing browser, and would cause serious difficulties due to the changes it requires in the parser). Plus, it would be insufficient. What if the content isn't numeric but is of the form "foo - bar" and you want to align on the hyphen, say? > Would the benefits of a more formal solution (supporting highly granular > datatypes such as various date and time levels, booleans, durations, &c.) to > support localized presentation and sorting be worthwhile? I'm not even convinced there's a real problem here, so it's unclear that any solution is worthwhile. :-) > > But in practice I haven't seen this kind of thing much. More objective research would > > be useful. > > I'm a bit incredulous that you haven't seen much use of numeric data in tables > that the author (who may not control the CSS for the site) wishes to be > right-aligned (is this culture-dependant?), with the hope that the browser will > be just aware enough of the broad datatype to better display it (and maybe > more). It's possible I've misunderstood your statement. I meant that I haven't seen people marking up their tables to indicate which bits are numeric, which bits are dates, etc. Sure, people use align="", but they can use CSS just as easily in the vast majority of cases (more easily, even). 63388 18 brian 2012-01-31 05:48:21 +0000 (In reply to comment #17) > Show me a site where this is a real problem. Unless there's a compelling case > to be made that this problem exists a lot, we shouldn't address it. I couldn't find a single production site using the td + td + ... approach! Everyone is decorating each cell. There must be a reason for this. Here's a few I found quickly: Wikipedia suggests align="right" or embedding a two-cell table in each numeric cell for the integer part and the fractional part of the number! http://en.wikipedia.org/wiki/Help:Table#Decimal_point_alignment http://en.wikipedia.org/wiki/Usage_share_of_web_browsers (align="right") Compass: "Experience cleaner markup without presentational classes." http://compass-style.org/examples/compass/tables/all/ td class='numeric' Google Analytics is right-aligning the entire table, then left-aligning text columns http://www.google.com/analytics/ table class="Yb" (.Yb td aligned right, td.so aligned left) Yahoo! Finance http://finance.yahoo.com/ td id="yui_3_3_0_2_1327965860085641" (styling individual IDs!) CNN Money http://money.cnn.com/data/markets/ td class="wsod_aRight" Amazon.com Order history td align="right" BankOfAmerica.com transactions td class="trans-balance-cell TL_NPI_Amt" Woot! account history qty td align="right" NumericaCU.org transactions td align="RIGHT" StackOverflow.com reputation page (leftmost column) td class="rep-cell" What does your bank use? > The "numeric semantics" are already present in the page, by virtue of the data > being numeric. That's machine-detectable. Loop through each cell in the table to determine which columns are numeric? That seems a pretty inefficient methodology! > I don't see "keeping the CSS in perfect sync with the markup" as being a > problem. If you really find this difficult you can just put the CSS in a scoped > <style> block before the table. This was discussed some time ago in StackOverflow, where the td + td + ... approach didn't gain much traction: http://stackoverflow.com/questions/1332406/better-way-to-right-align-text-in-html-table IE6 was at least part of the reason then, I think. But it was described as hackish. Even if you nail down the first td with :first-child so the selector doesn't "slide", the moment you change a column of td into th, or reposition the columns, you (your toolset) must remember to update the CSS, where possible. Even when scoped CSS is supported by browsers, I suspect it'll be disallowed to users on most sites out of security or branding concerns. Positional CSS selectors seem to violate the DRY principal. What happens when you've defined this behavior in a single CSS file across multiple tables and pages, then want to change one or more tables? > They don't need to manage it, they just need to know the classes that site has > available. That's assuming the site has created such a class, and wants to support it. > In practice, what you > really want is decimal alignment, precise control over padding, etc. No, I think just decimal alignment. Something like <col align=char>, but functional, and semantically attached to the data rather than maintained elsewhere. > In non-CSS environments, UAs can already automatically style numeric cells, so > it doesn't help them. I'm not familiar with this. Examples? > The backwards-compatibility story here is terrible (it wouldn't work in any > existing browser, and would cause serious difficulties due to the changes it > requires in the parser). Agreed. Adding an element, especially one that ruins backward compatibility should be avoided. However, there seems to be a widespread need for this functionality. > Plus, it would be insufficient. What if the content isn't numeric but is of the > form "foo - bar" and you want to align on the hyphen, say? That seems to be a strawman. How often does this come up, compared to numeric data? Examples? > I meant that I haven't seen people marking up their tables to indicate which > bits are numeric, which bits are dates, etc. Sure, people use align="", but > they can use CSS just as easily in the vast majority of cases (more easily, > even). Numbers have very specific expectations, dates and other types don't. If you have widespread examples of numeric data tables that don't decorate each cell, then I'm likely in error. Otherwise, the evidence I've provided would seem to suggest that there's an itch out there. 70521 19 contributor 2012-07-18 15:55:31 +0000 This bug was cloned to create bug 18026 as part of operation convergence. 81675 20 robin 2013-01-21 15:58:20 +0000 Mass move to "HTML WG" 81793 21 robin 2013-01-21 16:01:06 +0000 Mass move to "HTML WG" 82670 22 eoconnor 2013-02-06 23:57:31 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: No spec change. Rationale: This is already possible in CSS, as has been previously described on this bug. 1050 2011-12-08 16:53:21 +0000 2011-12-08 16:53:21 +0000 Column alignment test/example colalign.html text/html 844 brian PCFkb2N0eXBlIGh0bWw+DQo8c3R5bGUgdHlwZT10ZXh0L2Nzcz46bnRoLWNvbCgzKSB7dGV4dC1h bGlnbjpyaWdodH08L3N0eWxlPg0KPHRhYmxlIGJvcmRlcj0xPjxjYXB0aW9uPmFsaWdubWVudCB0 ZXN0PC9jYXB0aW9uPg0KPGNvbCBhbGlnbj1yaWdodD48Y29sIHN0eWxlPSd0ZXh0LWFsaWduOnJp Z2h0Jz4NCjx0aGVhZD48dHI+PHRoPjxjb2RlPiZsdDtjb2wgYWxpZ249cmlnaHQvJmd0OzwvY29k ZT48dGg+PGNvZGU+Jmx0O2NvbCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCcvJmd0OzwvY29kZT48 dGg+PGNvZGU+Om50aC1jb2woMyk8L2NvZGU+DQo8dGJvZHk+DQo8dHI+PHRkIHJvd3NwYW49Mj5B MTx0ZD5CMTx0ZD5DMQ0KPHRyPjx0ZD5CMjx0ZD5DMg0KPHRyPjx0ZD5BMzx0ZD5CMzx0ZD5DMw0K PHRyPjx0ZD5BNDx0ZD5CNDx0ZD5DNA0KPHRyPjx0ZD5BNTx0ZD5CNTx0ZD5DNQ0KPC90YWJsZT4N Cjx0YWJsZSBib3JkZXI9MT48Y2FwdGlvbj5UcmFuc2FjdGlvbiBTYW1wbGU8L2NhcHRpb24+DQo8 Y29sPjxjb2w+PGNvbCBhbGlnbj1yaWdodD4NCjx0aGVhZD48dHI+PHRoPkRhdGU8dGg+RGVzY3Jp cHRpb248dGg+QW1vdW50DQo8dGJvZHk+DQo8dHI+PHRkPjEyLzEvMjAxMTx0ZD5QZXJpbC1TZW5z aXRpdmUgU3VuZ2xhc3Nlczx0ZD4xLDIzOC4xMA0KPHRyPjx0ZD4xMi8xLzIwMTE8dGQ+U2F0Y2hl bDx0ZD43Mi4yMg0KPHRyPjx0ZD4xMi8yLzIwMTE8dGQ+U3ViLWV0aGEgc2VydmljZSAmYW1wOyBy b2FtaW5nIGZlZTx0ZD4yMywyNDEuODkNCjx0cj48dGQ+MTIvNC8yMDExPHRkPk9sJyBKYW54IFNw aXJpdCBCb3R0bGluZyBDbyBnaWZ0IHNob3A8dGQ+MTEyLjQyDQo8L3RhYmxlPg== 1051 2011-12-14 00:51:12 +0000 2011-12-14 00:51:12 +0000 A more complex alignment challenge sqldata.html text/html 4257 brian PCFkb2N0eXBlIGh0bWw+DQo8aHRtbD48aGVhZD48dGl0bGU+U1FMIFNlcnZlciBEYXRhdHlwZXMg UXVpY2tSZWY8L3RpdGxlPjwvaGVhZD4NCjxib2R5PjxoMT5TUUwgU2VydmVyIERhdGF0eXBlcyBR dWlja1JlZjwvaDE+DQo8aDI+RGF0YXR5cGVzPC9oMj4NCjx0YWJsZSBib3JkZXI9MT48Y2FwdGlv bj5EYXRhdHlwZXM8L2NhcHRpb24+PGNvbCBzcGFuPTIvPjxjb2wgc3Bhbj0yIGNsYXNzPW1pZC8+ PGNvbCBzcGFuPTIgY2xhc3M9bnVtZXJpYy8+DQo8dHI+PHRoPkZhbWlseTwvdGg+PHRoPm5hbWU8 L3RoPjx0aD5zaW5jZSBTUUwjPC90aD48dGg+Ynl0ZXM8L3RoPjx0aD5sb3dlciBib3VuZDwvdGg+ PHRoPnVwcGVyIGJvdW5kPC90aD48L3RyPg0KPHRyPjx0aCByb3dzcGFuPTYgdmFsaWduPW1pZGRs ZT5EYXRlL1RpbWU8L3RoPjx0ZD5kYXRlPC90ZD48dGQ+MjAwODwvdGQ+PHRkPjM8L3RkPjx0ZD4w MDAxLTAxLTAxPC90ZD48dGQ+OTk5OS0xMi0zMTwvdGQ+PC90cj4NCjx0cj48dGQ+ZGF0ZXRpbWU8 L3RkPjx0ZD48L3RkPjx0ZD44PC90ZD48dGQ+MTc1My0wMS0wMSAwMDowMDowMC4wMDA8L3RkPjx0 ZD45OTk5LTEyLTMxIDIzOjU5OjU5Ljk5NzwvdGQ+PC90cj4NCjx0cj48dGQ+ZGF0ZXRpbWUyWyg8 dmFyPnA8L3Zhcj4pXTwvdGQ+PHRkPjIwMDg8L3RkPjx0ZD48dmFyPnA8L3Zhcj4gJmx0OyAzLzUv OCA9IDYvNy84PC90ZD48dGQ+MDAwMS0wMS0wMSAwMDowMDowMC4wJmhlbGxpcDs8L3RkPjx0ZD45 OTk5LTEyLTMxIDIzOjU5OjU5LjkmaGVsbGlwOzwvdGQ+PC90cj4NCjx0cj48dGQ+ZGF0ZXRpbWVv ZmZzZXQ8L3RkPjx0ZD4yMDA4PC90ZD48dGQ+MTA8L3RkPjx0ZD4wMDAxLTAxLTAxIDAwOjAwOjAw LjAwMDAwMDAgLTE0OjAwPC90ZD48dGQ+OTk5OS0xMi0zMSAyMzo1OTo1OS45OTk5OTk5ICsxNDow MDwvdGQ+PC90cj4NCjx0cj48dGQ+c21hbGxkYXRldGltZTwvdGQ+PHRkPjwvdGQ+PHRkPjQ8L3Rk Pjx0ZD4xOTAwLTEyLTMxIDAwOjAwPC90ZD48dGQ+MjA3OS0xMi0zMSAyMzo1OTwvdGQ+PC90cj4N Cjx0cj48dGQ+dGltZTwvdGQ+PHRkPjIwMDg8L3RkPjx0ZD41PC90ZD48dGQ+MDA6MDA6MDAuMDAw MDAwMDwvdGQ+PHRkPjIzOjU5OjU5Ljk5OTk5OTk8L3RkPjwvdHI+DQo8dHI+PHRoIHJvd3NwYW49 NSB2YWxpZ249bWlkZGxlPkludGVnZXI8L3RoPjx0ZD5iaWdpbnQ8L3RkPjx0ZD4yMDAwPC90ZD48 dGQ+ODwvdGQ+PHRkPi05LDIyMywzNzIsMDM2LDg1NCw3NzUsODA4PC90ZD48dGQ+OSwyMjMsMzcy LDAzNiw4NTQsNzc1LDgwNzwvdGQ+PC90cj4NCjx0cj48dGQ+Yml0PC90ZD48dGQ+PC90ZD48dGQ+ MTwvdGQ+PHRkPjA8L3RkPjx0ZD4xPC90ZD48L3RyPg0KPHRyPjx0ZD5pbnQ8L3RkPjx0ZD48L3Rk Pjx0ZD40PC90ZD48dGQ+LTIsMTQ3LDQ4Myw2NDg8L3RkPjx0ZD4yLDE0Nyw0ODMsNjQ3PC90ZD48 L3RyPg0KPHRyPjx0ZD5zbWFsbGludDwvdGQ+PHRkPjwvdGQ+PHRkPjI8L3RkPjx0ZD4tMzIsNzY4 PC90ZD48dGQ+MzIsNzY3PC90ZD48L3RyPg0KPHRyPjx0ZD50aW55aW50PC90ZD48dGQ+PC90ZD48 dGQ+MTwvdGQ+PHRkPjA8L3RkPjx0ZD4yNTU8L3RkPjwvdHI+DQo8dHI+PHRoIHJvd3NwYW49MiB2 YWxpZ249bWlkZGxlPk1vbmV0YXJ5PC90aD48dGQ+bW9uZXk8L3RkPjx0ZD48L3RkPjx0ZD44PC90 ZD48dGQ+LTkyMiwzMzcsMjAzLDY4NSw0NzcuNTgwODwvdGQ+PHRkPjkyMiwzMzcsMjAzLDY4NSw0 NzcuNTgwNzwvdGQ+PC90cj4NCjx0cj48dGQ+c21hbGxtb25leTwvdGQ+PHRkPjwvdGQ+PHRkPjQ8 L3RkPjx0ZD4tMjE0LDc0OC4zNjQ4PC90ZD48dGQ+MjE0LDc0OC4zNjQ3PC90ZD48L3RyPg0KPHRy Pjx0aCByb3dzcGFuPTIgdmFsaWduPW1pZGRsZT5BcHByb3hpbWF0ZSBOdW1lcmljPC90aD48dGQ+ ZmxvYXRbKDx2YXI+bjwvdmFyPildPC90ZD48dGQ+PC90ZD48dGQ+ODwvdGQ+PC90cj4NCjx0cj48 dGQ+cmVhbDwvdGQ+PHRkPjwvdGQ+PHRkPjQ8L3RkPjwvdHI+DQo8dHI+PHRoIHJvd3NwYW49MiB2 YWxpZ249bWlkZGxlPkV4YWN0IE51bWVyaWM8L3RoPjx0ZD5kZWNpbWFsWyg8dmFyPnA8L3Zhcj5b LDx2YXI+czwvdmFyPl0pXTwvdGQ+PHRkPjwvdGQ+PHRkIHJvd3NwYW49Mj48dmFyPnA8L3Zhcj4g Jmx0OyA5LzE5LzI4LzM4ID0gNS85LzEzLzE3PC90ZD48L3RyPg0KPHRyPjx0ZD5udW1lcmljWyg8 dmFyPnA8L3Zhcj5bLDx2YXI+czwvdmFyPl0pXTwvdGQ+PHRkPjwvdGQ+PC90cj4NCjx0cj48dGgg cm93c3Bhbj0yIHZhbGlnbj1taWRkbGU+QmluYXJ5PC90aD48dGQ+YmluYXJ5Wyg8dmFyPm48L3Zh cj4pXTwvdGQ+PHRkPjwvdGQ+PHRkPjx2YXI+bjwvdmFyPiAmbGU7IDgsMDAwPC90ZD48L3RyPg0K PHRyPjx0ZD52YXJiaW5hcnlbKDx2YXI+bjwvdmFyPildPC90ZD48dGQ+PC90ZD48dGQ+JmxlOyA8 dmFyPm48L3Zhcj4gJmxlOyA4LDAwMDwvdGQ+PC90cj4NCjx0cj48dGggcm93c3Bhbj00IHZhbGln bj1taWRkbGU+Q2hhcmFjdGVyPC90aD48dGQ+Y2hhclsoPHZhcj5uPC92YXI+KV08L3RkPjx0ZD48 L3RkPjx0ZD48dmFyPm48L3Zhcj4gJmxlOyA4LDAwMDwvdGQ+PC90cj4NCjx0cj48dGQ+bmNoYXJb KDx2YXI+bjwvdmFyPildPC90ZD48dGQ+NzwvdGQ+PHRkPjx2YXI+bjwvdmFyPiAmdGltZXM7IDIg JmxlOyA4LDAwMDwvdGQ+PC90cj4NCjx0cj48dGQ+bnZhcmNoYXJbKDx2YXI+bjwvdmFyPildPC90 ZD48dGQ+NzwvdGQ+PHRkPiZsZTsgPHZhcj5uPC92YXI+ICZ0aW1lczsgMiAmbGU7IDIsMTQ3LDQ4 Myw2NDc8L3RkPjwvdHI+DQo8dHI+PHRkPnZhcmNoYXJbKDx2YXI+bjwvdmFyPildPC90ZD48dGQ+ PC90ZD48dGQ+JmxlOyA8dmFyPm48L3Zhcj4gJmxlOyA4LDAwMDwvdGQ+PC90cj4NCjx0cj48dGgg cm93c3Bhbj02IHZhbGlnbj1taWRkbGU+TG9uZyBUZXh0IGFuZCBCaW5hcnk8L3RoPjx0ZD5pbWFn ZTwvdGQ+PHRkPjxhYmJyIHRpdGxlPWRlcHJlY2F0ZWQ+ZGVwLjwvYWJicj4gMjAwNTwvdGQ+DQoJ PHRkIHJvd3NwYW49NiBjb2xzcGFuPTM+PHVsPg0KCQk8bGk+MTYgYnl0ZSBpbi1yb3cgcG9pbnRl ciB0byAmbGU7IDIsMTQ3LDQ4Myw2NDcgYnl0ZXMgZGF0YS48L2xpPg0KCQk8bGk+TWF4IHR5cGVz IGFyZSBzdG9yZWQgaW4tcm93IHVwIHRvIDgsMDAwIGJ5dGVzLjwvbGk+DQoJCTxsaT5uKHZhcilj aGFyL250ZXh0IGFyZSBzdG9yZWQgYXMgVVRGLTE2L0RCQ1MsIHR3byBieXRlcyBwZXIgY2hhcmFj dGVyLjwvbGk+PC91bD48L3RkPjwvdHI+DQo8dHI+PHRkPm50ZXh0PC90ZD48dGQ+NywgPGFiYnIg dGl0bGU9ZGVwcmVjYXRlZD5kZXAuPC9hYmJyPiAyMDA1PC90ZD48L3RyPg0KPHRyPjx0ZD5udmFy Y2hhcihtYXgpPC90ZD48dGQ+MjAwNTwvdGQ+PC90cj4NCjx0cj48dGQ+dGV4dDwvdGQ+PHRkPjxh YmJyIHRpdGxlPWRlcHJlY2F0ZWQ+ZGVwLjwvYWJicj4gMjAwNTwvdGQ+PC90cj4NCjx0cj48dGQ+ dmFyYmluYXJ5KG1heCk8L3RkPjx0ZD4yMDA1PC90ZD48L3RyPg0KPHRyPjx0ZD52YXJjaGFyKG1h eCk8L3RkPjx0ZD4yMDA1PC90ZD48L3RyPg0KPHRyPjx0aCByb3dzcGFuPTYgdmFsaWduPW1pZGRs ZT5TcGVjaWFsPC90aD48dGQ+aGllcmFyY2h5aWQ8L3RkPjx0ZD4yMDA4PC90ZD48dGQgY29sc3Bh bj0zPkEgc2xhc2gtc2VwYXJhdGVkIHBhdGg6IDxjb2RlPi8xLzMvPC9jb2RlPjwvdGQ+PC90cj4N Cjx0cj48dGQ+cm93dmVyc2lvbjwvdGQ+PHRkPjwvdGQ+PHRkPjg8L3RkPjx0ZD48L3RkPjwvdHI+ DQo8dHI+PHRkPnNxbF92YXJpYW50PC90ZD48dGQ+MjAwMDwvdGQ+PHRkIGNvbHNwYW49Mz5TdG9y ZXMgYW55IGRhdGF0eXBlIGV4Y2VwdCB0ZXh0LCBudGV4dCwgaW1hZ2UsIHRpbWVzdGFtcCwgYW5k IHNxbF92YXJpYW50IChtYXggODAxNiBieXRlcykuPC90ZD48L3RyPg0KPHRyPjx0ZD50YWJsZTwv dGQ+PHRkPjIwMDA8L3RkPjx0ZCBjb2xzcGFuPTM+RmFzdGVyIHRoYW4gdGVtcG9yYXJ5IHRhYmxl cy4gPGNvZGU+ZGVjbGFyZSBAPHZhcj5uYW1lPC92YXI+IHRhYmxlICggJmhlbGxpcDsgPHZhcj50 YWJsZSBkZWZpbml0aW9uPC92YXI+ICZoZWxsaXA7ICk8L2NvZGU+PC90ZD48L3RyPg0KPHRyPjx0 ZD51bmlxdWVpZGVudGlmaWVyPC90ZD48dGQ+NzwvdGQ+PHRkPjE2PC90ZD48L3RyPg0KPHRyPjx0 ZD54bWw8L3RkPjx0ZD4yMDA1PC90ZD48dGQ+MTYgKGluLXJvdyBwb2ludGVyKTwvdGQ+PHRkIGNv bHNwYW49Mz5YTUwgZGF0YSB3aXRoIGEgc2NoZW1hIGlzIHN0b3JlZCBhcyBhIHBhcnNlZCB0cmVl LjwvdGQ+PC90cj4NCjwvdGFibGU+DQo8L2JvZHk+PC9odG1sPg0K