> When the log is long, it is hard to find all the lines 
> about errors among all that text.  Also, for some reason 
> when I delete part of the log because I have made a 
> correction myself, the next time I open the log file, the 
> text is crowded and even more difficult to read.
> 
> It would be good if the log could be sorted so that all 
> error notes were grouped together.
> 
> I also notice that when I View Source a copied web page, 
> the html is really crowded together with black squares 
> instead of line breaks, making it very difficult to read.

Both of these problems have to do with the differences 
between operating systems regarding how the idea of "move 
to the beginning of the next line" is stored in a text 
file.  Unix systems use a "New Line" character (also known 
as LF, Control-J, chr(10) or 0x0A), Macs (before they were 
Unix) used to use a "Carriage Return" (CR, Control-M, chr
(13), 0x0D), and Dos/Windows machines use both together 
(CRLF), considering "move to the beginning of the line" 
and "move down a line" to be two separate operations.  
Depending on where a web page was created, you could see 
any of these combinations.

HTTrack on Windows, unfortunately, uses a unique CRCRLF 
combination for its log files that most Windows programs 
don't know how to handle.  The "View log" and "View error 
log" options in WinHTTrack (BTW, can someone tell me what 
the difference is between these two, anyway?) handle things 
OK, as long as the log file isn't too long, in which case 
it shows nothing, and you have no choice but to look at it 
some other way - but when you do, and especially if you 
edit the file, things can get strange.

Some programs ignore the character after a CR no matter 
what it is, and/or treat "lone" CRs or LFs as nonsense 
characters, which can result in what you're seeing - either 
garbage characters where the line breaks should be, or none 
at all.

In short, this could be fixed - easily for the log files, 
not so easy but not impossible for the captured Web pages.