Description: ------------ When using UTF-8 encoded PHP files and setting the appropriate setFormatConf the £-sign gets correctly encoded into £ if it doesn't exist within an a-tag. If the £-sign is within the a-tag then the sign is left untouched (which does display OK for me). Excellent package, thanks! Test script: --------------- <?php $sText = "This //string// **contains** a pound £ sign. This link also [http://example.com/ contains a £ sign] but this one is allright."; print($sText); require_once("Text/Wiki.php"); $oTextWiki =& new Text_Wiki(); $oTextWiki->setFormatConf('Xhtml', 'charset', 'UTF-8'); print($oTextWiki->transform($sText, 'Xhtml')); ?> Expected result: ---------------- This //string// **contains** a pound £ sign. This link also [http://example.com/ contains a £ sign] but this one is allright.<p>This <em>string</em> <strong>contains</strong> a pound £ sign. This link also <a href="http://example.com/" onclick="window.open(this.href, '_blank'); return false;">contains a £ sign</a> but this one is allright.</p> Actual result: -------------- This //string// **contains** a pound £ sign. This link also [http://example.com/ contains a £ sign] but this one is allright.<p>This <em>string</em> <strong>contains</strong> a pound £ sign. This link also <a href="http://example.com/" onclick="window.open(this.href, '_blank'); return false;">contains a £ sign</a> but this one is allright.</p> Note the litteral £-sign in the link and the encoded (expected) £ outside the link.

This affects not only Url rule but certainly others as well. To render the texts associated with the tokens: Url uses only htmlspecialchars() as do: Wikilink, Function, Image, Phplookup, Smiley, Interwiki. Other hands, Code and Anchor use htmlentities() For the text left as is in the source, it's the pre() method of the rendering object which proceeds the data. Only this one uses the Xhtml render's configuration thru: * 'translate': default htmlentities(), or htmlspecialchars() or nothing. * 'quote': default ENT_COMPAT * 'charset': default 'ISO-8859-1' I think this configurable way of proceeding the output should be generalized to any rule producing viewable text (as here anchors' content for Url) and anyway, not use "raw calls" to the php functions. Side-note 1: the Heading rule should avoid to htmlspecialchars() the associated 'id' direct by the Default (or others) parsing but let the renderer do it. Side-note 2: if the browser is compatible, a true UTF-8 output should not necessitate htmlentities, htmlspecialchars should be enough. However, that would require some browser inspection or limitation, so htmlentities are perhaps more generally compatible.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.