![]() ![]() Meanwhile, here’s a test with a strong left-to-right character inserted at the beginning:Įven in this case, Uniscribe still moves the number 21 to the far right end. The search bar simply forces left-to-right base direction while the address bar autodetects base direction. ![]() Thanks! So that was indeed a red herring. I could do it myself but I was worried I would miss some characters so I hand it over to you:) write( f" \n \n ")įor Hebrew, Arabic Subtitles you have to change persian_alpha_codepoints to your language The bad news is that we can’t really fix this in libass, short of reimplementing the whole bidirectional algorithm, which we currently delegate to FriBidi. It’s slightly surprising if it’s as old as Unicode 2, but again, going by the release dates, it seems plausible.) (We already know that Uniscribe’s bidi is frozen in time since before Unicode 6.3 at any rate, as it doesn’t match bracket pairs. Uniscribe apparently shipped with Internet Explorer 5 in March 1999. Unicode 3 was released in September 1999, and the first draft of the bidirectional algorithm that makes any attempt to move the number to the left (by adjusting rule N3) is dated February 1999. Looking at the release dates, it seems plausible that Uniscribe may be sticking to Unicode 2 semantics. Uniscribe’s behaviour here matches either Unicode 2, whose bidirectional algorithm lacked rule W7, or a misinterpretation of rule W7 whereby sos (or older sor) is distinguished from L and thus rule W7 isn’t applied at the start of the paragraph. If you know more, like the exact flavour and version of this subtitle-provider that would be great.Īlso, VSFilter's BiDi rendering is in some cases affected by which version of MS Windows it is being run on, so we also need to know which exact version of Windows you are using, including the servicepack or in case of Windows 10 the update level. Look in Aegisub's options at Advanced → Video → Subtitle-Provider to get a rough idea of what's rendering your subtitles. Aegisub can use all sorts of different VSFilters and in fact also libass, so labeling the result “Aegisub” doesn't tell us much. Though not authorative on this matter, interestingly recent Firefox (using a differnt version of harfbuzz and fribidi) and nano (nvm, only the number ordering is the same, the rest is different) agree with the libass rendering, but wxSCT and presumably native GTK3.24.5 elements (eg in Aegisub and pluma) agree with your “Aegisub” result. I get the same result matching you “libass” rendering, regardless of PR#443 (with fribidi 1.0.5-3.1 deb10u1 and harfbuzz 2.3.1).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |