122937 - Improve rendering of ASCII control codes

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[Lars Brinkhoff]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.5) Gecko/20011024
BuildID:    [debian]
Mozilla 0.9.5

Viewing an ASCII (text/plain) document with backspace,
carriage return, and form feed control codes does not
work correctly.

I would like to contribute the work to solve this problem.


Reproducible: Always
Steps to Reproduce:
View http://lars.nocrew.org/overstrike.txt


Actual Results:  ASCII backspace, carriage return, and form feed control codes
were displayed as boxes.


Expected Results:  ASCII backspace, carriage return, and form feed control codes
should be interpreted, preferrably in a way that enables bold
and underlined text.

Comment 1

[Christopher Hoess (gone)]

I think there's a bug out on not displaying the control codes as boxes, but whatis the rationale for interpreting them as underline/overstrike controls?  FWIW, I think at least in plaintext mail, if not in all plaintext documents, *this*appears as bold, and I think _this_ is underlined.

Comment 2

[Dan Tobias]

It's an interesting question what a standards-compliant browser should do with
control characters in ASCII text.  In HTML, such control characters as
backspaces aren't supposed to be used, but in plain ASCII they do have meanings
as defined in the ASCII standards, and in the old days were frequently used for
special effects (even including some fancy animations done with combinations of
carriage returns and backspaces).  I remember a lot of fancy "plan files"
viewable with the finger command on university computers in the '80s.  But if
Mozilla implements control codes, will this include CTRL-G, the BEL character,
which is supposed to cause a beep sound?  This could get annoying... and that
character *was* a favorite of teenage BBS sysops at one point...

What is the formfeed character supposed to do in a browser?  I remember some
terminal programs that cleared the screen when it was encountered, which was a
pain when you were trying to read the text but couldn't before it blanked out. 
(Though with 300 baud modems you could read faster than the text could download
anyway...)

Then there's all the exotic control characters like SOH (Start of Header) and US
(Unit Separator)... hardly anyone actually uses those for the original intended
purposes...

If the text file is in a Unicode format (UTF-8, UTF-16, etc.), you've got some
more exotic characters available, like various new sorts of line and paragraph
breaks, half-width spaces, zero-width spaces, etc...

Comment 3

[Lars Brinkhoff]

The rationale is that many (though certainly not the majority) existing
ASCII documents use these control codes for bold and underline.  Why not
interpret them in a somewhat intelligent way?

Comment 4

[rubydoo123]

per Kevin, this sounds more like an HTML parser implementation not a layout 
issue

Comment 5

[Lars Brinkhoff]

I got the suggestion to change
mozilla/netwerk/streamconv/converters/nsTXTToHTMLConv.cpp
and
mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp
but my changes doesn't seem to be picked up in the recompiled mozilla.

Any suggestions?

Comment 6

[Christopher Hoess (gone)]

I think this belongs to BenB, not parser.  Punting.

Comment 7

[Ben Bucksch (:BenB)]

Use mozTXTToHTMLConv.cpp only, nsTXTToHTMLConv.cpp is other code. I don't know,
why your changes were not picked up. Recompile all of netwerk/.

It's not DOM->TXT, but TXT->HTML. -> netwerk, nobody. Narrowing summary.

Comment 8

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"