Mailing-List: contact doxia-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: doxia-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: =?iso-8859-1?q?Herv=E9_BOUTEMY?= <herve.boutemy@free.fr>
To: doxia-dev@maven.apache.org
Subject: (output) encoding support in doxia-sink-api
Date: Fri, 7 Nov 2008 13:45:00 +0100
User-Agent: KMail/1.9.10
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200811071345.00920.herve.boutemy@free.fr>

Hi folks,

=46or the next 1.0-beta-1 version, 2 methods have been added to SinkFactory=
=20
interface to improve encoding support:
=2D Sink createSink( File outputDir, String outputName, String encoding )
=2D Sink createSink( Writer writer )
See [1] for the full interface.

I worked with Vincent to implement output encoding in Doxia, and we faced=20
problems that lead us think that forcing a fixed encoding was the right=20
approach to have something simple and reliable: with UTF-8 as this fixed=20
encoding, this didn't limit end-users from any country in the world.

But now, I'm convinced it's not the right approach and API:
1. some formats need to output the encoding (like HTML, or XML): we need an=
=20
encoding parameter, as we can't get it from a Writer instance
2. some formats embed images, like RTF or PDF, then need direct stream acce=
ss=20
to write binary data

Then I think "Sink createSink( Writer writer )" should be removed.
Or if we want an API without filename, this method could be transformed int=
o=20
Sink createSink( OutputStream output ) + Sink createSink( OutputStream=20
output, String encoding ).

Any objection or idea?

Herv=E9

[1]=20
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-sink-api/src/mai=
n/java/org/apache/maven/doxia/sink/SinkFactory.java?view=3Dmarkup