123326 - Text decoration and accent letter

Status: VERIFIED DUPLICATE of bug 106028

(MailNews Core :: Internationalization, enhancement)

Description

[j.queinnec]

In Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8) Gecko/20020202

Text decoration (ie *bold* or /italic/) don't work if the word begin or end with
an accent letter (for example éèàçù ...).

*test* or *testés* give the world in bold
but *àtester* or *testé* don't "boldize" (this word mustn't exist I suppose) the
words

Comment 1

[Sören 'Chucker' Kuklau (gone)]

Confirmed on 2002-02-03-18, Win32, MathML/SVG, using Windows XP Pro (OS => All?).

Comment 2

[Boris Zbarsky [:bzbarsky]]

WinNT and WinXP are not different enough to warrant an ALL, but setting status
to NEW.  :)

Comment 3

[ji]

Do you mean the bold/italic display is not working in mail body?
I don't see this problem. Could you please include reproduce steps or attach a
testing mail to this report? Thanks.

Comment 4

[marina]

i am not able to reproduce this bug neither on Win2K, NT  nor on Mac OSX. I
tried Composer/ Mail composer, in all cases when the string start or ends with
accented chars it is bold or italic if we chose so.

Comment 5

[Sören 'Chucker' Kuklau (gone)]

My Mac OS and Linux setups are both broken, so I can't test them at the moment.
Sorry.

Comment 6

[Sören 'Chucker' Kuklau (gone)]

Attachment: Testcase

ji: Yes, I figure that's what he means, because that's what's in fact not
working for me either.

Build ID: 2002-02-03-18, Win32, SVG/MathML
Platform: x86
OS:	  WinXP Pro
Charset:  ISO-8859-1 (maybe that's the problem)

I've attached a sample mail as a testcase. Note that Mozilla might try to open
it through the browser which causes the text decorations not to be shown at all
(e.g. only ASCII). I actually haven't found any way to open it with Mozilla
_Mail_.

Comment 7

[j.queinnec]

The proposed attachment is correct.

For test send to you a e-mail with this text :

1 *abcdef*
2 /abcdef/

3 *ért*
4 *azèert*
5 *qsdoè*

6 /àaazer/
7 /azeçezr/
8 /azeazù/

I use this option :
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

The line 1, 2, 4 and 7 are in bold or italic not the line 3, 5, 6 and 8.

This is of course for pure text e-mail not HTML mail.

Comment 8

[ji]

Did you mean the bold/italic display for quoted plain text messages? (For  new
plain text mail compose, there is no way to compose/display it in style) That
can be set from Edit | Preferences | Mail&Newsgroups | Message Display window,
and I don't have problems with that. After I select bold or italic for the
option, I can see the quoted message be displayed in style. 

Comment 9

[ji]

Attachment: A screenshot on 02/04 build.

Comment 10

[j.queinnec]

Attachment: screenshoot in 2002020512 build

Comment 11

[ji]

[e-mail], question again: how did you compose a plain text mail
with some chars in bold/italic? Could you describe the steps? As I mentioned in
comments #8, for plain text mail, we can only display quoted mail in bold/italic
in reply messages.
And some chars in the sample strings (comments #7) are actually iso-8859-2
chars, like è and à, you should have a charset alert when sending out messages
containing those chars with mail charset pointing to iso-8859-1 or iso-8859-15.
If you ignore the alert and send it out anyway, it can't be displayed correctly
after received.

Comment 12

[j.queinnec]

I don't compose an email with bold or italic caracter in plain text.
I compose email with word beetween "*" ou beetwenn "/". In this case, when you
read this email (in the sent box for example), the word beetween "*" must appair
in bold and the word beetween "/" must appair in italic.
This feature exist in most of unix mailreader.

I use iso-8859-15 charset and the caracters I use are legal in this charset.

The bug is that if I use accent letter like ιθηΰ legal in iso-8859-15 in beging
or end of the word, it don't appair in bold ou italic.

Comment 13

[ji]

 So here * or / has special meanings. It means the string between should appear
in bold or italic. Thanks for the explanation.

Comment 14

[Sören 'Chucker' Kuklau (gone)]

Attachment: Screenshot of proper behaviour

How it's supposed to work like ( for [e-mail] )

Comment 15

[Sören 'Chucker' Kuklau (gone)]

On the right of the image, you see a compose window where I typed

*bold*
_underline_
/italic/

On the left of it, you can see the results: in all cases, the special characters
remain, but text decorations are added.

This bug is about Mozilla not handling this feature correctly with accent
letters, as http://bugzilla.mozilla.org/attachment.cgi?id=68118&action=view shows.

Comment 16

[nhottanscp]

Cc to ducarroz, putterman, is this a new feature? I don't see it in NS6.2.

Comment 17

[Jean-Francois Ducarroz]

no, but I think there is a pref for it somewhere. If I remember right, BenB
wrote that!

Comment 18

[nhottanscp]

Cc to Ben, is this yours?

Comment 19

[Ben Bucksch (:BenB)]

Yes, that's the TXT->HTML code (mozTXTToHTMLConv) I wrote.

The converter works as specified, see
<http://www.bucksch.com/1/projects/mozilla/16507/>, headings "Goals" and
"Structured phrases recognition". Relevant quotes:

"Failures should be minimized. A wrong recognition is a failure, not recognizing
a structure/formatting is not seen as failure."
"In general, if "delimiter plainTextTag alpha anyContent alpha plainTextTag
delimiter" is found, htmlTag is inserted as following..."

The exact meaning of "alpha" is defined by nsCRT::IsAsciiAlpha().

Maybe you want to modify that function or close this as WONTFIX.

Comment 20

[Ben Bucksch (:BenB)]

BTW: *Shut up!* is not made bold either, for the same reason.

Comment 21

[ji]

What preference is used for this feature?

Comment 22

[Ben Bucksch (:BenB)]

$grep struct mailnews.js 
pref("mail.display_struct", true);  // TXT->HTML in viewer; ditto
pref("mail.send_struct", false);   // HTML->HTML during Send; ditto

Comment 23

[nhottanscp]

Reassign to Ben.

Comment 24

[Ben Bucksch (:BenB)]

WONTFIX.

Comment 25

[Ben Bucksch (:BenB)]

Dumbass, Ben. It's nsCRT::Is*Ascii*Alpha(). Of course, that doesn't cover i18n
chars.

nhotta, is there any equiv function, which I should use to decide, if it's an
alpha (or whitespace, BTW), and which works internationally?

Comment 26

[Arthur]

That's a dupe of bug 106028. Ben, in which direction do want it to be resolved
as duplicate?

Comment 27

[Boris 'pi' Piwinger]

I'll dupe it on the older one. Further, I don't think, this is an enhancement.
The other bug gets this better.

pi

*** This bug has been marked as a duplicate of 106028 ***

Comment 28

[Thomas D. (:thomas8)]

Duplicate bugs no longer need assignee, I suppose.

Comment 29

[Ben Bucksch (:BenB)]

v