Re: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/ docs/site/news/ do
am 18.08.2007 14:37:43 von sebb
On 18/08/07, tetsuya@apache.org wrote:
> Author: tetsuya
> Date: Sat Aug 18 04:14:52 2007
> New Revision: 567258
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=567258
> Log:
> Apache DB (http://db.apache.org/), especially OJB and Torque had been in Jakarta - "Ex-Jakarta". - Now I am using "CHCP 1252" mode (for ISO-8859-1 characters)
>
Is there a way to fix build.xml so that the user's default encoding
does not affect the output? Or perhaps we could add a check and warn
if the encoding is wrong?
The xml source files are already flagged as ISO-8859-1, as is the
stylesheet, which uses output encoding ISO-8859-1 as well, which one
might have hoped would be enough...
As an alternative, I tried to generate the output to use ö/ü
etc instead of the iso-8859-1 characters, but could not work out how
to code this in the source XML without generating errors.
It might solve the problem if the XSLT output format were changed from
xml to html, but I assume there are good reasons for using xml as the
output format, and it would mean updating every page.
S///
Re: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/ docs/site/news/ do
am 18.08.2007 15:08:09 von tetsuya
I personally think that providing "build.sh"/"build.bat"
properly would be sufficient.
Kindly regards,
-- Tetsuya. (tetsuya@apache.org)
----
On Sat, 18 Aug 2007 13:37:43 +0100
(Subject: Re: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/ docs/site/news/ docs/site/pmc/ xdocs/stylesheets/)
sebb wrote:
> On 18/08/07, tetsuya@apache.org wrote:
> > Author: tetsuya
> > Date: Sat Aug 18 04:14:52 2007
> > New Revision: 567258
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=567258
> > Log:
> > Apache DB (http://db.apache.org/), especially OJB and Torque had been in Jakarta - "Ex-Jakarta". - Now I am using "CHCP 1252" mode (for ISO-8859-1 characters)
> >
>
> Is there a way to fix build.xml so that the user's default encoding
> does not affect the output? Or perhaps we could add a check and warn
> if the encoding is wrong?
>
> The xml source files are already flagged as ISO-8859-1, as is the
> stylesheet, which uses output encoding ISO-8859-1 as well, which one
> might have hoped would be enough...
>
> As an alternative, I tried to generate the output to use ö/ü
> etc instead of the iso-8859-1 characters, but could not work out how
> to code this in the source XML without generating errors.
>
> It might solve the problem if the XSLT output format were changed from
> xml to html, but I assume there are good reasons for using xml as the
> output format, and it would mean updating every page.
>
> S///
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: site-cvs-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: site-cvs-help@jakarta.apache.org
>
------------------------------------------------------------ ---------
Tetsuya Kitahata -- Terra-International, Inc. - President -
E-mail: kitahata@terra-intl.com http://www.terra-intl.com/
Apache News Online http://www.apachenews.org/
Re: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/docs/site/news/ doc
am 19.08.2007 07:52:54 von Roland Weber
sebb wrote:
> Is there a way to fix build.xml so that the user's default encoding
> does not affect the output? Or perhaps we could add a check and warn
> if the encoding is wrong?
>
> The xml source files are already flagged as ISO-8859-1, as is the
> stylesheet, which uses output encoding ISO-8859-1 as well, which one
> might have hoped would be enough...
I don't know what the exact symptoms of the problem are.
This is what the XSLT spec says about output encodings [1]:
> The encoding attribute specifies the preferred encoding to use for
> outputting the result tree. XSLT processors are required to respect
> values of UTF-8 and UTF-16. For other values, if the XSLT processor
> does not support the specified encoding it may signal an error; if
> it does not signal an error it should use UTF-8 or UTF-16 instead.
Is the output generated in UTF-8 or UTF-16? Then the solution
would be to use one of those as the output encoding, since only
those are required to be supported on all platforms.
cheers,
Roland
[1] http://www.w3.org/TR/xslt#section-XML-Output-Method