Hi Veniamin, Thank you for your reply.
What it means "character is not encoded correctly"? If PDF content is unreadable, then that's PDF file problem, not Tomcat. Is this PDF opens correctly by itself, i.e. when you open it through Adobe Reader?I tried. Then Japanese characters are all dimed (converted to randome characters like noise).
Anyway, just do response.setContentType("application/pdf") and let browser open it accordingly.
Because itext asumes Japanese character as Shift_JIS encoded, but Tomcat default is UTF-8, so I have to specify pageEncoding attribute in page directive.
Sorry, I don't know what is itext for, text->pdf translator? Try this:
<%@ page contentType="application/pdf; charset=ISO-8859-1"
pageEncoding="Shift_JIS" %>Is this what you want to archive -- set response type to look like PDF without any particular encoding, and to tell Jasper that your source encoded with "Shift_JIS"?
By the way, it's Jasper who thinks that JSPs are in UTF-8, but Tomcat assumes ISO-8859-1 (HTTP standard AFAIK) when processing request/response.
I can see PDF content is correct when I save it as a file and open with Adobe Reader.
My point is why tomcat put charset option to contentType when I specify pageEncoding attribute. I might write code to generate
image from String, then the content should not be attributed
like "charset=Shift_JIS". but still I need to specify pageEncoding attribute for correct character encoding.
I just want tomcat to stop adding charset option when pageEncoding attribute is specified.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
