Hi Benjamin,
Thanks to spot it! I will revert the release and call a new one.
So by default, we have now:
- encoding = ${project.build.sourceEncoding}
- docencoding = ${project.reporting.outputEncoding}
- charset = null
And if charset == null, charset = docencoding
I will add a faq about this logic.
Also, I noticed in the Javadoc tool documentation:
-encoding "If this option is not specified, the platform default
converter is used."
Ok Hervé displays a warn about build platform dependent if null but
the -encoding param is not passed in the Javadoc tool.
-docencoding "If you omit this option but use -encoding, then the
encoding of the generated HTML files is determined by -encoding."
We need to reflect this logic and NOT using UTF-8 which is actually the default.
Cheers,
Vincent
2008/8/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi Vincent,
>
>> We solved around 30 issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14120&styleName=Text&projectId=11138
>
> The handling of the charset parameter I proposed to Hervé in MJAVADOC-206
> gives rise to misbehavior. Imagine the following plugin configuration:
>
> <configuration>
> <docencoding>ISO-8859-1</docencoding>
> </configuration>
>
> i.e. the generated HTML files are encoded using Latin-1. However, the
> charset written in the <META> tag will state "text/html; charset=UTF-8",
> potentially making a browser render garbage characters.
>
> I just fixed that, so maybe it's worth to include this for the release.
> Sorry, that I didn't spot this earlier.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
