[jdom-interest] PrintWriter in XMLOutputter

[Kevin Regan]

> > 
> > Another reason to use \r\n over \n is that it'll only cause issues for
> > Unix people who tend to be familiar with handling such issues.  In
> other
> > words, every Unix user knows how to remove ^M's, but not every Windows
> > user know what to do when Notepad shows one long line.  :-)
> 
> Yes, we all know how to clean our bathrooms too, but does that mean we
> enjoy it?  I despise seeing ^Ms strewn like dust bunnies around my
> files.
> 
> I vaguely remember that \n is defined in Java as representing the
> platform-dependent line ending character(s).  I can't remember where
> this is implemented -- in PrintStream probably --- but I know that
> printing "foo\nbar" does the right thing on all platforms.
> 
> I propose that the default EOL for XMLOutputter be "\n" because that's
> the Java standard and that the field be public (or rather, that we add
> a "setNewline(String)" method) so people with specific IO needs can
> get the behavior they want.
> 

When reading in an XML file, a processor is obligated to change
all occurrences of \r\n with \n:

2.11 End-of-Line Handling

           XML parsed entities are often stored in computer files which,
for editing convenience, are organized into lines.
         These lines are typically separated by some combination of the
characters carriage-return (#xD) and line-feed
         (#xA).
           To simplify the tasks of applications, wherever an external
parsed entity or the literal entity value of an internal
         parsed entity contains either the literal two-character sequence
"#xD#xA" or a standalone literal #xD, an XML
         processor must pass to the application the single character
#xA. (This behavior can conveniently be produced by
         normalizing all line breaks to #xA on input, before parsing.) 

It may be a bit of a reach, but given that \r\n should be replaced with \n
on input, it is not to much to expect a \n on ouput as well...

--Kevin