6148 2005-12-19 04:47:00 -0800 WebKit doesn't shape characters (like Arabic) across style changes 2025-12-31 14:03:26 -0800 1 1 1 Unclassified WebKit Layout and Rendering 420+ All All NEW https://bugs.webkit.org/show_bug.cgi?id=222734 https://bugs.webkit.org/show_bug.cgi?id=229421 https://bugs.webkit.org/show_bug.cgi?id=282444 https://bugs.webkit.org/show_bug.cgi?id=289997 http://blogs.msdn.com/michkap/archive/2005/12/19/505309.aspx BrowserCompat, InRadar P2 Normal --- 300583 298830 298889 298895 298902 298953 298964 299106 299109 299129 299226 299605 299624 299902 299913 300441 229361 47213 1 webkit-bugs mmaxfield abdullahh883 abuzakham ah.abuali2 ahmad.moshref amir.aharoni ap bashar.harfoush behdad brettw caddish-figures-03 cedric daniel dbates dermot_rourke ehsan eric fantasai.bugs farev88999 glenn hassan_deldar hosskhalifa ian ishida johnfeirick kilise_90 krinklemail mail mehmetgelisin michellerodri247 mitz mmaxfield mostafa.h munzirtaha mustafa.0x mustafamsy nickshanks noonon peter playmobil rik sabouhallawa seikwon.kim shagarah shokeenali simon.fraser siqinbilige webkit-bug-importer webkitbugzilla zalan oldest_to_newest 26175 0 webkit-bugs 2005-12-19 04:47:00 -0800 See the attached html document. The runs should look the same, but with different colorings as they do in IE for Windows. 26176 1 5149 webkit-bugs 2005-12-19 04:47:44 -0800 Created attachment 5149 Arabic Style Shaping test. 68963 2 ap 2008-01-31 13:11:48 -0800 *** Bug 17116 has been marked as a duplicate of this bug. *** 68994 3 mitz 2008-01-31 17:20:30 -0800 <rdar://problem/5718885> 69011 4 18841 ap 2008-01-31 23:21:37 -0800 Created attachment 18841 test from bug 17116 The original tests pass in Firefox 3 beta, but some of these do not. 104836 5 playmobil 2009-01-07 20:13:11 -0800 Filed in Chrome as http://code.google.com/p/chromium/issues/detail?id=6122 373427 6 eric 2011-03-25 03:19:37 -0700 *** Bug 47213 has been marked as a duplicate of this bug. *** 412455 7 glenn 2011-05-30 22:45:12 -0700 If nobody is actively working on this, I'm willing to take a pass at a patch. 412471 8 playmobil 2011-05-30 23:46:02 -0700 Go for it! 415379 9 glenn 2011-06-03 20:57:45 -0700 Initial investigation shows that BidiResolver::createBidiRunsForLine is breaking runs at a display:inline element boundary, e.g., span, even if the eventual embedding levels on both side of the boundary are the same. This causes RenderBlock::createLineBoxesFromBidiRuns to create distinct inline boxes across this boundary, preventing eventual complex text shaping from applying shaping context across the boundary. 416166 10 eric 2011-06-06 17:35:13 -0700 Yes. LineBoxes have a pointer back to their renderer and do not span renderers. 424547 11 ap 2011-06-21 10:44:12 -0700 *** Bug 63038 has been marked as a duplicate of this bug. *** 509383 12 munzirtaha 2011-11-26 12:43:52 -0800 Hi, I just encountered this bug while I am loading a page using QWebView *view = new QWebView(); view->load(QUrl("test.html")); while the test.html contains <!DOCTYPE HTML> <html> <head> <meta charset=utf8> <style type="text/css"> p:first-letter { color: red; } </style> </head> <body> The two arabic letters should apear like عر but they really show as <p>عر</p> and <div><span>ع</span>ر</div> </body> </html> Any update on this? 509389 13 glenn 2011-11-26 13:55:20 -0800 (In reply to comment #12) > Any update on this? Not yet. 597365 14 dermot_rourke 2012-04-06 08:12:19 -0700 I was wondering if there's been any progress made on this issue? I've come accross a number of Arabic Language Learning websites that rely on the ability to highlight specific letters within a word for teaching purposes. For example: http://transliteration.org/quran/WebSite_CD/HighlightSample/Fram3.htm http://arabiccomplete.com/modules_colloquial_msa/possessive_suffix_1.htm http://www.dalilusa.com/arabic_course/exercise02.asp Thanks. 597404 15 glenn 2012-04-06 09:20:06 -0700 (In reply to comment #14) > I was wondering if there's been any progress made on this issue? I'm trying to get this back on my priority list, and there is a good chance I will do so in the next four weeks. 619497 16 dermot_rourke 2012-05-09 08:16:44 -0700 Just checking in to see if any progress has been made? A colleague of mine found a temporary work-around that may be useful to some developers in some scenarios - using the zero-width-joiner (&zwj;/‍) will force the letters to join (or, at least, appear joined). Of course, it's not ideal as you'll need to test for the browser and insert them on page load (or something along those lines). Also, it does not work for every situation - in the example in comment #12 above, the css selector fails. The code would look something like: <!DOCTYPE HTML> <html> <head> <meta charset=utf8> <style type="text/css"> p:first-letter { color: red; } p, div { font-family: times new roman; font-size: x-large; } </style> </head> <body> The two arabic letters should appear like عر but they really show as <p>&zwj;عر</p> and <div><span>ع&zwj;</span>ر</div> </body> </html> 675570 17 playmobil 2012-07-23 02:44:57 -0700 *** Bug 91975 has been marked as a duplicate of this bug. *** 675574 18 153763 playmobil 2012-07-23 02:50:40 -0700 Created attachment 153763 Testcase from bug 91975 Amir Aharoni's simple testcase from bug 91975 675575 19 playmobil 2012-07-23 02:52:52 -0700 Also tracked as http://crbug.com/138434 (http://crbug.com/6122 tracks the color issue) 720338 20 glenn 2012-09-13 23:09:07 -0700 this is (finally) on the top of my queue, so assigning to myself 752715 21 eric 2012-10-27 00:27:53 -0700 *** Bug 77790 has been marked as a duplicate of this bug. *** 752716 22 eric 2012-10-27 00:29:06 -0700 If you're still working on this Glenn, we should chat. 780703 23 noonon 2012-12-01 02:50:34 -0800 @Dermot Rourke, to fix this entirely, use TWO zero-width-joiners e.g. <p>عرب‍<span style="color: Red;">‍ي</span></p> e.g. <!DOCTYPE HTML> <html> <head> <meta charset=utf8> <style type="text/css"> body{font-size:40px;} .test{ color:red; font-weight:bolder; } </style> </head> <body> The two arabic letters should apear like عربي but they really show as the following in webkit(chrome,safari) <p>عرب<span>ي</span></p> solution: <p>عرب‍<span style="color: Red;">‍ي</span></p> </body> </html> demo: http://jsfiddle.net/noonon/esz4S/2/ 785950 24 abuzakham 2012-12-07 10:05:32 -0800 Hi, any update on this issue ? My case running Version 23.0.1271.95, i tried to work around the issue with the zero-width-joiner or double zero-width-joiner, still the Arabic letter shapes appears broken. Coloring part of Arabic words is a common practice used in Arabic learning sites, currently we recommend our users to switch to other browsers as (Firefox, IE ) in order to render pages correctly. 786431 25 noonon 2012-12-07 22:34:28 -0800 @Hamzeh if you can paste some code samples? I might be of some help 786441 26 glenn 2012-12-07 23:17:23 -0800 it is not necessary to provide any more examples; the problem is well understood; however, the solution requires working around certain design limitations that aren't straightforward 786474 27 abuzakham 2012-12-08 03:16:57 -0800 (In reply to comment #25) > @Hamzeh > if you can paste some code samples? > I might be of some help Nasser, I've followed the demo link provided by you and the same Arabic shape problem existed with my chrome version. trying to color part of the Arabic word fails on chrome regardless of using zero-width-joiner or not. while Firefox and IE rendering engines are working just fine with or without zero-width-joiner. this defect is vital for learning sites, since coloring part of the word is widely used to identify prefixes, suffixes, and certain language characteristics. I hope that someone from webkit to give it priority, it's a very important for languages such as Arabic, Persian, and Urdo. 787427 28 glenn 2012-12-10 09:53:00 -0800 *** Bug 104530 has been marked as a duplicate of this bug. *** 974550 29 bashar.harfoush 2014-01-31 18:28:18 -0800 Are there any updates on this bug? 976013 30 mmaxfield 2014-02-03 14:27:24 -0800 Not as of yet. 978778 31 bashar.harfoush 2014-02-10 00:51:31 -0800 Is there a way we can give this bug a higher priority(possibly Major)? The ability to style individual characters is very important for educational and word-game apps but it's currently broken for all sites that use complex script. 978860 32 glenn 2014-02-10 07:06:08 -0800 (In reply to comment #31) > Is there a way we can give this bug a higher priority(possibly Major)? The ability to style individual characters is very important for educational and word-game apps but it's currently broken for all sites that use complex script. Raising the priority on the bug won't make it get fixed faster if there is no body willing to take on the work, which is not going to be trivial. The fundamental problem is that the character to glyph shaping process in WK doesn't make use of any context that crosses an element boundary. Fixing this will most likely introduce a performance regression in the slow text path, which is already slow. There are at least two temporary work arounds for this that authors may use. One is document in comment #16. The other is to specifically code for presentation forms (U+FB50-FDFF, FE70-FEFC). This isn't ideal, but it works. 978985 33 bashar.harfoush 2014-02-10 11:46:37 -0800 (In reply to comment #32) > Raising the priority on the bug won't make it get fixed faster if there is no body willing to take on the work, which is not going to be trivial. The fundamental problem is that the character to glyph shaping process in WK doesn't make use of any context that crosses an element boundary. Fixing this will most likely introduce a performance regression in the slow text path, which is already slow. > > There are at least two temporary work arounds for this that authors may use. One is document in comment #16. The other is to specifically code for presentation forms (U+FB50-FDFF, FE70-FEFC). This isn't ideal, but it works. The suggested fix in comment #16 does not produce the correct rendering. Observe the difference in rendering the last character in http://jsfiddle.net/noonon/esz4S/2/ between Chrome and Firefox. For your other suggestion, I think shifting the responsibility of producing the correct glyph to user scripts will add an unnecessary complication. IMO, this should be transparent to the web developer. Any web developer who currently wants to style individual complex characters in Webkit is stuck. I was hoping giving the bug a higher priority would make it more visible and more likely to be picked up and fixed. 978986 34 behdad 2014-02-10 11:49:21 -0800 (In reply to comment #33) > (In reply to comment #32) > > Raising the priority on the bug won't make it get fixed faster if there is no body willing to take on the work, which is not going to be trivial. The fundamental problem is that the character to glyph shaping process in WK doesn't make use of any context that crosses an element boundary. Fixing this will most likely introduce a performance regression in the slow text path, which is already slow. > > > > There are at least two temporary work arounds for this that authors may use. One is document in comment #16. The other is to specifically code for presentation forms (U+FB50-FDFF, FE70-FEFC). This isn't ideal, but it works. > > The suggested fix in comment #16 does not produce the correct rendering. Observe the difference in rendering the last character in http://jsfiddle.net/noonon/esz4S/2/ between Chrome and Firefox. That was fixed very recently: https://code.google.com/p/chromium/issues/detail?id=311372 > For your other suggestion, I think shifting the responsibility of producing the correct glyph to user scripts will add an unnecessary complication. IMO, this should be transparent to the web developer. True. We understand that. > Any web developer who currently wants to style individual complex characters in Webkit is stuck. I was hoping giving the bug a higher priority would make it more visible and more likely to be picked up and fixed. 978998 35 bashar.harfoush 2014-02-10 12:18:43 -0800 (In reply to comment #34) > > The suggested fix in comment #16 does not produce the correct rendering. Observe the difference in rendering the last character in http://jsfiddle.net/noonon/esz4S/2/ between Chrome and Firefox. > > That was fixed very recently: Thank you! I'm looking forward to trying it. I hope you guys can still make a comprehensive fix for this bug so that we wouldn't even need to use zero-width joiners to display individually styled characters. 1025996 36 mmaxfield 2014-07-31 10:06:59 -0700 *** Bug 135416 has been marked as a duplicate of this bug. *** 1069866 37 ah.abuali2 2015-02-17 09:49:31 -0800 How to solve this problem by javasript in rich text editor to prevent arabic characters from sperated when put the cursor on any word to edit this bug is only in webkit browsers, the solution is to add ‍ before and after span element ex: م‍<span></span>‍ن, please any one have the function javascript to solve it, please advice me. 1109201 38 mmaxfield 2015-07-13 13:51:01 -0700 *** Bug 146907 has been marked as a duplicate of this bug. *** 1141098 39 kilise_90 2015-11-11 06:59:01 -0800 Status on this? 1141131 40 mmaxfield 2015-11-11 09:42:34 -0800 (In reply to comment #39) > Status on this? No update. 1315134 41 mmaxfield 2017-06-02 11:39:01 -0700 *** Bug 172855 has been marked as a duplicate of this bug. *** 1412054 42 krinklemail 2018-04-05 09:25:05 -0700 This issue affects various Wikipedia content services. Downstream: https://phabricator.wikimedia.org/T188127 1525603 44 shagarah 2019-04-09 04:23:34 -0700 You can take a look at Madinah Arabic various lessons to see the difference between Chrome and FireFox Arabic rendering: https://www.madinaharabic.com/Arabic_Language_Course/Lessons/ FireFox does display Arabic correctly. An example: https://www.madinaharabic.com/Arabic_Language_Course/Lessons/L057_006.html Look at the difference between the two in the first table (Tashkeel like /đammah/) and the last two ones (colored middle letters). 1575322 45 mmaxfield 2019-09-30 14:05:53 -0700 https://gankra.github.io/blah/text-hates-you/#style-can-change-mid-ligature 1634497 46 mustafa.0x 2020-03-26 12:45:41 -0700 This issue has been resolved in Chrome (crbug.com/837574) with the new layout engine (LayoutNG). Safari is now an outlier in this behavior (i.e., Firefox, Chrome, and Edge support shaping characters across style changes). 1634976 47 shagarah 2020-03-27 13:38:13 -0700 I can see now that the issue of multiple colors in the same word has been resolved. Thank you! I can still see however the issue of some letters being shifted up: https://www.madinaharabic.com/arabic-language-course/lessons/L025_001.html Look at الْمُعْرَبُ وَالْمَبْنِيُّ in chrome and firefox. Firefox is still displaying it the correct way (font?). I'm using Mac Book Pro Catalina, latest. 1710935 48 5149 shokeenali 2020-11-30 22:16:27 -0800 Comment on attachment 5149 Arabic Style Shaping test. >ï»¿<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > ><html> ><head> > <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ><title>Arabic Shaping Test</title> ></head> ><body> ><p style="font-size:48px"><FONT color=#ffa500>Ø§</FONT><FONT color=#ff1493>Ù</FONT><FONT color=#800080>Ø¹</FONT><FONT color=#0000ff>Ø±</FONT><FONT color=#800080>Ø¨</FONT><FONT color=#008000>Ù</FONT><FONT color=#a52a2a>Ø©</FONT> and Ø§ÙØ¹Ø±Ø¨ÙØ© should look the same (other than the colors)</p> ></body> ></html> 1739087 49 mmaxfield 2021-03-12 18:21:06 -0800 *** Bug 222734 has been marked as a duplicate of this bug. *** 1783413 50 mmaxfield 2021-08-11 00:29:05 -0700 *** Bug 215643 has been marked as a duplicate of this bug. *** 1808704 54 mmaxfield 2021-10-25 18:27:16 -0700 *** Bug 231668 has been marked as a duplicate of this bug. *** 1879739 55 ishida 2022-07-01 06:33:08 -0700 Open Bug 1777686 Opened 19 minutes ago Inline elements break cursive shaping Product: Core ▾ Component: Layout: Text and Fonts ▾ Version: Firefox 102 Type: defect Priority: Not set Severity: -- Status: UNCONFIRMED Votes: 0 Richard Ishida Reporter Description • 19 minutes ago User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0 Steps to reproduce: I'd like to take this bug report back a step, and then expand it to encompass a wider set of issues – all related to the original title of the bug report. The backstep has to do with WebKit splitting cursive text (in Arabic, Adlam, N'Ko, Mongolian, and other cursive scripts) any time you simply insert inline markup (such as a span) around some of the characters within a word (with no styling changes). That, of course, makes it fundamentally difficult to apply style changes, too. The expansion has to do with the fact that since this bug was first raised, the CSS WG has looked at what kinds of styling should and shouldn't break cursiveness, extending the scope well beyond simple colour assignments. See https://www.w3.org/TR/css-text-3/#boundary-shaping. With the above in mind, i'm going to paste here the text of one of the language enablement gap reports produced by the W3C, which points to various tests and results. It also points to the relevant CSS discussion. --- This issue is applicable to text in all cursive scripts. When elements surround part of a cursive run of text, and apply styling, the results often break the cursive joins. (See the results of trying to colour individual letters in the illustration below – as expected above, unsuccessful below.) https://user-images.githubusercontent.com/4839211/105509398-5cca3300-5cc5-11eb-93e3-9398a9959a74.png https://user-images.githubusercontent.com/4839211/73611430-b24f9080-45d9-11ea-8b96-8f75648c725e.png SPECS: After some discussion (https://github.com/w3c/csswg-drafts/issues/698), the CSS spec requires the following (see https://www.w3.org/TR/css-text-3/#boundary-shaping): 1. Markup alone around part of a joined up sequence must not disturb the joining behaviour. 2. Styling that doesn't affect the characters, such as text-decoration, must not break the joins. 3. Styling that does affect the shape of the characters should not break the joins, however the result is not well defined for complex glyph arrangements such as ligatures where the markup occurs between characters that make up the ligature. 4. Non-zero margins, padding, and borders, will break the join, as will isolation boundaries. TESTS & RESULTS: Interactive test, A span with a colour change for one letter in an Arabic word doesn't break the joining behaviour https://github.com/w3c/character_phrase_tests/issues/43 - Gecko: ✅ Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0 - Blink: ✅ Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36 - Webkit: ❌ Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15 I18n test suite, Cursive joining https://w3c.github.io/i18n-tests/results/css-text-shaping - Gecko: ✅❌ Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0 - Blink: ✅ ❌ Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36 - Webkit: ❌ Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15 Webkit breaks cursive joining as soon as markup appears around a character, and so obviously fails for any type of styling application, too. Gecko and Blink keep joins for styling that doesn't affect the shape of the characters (eg. text-decoration), and keeps it for colour changes, however Firefox fails for changes in font-weight, font-style, and font-size, as well as for markup such as em and b tags. (Gecko and Blink also only pass some of the tests for non-zero margin/padding/border and bdi isolation. Which expect the cursive joins to be broken.) Expected results: Please fix WebKit so that shaping is not broken by inline markup, and then ensure that appropriate style changes don't break the shaping either (which includes, but goes beyond colour changes). At a minimum, please produce the same results as Gecko and Blink engines. 1879740 56 ishida 2022-07-01 06:35:30 -0700 Apologies, some initial text in the previous comment was inadvertently copied from elsewhere. The actual comment should begin with "Steps to reproduce:". (If i missed how to delete a comment or edit it, please let me know.) 1925814 57 cedric 2023-01-16 07:13:19 -0800 Any update about this issue regarding ligation on HTML between spans? There is also the same issue on SVG text with tspan and/or textPath. It has been reported here: https://bugs.webkit.org/show_bug.cgi?id=78711 1938420 58 cedric 2023-03-03 00:20:50 -0800 I'm adding here a codePen to see the problem simply: https://codepen.io/nyroDev/full/NWLpEXL You can choose the font to see when the problems occurs. On Safari TP 146, I see problem with: - Caveat - Climate crisis - Lobster - Shantell Sans (not sure if it's a ligature problem here) - Roboto - Brush Script MS. 1962586 59 ap 2023-06-20 10:51:08 -0700 *** Bug 258300 has been marked as a duplicate of this bug. *** 1962609 60 mmaxfield 2023-06-20 12:05:33 -0700 I have some ideas for how to fix this at some point in the future. It’s a fairly significant architectural change, but IFC makes it easier. We should do: - bidi across the whole paragraph (which we already do) - shaping across the whole paragraph - line breaking across the whole paragraph Because bidi is already done this way in IFC we can use that as a model for the other two. 1968793 61 mustafamsy 2023-07-30 10:28:27 -0700 @Myles Any plan or timeline where this would be worked on? I have to tell you that the fix for this issue is really essential for our apps to work correctly. I am sure not only me who is affected by this but many developers as well. Please, prioritize it and initiate a plan to get it fix soon. Appreciate your understanding. 2144908 62 webkitbugzilla 2025-09-22 10:28:08 -0700 I'd be nice to bring Safari up to spec on this. Is there an ETA for this? In a couple of months this bug is old enough to buy beer. 2150330 63 zalan 2025-10-12 07:47:33 -0700 This is now (301354@main) fixed for complex text (see FontCascade::characterRangeCodePath for details). Most cases in this bug report where shaping affects legibility appear to be working correctly. Although shaping of "simple text" still fails, it should not impact readability in typical cases (e.g. latin extended range -> 'find' where 'f' and 'i' may form a ligature). 5149 2005-12-19 04:47:44 -0800 2005-12-19 04:47:44 -0800 Arabic Style Shaping test. arabicshaping.html text/html 515 webkit-bugs 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIiA+CjxodG1sPgo8aGVhZD4KIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04IiAvPgo8dGl0bGU+QXJhYmljIFNoYXBp bmcgVGVzdDwvdGl0bGU+CjwvaGVhZD4KPGJvZHk+CjxwIHN0eWxlPSJmb250LXNpemU6NDhweCI+ PEZPTlQgY29sb3I9I2ZmYTUwMD7YpzwvRk9OVD48Rk9OVCBjb2xvcj0jZmYxNDkzPtmEPC9GT05U PjxGT05UIGNvbG9yPSM4MDAwODA+2Lk8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDBmZj7YsTwvRk9O VD48Rk9OVCBjb2xvcj0jODAwMDgwPtioPC9GT05UPjxGT05UIGNvbG9yPSMwMDgwMDA+2Yo8L0ZP TlQ+PEZPTlQgY29sb3I9I2E1MmEyYT7YqTwvRk9OVD4gYW5kINin2YTYudix2KjZitipIHNob3Vs ZCBsb29rIHRoZSBzYW1lIChvdGhlciB0aGFuIHRoZSBjb2xvcnMpPC9wPgo8L2JvZHk+CjwvaHRt bD4= 18841 2008-01-31 23:21:37 -0800 2008-01-31 23:21:37 -0800 test from bug 17116 cluster.html text/html 1441 ap PGh0bWw+PGJvZHk+IA0KPEZPTlQgZmFjZT1BcmlhbCBzaXplPTQ+IA0KIA0KIA0KPFA+IFUrMDY0 NyBhbmQgVSswNjRBIDwvUD4gDQogDQogDQo8UD48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTEwIGNv bG9yPSMwMDgwMDA+JiN4NjQ3OyYjeDY0YTs8L0ZPTlQ+PC9QPiANCiANCjxQPlNhbWUgY2hhcnMg ZGlmZmVyZW50IGNvbG9yczo8L1A+IA0KIA0KPFA+PEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0xMD48 Rk9OVCBjb2xvcj0jZmYwMDAwPiYjeDY0Nzs8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwODAwMD4mI3g2 NGE7PC9GT05UPjwvRk9OVD48L1A+IA0KIA0KIA0KPFA+IndvcmxkIiBpbiBhcmFiaWMgc3RhcnRz IHdpdGggVSs2NEEgYW5kIFUrNjRGIC0gYSBzaW5nbGUgY2x1c3Rlci4gQ29sb3Igb2YgVSs2NEEg aXMgZXh0ZW5kZWQgdG8gdGhlIGVudGlyZSBjbHVzdGVyIGluIEludGVybmV0IEV4cGxvcmVyIChx dWl0ZSByZWFzb25hYmxlIGRlY2lzaW9uKS4gRmlyZWZveCAyLjAuMC4xMSBzZWVtcyBxdWl0ZSBj b25mdXNlZCB3aGlsZSBXZWJLaXQgY29uc2lkZXIgY29sb3IgY2hhbmdlIGFzIHZlcnkgaW1wb3J0 YW50IHNvIGl0IGJyZWFrcyBjb250ZXh0dWFsIHNoYXBpbmcgKGFzIGluIHRoZSBzYW1wbGUgYWJv dmUpPC9QPiANCiANCiANCjxQPjxGT05UIGZhY2U9VGFob21hIHNpemU9MTAgY29sb3I9IzAwODAw MD4mI3g2NGE7JiN4NjRmOyYjeDYzMzsmI3g2Mjc7JiN4NjQ4OyYjeDY1MDsmI3g2NGE7PC9GT05U PjwvUD4gDQogDQo8UD48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTEwPjxGT05UIGNvbG9yPSNmZjAw MDA+JiN4NjRhOzwvRk9OVD48Rk9OVCBjb2xvcj0jMDA4MDAwPiYjeDY0ZjsmI3g2MzM7JiN4NjI3 OyYjeDY0ODsmI3g2NTA7JiN4NjRhOzwvRk9OVD48L0ZPTlQ+PC9QPiANCiANCjxQPiBEaWZmZXJl bnQgY29sb3IgZm9yIGNvbWJpbmluZyBjaGFyYWN0ZXIgPC9QPiANCjxQPjxGT05UIGZhY2U9VGFo b21hIHNpemU9MTAgY29sb3I9I2ZmMDAwPkhlbGxvJiN4MzAzOyB3b3JsZDwvRk9OVD48L1A+IA0K PFA+PEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0xMD4gPEZPTlQgY29sb3I9I2ZmMDAwPkhlbGxvPC9G T05UPiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxGT05UIGNvbG9yPSMwMDgwMDA+ JiN4MzAzOzwvRk9OVD4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3JsZDwvUD4g DQogDQo8UD5UZXN0IGZvciB3b3JkIHdyYXA8L1A+IA0KPFA+PEZPTlQgZmFjZT1UYWhvbWEgc2l6 ZT0xMCBjb2xvcj0jMDA4MDAwPkhlbGxvICYjeDY0YTsmI3g2NGY7JiN4NjMzOyYjeDYyNzsmI3g2 NDg7JiN4NjUwOyYjeDY0YTsgcGxheSAmI3g2NDM7JiN4NjMxOyYjeDYyOTsgJiN4NjI3OyYjeDY0 NDsmI3g2NDI7JiN4NjJmOyYjeDY0NTs8L0ZPTlQ+PC9QPiANCiANCiANCiANCiANCjwvRk9OVD4g DQo8L2JvZHk+PC9odG1sPg== 153763 2012-07-23 02:50:40 -0700 2012-07-23 02:50:40 -0700 Testcase from bug 91975 arabic-joining-test.html text/html 331 playmobil PCFET0NUWVBFIGh0bWw+CjxodG1sIGRpcj0icnRsIiBsYW5nPSJhciI+CjxoZWFkPgo8bWV0YSBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYt OCIgPgo8dGl0bGU+QXJhYmljIHRlc3Q8L3RpdGxlPgo8L2hlYWQ+Cjxib2R5Pgo8cD5pbmNvcnJl Y3QgZGlzcGxheSwgd2l0aCBzcGFuIGluc2lkZSB0aGUgd29yZDog2Kg8c3Bhbj7Yp9mE2LnYsdio 2YrYqTwvc3Bhbj48L3A+CjxwPmNvcnJlY3QgZGlzcGxheSwgd2l0aG91dCBzcGFuIGluc2lkZSB0 aGUgd29yZDog2KjYp9mE2LnYsdio2YrYqTwvcD4KPC9ib2R5Pgo8L2h0bWw+Cg==