Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mattom@gmx.at designates
 213.165.64.21 as permitted sender)
Message-ID: <43E9ED8A.7020106@gmx.at>
Date: Wed, 08 Feb 2006 14:09:30 +0100
From: Thomas Lutz <mattom@gmx.at>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Forms encoding problem
References: <s3ea01f5.014@cs-emo.csir.co.za>
In-Reply-To: <s3ea01f5.014@cs-emo.csir.co.za>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

ok, tried to dig in this issue "remote" (I am not working for the 
company any more, where we had this problem, so no sources to try :-)). 
obviously this error is not thrown by cocoon itself, but by the sax parser:

> org.apache.cocoon.ProcessingException: 
> Failed to execute pipeline.: 
> java.lang.RuntimeException: 
> org.xml.sax.SAXException: 
> Attempt to output character of integral value 160 that is not represented in specified output encoding of .

Basically you're already deep in trouble because I think you've 
obviously a mixture of UTF-8 and other encodings... which is really a 
pain in the a...
So, first I'd try to replace the default sax parser with saxon. this 
will cause some headache (about 2 hours last time I tried), because some 
of the form style sheets have to be fixed to work with saxon, cool 
parser but very restrictive :-).
If it's still there afterwards I'd had a look at the form stylesheets, 
and all other stylesheets involved in your form processing pipeline. 
Could be that there is a output encoding hardwired to non UTF-8 
somewhere, and that's a problem. (I've tried to add the escaped space in 
some UTF-8 jx templates, and it works, but there is no form processing, 
better no xsl stylesheet involved).
Googling around I think it could be a xalan bug, too: see
http://java2.5341.com/msg/44662.html (happened with cocoon before :-) )
http://mail-archives.apache.org/mod_mbox/xml-xalan-dev/200511.mbox/%3C1760437284.1132320401907.JavaMail.jira@ajax.apache.org%3E
http://marc.theaimsgroup.com/?l=forrest-dev&m=107482159715139&w=2

Reading all this stuff I'd guess that checking your xalan version in the 
production enviromnent or switching to saxon might solve your problem. 
Have fun with the endorsed stuff, this is one of the things I hate in 
java :-).

hth,
tom


Derek Hohls wrote:
> What I have done;
>  
> Tried all the settings as suggested so far in this thread... 
> switching everything to UTF-8 - checked ALL my files for any
> sign of ISO... (to avoid mixing concerns) ... still no luck!
>  
> Looked in the offending forms and found the &#160; reference -
> when I removed that then everything worked.
>  
> This is OK, BUT I do not understand what the real issue/cause
> is here, or why forms do not display a simple UNICODE character?
>  
> Any clarification would help me (and maybe others) avoid this
> nasty issue!
>
>
>   
>>>> mattom@gmx.at 2006/02/07 03:58:54 PM >>>
>>>>         
> first thought:
> i think we had this error message when using escaped utf-8 chars...
>
> our source files are encoded in utf-8, and some guy inserted a escaped 
> "&#160" in utf 8 with is &nbsp; in utf-8 (<!ENTITY *nbsp* "&#160;">)
>
> this crashed the forms. didn't figure out why, not enough time, just 
> threw out the escaped chars. but as you are using iso-8859-1, just 
> search for a file that's not in the right encoding, or a string 160 in 
> your form files and delete this... (ultraedit or grep, depending on your 
> system :-) ) probably one of your coders or editors uses utf-8, so 
> you'll accidently inserted this utf-8 fragment (and doesn't know it :-) )
>
>   
<snip />


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org