From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020111 BuildID: 20020211108 When editing or reading Email that contains mixed Hebrew/roman text, there is no way to set the directionality of the window, making composing plain text messages with mixed Hebrew english text or reading such messages very difficult if not impossible Reproducible: Always Steps to Reproduce: 1. start a new email messege 2. try to compose mixed text. esp. things that have () or lists (even plain text) Actual Results: notice that there is no way to set the window as RTL to compose the text proprly OE has an option to change the directionality of a message locally. something similar would be fine
Can't set it for HTMl emai either. Should i open a separate bug for that (since it affects sending and not just local viewing)?
Changing platform/OS to ALL/ALL. I think that between this bug and bug 96057 and bug 98160 we have covered all the bases, and there is no need for another bug for HTML mail. On the other hand, HTML mail is a more serious case than normal HTML composition, because there doesn't seem to be a way to workaround by editing the HTML source directly, unless I am missing it.
*** Bug 120509 has been marked as a duplicate of this bug. ***
Re: bug 98160 - it is a windows only bug (mac does not have that behavier at all). Any progress going to be done on this bug here, which was originaly filed for the mac? It is a real pain to compose plain text email properly on the mac, which kind of defeates the whole thing...
ok, until this bug is fixed, there is a workaround published by Mooffie, which can be fund at: http://www.typo.co.il/~mooffie/mozilla/hebmailpack.html (the server is not stable so you might need to try a few times before you can get thruh)
what's the differece between this bug and bug 96057?
This bug is about composing plain text, and bug 96057 is about composing in HTML format.
Shoshannah Forbes: > "ok, until this bug is fixed, there is a workaround published by Mooffie" Since this link is now dead, could you please post this workaround here? Thanks, Prog.
Well, I don't know about Mooffie's workaround, but Ilya Konstantinov's suggestion (in Bug 96057) seem to do the trick here as well: Format-> Page Colors and Background-> Advanced Edit-> Attribute=Dir;Value=RTL Prog.
> Format-> Page Colors and Background-> Advanced Edit-> Attribute=Dir;Value=RTL 1) this does not work with plain text email 2) These menus are not avalible when viewing a message- only when composing
It seems like there's another bug that hinders the use of my workaround: If the body of the message only includes plain text, Mozilla defaults to Content-Type: text/plain, instead of Content-Type: text/html - regardless of the settings in the Send Format prefs. Is this a known issue? should I open a new bug? this problem appears in both Mozilla 1.2.1 for Windows and 1.3a for BeOS. BTW, one can bypass this bug by using some HTML formatting *within* the body of the message (setting a single white space as boldface is sufficient). Prog.
The bug that I described in comment #11 was recently fixed by Scott MacGregor. More details in Bug 228720 ("Don't down-convert message to plain text if dir attribute is set"). This makes Moofie's XPI (see comment #5) a much more effective solution, it's a shame that only hardcore Mozilla enthusiasts know about the existence of this addon. Is there any opposition to including it by default in Mozilla? Prog.
Since mooffies's site seems unstable I downloaded mooffie's fix. So if anyone want it. send an email to adinaronson at hotmail.com
Created attachment 139888 [details] Mooffie's xpi fix unzip the html page and xpi to a folder. Open the webpage and click the link to install the xpi patch.
Can anyone point out why Moofie's XPI, despite containing an 'overlay' for composition as well as for viewing, only works for viewing messages, not for composing them? I mean, when I right-click the content-frame in the composer window and select 'RTL body', nothing happens. What's up with that?
(In reply to comment #15) > Can anyone point out why Moofie's XPI, despite containing an 'overlay' for > composition as well as for viewing, only works for viewing messages, not for > composing them? It works very well for both. > I mean, when I right-click the content-frame in the composer > window and select 'RTL body', nothing happens. What's up with that? This is probably just an isolated issue with your setup, but instead of spamming bugzilla, let's continue this discussion in mozilla.org.il forum. Prog.
Created attachment 141324 [details] Alternative hebmailpack To solve my problem, I replaced the 'dirAlignComposer' function code (see inside the zip; note you have multiple unzipping to do before you actually get to any sources...) with alternative code; it now works for me. I also added a submenu to the view menu for the composer window, same as for the messenger main window, with the directionality control. TODO list (well, my opinion of what a TODO list should be): 1. this needs a toolbar button, not just a menu setting 2. the visibility of these controls needs to be controlled by a "show directionality controls" option in Edit|Preference|Mail&Newsgroups|Composition (this would make the fix more attractive as a checkin into the trunk code) 3. the submenu should show a checkmark for the current directionality 4. how about installation of the XPI into a user's profile rather than the mozilla program directory?
*** Bug 245551 has been marked as a duplicate of this bug. ***
More items for the TODO list: 5. Need to improve the direction guessing policy, which is currently not at all perfect. 6. Need to apply the direction guessing policy for composition of 'reply' messages, that is, if a message is displayed RTL and I press 'reply' or 'reply all' , the new message's initial direction should be set to RTL.
(In reply to comment #17) > 2. the visibility of these controls needs to be controlled by a "show > directionality controls" option in Edit|Preference|Mail&Newsgroups|Composition > (this would make the fix more attractive as a checkin into the trunk code) actually, IMO it should go to composer|toolbars prefs panel. > 4. how about installation of the XPI into a user's profile rather than the > mozilla program directory? that's a good thing for every extension. however, things which are only relevant for an extension shouldn't be discussed here, IMHO.
Over time I've noticed most failures of Moofie's auto-detection are in cases where latin documents use accented letters within a word. The algorithm should decide whether the encoding is Hebrew based on words which have 0xE0-and-higher character values in all characters of the word, rather than based on single characters with no regard of context (e.g. single 0xE0-and-higher character within a mostly below-0xE0 word). This would reduce the false positives at practically no cost of false negatives. (0xE0 is where Hebrew letters start in windows codepage 1255)
Ok, the 0xE0 is meaningless, apparently moofie checks for Hebrew by the unicode values, which means after MailNews chooses the encoding. So the false positive LTR alignment can be fixed by in the extension, but not the wrong selection of the encoding (I thought the extension also reset the encoding, I was wrong).
Created attachment 154019 [details] hebmailpack 1.0.2 Implemented the "look for words instead of characters" logic I suggested, plus changed the installation script so as to be able to install to the profile directory. Note that if the extension has already been installed to the app directory, it will be installed there, so remove it. Version bumped to 1.0.2.
Created attachment 154082 [details] hebmailpack 1.2.1 Well, it seems Moofie himself has made some modifications since 1.0.0 in his own typo.co.il webpage (I thought he was inactive). Anyway, this latest attachment incroporates my changes into his most recent version. This time no zip, just the xpi. I promise not spam this bug any more until I sort things out with him (or is it her?). Eyal PS - this now has he-IL support, plus context menu for viewed as well as composed messages
*** Bug 231277 has been marked as a duplicate of this bug. ***
*** Bug 234894 has been marked as a duplicate of this bug. ***
The BiDi UI project now offers an extension which is a further development of Moofie's fix, above, with plenty of new functionality and other goodies. See: http://bidiui.mozdev.org/mail/
The functionality provided by BiDi Browser UI extension was recently merged into FF 1.0 and SM 1.8.x. Is there anything that prevents the Mail extension from sharing the same happy ending? Prog.
*** Bug 342112 has been marked as a duplicate of this bug. ***
Is there any work done on this in the context of Thunderbird 3?
Not any that I'm aware of.
Comment on attachment 139888 [details] Mooffie's xpi fix Obsoleting here to avoid confusion. And I'll use this opportunity to mention that I'm always willing to collaborate to integrate some of this functionality into the Mozilla codebase...
(In reply to comment #33) > I'll use this opportunity to mention that I'm always willing to collaborate > to integrate some of this functionality into the Mozilla codebase... Which parts do you suggest to omit? I'm not sure if we need the directionality auto-detection now-days, but a RTL/LTR buttons in Composer and a 'Switch page detection' command should be enough.
Well, it's not about omissions, but rather about different implementations. I'll remind everyone of our discussion here: https://www.mozdev.org/bugs/show_bug.cgi?id=20370 As for directionality auto-detection - it's a must. So much so that I've made it a different, default mode to all-LTR and all-RTL, and users rarely bother to use any of the latter two.
Paragraph auto detection is complicated algorithm, and no other software do this. Currently more users are aware of directionality in mail messages than few years ago, and even web mail sites such as gmail do include those control buttons. While it could be a nice feature, please don't forget that most Thunderbird users won't ever need it. I'd suggest adding the basic functionality to the core, and keeping all the nice features in an optional add-on.
Paragraph auto-detection will come in form of bug 548206.
(In reply to comment #37) > Paragraph auto-detection will come in form of bug 548206. What's the status of that code? Is it going to land in the near future? If so, maybe we should make it blocking this bug.
(In reply to comment #38) > (In reply to comment #37) > > Paragraph auto-detection will come in form of bug 548206. > What's the status of that code? Is it going to land in the near future? If so, > maybe we should make it blocking this bug. We're still working on the specification in the W3C HTML bidi group. It should then be submitted to the WHATWG group for submission. I don't think that anyone has started to work on the implementation yet.
I am not sure that I understand all the comments. This bug was opened 10 years ago. Working code exists in the form of the BiDiUi extension. This extension breaks when updating Thunderbird between version numbers, requiring Arabic, Hebrew, and Persian Thunderbird users to delay upgrading to the latest stable Thunderbird. What is the argument against including the BidiUi code in core Thunderbird? Is it just "nobody's done it yet"? Can I get SVN access to do it?