120889 - Saving HTML document as plain text produces rather awkward, messy result

Status: VERIFIED DUPLICATE of bug 135239

(Core :: DOM: Serializers, enhancement)

Description

[Dan Tobias]

It's nice that "Save As Plain Text" has been added as an option on the file
menu.  A couple of bugs in this (that the Saving dialog doesn't go away, and
that the default extension stays at .html instead of .txt) have already been
noted.  However, nobody has yet commented on the general formatting of the
resulting plain text document, so that's what I'm doing here.  I've tested
Mozilla vs. Netscape 4 and MSIE at saving a couple of different Web pages as
plain text, and will be uploading the results as attachments with my comments. 
Basically, I found the Mozilla output to be difficult to read or use due to its
overly messy and "noisy" format, coming from its trying to do too much at once
-- the authors seem to have been trying to capture the boldfacing, italics, and
hyperlinks of the HTML in the plain text version, with fairly awkward results.
However, Mozilla doesn't try to duplicate the table layout.

In contrast, NS 4 ignores boldfacing, italics, and hyperlinks, but does do a
rough table layout.  This loses some information, to be sure, but I generally
found the NS 4 renditions to be more readable and more clean-looking with less
clutter.

MSIE comes out generally the worst of the three, as it ignores image ALT text
altogether (shown in both the Mozilla and NS 4 renditions), and uses inscrutable
line spacing and indenting.

Whether to try to lay out tables in text mode can be the subject of a raging
debate (Lynx doesn't, while W3M does), but as for the other differences between
NS4 and Mozilla, I think attempting to represent bold/italics with things like
asterisks is too messy-looking and should possibly be scrapped, while putting
link URLs inline really clutters up the document a lot -- maybe putting all the
links at the end of the document (an option in Lynx) would be better.  Also, if
link URLs are to be shown, they should be resolved into absolute URLs instead of
just being output as-is when some are relative, since once the page is saved or
printed the relative locations aren't meaningful.

Comment 1

[Dan Tobias]

Attachment: Page 1, as saved by Mozilla

Page: http://apnews1.iwon.com/article/20020119/D7H4D9IG0.html

Note all the messy stuff at the top, the rendition of the top menu, full of
asterisks and URLs.  The main body of the text is pretty clean, though;
however, in the middle of it there's a bit of mess where an ad graphic with no
ALT text is shown as an image URL.  Then there's some more mess as the bottom
menus are rendered.

Comment 2

[Dan Tobias]

Attachment: Page 1, as rendered by Netscape 4

As saved by Netscape 4, it's much cleaner looking.  The top menus seem to be
absent entirely, maybe because there is JavaScript involved that is ignored in
saving?  But that sort of navigation stuff is pretty much irrelevant in a plain
text document, and the main body comes out pretty good.  The ad in the middle
of the article gets ignored altogether, which is a good thing, I think.  The
multicolumn layout looks OK, but might present a problem for cutting and
pasting from the article into another program.

Comment 3

[Dan Tobias]

Attachment: Page 1, as rendered by MSIE

MSIE shows the top menu in a configuration that looks like some sort of
avant-garde ASCII art, then goes into the main text without spacing the
paragraphs apart.  The ad seems to have wound up in text form in the middle;
probably a different form of the ad is used in MSIE than in Mozilla and
Netscape.  More ad and menu stuff is jumbled at the bottom.

Comment 4

[Dan Tobias]

Attachment: Page 2, as saved by Mozilla

http://www.21stcenturyalert.com/

This is a site's home page, consisting of short blurbs about various sections,
articles, and related sites.  The inline URLs and asterisked highlighting makes
for a messy, choppy appearance where it's hard to get the gist of the atual
content.  No attempt is made to preserve the page layout.

Comment 5

[Dan Tobias]

Attachment: Page 2, as saved by Netscape 4

The main flaw of the Netscape rendering is that it's 127 characters wide.  This
often won't fit in a text viewer/editor screen and forces horizontal scrolling,
or worse, turns into a horrible mess if long lines are word-wrapped. 
Otherwise, though, it's a pretty nice textual rendition of the layout,
structure, and content of the page, attractive and readable.

Comment 6

[Dan Tobias]

Attachment: Page 2, as saved by MSIE

MSIE's rendition is decently readable, though with rather odd indenting and
line spacing.  However, a lot of content is lost due to the failure to use ALT
text for images, which are simply left out with no replacement, even though
many of the logos and captions on the page are graphical with reasonable ALTs.

Comment 7

[Bill Law]

->adamlock

I'm not sure what code actually does the conversion to plain text, though.

Comment 8

[Dan Tobias]

Attachment: Page 1, as rendered by Lynx with -dump option

Here's another alternative text rendering, the one output by Lynx when run from
a command line using the -dump option.	It's a nice clean text version, though
with no attempt to render table layout or execute Javascript.  Note that links
are shown as square-bracketed numbers with the reference URLs at the end of the
document, a reasonable compromise between omitting links altogether (as NS4 and
IE do) and showing the URLs inline (as Mozilla presently does).  Reference URLs
are always converted to absolute URLs even if the original links were relative.
Image ALT text is inserted inline without adding any extra brackets around it
(in contrast to Mozilla and NS4, which add square brackets, and to IE, which
doesn't show ALTs at all).  The "no-brackets" approach works best when the
image takes the place of normal text (e.g., a fancy-form first letter of a
paragraph, or a graphical header that's already set off from the rest of the
text with appropriate tags), while the addition of brackets may make sense for
an inline figure stuck in the middle of text that would butt against the ALT
text in an awkward way without it (though as a web author I always take pains
to add brackets to my own ALT text in those cases).

Comment 9

[Dan Tobias]

Attachment: Page 2, as rendered by Lynx with the -dump option

Here's the other example page in its Lynx rendering.  (Some of the content of
that page has changed in the few days between this and the earlier renderings,
but the basic structure and layout remains the same.)  Note that the <LINK>
elements are rendered as links in the top line of the document, with a # sign
at the start of the line to indicate that it is an insertion.  Like other
hyperlinks, the associated URLs are at the bottom of the document, numbered
appropriately.

Comment 10

[Dan Tobias]

Now I've shown you how four different browsers handle the rendering of two
different Web pages in text form... the ideal would be if Mozilla's developers
took all the best aspects of all of them, and left out all the worst, to combine
them into a real "killer" save-as-plain-text function!

Comment 11

[Adam Lock]

Reassign

Comment 12

[Boris Zbarsky [:bzbarsky]]

Confirming that our output is a lot harder to read than lynx's or NS4's....  I
suggest going the lynx route for embedded urls (doesn't break up the text as much).

There are already bugs on some of these issues (but not on the insertion of "*"
and such, that I have seen).

Comment 13

[Ben Bucksch (:BenB)]

very reasonable feedback, but too much issues at once.

I'll mark it as dup of the "option not to output urls" enh request.
Tables are just not implemented, see bug 18012.
option to disable "structural phrases" (bold->stars etc.) is not filed as enh
request yet, but also reasonable. Biggest problem is the UI. If you file a bug,
please cc me.
Relative URLs are bug 134457.

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

Comment 14

[Ben Bucksch (:BenB)]

Bug 46990 is about the lynx-like URL output, i.e. as footnotes. (Would have been
a good dup-candidate as well, but too late.)

Comment 15

[sujay]

verified.