i18n in awt viewer [PATCH]
Hi all ! For AWTViewer i18n, I hacked the AWTViewer for FOP-0.23.0rc maintenance release and I had some questions. I tried to show the menu as Japanese text for i18n for trial. I wrote the resource files by UTF-8 encoding because it is not possible to map multi-bytes characters by iso-8859-1 encoding. I also convert all existed resource file for AWTViewer from iso-8859-1 to UTF-8 automatically. I modified some source files associated with AWTViewer, too. This modification is for the message i18n and for additional fonts support on AWTViewer. The additional fonts are specified in a userconfig.xml file. And you may start FOP with -c and -awt options. NOTE:Now the additional fonts that you can specified is only TrueType font (.ttf and .ttc). This restriction comes from the feature of SUN's JDK (see java.awt.Font javadoc). 1) If you specify the embed-file attribute in userconfig.xml and use JDK1.3 or higher, the specified TrueType font is loaded and used in AWTViewer. 2) Otherwise, if you don't specify the embed-file attribute or use JDK1.2, the additional font is regarded as Java's "Dialog" logical font name for each Locale. I attempt to show Japanese fo file. My test environment is: SUN's JDK1.2.2 and JDK1.3. LANG=EN and JA environment variable. When use LANG=JA, 1) and 2) are works fine (menu is Japanese text and the represented document is readable). LANG=EN and 1) also works fine (menu is English text and document readable). But the convination of LANG=EN and 2) does not works fine (menu looks English text well but document is unreadble). However I think that this behavior is right. Below is my questions. Currently the text of menu for the AWTViewer is loaded from org.apache.fop.viewer.resources package. The AWTViewer needs two kinds of resource file (messages.lang and resources.lang). I can not found messages.lang file for some languages (fi,fr, it,pl.ru). Therefore the following command can not start the AWTViewer (thrown NPE). fop -awt -l fi foo.fo Q1.Is not messages.lang file necessary with resources.lang file? The language to use on AWTViewer is decided by getting the system default or specifying -l option. The decided language is used for the suffix of resource files. However Java has a feature that access to a resource file for every language by default (i.e. java.util.ResourceBundle class and for examples rsources_ja.properties). Currently AWTViewer regards resource files as written by iso-8859-1 encoding. This is not good for i18n. I converted them to UTF-8 encoding, but I think that the ResourceBundle framework is better than now because AWTViewer can start even if there are not resource files for any languages. Q2.Why AWTViewer does not use ResourceBundle? Best Regards. --- 石神 覚司(Satoshi Ishigami) VIC TOKAI CORPORATION patch.tar.gz Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: i18n in awt viewer [PATCH]
Thank you. We should be able to squeeze your code in before delivering the final FOP-0.20.3. I'll take your questions under advisement when I investigate your patch in detail. Regards, Arved Sandstrom -Original Message- From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]] Sent: January 27, 2002 7:33 PM To: [EMAIL PROTECTED] Subject: i18n in awt viewer [PATCH] Hi all ! For AWTViewer i18n, I hacked the AWTViewer for FOP-0.23.0rc maintenance release and I had some questions. I tried to show the menu as Japanese text for i18n for trial. I wrote the resource files by UTF-8 encoding because it is not possible to map multi-bytes characters by iso-8859-1 encoding. I also convert all existed resource file for AWTViewer from iso-8859-1 to UTF-8 automatically. I modified some source files associated with AWTViewer, too. This modification is for the message i18n and for additional fonts support on AWTViewer. The additional fonts are specified in a userconfig.xml file. And you may start FOP with -c and -awt options. NOTE:Now the additional fonts that you can specified is only TrueType font (.ttf and .ttc). This restriction comes from the feature of SUN's JDK (see java.awt.Font javadoc). 1) If you specify the embed-file attribute in userconfig.xml and use JDK1.3 or higher, the specified TrueType font is loaded and used in AWTViewer. 2) Otherwise, if you don't specify the embed-file attribute or use JDK1.2, the additional font is regarded as Java's "Dialog" logical font name for each Locale. I attempt to show Japanese fo file. My test environment is: SUN's JDK1.2.2 and JDK1.3. LANG=EN and JA environment variable. When use LANG=JA, 1) and 2) are works fine (menu is Japanese text and the represented document is readable). LANG=EN and 1) also works fine (menu is English text and document readable). But the convination of LANG=EN and 2) does not works fine (menu looks English text well but document is unreadble). However I think that this behavior is right. Below is my questions. Currently the text of menu for the AWTViewer is loaded from org.apache.fop.viewer.resources package. The AWTViewer needs two kinds of resource file (messages.lang and resources.lang). I can not found messages.lang file for some languages (fi,fr, it,pl.ru). Therefore the following command can not start the AWTViewer (thrown NPE). fop -awt -l fi foo.fo Q1.Is not messages.lang file necessary with resources.lang file? The language to use on AWTViewer is decided by getting the system default or specifying -l option. The decided language is used for the suffix of resource files. However Java has a feature that access to a resource file for every language by default (i.e. java.util.ResourceBundle class and for examples rsources_ja.properties). Currently AWTViewer regards resource files as written by iso-8859-1 encoding. This is not good for i18n. I converted them to UTF-8 encoding, but I think that the ResourceBundle framework is better than now because AWTViewer can start even if there are not resource files for any languages. Q2.Why AWTViewer does not use ResourceBundle? Best Regards. --- 石神 覚司(Satoshi Ishigami) VIC TOKAI CORPORATION - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Choice of a XSL-Fo processor
big snip $ The evaluation version does not include the API $ documentation: it is meant $ to let people assess formatting quality, memory footprint and $ performance. $ In our view, detailed knowledge of API is not necessary for making a $ purchase $ decision. Well, that depends on the requirements one has for software. I for one would not choose any tool if I had not been able to evaluate those things that I would be using the tool for. I agree that very detailed API knowledge may not be required but on the other hand: if I could choose between a tool that I could evaluate in full (and thus have a reasonable idea of what to expect in the future) for a limited time and a tool that I could partially test I'd go for the tool that I could test in full (provided it passed the test, of course). Just my $0.02, Michiel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Choice of a XSL-Fo processor
hi, even i am working on a similar sort of project of making PDF from XSL-FO. I evaluated XEP, FOP XFC by IBM. XFC is quite good but the file size very large compare to other rendering engines. so it may not be of much help. XEP gives has a windows COM wrapper available but not for free. It should be of use if you don't want to use the command-line application. The evaluation version of XEP adds a line Rendered by www.RenderX.com line to the left bottom of the PDF output page. So this version can not be used for commercial purpose. I tried to find out about the prices of COM component, but i din't get a reply from RenderX as yet. (if anyone can figure out the prices do let me know) Apache FOP: is good. But it still does not support many properties. But u can get the desired output by doing changes in your XSL-FO file. Hopefully newer releases of FOP will have all the properties implemented. Let me know if you get some more information abut these rendering engines. Thanks, Dhiraj - Original Message - From: Michiel Verhoef [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 28, 2002 12:47 PM Subject: RE: Choice of a XSL-Fo processor big snip $ The evaluation version does not include the API $ documentation: it is meant $ to let people assess formatting quality, memory footprint and $ performance. $ In our view, detailed knowledge of API is not necessary for making a $ purchase $ decision. Well, that depends on the requirements one has for software. I for one would not choose any tool if I had not been able to evaluate those things that I would be using the tool for. I agree that very detailed API knowledge may not be required but on the other hand: if I could choose between a tool that I could evaluate in full (and thus have a reasonable idea of what to expect in the future) for a limited time and a tool that I could partially test I'd go for the tool that I could test in full (provided it passed the test, of course). Just my $0.02, Michiel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
