Re: pageEncoing and contentType
Hi
Maybe you should query tomcat-dev list about how (and if you really
need) to override Jasper's behaviour on inserting pageEncoding value
into Content-Type header.
In tomcat-dev list, they say IT'S SPEC. that's it.
I've learned that If you don't like it, shut up and use your default.
I found a workaround. Let the jasper using default encoding, and
call encoding conversion method before you pass strings to other
methods in your jsp.
Hope this helps someone.
-
%@ page
language=java
import=java.io.*, com.lowagie.text.*, com.lowagie.text.pdf.*
%
%@ page contentType=application/pdf%
%!
//=encoding conversion
String getSjis(String str) throws java.io.UnsupportedEncodingException{
String str2=new String(str.getBytes(ISO-8859-1),SJIS);
return str2;
}
%
%
Document document = new Document();
ByteArrayOutputStream buffer = new ByteArrayOutputStream();
PdfWriter pdfwriter = PdfWriter.getInstance( document, buffer );
document.open();
BaseFont bf = BaseFont.createFont(HeiseiKakuGo-W5,UniJIS-UCS2-H,false);
PdfContentByte pcb = pdfwriter.getDirectContent();
pcb.beginText();
pcb.setTextMatrix(50,800);
pcb.setFontAndSize(bf,12);
pcb.setLeading(15);
pcb.showText(English);
// use encoding conversion =
pcb.showText(getSjis(=JAPANESE STRING HERE=));
pcb.endText();
document.close();
response.setContentLength(buffer.size());
ServletOutputStream output = response.getOutputStream();
buffer.writeTo(output);
output.flush();
%
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pageEncoing and contentType
Hi,Antonio Thank you for your reply. Here is my whole jsp code. It is OK except that I want: response.setContentType(application/pdf); rather than: response.setContentType(application/pdf;charset=Shift_JIS); (I'm looking into .java in tomcat work directory which jasper generates.) %@ page language=java import=java.io.*, com.lowagie.text.*, com.lowagie.text.pdf.* % %@ page contentType=application/pdf pageEncoding=Shift_JIS % % Document document = new Document(); ByteArrayOutputStream buffer = new ByteArrayOutputStream(); PdfWriter pdfwriter = PdfWriter.getInstance( document, buffer ); document.open(); BaseFont bf = BaseFont.createFont(HeiseiKakuGo-W5,UniJIS-UCS2-H,false); PdfContentByte pcb = pdfwriter.getDirectContent(); pcb.beginText(); pcb.setTextMatrix(50,800); pcb.setFontAndSize(bf,12); pcb.setLeading(15); pcb.showText(English); pcb.showText(---JAPANESE CHARACTER HERE); pcb.endText(); document.close(); response.setHeader(Content-Disposition,attachment; filename=pdf4.pdf); response.setContentLength(buffer.size()); ServletOutputStream output = response.getOutputStream(); buffer.writeTo(output); output.flush(); % What are you using to make the PDF content slip into the wire? If you are using a Writer you get from response.getWriter(), you may have interest in trying to use the OutputStream, as in response.getOutputStream(). This is what the description of the getWriter method says: Returns a print writer for writing formatted text responses. The MIME type of the response will be modified, if necessary, to reflect the character encoding used, through the /charset=.../ property. This means that the content type must be set before calling this method. So don't use it for binary things... Antonio Fiol seiji takegata wrote: 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? Anyway, just do response.setContentType(application/pdf) and let browser open it accordingly. I tried. Then Japanese characters are all dimed (converted to randome characters like noise). 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. 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. Am I wrong? seiji takegata wrote: I'm trying to generate PDF document directory from JSP using itext library. I have an encoding problem. I put pageEncoding and contentType attributes in page directive as: %@ page contentType=application/pdf% %@ page pageEncoding=Shift_JIS% Then tomcat (or jasper) translates them like: response.setContentType(application/pdf;charset=Shift_JIS); IE will not open AdobeReader, show download dialog instead. If I do not specify pageEncoding, then the line above will be: response.setContentType(application/pdf); AdobeReader opens as I expect. But character is not encoded correctory. I wonder why charset=Shift_JIS is added to contentType string. I want remove it from the contentType string, or remove whole the line. I think I can specify contentType by response.setCotentType(application/pdf); -- seiji takegata [EMAIL PROTECTED] - 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]
Re: pageEncoing and contentType
Hello Seiji. 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? Anyway, just do response.setContentType(application/pdf) and let browser open it accordingly. seiji takegata wrote: I'm trying to generate PDF document directory from JSP using itext library. I have an encoding problem. I put pageEncoding and contentType attributes in page directive as: %@ page contentType=application/pdf% %@ page pageEncoding=Shift_JIS% Then tomcat (or jasper) translates them like: response.setContentType(application/pdf;charset=Shift_JIS); IE will not open AdobeReader, show download dialog instead. If I do not specify pageEncoding, then the line above will be: response.setContentType(application/pdf); AdobeReader opens as I expect. But character is not encoded correctory. I wonder why charset=Shift_JIS is added to contentType string. I want remove it from the contentType string, or remove whole the line. I think I can specify contentType by response.setCotentType(application/pdf); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pageEncoing and contentType
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? Anyway, just do response.setContentType(application/pdf) and let browser open it accordingly. I tried. Then Japanese characters are all dimed (converted to randome characters like noise). 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. 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. Am I wrong? seiji takegata wrote: I'm trying to generate PDF document directory from JSP using itext library. I have an encoding problem. I put pageEncoding and contentType attributes in page directive as: %@ page contentType=application/pdf% %@ page pageEncoding=Shift_JIS% Then tomcat (or jasper) translates them like: response.setContentType(application/pdf;charset=Shift_JIS); IE will not open AdobeReader, show download dialog instead. If I do not specify pageEncoding, then the line above will be: response.setContentType(application/pdf); AdobeReader opens as I expect. But character is not encoded correctory. I wonder why charset=Shift_JIS is added to contentType string. I want remove it from the contentType string, or remove whole the line. I think I can specify contentType by response.setCotentType(application/pdf); -- seiji takegata [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pageEncoing and contentType
seiji takegata wrote: 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? Anyway, just do response.setContentType(application/pdf) and let browser open it accordingly. I tried. Then Japanese characters are all dimed (converted to randome characters like noise). 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]
Re: pageEncoing and contentType
Hi, seiji takegata wrote: 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? Anyway, just do response.setContentType(application/pdf) and let browser open it accordingly. -- I tried. Then Japanese characters are all dimed (converted to randome characters like noise). 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 % I tried. This time jasper generates: response.setContentType(application/pdf; charset=ISO-8859-1); 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? Yes that is exactly what I want. 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. OK, I'll study more. Thank you again. Seiji 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. -- seiji takegata [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pageEncoing and contentType
seiji takegata wrote: Try this: %@ page contentType=application/pdf; charset=ISO-8859-1 pageEncoding=Shift_JIS % I tried. This time jasper generates: response.setContentType(application/pdf; charset=ISO-8859-1); OK, and with that you still can't get PDF right? Maybe you should query tomcat-dev list about how (and if you really need) to override Jasper's behaviour on inserting pageEncoding value into Content-Type header. All I found is: org.apache.jasper.compiler.Validator public static void validate(Compiler, Node.Nodes) throws JasperException; In that method there is some logic that determines ...; charset=... value in case this substring is absent in contentType page directive. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pageEncoing and contentType
On 2004.4.19, at 10:02 PM, Veniamin Fichin wrote: seiji takegata wrote: Try this: %@ page contentType=application/pdf; charset=ISO-8859-1 pageEncoding=Shift_JIS % I tried. This time jasper generates: response.setContentType(application/pdf; charset=ISO-8859-1); OK, and with that you still can't get PDF right? Yes, I can get right PDF by specifying just pageEncoding. But IE displays download dialog (with some warning message) that I don't want to see. Maybe you should query tomcat-dev list about how (and if you really need) to override Jasper's behaviour on inserting pageEncoding value into Content-Type header. All I found is: org.apache.jasper.compiler.Validator public static void validate(Compiler, Node.Nodes) throws JasperException; In that method there is some logic that determines ...; charset=... value in case this substring is absent in contentType page directive. I see. Your suggestion helps me a lot, thanks. Seiji - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pageEncoing and contentType
What are you using to make the PDF content slip into the wire? If you are using a Writer you get from response.getWriter(), you may have interest in trying to use the OutputStream, as in response.getOutputStream(). This is what the description of the getWriter method says: Returns a print writer for writing formatted text responses. The MIME type of the response will be modified, if necessary, to reflect the character encoding used, through the /charset=.../ property. This means that the content type must be set before calling this method. So don't use it for binary things... Antonio Fiol seiji takegata wrote: 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? Anyway, just do response.setContentType(application/pdf) and let browser open it accordingly. I tried. Then Japanese characters are all dimed (converted to randome characters like noise). 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. 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. Am I wrong? seiji takegata wrote: I'm trying to generate PDF document directory from JSP using itext library. I have an encoding problem. I put pageEncoding and contentType attributes in page directive as: %@ page contentType=application/pdf% %@ page pageEncoding=Shift_JIS% Then tomcat (or jasper) translates them like: response.setContentType(application/pdf;charset=Shift_JIS); IE will not open AdobeReader, show download dialog instead. If I do not specify pageEncoding, then the line above will be: response.setContentType(application/pdf); AdobeReader opens as I expect. But character is not encoded correctory. I wonder why charset=Shift_JIS is added to contentType string. I want remove it from the contentType string, or remove whole the line. I think I can specify contentType by response.setCotentType(application/pdf); -- seiji takegata [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
