102374 2012-11-15 05:53:42 -0800 [Cairo, FreeType] Incorrect baseline positioning & line spacing due to rounding 2017-09-05 11:19:53 -0700 1 1 1 Unclassified WebKit WebKit EFL 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID https://bugs.webkit.org/show_bug.cgi?id=176351 P2 Normal --- 103740 89458 1 d-r d-r alex behdad eae gustavo gyuyoung.kim leviw lucas.de.marchi mrobinson ostap73 rakuco sw0524.lee wl zan zimmermann oldest_to_newest 767994 0 d-r 2012-11-15 05:53:42 -0800 When enabling subpixel layout on EFL, many fast/css/* tests have enclosed elements positioned 1 pixel too high. Example: --- /fast/dominik/dev/WebKitGit_EFL/lt_sub/fast/css/background-image-with-baseurl-expected.txt +++ /fast/dominik/dev/WebKitGit_EFL/lt_sub/fast/css/background-image-with-baseurl-actual.txt @@ -3,5 +3,5 @@ layer at (0,0) size 800x600 RenderBlock {HTML} at (0,0) size 800x600 RenderBody {BODY} at (8,8) size 784x584 - RenderText {#text} at (0,0) size 196x19 - text run at (0,0) width 196: "red squares background image." + RenderText {#text} at (0,-1) size 196x19 + text run at (0,-1) width 196: "red squares background image." Mac & Chromium subpixel-enabled expectations have: layer at (0,0) size 800x600 RenderView at (0,0) size 800x600 layer at (0,0) size 800x600 RenderBlock {HTML} at (0,0) size 800x600 RenderBody {BODY} at (8,8) size 784x584 RenderText {#text} at (0,0) size 196x18 text run at (0,0) width 196: "red squares background image." Levi, Emil, any suggestions what kind of platform-specific metrics input to the line layout calculations could lead to such an offset? 770509 1 d-r 2012-11-19 02:22:30 -0800 In void SimpleFontData::platformInit() float ascent = narrowPrecisionToFloat(font_extents.ascent); float descent = narrowPrecisionToFloat(font_extents.descent); float lineGap = narrowPrecisionToFloat(font_extents.height - font_extents.ascent - font_extents.descent); lineGap results in -1. That seems wrong, since the cairo documentation days: "double height; the recommended vertical distance between baselines when setting consecutive lines of text with the font. This is greater than ascent+descent by a quantity known as the line spacing or external leading. When space is at a premium, most fonts can be set with only a distance of ascent+descent between lines." 770699 2 d-r 2012-11-19 06:54:27 -0800 This is originally caused by freetype rounding when "GRID_FIT_METRICS" is on: #ifdef GRID_FIT_METRICS metrics->ascender = FT_PIX_CEIL( FT_MulFix( face->ascender, metrics->y_scale ) ); metrics->descender = FT_PIX_FLOOR( FT_MulFix( face->descender, metrics->y_scale ) ); metrics->height = FT_PIX_ROUND( FT_MulFix( face->height, metrics->y_scale ) ); metrics->max_advance = FT_PIX_ROUND( FT_MulFix( face->max_advance_width, metrics->x_scale ) ); #else /* !GRID_FIT_METRICS */ Here, the CEIL + FLOOR of ascender and descender results in a non-uniform scaling - making the sum of ascender and descender larger than the height :-/ 771758 3 d-r 2012-11-20 04:56:01 -0800 Turns out, cairo is only using the Freetype clamping path if cairo_font_options_set_hint_metrics is set to CAIRO_HINT_METRICS_DEFAULT or CAIRO_HINT_METRICS_ON, see http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c?id=1.12.4#n1888 WebCore's Cairo backend does not modify the DEFAULT setting, which results in always receiving integer-clamped values SimpleFontData::platformInit(). As mentioned, the clamping in FreeType can lead to incorrect, negative line gap values which are exposed when enabling subpixel layout. Since WebCore maintains the font metrics in floats, there's no reason we should clamp early, allowing such bugs. I suggest to disable cairo's metrics hinting and receive correct, proportionally scaled values in SimpleFontDataFreetype.cpp. 771843 4 175215 d-r 2012-11-20 07:13:21 -0800 Created attachment 175215 Patch 771846 5 d-r 2012-11-20 07:14:24 -0800 If we wanted to keep the old letter-spacing behavior, we can round as follows: --- a/Source/WebCore/platform/graphics/freetype/SimpleFontDataFreeType.cpp +++ b/Source/WebCore/platform/graphics/freetype/SimpleFontDataFreeType.cpp @@ -146,7 +146,7 @@ float SimpleFontData::platformWidthForGlyph(Glyph glyph) const float w = (float)m_spaceWidth; if (cairo_scaled_font_status(m_platformData.scaledFont()) == CAIRO_STATUS_SUCCESS && extents.x_advance) - w = (float)extents.x_advance; + w = (float)lroundf(extents.x_advance); return w; } 771848 6 d-r 2012-11-20 07:19:21 -0800 CC'ing GTK+ people with the hope of supporting this change, agreeing on the big rebaseline that this would require. On EFL, we'd like to do this at the same time with enabling subpixel-layout. How do the GTK people feel about doing the same? 771893 7 mrobinson 2012-11-20 08:29:02 -0800 We did something like this once and then undid it, which was terribly labor intensive. If this is necessary perhaps we can only do it when subpixel layout is turned on. 771903 8 d-r 2012-11-20 08:47:32 -0800 (In reply to comment #7) > We did something like this once and then undid it, which was terribly labor intensive. If this is necessary perhaps we can only do it when subpixel layout is turned on. Yes, I would like to land this and activate subpixel on EFL hopefully this week - if you think the patch is okay? Ideally without a platform or subpixel specific ifdef. That's why i am asking whether you would be up for activating subpixel now as well. Mac has recently switched. 771918 9 mrobinson 2012-11-20 09:16:43 -0800 (In reply to comment #8) > Ideally without a platform or subpixel specific ifdef. That's why i am asking whether you would be up for activating subpixel now as well. Mac has recently switched. I think an #ifdef makes sense, as it will allow us to switch to subpixel positioning for the right reason (it's ready and we've tested it). We're in the middle of a development cycle and spending a lot of time updating baselines for a feature we may disable later is a bit risky. Since we have a responsibility to ship stable software on a schedule that we cannot control entirely, we need to be pretty cautious. Can you elaborate on the problems that you think an #ifdef poses. Perhaps there is some middle ground here. 771996 10 d-r 2012-11-20 10:44:58 -0800 (In reply to comment #9) > (In reply to comment #8) > > > Ideally without a platform or subpixel specific ifdef. That's why i am asking whether you would be up for activating subpixel now as well. Mac has recently switched. > Can you elaborate on the problems that you think an #ifdef poses. Perhaps there is some middle ground here. Well, as in this case there would not be a technical reason for the #ifdef since we're sharing the backends, I was hesitant to put one in the patch. Of course, it's possible, with a comment explaining why. > We did something like this once and then undid it, which was terribly labor intensive. Can you tell a bit more how similar this attempt was? I am positive that there is actually a bug here. I'd like to know a bit more why you reverted a similar change. Gyuyoung, what do you think about the letter spacing change implication? 775534 11 mrobinson 2012-11-26 09:08:06 -0800 (In reply to comment #10) > > Can you elaborate on the problems that you think an #ifdef poses. Perhaps there is some middle ground here. > Well, as in this case there would not be a technical reason for the #ifdef since we're sharing the backends, I was hesitant to put one in the patch. Of course, it's possible, with a comment explaining why. I think a comment and an #ifdef are a bit safer. We can always remove an #ifdef, but changing hundreds of baselines is a bigger task. > Can you tell a bit more how similar this attempt was? I am positive that there is actually a bug here. I'd like to know a bit more why you reverted a similar change. Wildfox made the original change, I believe. I tried searching for it but the relevant patches continue to elude me. If I recall correctly it had to do with enabling and disabling cairo_font_options_set_hint_metrics and the reason we reverted it is that it seemed to introduce flakiness into many tests. 775624 12 175215 mrobinson 2012-11-26 10:28:26 -0800 Comment on attachment 175215 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=175215&action=review > Source/WebCore/platform/graphics/freetype/FontPlatformDataFreeType.cpp:115 > + cairo_font_options_t* defaultFontOptions = cairo_font_options_create(); > + // Set to off in order to receive non-rounded floating point values for font metrics in SimpleFontDataFreeType instead > + // of integer-clamped values that may cause negative values for line-gap. > + cairo_font_options_set_hint_metrics(defaultFontOptions, CAIRO_HINT_METRICS_OFF); If we turn this off globally we probably want to force it off for the GDK font options as well above. 776488 13 d-r 2012-11-27 01:48:33 -0800 Martin, thanks for the details, I think I found the changes you refer to: > Wildfox made the original change, I believe. http://trac.webkit.org/changeset/101343 > [...] If I recall correctly it had to do with enabling and disabling cairo_font_options_set_hint_metrics and the reason we reverted it is that it seemed to introduce flakiness into many tests. And the revert came in two steps, http://trac.webkit.org/changeset/102748 + http://trac.webkit.org/changeset/114796 There's some magic there in the ChangeLog. "Re-enable Cairo metrics hinting, which seems to ensure consistent results in reference and pixel test results." From the other way 'round: Can you recall how the results were inconsistent? Were they inconsistent between runs on the same machine? Or were they inconsistent between different hosts? In the latter case, the reason might be in different fontconfig and gnome-settings-daemon configurations for hinting? I'd like to really resolve this issue and later hopefully land a patch that doesn't have the word "seems" in the Changelog :-). 776748 14 mrobinson 2012-11-27 07:58:17 -0800 (In reply to comment #13) > From the other way 'round: Can you recall how the results were inconsistent? Were they inconsistent between runs on the same machine? Or were they inconsistent between different hosts? In the latter case, the reason might be in different fontconfig and gnome-settings-daemon configurations for hinting? Tests started to flake after the change. If I recall correctly we had reftest failures that we didn't have before. > I'd like to really resolve this issue and later hopefully land a patch that doesn't have the word "seems" in the Changelog :-). Well, that's mostly just my poor style of writing, but I fully support this work. :) 778089 15 mrobinson 2012-11-28 11:10:39 -0800 I've been doing a little research [1] and it seems that Behdad suggests that metrics hinting should be on if subpixel layout is disabled. "If you don’t have subpixel text positioning (ie. your graphics system knows only how to rasterize one image for a glyph and blit that onto the screen), then you really want to enable metrics hinting." This is the first bullet point in the "Constraints" section. 1. https://docs.google.com/document/d/1wpzgGMqXgit6FBVaO76epnnFC_rQPdVKswrDQWyqO1M 778091 16 mrobinson 2012-11-28 11:11:56 -0800 CCing Behdad, who probably has some insightful input. 778266 17 mrobinson 2012-11-28 13:23:11 -0800 (In reply to comment #16) > 1. https://docs.google.com/document/d/1wpzgGMqXgit6FBVaO76epnnFC_rQPdVKswrDQWyqO1M Sorry. This link should be: https://docs.google.com/document/d/1wpzgGMqXgit6FBVaO76epnnFC_rQPdVKswrDQWyqO1M/edit 778923 18 behdad 2012-11-29 04:53:43 -0800 Hi, Martin is correct: cairo does not know how to render subpixel positioned text, and as such it will be a disaster IMO to turn metrics hinting off. There is an example in the document of the kind of wrong effects one would get doing that. What I suggest is to do something different only for getting the line metrics perhaps. For the actual measurement and layout of glyphs, don't disable metrics hinting with cairo. 778925 19 behdad 2012-11-29 04:56:45 -0800 Another reason why you can't disable metrics hinting is that you are not disabling hinting. Same document explains why that is a problem also. Second bullet in the "constraints" section. 778930 20 d-r 2012-11-29 05:15:46 -0800 (In reply to comment #18) > What I suggest is to do something different only for getting the line metrics perhaps. For the actual measurement and layout of glyphs, don't disable metrics hinting with cairo. Thanks, Behdad. I'll see what I can do to just get the right height info. Maybe I can temporarily disable metrics hinting just to retrieve these. 779014 21 176736 d-r 2012-11-29 07:44:45 -0800 Created attachment 176736 Patch 779015 22 d-r 2012-11-29 07:46:37 -0800 This new patch works for fixing the line height, line gap issue and leaves hinting (and metrics hinting) enabled. This way, we give non-rounded height information to WebCore for use in layout. Any other comments on this Behdad? What do you think, Martin? Thanks for your help. 780094 23 d-r 2012-11-30 07:14:52 -0800 Btw, this is also fixing bug 103740. 782782 24 behdad 2012-12-04 12:12:28 -0800 LGTM. I wonder whether there's something to be done in FreeType itself. Would help knowing what Windows does in this case. If you can get those numbers, I can do the upstreaming work in FreeType. 782826 25 d-r 2012-12-04 12:55:00 -0800 (In reply to comment #24) Behdad, thanks for your feedback, much appreciated. > LGTM. I wonder whether there's something to be done in FreeType itself. You mean, with regards to the issue I mentioned in comment 2? > Would help knowing what Windows does in this case. If you can get those numbers, I can do the upstreaming work in FreeType. What numbers would you need? Just the line height, ascent & descent of the same font? And would just retrieving the font details from a small test app be enough, or do you mean, dumping this from the same execution path in Safari/Win? 782951 26 behdad 2012-12-04 14:35:20 -0800 Thanks. I'm mostly interested to know what would Windows APIs returns for ascent / descent / linegap for that font at that size . Because I'm sure FreeType / others would insist that the lineheight should match what Windows returns... 783582 27 176736 kenneth 2012-12-05 03:07:11 -0800 Comment on attachment 176736 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176736&action=review > Source/WebCore/ChangeLog:12 > + than the line height. To work around this without globally disabling font metrics > + hinting, I am temporarily creating a new cairo scaled font with metrics hinting > + off and retrieving the height values from this one. isnt metrics hinting bad anyway for scaling? like it might affect layout at different scales. 783588 28 d-r 2012-12-05 03:16:48 -0800 (In reply to comment #27) > isnt metrics hinting bad anyway for scaling? like it might affect layout at different scales. See comment 15, metrics hinting is useful if you don't have subpixel positioning. When scaling, a new font with the right font size is instantiated. 783679 29 d-r 2012-12-05 05:40:24 -0800 (In reply to comment #26) > Thanks. I'm mostly interested to know what would Windows APIs returns for ascent / descent / linegap for that font at that size . Because I'm sure FreeType / others would insist that the lineheight should match what Windows returns... So, using a quick and dirty C# app [1], I got this: "Liberation Sans, 16 (fontSize: 16) - lineSpacingPixel: 18.39844, ascentPixel 14.48438, descent 3.390625, ascent+descent: 17.875" Very very close to what I get from Cairo/Freetype (after my temporary-hinting-off patch): ascent: 14.484375 descent: 3.390625 height: 18.3984375 [1] https://gist.github.com/4215546 That means, we're good to proceed with this patch, right? 786111 30 behdad 2012-12-07 13:49:04 -0800 (In reply to comment #29) > (In reply to comment #26) > > Thanks. I'm mostly interested to know what would Windows APIs returns for ascent / descent / linegap for that font at that size . Because I'm sure FreeType / others would insist that the lineheight should match what Windows returns... > > So, using a quick and dirty C# app [1], I got this: > "Liberation Sans, 16 (fontSize: 16) - lineSpacingPixel: 18.39844, ascentPixel 14.48438, descent 3.390625, ascent+descent: 17.875" > > Very very close to what I get from Cairo/Freetype (after my temporary-hinting-off patch): > ascent: 14.484375 > descent: 3.390625 > height: 18.3984375 > > [1] https://gist.github.com/4215546 > > That means, we're good to proceed with this patch, right? Thanks for testing. I think the patch is fine to go in. That said, for Windows. I was more interested in the hinted integer metrics, since that's where the current bug in FreeType is. If you can get those number I will followup with FreeType upstream to fix it properly. I don't have access to Windows myself. Thanks again! 788399 31 d-r 2012-12-11 06:39:57 -0800 (In reply to comment #30) > Thanks for testing. I think the patch is fine to go in. That said, for Windows. I was more interested in the hinted integer metrics, since that's where the current bug in FreeType is. If you can get those number I will followup with FreeType upstream to fix it properly. I don't have access to Windows myself. Thanks again! More lovely Win programming [1] using GDI GetTextMetrics on a device context handle optained from .net gives me (Liberation Sans, 16 pixel): ascent: 14 descent: 3 height: 17 whereas the freetype code here gives me: ascent: 15 descent: 4 height: 18 Good luck fixing this on Freetype. [1] https://gist.github.com/d4169b1068c203432846 788407 32 behdad 2012-12-11 06:58:03 -0800 Thanks Dominik. I'll see what I can do. 789074 33 ostap73 2012-12-11 18:07:06 -0800 (In reply to comment #31) > (In reply to comment #30) > > Thanks for testing. I think the patch is fine to go in. That said, for Windows. I was more interested in the hinted integer metrics, since that's where the current bug in FreeType is. If you can get those number I will followup with FreeType upstream to fix it properly. I don't have access to Windows myself. Thanks again! > > More lovely Win programming [1] using GDI GetTextMetrics on a device context handle optained from .net gives me (Liberation Sans, 16 pixel): > ascent: 14 > descent: 3 > height: 17 > > whereas the freetype code here gives me: > ascent: 15 > descent: 4 > height: 18 > > Good luck fixing this on Freetype. > > [1] https://gist.github.com/d4169b1068c203432846 Win GDI uses simple truncate instead of rounding? 789396 34 d-r 2012-12-12 02:46:15 -0800 (In reply to comment #33) > Win GDI uses simple truncate instead of rounding? It looks as if it's flooring all values, yes. But let's say I haven't looked at the GDI code :-). As per comment 2, at least a combination of ceiling some values and rounding others is an unholy combination. 798295 35 ostap73 2012-12-30 22:26:36 -0800 *** Bug 104573 has been marked as a duplicate of this bug. *** 804320 36 d-r 2013-01-10 06:27:51 -0800 (In reply to comment #32) > Thanks Dominik. I'll see what I can do. Any update on the FreeType front here, Behdad? Thanks. 804540 37 behdad 2013-01-10 10:55:16 -0800 I wasn't sure what to suggest to FreeType, so I put it off. Went ahead and sent a mail right now bringing it to others' attention. We'll see what people have to offer. It doesn't show up in the list archives yet, but it will be here: http://lists.nongnu.org/archive/html/freetype-devel/2013-01/index.html 805211 38 wl 2013-01-11 05:56:28 -0800 There is definitely a bug in FreeType. Thanks for the report. It seems that the rounded ascender and descender values must be added to get the height. Instead, we currently add the ascender and descender values, then do rounding. For verifying this assumption I ask you to run your program from comment #31 for a whole range of sizes, say, 8ppem to 30ppem (I don't use Windows :-). Please tell me exactly the used version (and size) of LiberationSans-Regular.otf to avoid any ambiguities. Maybe it also helps to repeat this with other MS core fonts, just to be sure. Additionally, I would like to know which FreeType function Webkit was calling to get the incorrect results (in comment #31). Theoretically, this shouldn't happen at all because there is already code in `sfobjs.c' which uses ROUND only (as requested by TrueType), overriding the CEIL and FLOOR results FreeType is using for other font formats. 805333 39 d-r 2013-01-11 09:44:27 -0800 (In reply to comment #38) Thanks for taking a look, Werner. I'll try to get you the data you requested. 806189 40 d-r 2013-01-14 02:33:24 -0800 I was relying on our jhbuild freetype version being somewhat up to date - turns out this was an incorrect assumption. I should have done the bisecting earlier. In any event, freetype commit b0962ac34e660 "[truetype] Fix metrics on size request for scalable fonts." by Steven Chu changes my initial failure example to the better looking: @@ -3,5 +3,5 @@ layer at (0,0) size 800x600 RenderBlock {HTML} at (0,0) size 800x600 RenderBody {BODY} at (8,8) size 784x584 - RenderText {#text} at (0,0) size 196x19 + RenderText {#text} at (0,0) size 196x17 text run at (0,0) width 196: "red squares background image." So, we're actually hitting the same problem that Steven has been describing in http://lists.gnu.org/archive/html/freetype-devel/2011-07/msg00029.html He's commenting there that FT_Request_Size - actually computes incorrect values for Ahem - similar for my case of Liberation Sans here. If for TrueType - the ascent and descent metrics are reset afterwards anyway - why are we calling it for scalable fonts? Werner, regarding your original question: How is the incorrect rounding code reached? It is reached from FT_Request_Size -> tt_size_request -> ft_recompute_scaled_metrics (for details, I attached the stacktrace with freetype 2.4.11). But then, after Steven's patch - as far as I understand his patch - these incorrectly rounded values are discarded and replaced. Would you still need the values from Windows after this finding? 806190 41 182532 d-r 2013-01-14 02:33:54 -0800 Created attachment 182532 Stacktrace leading to incorrect rounding 806203 42 wl 2013-01-14 02:54:45 -0800 Yes, please, just to be sure. And sorry, I don't fully understand the rest of your last comment: Is there still a problem left? 806208 43 d-r 2013-01-14 03:02:47 -0800 (In reply to comment #42) > Yes, please, just to be sure. > > And sorry, I don't fully understand the rest of your last comment: Is there still a problem left? Well, it seems that the (incorrect) rounding code in question is still run, but then these preliminary values are replaced - do I understand that right? (Same as in Steven's analysis: http://lists.gnu.org/archive/html/freetype-devel/2011-07/msg00029.html ) [...] " FT_Request_Metrics( size->face, req ); /* Calculates new metrics, incorrect for Ahem */ if ( FT_IS_SCALABLE( size->face ) ) /* Ahem is scalable */ error = tt_size_reset( ttsize ); /* Calculates proper metrics stored in ttsize */ [...] Shouldn't this code be changed so that FT_Request_Metrics is not called for SCALABLE fonts in order to avoid unnecessary computation? 807347 44 176736 d-r 2013-01-15 08:50:31 -0800 Comment on attachment 176736 Patch Obsoleting patch - solved in Freetype >= 2.4.6, see bug 106774. 812877 45 d-r 2013-01-22 03:39:09 -0800 Werner informed me that there has been indeed a fix/change in FreeType after our discussion here: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=e0469372be3870a5ad60b2c4586e9c281357bd28 175215 2012-11-20 07:13:21 -0800 2012-11-29 07:44:37 -0800 Patch bug-102374-20121120171109.patch text/plain 4129 d-r U3VidmVyc2lvbiBSZXZpc2lvbjogMTM0OTQxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggMjZlMjIxODAwMmRmMjQ1 ZTBlNmY3YzcwZmI1NzRjZDMzMjI0Y2RkYy4uMDdhODZkNmE1MDRjMjBhMzg3NzhkNmZiMWZlZmJj NzUxNjM2Zjk1MSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDM0IEBACisyMDEyLTExLTIwICBEb21p bmlrIFLDtnR0c2NoZXMgIDxkb21pbmlrLnJvdHRzY2hlc0BpbnRlbC5jb20+CisKKyAgICAgICAg W0ZyZWVUeXBlXSBJbmNvcnJlY3QgYmFzZWxpbmUgcG9zaXRpb25pbmcgJiBsaW5lIHNwYWNpbmcg ZHVlIHRvIHJvdW5kaW5nCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn LmNnaT9pZD0xMDIzNzQKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKwor ICAgICAgICBDYWlybyB3aXRoIGZvbnQgbWV0cmljcyBoaW50aW5nIHNldCB0byBkZWZhdWx0IHdp bGwgZW50ZXIgYSBGcmVlVHlwZSBjb2RlCisgICAgICAgIHBhdGggdGhhdCBlbmFibGVzIGdyaWQg Zml0dGluZy4gVGhpcyBwYXRoIGNlaWxzIHRoZSBhc2NlbnQsIGZsb29ycyB0aGUKKyAgICAgICAg ZGVzY2VudCBhbmQgcm91bmRzIHRoZSBoZWlnaHQuIFRoaXMgY2FuIGxlYWQgdG8gY2FzZXMgd2hl cmUgdGhlIGxpbmUgZ2FwCisgICAgICAgIHRoYXQgV2ViS2l0IGNhbGN1bGF0ZXMgYXMgaGVpZ2h0 IC0gYXNjZW50IC0gZGVzY2VudCBjYW4gYmUgbmVnYXRpdmUuCisgICAgICAgIFRoaXMgaXMgY2xl YXJseSBleHBvc2VkIHdoZW4gZW5hYmxpbmcgc3VicGl4ZWwgbGF5b3V0IHdpdGggdGhlIENhaXJv IGFuZCBGcmVlVHlwZQorICAgICAgICBiYWNrZW5kLCBidXQgaXQncyBhbHNvIHNob3dpbmcgd2l0 aG91dCBzdWItcGl4ZWwgbGF5b3V0IGVuYWJsZWQuIFBvcnRzCisgICAgICAgIHVzaW5nIHRoaXMg YmFja2VuZCB3aWxsIHByb2R1Y2Ugb3V0cHV0IHdoZXJlIHRoZSB0ZXh0IGJhc2VsaW5lIGlzIGlu Y29ycmVjdGx5CisgICAgICAgIHBvc2l0aW9uZWQgMSBwaXhlbCB0b28gbG93LgorCisgICAgICAg IFRoZSBmaXggZGlzYWJsZXMgZm9udCBtZXRyaWNzIGhpbnRpbmcgaW4gY2Fpcm8sIHJlc3VsdGlu ZyBpbiBhY3R1YWwKKyAgICAgICAgZmxvYXRpbmcgcG9pbnQgdmFsdWVzIHJldHJpZXZlZCBmb3Ig Zm9udCBtZXRyaWNzLiBCZWNhdXNlIG5vdyBnbHlwaCB3aWR0aAorICAgICAgICBpcyByZXRyaWV2 ZWQgaW4gZmxvYXQgYXMgd2VsbCwgbm90IHJvdW5kZWQgYW55bW9yZSwgdGhpcyByZXN1bHRzIGlu IHNsaWdodGx5CisgICAgICAgIHdpZGVyIGxldHRlciBzcGFjaW5nLgorCisgICAgICAgIE5vIG5l dyB0ZXN0cy4gVGhpcyBhZmZlY3RzIHRoZSBtYWpvcml0eSBvZiBsYXlvdXQgdGVzdHMgYW5kIHJl cXVpcmVzCisgICAgICAgIGEgbWFqb3IgcmViYXNlbGluZS4gTW9zdCBvZiB0aGUgY2FzZXMgd2hl cmUgdGV4dCBpcyBwb3NpdGlvbmVkIGluIGEgYm9yZGVyZWQKKyAgICAgICAgYm94IGFjdHVhbGx5 IGV4cG9zZXMgdGhlIHdyb25nIGJhc2VsaW5lIHBvc2l0aW9uaW5nLiBJbiBhZGRpdGlvbiwKKyAg ICAgICAgZW5hYmxpbmcgc3VicGl4ZWwgbGF5b3V0IHNob3dzIHRoZSAtMSBuZWdhdGl2ZSBsaW5l IGdhcCBvZmZzZXQuCisKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy9mcmVldHlwZS9Gb250 UGxhdGZvcm1EYXRhRnJlZVR5cGUuY3BwOgorICAgICAgICAoV2ViQ29yZTo6Z2V0RGVmYXVsdEZv bnRPcHRpb25zKTogRGlzYWJsaW5nIGZvbnQgbWV0cmljcyBoaW50aW5nLgorICAgICAgICAqIHBs YXRmb3JtL2dyYXBoaWNzL2ZyZWV0eXBlL1NpbXBsZUZvbnREYXRhRnJlZVR5cGUuY3BwOgorICAg ICAgICAoV2ViQ29yZTo6U2ltcGxlRm9udERhdGE6OnBsYXRmb3JtSW5pdCk6IFJlbW92aW5nIHJv dW5kaW5nLCBzaW1pbGFyIHRvIG90aGVyIHBvcnRzLCBsaW5lIHNwYWNpbmcgaW4gV2ViS2l0IGlz IHN0b3JlZCBhcyBhIGZsb2F0LgorCiAyMDEyLTExLTE2ICBLZW50YXJvIEhhcmEgIDxoYXJha2Vu QGNocm9taXVtLm9yZz4KIAogICAgICAgICBbVjhdIFJlbW92ZSBJc1N1YlR5cGUoKSBmcm9tIENv ZGVHZW5lcmF0b3JWOC5wbQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3Jh cGhpY3MvZnJlZXR5cGUvRm9udFBsYXRmb3JtRGF0YUZyZWVUeXBlLmNwcCBiL1NvdXJjZS9XZWJD b3JlL3BsYXRmb3JtL2dyYXBoaWNzL2ZyZWV0eXBlL0ZvbnRQbGF0Zm9ybURhdGFGcmVlVHlwZS5j cHAKaW5kZXggYzk1ZDFiM2I5ODNjODY1NjkxNzMyZTZkNDUwNzIyOGY1NDMxZjA2Ny4uNTk0ZDll ODhhYjY5NGM1NDdhOTVmMjI4Y2JkYzY3NzcxYWY0MTNhOCAxMDA2NDQKLS0tIGEvU291cmNlL1dl YkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZnJlZXR5cGUvRm9udFBsYXRmb3JtRGF0YUZyZWVUeXBl LmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9mcmVldHlwZS9Gb250 UGxhdGZvcm1EYXRhRnJlZVR5cGUuY3BwCkBAIC0xMDksNyArMTA5LDExIEBAIHN0YXRpYyBjYWly b19mb250X29wdGlvbnNfdCogZ2V0RGVmYXVsdEZvbnRPcHRpb25zKCkKICAgICAgICAgICAgIHJl dHVybiBjYWlyb19mb250X29wdGlvbnNfY29weShzY3JlZW5PcHRpb25zKTsKICAgICB9CiAjZW5k aWYKLSAgICByZXR1cm4gY2Fpcm9fZm9udF9vcHRpb25zX2NyZWF0ZSgpOworICAgIGNhaXJvX2Zv bnRfb3B0aW9uc190KiBkZWZhdWx0Rm9udE9wdGlvbnMgPSBjYWlyb19mb250X29wdGlvbnNfY3Jl YXRlKCk7CisgICAgLy8gU2V0IHRvIG9mZiBpbiBvcmRlciB0byByZWNlaXZlIG5vbi1yb3VuZGVk IGZsb2F0aW5nIHBvaW50IHZhbHVlcyBmb3IgZm9udCBtZXRyaWNzIGluIFNpbXBsZUZvbnREYXRh RnJlZVR5cGUgaW5zdGVhZAorICAgIC8vIG9mIGludGVnZXItY2xhbXBlZCB2YWx1ZXMgdGhhdCBt YXkgY2F1c2UgbmVnYXRpdmUgdmFsdWVzIGZvciBsaW5lLWdhcC4KKyAgICBjYWlyb19mb250X29w dGlvbnNfc2V0X2hpbnRfbWV0cmljcyhkZWZhdWx0Rm9udE9wdGlvbnMsIENBSVJPX0hJTlRfTUVU UklDU19PRkYpOworICAgIHJldHVybiBkZWZhdWx0Rm9udE9wdGlvbnM7CiB9CiAKIEZvbnRQbGF0 Zm9ybURhdGE6OkZvbnRQbGF0Zm9ybURhdGEoRmNQYXR0ZXJuKiBwYXR0ZXJuLCBjb25zdCBGb250 RGVzY3JpcHRpb24mIGZvbnREZXNjcmlwdGlvbikKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3Jl L3BsYXRmb3JtL2dyYXBoaWNzL2ZyZWV0eXBlL1NpbXBsZUZvbnREYXRhRnJlZVR5cGUuY3BwIGIv U291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZnJlZXR5cGUvU2ltcGxlRm9udERhdGFG cmVlVHlwZS5jcHAKaW5kZXggYTE2YWQxN2RmOWQ4YmZmODlmMzgwOGEwNzNkNjA3NzkwM2ZkNzI2 Yi4uYTMxZjljMTQwODZiMGFmMDI1NTJhMjg5M2IzODZmMWFhZTNjMGE5YyAxMDA2NDQKLS0tIGEv U291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZnJlZXR5cGUvU2ltcGxlRm9udERhdGFG cmVlVHlwZS5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZnJlZXR5 cGUvU2ltcGxlRm9udERhdGFGcmVlVHlwZS5jcHAKQEAgLTY1LDggKzY1LDcgQEAgdm9pZCBTaW1w bGVGb250RGF0YTo6cGxhdGZvcm1Jbml0KCkKICAgICBtX2ZvbnRNZXRyaWNzLnNldEFzY2VudChh c2NlbnQpOwogICAgIG1fZm9udE1ldHJpY3Muc2V0RGVzY2VudChkZXNjZW50KTsKIAotICAgIC8v IE1hdGNoIENvcmVHcmFwaGljcyBtZXRyaWNzLgotICAgIG1fZm9udE1ldHJpY3Muc2V0TGluZVNw YWNpbmcobHJvdW5kZihhc2NlbnQpICsgbHJvdW5kZihkZXNjZW50KSArIGxyb3VuZGYobGluZUdh cCkpOworICAgIG1fZm9udE1ldHJpY3Muc2V0TGluZVNwYWNpbmcoYXNjZW50ICsgZGVzY2VudCAr IGxpbmVHYXApOwogICAgIG1fZm9udE1ldHJpY3Muc2V0TGluZUdhcChsaW5lR2FwKTsKIAogICAg IGNhaXJvX3NjYWxlZF9mb250X3RleHRfZXh0ZW50cyhtX3BsYXRmb3JtRGF0YS5zY2FsZWRGb250 KCksICJ4IiwgJnRleHRfZXh0ZW50cyk7Cg== 176736 2012-11-29 07:44:45 -0800 2013-01-15 08:50:31 -0800 Patch bug-102374-20121129174217.patch text/plain 4358 d-r U3VidmVyc2lvbiBSZXZpc2lvbjogMTM2MTI1CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggYWZhNzUyM2ZkZjVlNjMw MGQ0ZGQ0ODlkYjBkODNiYzk1OTg3MWYwMS4uNjllNjQzY2ExNDI3YzMyZmRmOTAzYzYzYjc2ZWRh M2UxZGNkOTA5NiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDI2IEBACisyMDEyLTExLTI5ICBEb21p bmlrIFLDtnR0c2NoZXMgIDxkb21pbmlrLnJvdHRzY2hlc0BpbnRlbC5jb20+CisKKyAgICAgICAg W0NhaXJvLCBGcmVlVHlwZV0gSW5jb3JyZWN0IGJhc2VsaW5lIHBvc2l0aW9uaW5nICYgbGluZSBz cGFjaW5nIGR1ZSB0byByb3VuZGluZworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9z aG93X2J1Zy5jZ2k/aWQ9MTAyMzc0CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT ISkuCisKKyAgICAgICAgUmV0cmlldmluZyBsaW5lIHNwYWNpbmcgaW5mbyB3aXRob3V0IG1ldHJp Y3MgaGludGluZyAtIEZyZWVUeXBlJ3MgbWV0cmljIGhpbnRpbmcKKyAgICAgICAgdXNlcyByb3Vu ZGluZyB3aGljaCByZXN1bHRzIGluIHRoZSBzdW0gb2YgYXNjZW50IGFuZCBkZXNjZW50IGJlaW5n IGxhcmdlcgorICAgICAgICB0aGFuIHRoZSBsaW5lIGhlaWdodC4gVG8gd29yayBhcm91bmQgdGhp cyB3aXRob3V0IGdsb2JhbGx5IGRpc2FibGluZyBmb250IG1ldHJpY3MKKyAgICAgICAgaGludGlu ZywgSSBhbSB0ZW1wb3JhcmlseSBjcmVhdGluZyBhIG5ldyBjYWlybyBzY2FsZWQgZm9udCB3aXRo IG1ldHJpY3MgaGludGluZworICAgICAgICBvZmYgYW5kIHJldHJpZXZpbmcgdGhlIGhlaWdodCB2 YWx1ZXMgZnJvbSB0aGlzIG9uZS4KKworICAgICAgICBBbHNvIGRpc2FibGluZyB0aGUgcm91bmRp bmcgZm9yIGxpbmUgc3BhY2luZywgb3RoZXIgcG9ydHMgZG9uJ3QgZG8gdGhpcyBhbnkgbW9yZSwK KyAgICAgICAgYW5kIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIHdvdWxkIGltcHJvdmUgcmVuZGVyaW5n LiBJbiBteSB1bmRlcnN0YW5kaW5nIGl0J3MKKyAgICAgICAgdXNlZnVsIHRvIGhhdmUgdGhlIG5v bi1yb3VuZGVkIHZhbHVlIGhlcmUgZm9yIHpvb21pbmcgc2l0dWF0aW9ucy4KKworICAgICAgICBO byBuZXcgdGVzdHMsIGJhc2ljYWxseSBhZmZlY3RzIGFsbCB0ZXN0cywgbmVlZHMgbGFyZ2UgcmVi YXNlbGluaW5nLgorCisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvZnJlZXR5cGUvU2ltcGxl Rm9udERhdGFGcmVlVHlwZS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpjbG9uZVNjYWxlZEZvbnRX aXRob3V0TWV0cmljc0hpbnRpbmcpOiBOZXcgZnVuY3Rpb24gdG8gY2xvbmUgdGhlIGV4aXN0aW5n IGZvbnQsIG9ubHkgd2l0aCBtZXRyaWNzIGhpbnRpbmcgZGlzYWJsZWQuCisgICAgICAgIChXZWJD b3JlOjpTaW1wbGVGb250RGF0YTo6cGxhdGZvcm1Jbml0KTogR2V0IGhlaWdodCBpbmZvIGZyb20g bm9uLW1ldHJpY3MgaGludGVkIGZvbnQsIGRpc2FibGUgcm91bmRpbmcgZm9yIGxpbmVzcGFjaW5n LgorCiAyMDEyLTExLTI5ICBGbG9yaW4gTWFsaXRhICA8Zm1hbGl0YUBjaHJvbWl1bS5vcmc+CiAK ICAgICAgICAgW1NraWFdIEFkZCBtaXNzaW5nIE9wYXF1ZVJlZ2lvblNraWEgbm90aWZpZXIgY2Fs bHMKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL2ZyZWV0eXBl L1NpbXBsZUZvbnREYXRhRnJlZVR5cGUuY3BwIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3Jh cGhpY3MvZnJlZXR5cGUvU2ltcGxlRm9udERhdGFGcmVlVHlwZS5jcHAKaW5kZXggYTE2YWQxN2Rm OWQ4YmZmODlmMzgwOGEwNzNkNjA3NzkwM2ZkNzI2Yi4uNWM0OWY0NzZmYmNiYjM4ODBkNmYyMWMy NmJiNTQzYWJkN2Q3NWQxNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3Jh cGhpY3MvZnJlZXR5cGUvU2ltcGxlRm9udERhdGFGcmVlVHlwZS5jcHAKKysrIGIvU291cmNlL1dl YkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZnJlZXR5cGUvU2ltcGxlRm9udERhdGFGcmVlVHlwZS5j cHAKQEAgLTQ4LDYgKzQ4LDIwIEBACiAKIG5hbWVzcGFjZSBXZWJDb3JlIHsKIAorc3RhdGljIGNh aXJvX3NjYWxlZF9mb250X3QqIGNsb25lU2NhbGVkRm9udFdpdGhvdXRNZXRyaWNzSGludGluZyhj YWlyb19zY2FsZWRfZm9udF90KiBvcmlnaW5hbCkKK3sKKyAgICBjYWlyb19mb250X29wdGlvbnNf dCogZm9udE9wdGlvbnMgPSBjYWlyb19mb250X29wdGlvbnNfY3JlYXRlKCk7CisgICAgY2Fpcm9f c2NhbGVkX2ZvbnRfZ2V0X2ZvbnRfb3B0aW9ucyhvcmlnaW5hbCwgZm9udE9wdGlvbnMpOworICAg IGNhaXJvX2ZvbnRfb3B0aW9uc19zZXRfaGludF9tZXRyaWNzKGZvbnRPcHRpb25zLCBDQUlST19I SU5UX01FVFJJQ1NfT0ZGKTsKKyAgICBjYWlyb19tYXRyaXhfdCBmb250TWF0cml4OworICAgIGNh aXJvX3NjYWxlZF9mb250X2dldF9mb250X21hdHJpeChvcmlnaW5hbCwgJmZvbnRNYXRyaXgpOwor ICAgIGNhaXJvX21hdHJpeF90IGZvbnRDdG07CisgICAgY2Fpcm9fc2NhbGVkX2ZvbnRfZ2V0X2N0 bShvcmlnaW5hbCwgJmZvbnRDdG0pOworICAgIGNhaXJvX3NjYWxlZF9mb250X3QqIG5ld1NjYWxl ZEZvbnQgPSBjYWlyb19zY2FsZWRfZm9udF9jcmVhdGUoY2Fpcm9fc2NhbGVkX2ZvbnRfZ2V0X2Zv bnRfZmFjZShvcmlnaW5hbCksICZmb250TWF0cml4LCAmZm9udEN0bSwgZm9udE9wdGlvbnMpOwor ICAgIGNhaXJvX2ZvbnRfb3B0aW9uc19kZXN0cm95KGZvbnRPcHRpb25zKTsKKyAgICByZXR1cm4g bmV3U2NhbGVkRm9udDsKK30KKwogdm9pZCBTaW1wbGVGb250RGF0YTo6cGxhdGZvcm1Jbml0KCkK IHsKICAgICBpZiAoIW1fcGxhdGZvcm1EYXRhLm1fc2l6ZSkKQEAgLTU2LDcgKzcwLDEyIEBAIHZv aWQgU2ltcGxlRm9udERhdGE6OnBsYXRmb3JtSW5pdCgpCiAgICAgQVNTRVJUKG1fcGxhdGZvcm1E YXRhLnNjYWxlZEZvbnQoKSk7CiAgICAgY2Fpcm9fZm9udF9leHRlbnRzX3QgZm9udF9leHRlbnRz OwogICAgIGNhaXJvX3RleHRfZXh0ZW50c190IHRleHRfZXh0ZW50czsKLSAgICBjYWlyb19zY2Fs ZWRfZm9udF9leHRlbnRzKG1fcGxhdGZvcm1EYXRhLnNjYWxlZEZvbnQoKSwgJmZvbnRfZXh0ZW50 cyk7CisKKyAgICAvLyBUZW1wb3JhcmlseSBjcmVhdGUgYSBjbG9uZSB0aGF0IGRvZXNuJ3QgaGF2 ZSBtZXRyaWNzIGhpbnRpbmcgaW4gb3JkZXIgdG8gYXZvaWQgaW5jb3JyZWN0CisgICAgLy8gcm91 bmRpbmcgcmVzdWx0aW5nIGluIGluY29ycmVjdCBiYXNlbGluZSBwb3NpdGlvbmluZyBzaW5jZSB0 aGUgc3VtIG9mIGFzY2VudCBhbmQgZGVzY2VudAorICAgIC8vIGJlY29tZXMgbGFyZ2VyIHRoYW4g dGhlIGxpbmUgaGVpZ2h0LgorICAgIGNhaXJvX3NjYWxlZF9mb250X3QqIGZvbnRXaXRob3V0TWV0 cmljc0hpbnRpbmcgPSBjbG9uZVNjYWxlZEZvbnRXaXRob3V0TWV0cmljc0hpbnRpbmcobV9wbGF0 Zm9ybURhdGEuc2NhbGVkRm9udCgpKTsKKyAgICBjYWlyb19zY2FsZWRfZm9udF9leHRlbnRzKGZv bnRXaXRob3V0TWV0cmljc0hpbnRpbmcsICZmb250X2V4dGVudHMpOwogCiAgICAgZmxvYXQgYXNj ZW50ID0gbmFycm93UHJlY2lzaW9uVG9GbG9hdChmb250X2V4dGVudHMuYXNjZW50KTsKICAgICBm bG9hdCBkZXNjZW50ID0gbmFycm93UHJlY2lzaW9uVG9GbG9hdChmb250X2V4dGVudHMuZGVzY2Vu dCk7CkBAIC02NSwxMCArODQsMTEgQEAgdm9pZCBTaW1wbGVGb250RGF0YTo6cGxhdGZvcm1Jbml0 KCkKICAgICBtX2ZvbnRNZXRyaWNzLnNldEFzY2VudChhc2NlbnQpOwogICAgIG1fZm9udE1ldHJp Y3Muc2V0RGVzY2VudChkZXNjZW50KTsKIAotICAgIC8vIE1hdGNoIENvcmVHcmFwaGljcyBtZXRy aWNzLgotICAgIG1fZm9udE1ldHJpY3Muc2V0TGluZVNwYWNpbmcobHJvdW5kZihhc2NlbnQpICsg bHJvdW5kZihkZXNjZW50KSArIGxyb3VuZGYobGluZUdhcCkpOworICAgIG1fZm9udE1ldHJpY3Mu c2V0TGluZVNwYWNpbmcoYXNjZW50ICsgZGVzY2VudCArIGxpbmVHYXApOwogICAgIG1fZm9udE1l dHJpY3Muc2V0TGluZUdhcChsaW5lR2FwKTsKIAorICAgIGNhaXJvX3NjYWxlZF9mb250X2Rlc3Ry b3koZm9udFdpdGhvdXRNZXRyaWNzSGludGluZyk7CisKICAgICBjYWlyb19zY2FsZWRfZm9udF90 ZXh0X2V4dGVudHMobV9wbGF0Zm9ybURhdGEuc2NhbGVkRm9udCgpLCAieCIsICZ0ZXh0X2V4dGVu dHMpOwogICAgIG1fZm9udE1ldHJpY3Muc2V0WEhlaWdodChuYXJyb3dQcmVjaXNpb25Ub0Zsb2F0 KHRleHRfZXh0ZW50cy5oZWlnaHQpKTsKIAo= 182532 2013-01-14 02:33:54 -0800 2013-01-14 02:33:54 -0800 Stacktrace leading to incorrect rounding stacktrace_leading_to_ft_recompute_scaled_metrics.txt text/plain 1602 d-r IzAgIGZ0X3JlY29tcHV0ZV9zY2FsZWRfbWV0cmljcyAoZmFjZT0weDExNTUwMTAsIG1ldHJpY3M9 MHgxMTViZWM4KSBhdCAvZmFzdC9kb21pbmlrL2Rldi9XZWJLaXRHaXRfRUZML1dlYktpdEJ1aWxk L0RlcGVuZGVuY2llcy9Tb3VyY2UvZnJlZXR5cGUtMi40LjExL3NyYy9iYXNlL2Z0b2Jqcy5jOjI1 NjAKIzEgIDB4MDAwMDdmZmZmMDVmYzU1OSBpbiB0dF9zaXplX3JlcXVlc3QgKHNpemU9MHgxMTVi ZWIwLCByZXE9MHg3ZmZmZmZmZjdlZjApIGF0IC9mYXN0L2RvbWluaWsvZGV2L1dlYktpdEdpdF9F RkwvV2ViS2l0QnVpbGQvRGVwZW5kZW5jaWVzL1NvdXJjZS9mcmVldHlwZS0yLjQuMTEvc3JjL3Ry dWV0eXBlL3R0ZHJpdmVyLmM6MjQ2CiMyICAweDAwMDA3ZmZmZjA1ZWI5YWMgaW4gRlRfUmVxdWVz dF9TaXplIChmYWNlPTB4MTE1NTAxMCwgcmVxPTxvcHRpbWl6ZWQgb3V0PikgYXQgL2Zhc3QvZG9t aW5pay9kZXYvV2ViS2l0R2l0X0VGTC9XZWJLaXRCdWlsZC9EZXBlbmRlbmNpZXMvU291cmNlL2Zy ZWV0eXBlLTIuNC4xMS9zcmMvYmFzZS9mdG9ianMuYzoyODM0CiMzICAweDAwMDA3ZmZmZjA1ZWJh NWUgaW4gRlRfU2V0X0NoYXJfU2l6ZSAoZmFjZT08b3B0aW1pemVkIG91dD4sIGNoYXJfd2lkdGg9 PG9wdGltaXplZCBvdXQ+LCBjaGFyX2hlaWdodD08b3B0aW1pemVkIG91dD4sIGhvcnpfcmVzb2x1 dGlvbj08b3B0aW1pemVkIG91dD4sIHZlcnRfcmVzb2x1dGlvbj08b3B0aW1pemVkIG91dD4pIGF0 IC9mYXN0L2RvbWluaWsvZGV2L1dlYktpdEdpdF9FRkwvV2ViS2l0QnVpbGQvRGVwZW5kZW5jaWVz L1NvdXJjZS9mcmVldHlwZS0yLjQuMTEvc3JjL2Jhc2UvZnRvYmpzLmM6MjkyMgojNCAgMHgwMDAw N2ZmZmY3ZDg2YmJiIGluIF9jYWlyb19mdF91bnNjYWxlZF9mb250X3NldF9zY2FsZSAodW5zY2Fs ZWQ9MHgxMTU0NDAwLCBzY2FsZT08b3B0aW1pemVkIG91dD4pIGF0IGNhaXJvLWZ0LWZvbnQuYzo4 MDIKIzUgIDB4MDAwMDdmZmZmN2Q4NzIwNyBpbiBfY2Fpcm9fZnRfZm9udF9mYWNlX3NjYWxlZF9m b250X2NyZWF0ZSAoYWJzdHJhY3RfZm9udF9mYWNlPTB4MTBlODZiMCwgZm9udF9tYXRyaXg9MHg3 ZmZmZmZmZjgyZDAsIGN0bT0weDdmZmZmZmZmODJhMCwgb3B0aW9ucz0weDc0ZGE5MCwgZm9udF9v dXQ9MHg3ZmZmZmZmZjgwNDgpIGF0IGNhaXJvLWZ0LWZvbnQuYzoxODY2CiM2ICAweDAwMDA3ZmZm ZjdkMzYyZjIgaW4gSU5UX2NhaXJvX3NjYWxlZF9mb250X2NyZWF0ZSAoZm9udF9mYWNlPTB4MTBl ODZiMCwgZm9udF9tYXRyaXg9MHg3ZmZmZmZmZjgyZDAsIGN0bT0weDdmZmZmZmZmODJhMCwgb3B0 aW9ucz0weDc0ZGE5MCkgYXQgY2Fpcm8tc2NhbGVkLWZvbnQuYzoxMTExCiM3ICAweDAwMDA3ZmZm ZjRlODZmOTQgaW4gV2ViQ29yZTo6Rm9udFBsYXRmb3JtRGF0YTo6aW5pdGlhbGl6ZVdpdGhGb250 RmFjZSAodGhpcz0weDExNGU0YjAsIGZvbnRGYWNlPTB4MTBlODZiMCwgZm9udERlc2NyaXB0aW9u PS4uLikgYXQgL2Zhc3QvZG9taW5pay9kZXYvV2ViS2l0R2l0X0VGTC9Tb3VyY2UvV2ViQ29yZS9w bGF0Zm9ybS9ncmFwaGljcy9mcmVldHlwZS9Gb250UGxhdGZvcm1EYXRhRnJlZVR5cGUuY3BwOjMw OQoKCgoK