font name for korean language in jasper

[crazybugs]

Can some one say what font name can be given in jasper xml file for pdf fontname "HYGoThic-Medium".

Post Edited by crazybugs at 09/10/2009 09:41

[teodord]

Hi,

 

This is a PDF font that comes with Adobe Asian font pack. You have to have this pack installed on the machines that view the PDF. If not, then the font has to be embedded in the PDF itself.

In any case, in order to use this font with the reports, you have to have the TTF file installed in your system, or you have to pack it as a font extension.

 

Check your local system and see if the font appears in the list of fonts (open a document editor and check the font list). See what is the name of the font in that list. You would be using that name as fontName attribute.

If you don't find such a font in the system's available font list, it means it is not installed in the local system. You probably don't have the Adobe Asian font pack installer. You should install it, if you want to make use of this font.

 

Not sure how you run your reports or how you ship them, but it would be good to make sure the TTF files you use in your reports are available on the machine that runs those reports, and you should pack them in a font extension JAR, as you can see in the JR project package samples, under the /demo/fonts folder.

 

I hope this helps.

Teodor

 

[crazybugs]

I have installed the adobe asian fonts pack. However I am unable to locate the TTF file in my system. Is there any way by which I could find that?

 

I checked in the list of fonts in the WINDOWS/FONTS folder ,but there is no file with the mentioned name.

[teodord]

Hi,

 

I'm not sure what the Asian Font pack installation does. You could get better answers from the Adobe website.

 

I suggest you do it the other way around: You pick a TTF font that you like and that supports your language from the web or other places, and you use it with JR making sure you embed it in the PDF using the pdfEmbedded option available in the font extension config file.

It will produce larger PDF files, but this way you make sure that the PDF will be OK even on machines that do not have the Asian pack installed.

 

I hope this helps.

Teodor

 

[crazybugs]

 

---

We have iTextAsian jar file in our build path. Is there any way by which I can use the fonts there as "fontName" in my xml file.

[teodord]

OK. Let's make one step back.

 

What version of Acrobat Reader are you using?

If you are using Acrobat Reader 8 or earlier, you should have installed the Asian Font Pack from here:

http://www.adobe.com/products/acrobat/acrrasianfontpack.html

This is not the same thing as the iTextAsian.jar file you said you have.

 

If you are using Acrobat Reader 9, it does not require manual installation of an Asian Font Pack, but rather the program installs them automatically when you try open a PDF that contains Korean.

 

So, we need to understand what version of Acrobat you have and how the Korean fonts were installed.

 

Thank you,

Teodor

 

[crazybugs]

We are using adobe 7 version.

We installed korean fonts with the same link you had mentioned.

 

 

 

[teodord]

And what version of JasperReports are you using?

 

Thank you,
Teodor

 

[crazybugs]

Jasperreports-3.5.0

[teodord]

OK, one more thing before trying to give you a comprehensive explanation.

Are you sure you want to use this HYGoThic-Medium Acrobat built-in font?

Or would you be willing to use any other Korean font that would do the job?

 

Using build-in fonts has the advantage of producing smaller PDF files, but relies on the Asian Font pack being installed on the machines that view the PDF. If you go with other TTF font, it would have to be embedded into the PDF files themselves, producing slighly larger files.

 

Thank you,
Teodor

 

[crazybugs]

We need smaller files. So is there any option with HYGoThic-Medium Acrobat built-in font?

[teodord]

Hi,

 

Yes, there is a solution, but there is a little more complicated than initially thought.

 

Here's what happens:

 

Acrobat comes with several so-called build-in fonts, among which we can find the one you want to use, called "HYGoThic-Medium". This font is brought by an additional Acrobat Asian Font Pack or is downloaded automatically by Acrobat 9, when you open a document requiring this font.

Using Acrobat built-in fonts as this one has the advantage of working with smaller PDF files, as alerady mentioned.

 

JasperReports generates PDF using a third partly open source library called iText. This library is specialized in productin PDF files and it lets you create PDF files using the mentioned Korean built in font if you add the optional iTextAsian.jar to the classpath of the Java application. This JAR does not contain font files, but rather font mappings that would be used during PDF generation.

 

JasperReports is a Java application that relies on Java AWT fonts to generate reports. It works with the AWT API to calculate document layout and uses the AWT font metrics to do so. This means that for JasperReports, all that matters is that the font specified with the fontName attribute must be a font that is available to the JVM at the time the font calculations are made.

The Java Virtual Machine is able to work only with fonts that are installed in the system, or TTF files that are registered with the JVM at runtime. JasperReports offerst support for registering TTF files at runtime using the so-called font extensions.

 

In order to solve your problem with the text being cut in PDF, you would need to make sure that the same font is used both by the Java/AWT through the fontName attribute and by the PDF/iText exporter with the pdfFontName attribute.

 

And now, WHAT THE PROBLEM IS:

The Acrobat built-in fonts are NOT TrueType Fonts (TTF). They are OpenType Fonts (OTF).

If you installed the Acrobat Asian Font Pack, you should search for *.otf files under the Acrobat Reader installation folder. There is no point in trying to find the Acrobat fonts as TTF files in the system fonts folder (Windows/Fonts). You will not find them there.

So while we need TTF files for proper metrics in Java, we also want to use the OTF files from Acrobat, for generating smaller PDFs.

We need to produce TTF files from the Acrobat OTF files.

 

SOLUTION:

There is an open source project called http://fontforge.sf.net which is able to convert OTF files to TTF files. I have not tried it, but others on the Web said they used it and it worked.

You would need to take the Korean OTF font file from the Acrobat fonts folder and convert it to a TTF file that you would then deploy in the application as a font extension.

 

I hope this helps.

Teodor

 

 

[crazybugs]

Teodor,

 

Thanks for the help.

Once the conversion to TTF is done,how will I we able to proceed with the font extension. Should I put it in a folder and mention the path in xml file.

[teodord]

Hi,

 

I have successfuly converted the OTF file to TTF file using FontForge and I have prepared a font extension JAR with it.

However, before giving you the link, I want to shed some more light into what I think it happens when you deal with these fonts in PDF.

I have attached a PDF sample file to this message. It contains two Korean characters using the "HYGoThic-Medium" PDF built-in font, with encoding "UniKS-UCS2-H", not embedded (JRXML file also attached, for your reference).

 

FACT: If you try open the attached PDF file with Acrobat 9 that does not have the Korean Font package installed, it will tell you it needs to download the font pack. If you click OK, it will download the OFT file of 3.9Mb, Acrobat would restart, and the document will appear OK. If you click Cancel, it will not download anything and you'll only see a blank PDF. Of course, if you already had the Korean font package installed in Acrobat, it would have not asked for anything and the document would have displayed OK right away.

 

Uptill now, all should be nice and well.

However, if you check the properties of the PDF file in Acrobat, by going to the File/Properties/Fonts tab, depending on your system configuration, you would see different things. Actually, depending on the system configuration, the font you would be seeing in Acrobat would be different. And that poses us a major problem.

 

On Windows (I have tried only on WinXP and only with Acrobat 9)

 

WinXP Case 1 - Windows XP in English, without support for East Asian languages

(Control Panel/Regional and Language Options/Languages/Install files for East Asian languages/NOT CHECKED)

In this case, the Acrobat properties would tell you the document contains the

HYGoThic-Medium/Actual Font: AdobeMyungjoStd-Medium

WinXP Case 2 - Windows XP in English, with support for East Asian languages

(Control Panel/Regional and Language Options/Languages/Install files for East Asian languages/CHECKED)

In this case, the Acrobat properties would tell you the document contains the

HYGoThic-Medium/Actual Font: DotumChe

 

On Linux (I have tried only on Ubuntu and only with Acrobat 9)

Ubuntu does not seem to have a separate package for East Asian languages, so Acrobat always uses the font from its own Korean package. This is why in Ubuntu we always see the correct/expected PDF properties:

HYGoThic-Medium/Actual Font:

AdobeMyungjoStd-Medium

 

PROBLEM:

On Windows, depending on whether you have the East Asian language support installed or not, the actual font used in PDF to render the built-in Korean PDF font is different. The Windows East Asian language support installs the guliam.ttc font under /WINDOWS/Fonts and this TTC file contains 4 fonts, including DotumChe. Acrobat for Windows has the ability to use this DotumChe font from Windows if it finds it, instead of its own OFT font that it forces you to download anyway.

The trouble is that DotumChe and AdobeMyungjoStd-Medium look different, although they are both Korean fonts. So you cannot be sure which one your end user will see, because you are not sure what kind of system configuration they have, with or without East Asian language support.

 

SOLUTIONS:

The solution depends on whether you know all your viewer are on windows and have the east asian language support installed or not. It also depends on which machine you generate the PDF. Is it a windows machine that also has the east asian package (meaning it has the DotumChe font available to the JVM)?

 

The font extension JAR I mentioned at the begining of the message can be found temporarily at:

http://jasperreports.sf.net/AdobeMyungjoStd-Medium.jar

In order to make use of it, you should add it to the classpath of your application and make sure you use:

<font fontName="AdobeMyungjoStd-Medium"/> for your text fields. Note that we no longer specify any pdfXXX attribute, as they are taken care in the font extension config file in the JAR itself.

However, due to a current limitation of the JR font extension support that we are going to address in the following days, the font will end up being embedded into the PDF.

So I suggest you wait for the fix, and only then make use of the font extension, which will have the config file a little altered to allow specifying the pdfFontName attribute inside the font extension (currently not possible due to an oversight).

 

I hope this helps.
Teodor

 

 

Post Edited by teodord at 09/11/2009 19:55

[crazybugs]

Teodord,

Thanks for the suggestion.

To give you the background of our problem,we were using "HYGoThic-Medium" as pdfFontname with encoding "UniKS-UCS2-H". We were not using the fontName parameter in the xml file. So when the report was generated data was proper in our Jasper viewer, but some data got truncated on saving to pdf format.

We implemented  the solution you provided in Windows English OS with Adobe reader 7 with adobe Asian fonts installed.

We included the jar file you had attached in our class path and made the following changes in the xml file.
We are using conditional styling in our xml file.

1) We made the fontName as "AdobeMyungjoStd-Medium" in the xml file .We didnt include the pdfFontname,pdfEncoding and isPdfEmbedded values in the xml file.We then generated the report. The values in the Jasper Viewer were a bit misarranged.However, truncation of data was not there in the Jasper Viewer. But when we saved  to pdf format, all the korean fonts vanished and we were able to see only English data. The English data didn't show any truncation.

2) Then we changed the fontName to "HYGoThic-Medium" in the xml file.We didnt include the pdfFontname,pdfEncoding and isPdfEmbedded values in the xml file.We then generated the report. The values in the Jasper Viewer were properly arranged, truncation of data was not there in the Jasper Viewer. But when we saved to pdf format, all the korean fonts vanished and we were able to see only English data.The English data didn't show any truncation.

In both the cases,on checking the pdf properties(File -> Document Properties -> Fonts),it showed only "Helvetica" as font, whereas we were expecting  "HYGoThic-Medium". We have attached the sample xml file.

Please let us know if we are missing out something here.

Thanks a lot. Have a great day.

[teodord]

Hi,

 

There must be something wrong with your report sample. For example, it is not a valid JRXML, as the "font" parameter is missing.

Can you specify the Korean text using \u escape sequences and their Unicode representation. I have encoding problems trying to test your report, and I'm not able to transform the text field content into proper Korean text.

Having the unicode code of the characters would be better.

 

Also, can you use two separate text fields, one for English and one for Korean, in the same report, instead of switching using a conditional style and a parameter.

 

I would check again if the adobe font JAR is indeed in the classpath.

 

Thank you,
Teodor

 

[crazybugs]

Thanks for the reply.

 

We are not having issues with viewing the korean fonts in pdf file. The korean fonts are visible in the pdf file.The asian font pack which is installed for viewing the korean fonts uses "DotumChe" for viewing korean fonts. However, the pdffontname in our case is "HYGoThic-Medium".

 

We have English as well as korean data is the generated report.Data appears properly in JV but truncation of data happens in the saved pdf file.

 

Moreover, our application works in more than two languages. Hence having seperate fields for different languages is not possible.

 

Teodard,

We tried with the jar file you had provided. But the issue didn't get solved.Was that due to classpath issues or due to the use of conditional style.

[teodord]

Hi,

 

Let's not restart the discussion from square one. I know what your problem is. I understood it. You experience text being cut in PDF. I understood that.

 

I was trying to explain you why that happens. It is because how Acrobat works (at least on Windows).

 

So, let's take it from our last message exchange where you told me that in the PDF properties, you don't see any "HYGoThic-Medium".

Please attach there the PDF files you generate. As I told you, you should give up the conditional style and put two text fields in the same report: one with English and one with Korean. So that you don't generate the same report twice, changing a parameter.

It is easier without parameter and coditional style, just two text fields side by side.

 

Thank you,
Teodor

 

 

[teodord]

Hi,

 

I have made modifications to JasperReports so that we can specify the built-in PDF fonts (normalPdfFont, boldPdfFont, italicPdfFont and boldItalicPdfFont optional properties in FontFamily).

This allows you to create PDFs that do not embed fonts, but rather leverage Acrobat fonts from font packages.

 

Secondly, I have modified JasperReports so that we can map system fonts to PDF export fonts and hence further eliminate the need to use the FONT_MAP exporter parameter at runtime or the pdfXxx attributes in JRXML.

This way you could use fonts that are already available to the JVM, and not provide TTF files for runtime installation through the font extension. This is useful in the case of the DotumChe from Windows Asian Pack, which comes in a form of a TTC file, which is not installable in Java, so you must rely on it being present in the system. However, you can use that TTC file as PDF export font, because iText knows how to work with TTC files.

 

I have uploaded a snapshot of the future JR 3.6.1 JAR file at the following location:

http://jasperreports.sf.net/jasperreports-3.6.1.jar

Also, I have uploaded a new font extension JAR file that maps the system installed "DotumChe" font to the built-in PDF "HYGoThic-Medium" font.

http://jasperreports.sf.net/MyungjoAndDotum.jar

If you use this JAR file on a Windows that has the DotumChe font installed (look for the gulim.ttc file among the system font files) and you use fontName="DotumChe", it will produce a PDF file that has the "HYGoThic-Medium" font inside. Because this built-in font would map to the actual DotumChe font on that windows system, the font metrics should be OK and no text should be cut.

 

Let me know how it goes for you.

I want us to finalize on this issue. In case it still does not work for you, please attach the PDF files that would show us your problem.

 

Thank you,

Teodor

 

[crazybugs]

Teodor,

We tried this issue with the latest jasper report and the font jar file you had attached in an English OS with East Asian pack installed.

But still the issue got recreated.Please find the attachment with the xml file,report pdf and Jasper viewer screen shot.

[teodord]

Well, I thought your disappearing text is Korean text. But now I see it is about English text.

Do you have a case where the disappearing text is Korean? Can you attach a similar sample here?

 

It looks like the DotumChe font has narrower characters when viewed in AWT (JasperViewer) than it has in PDF.

This is why in PDF, the text displays wider and it disappears at the right, not fitting the text area. I set a yellow background to the text field to better see the effect.

 

If disappearing text is only the English text, and Korean is generally fine, then it might be related to the fact that this font is really a Korean font, not meant for use with English? I don't know.

But I think you should use proper fonts for proper languages. When you run your report in English, use English fonts, and when you run it in Korean, you use Korean fonts. This is possible using JR font extensions, because in each font family you can tell which locales it supports.

Basically, you could have multiple font families with the same name, but that apply to different locales. And depending on the REPORT_LOCALE report fill parameter at runtime, the right font family with the right fonts will be picked for the text field.

But we'll talk about this after you confirm only English text has this problem or not.

 

Thank you,

Teodor

 

[crazybugs]

Thanks for the reply Teodor.

Truncation happens in the case of korean data  in English OS with East Asian fonts. Please refer to the attachment.

We support 2 languages in our application.

1) English : Here only english data is displayed. The system default font is "Helvetica" and pdffontname is "Helvetica".Truncation does not happen in this case.

2) Korean : Here both english and korean data is displayed.The system default font is "DotumChe" and pdffontname is "HygoThic-Medium".Truncation happens in both English and Korean data.

As you mentioned,it seems that in PDF, the text displays wider and it disappears at the right, not fitting the text area

Is there any way by which we can,

1) Reduce the font size of the data displayed in pdf file. (i.e) can we have seperate font sizes for Jasper Viewer and pdf.

2) Increase the height of the field in pdf alone(not in Jasper Viewer) so that, even if text in pdf extends it may move to the next line and may avoid truncation.

Thanks again for the help you had rendered so far.

 

[teodord]

One more question about this.

You say you have reports that display both English and Korean at the same time.

Let's say such a report has two text field elements.

 

Do you know, at report design time, that one of these text fields will always display English, and that only the other one is susceptible of displaying English or Korean depending on the REPORT_LOCALE parameter?

I'm asking such question because the REPORT_LOCALE parameter is very important in JasperReports. It is the only locale related information we have at runtime to know the language used by the report and thus pick the correct fonts from font extensions.

If the language of the text fields is completely independent from this REPORT_LOCALE parameter, we would be in a difficult use case scenario, as there is no way for us to know which is the language used by a text field and so we cannot pick the correct font for it.

 

 

Let me put the question in a different way. Do you use the REPORT_LOCALE fill parameter to control the language in which the report is generated? If you don't it means that you are not using JR internationalization support, but rather display whatever text comes from the database, without knowing in which language it is written.

 

We need these details in order to move forward with this. Seeing the complete report template that you have would help understand what you are trying to do.

 

Thank you,

Teodor

 

[crazybugs]

Hello Teodor

 

Currently in our application we support both English and Korean. For both the languages we have only single JRXML file for each report.

We are using Conditional Style to determine the fontName and pdfFontName values at runtime depending on the Locale value

 

<style name="myStyle" isDefault="true" fontName="Helvetica" pdfFontName="Helvetica"  pdfEncoding="Cp1252">

<conditionalStyle>

<conditionExpression><![CDATA[new Boolean(new String($P{locale}).equals("ko_KR")==true)]]></conditionExpression>

<style fontName="DotumChe" pdfFontName="HYGoThic-Medium"        pdfEncoding="UniKS-UCS2-H" ispdfEmbedded="false"/>

</conditionalStyle>

</style>

 

OR (we also tried removing Conditional Style and also we completely removed the Style and used font tag for each element........ and one more way we tried is below)

 

<style name="myStyle" isDefault="true"   >

<conditionalStyle>

<conditionExpression><![CDATA[new Boolean(new String($P{locale}).equals("en_US")==true)]]></conditionExpression>

<style fontName="Helvetica" pdfFontName="Helvetica" pdfEncoding="Cp1252" ispdfEmbedded="false"/>

</conditionalStyle>

<conditionalStyle>

<conditionExpression><![CDATA[new Boolean(new String($P{locale}).equals("ko_KR")==true)]]></conditionExpression>

<style fontName="DotumChe" pdfFontName="HYGoThic-Medium"        pdfEncoding="UniKS-UCS2-H" ispdfEmbedded="false"/>

</conditionalStyle>

</style>

 

OR (Font Extension Feature)

<style name="myStyle" isDefault="true"   >

<conditionalStyle>

<conditionExpression><![CDATA[new Boolean(new String($P{locale}).equals("en_US")==true)]]></conditionExpression>

<style fontName="Helvetica" pdfFontName="Helvetica" pdfEncoding="Cp1252" ispdfEmbedded="false"/>

</conditionalStyle>

<conditionalStyle>

<conditionExpression><![CDATA[new Boolean(new String($P{locale}).equals("ko_KR")==true)]]></conditionExpression>

<style fontName="AdobeMyungjoStd-Medium" />

</conditionalStyle>

</style>

 

 

1. And if the Locale is Korean, then each report column values can have either Korean text or English text or both (these values are queried from Database). As Korean fonts are supersets of English fonts, we expected Koran fonts to support both Korean and English texts (Also we din't face any problems in this regard, when the Locale is Korean both English and Korean text displayed properly in Jasper Viewer.)

 

2. Also in your earlier post you mentioned to use seperate JRXML files for each language, but this approach will be difficult to maintain, if we are expecting our application to support 4 to 5 languages. And that is the reason for going with Conditional Style. Which looked very good until we faced this data cut-off problem in PDF.

 

3. We set the fontName="DotumChe" and pdfFontName="AdobeMyungjoStd-Medium" (this TTF file is placed in the classpath i.e. in Windows\Fonts folder). But when we tried to save it in PDF the pdf file was blank.

 

4. We also registered the "AdobeMyungjoStd-Medium" font using <property name="net.sf.jasperreports.export.pdf.font.myFont" value="C:\Windows\Fonts\AdobeMyungjoStd-Medium.ttf" />

<style fontName="DotumChe" pdfFontName="myFont"     pdfEncoding="UniKS-UCS2-H" ispdfEmbedded="true"/>

 

Even this did not work the saved PDF file was blank. What could be the reason in the above two cases.

 

Thanks for your help

 

[teodord]

Hi,

 

Here are some answers to your previous numbered issues:

#1. You said the magic words: "each report column values can have either Korean text or English text or both (these values are queried from Database)"

The problem that we have experience in all our recent test, when we tried to leverage the PDF built-in font called "HYGoThic-Medium", in order to minimize the PDF files size, was that the actual font behind the scenes (DotumChe), does not have the same character width for the English (ANSI) characters in AWT/Java and in PDF (Acrobat).

This problem can be see in the Korean sample you sent, where the last Korean character is cut off, simply because the 3 English (ANSI) characters present there (two blank spaces and a minus), were wider than in AWT. All Korean characters had similar widths in AWT in PDF. Only the two spaces and the little line were wider, pushing the last Korean character out of the text field in PDF.

This is basically the root cause of all problems we descriebed in this very long thread.

Unfortunately, there is little we can do to fix this from JR, as it has to do with how iText works and probably with the HYGoThic-Medium.properties file that you can find in the iTextAsian.jar file. My understanding is that file specifies the characters widths. I'm not an expert in fonts, PDF or iText, but I tried to modify that file and I was able to control the character width of text in PDF. I'm not encouraging you to do so, in order to solve the problem. You should rather post the problem on the iText forums, or even get professional help from the iText team.

In my opinion, and especially if you don't want to get your hands dirty and modify font configurations file like that, I suggest you give up your requirement of creating PDF files using PDF built-in fonts. In all the test we made so far, we have proved that there is no guarantee that the AWT rendering (JasperViewer) and the PDF rendering will match, using this approach. There will always be the risk that the text will get cut.

The only solution to make sure the text looks perfectly the same in AWT and in PDF, is by using TTF files and embedding them into PDF. This would of course produce larger PDF files, but they will be perfect on any machine.

If you accept this solution, I'll be happy to assist you further and solve your reports once and for all. But if you insist on creating PDF files without embedding the font, I'm afraid I have no further suggestions and I think this is actually impossible, unless you work with custom CMAP files and understand how iText works.

 

#2. I never said you should have different reports for different languages. You probably misundersood me.

 

#3 and #4. I don't know what happens, but maybe there is an expcetion raised and the PDF is not generating propertly. Check the logs.

 

And not, some further recommandations, in waiting for your reply about how you want to proceed further.

You don't need to create a report parameter called "locale". You should use the built-in JR parameter called REPORT_LOCALE. Using this built-in parameter has the advantage that you don't need to use conditional styles anymore, because font extensions have support for locale and they take into consideration the REPORT_LOCALE parameter, if provided. Basically, each font family in the font extension file could be configured to apply to certain specified locales. You could have multiple families with the same name, used for the fontName atttribute, but each on of them applying to different locales (supportedLocale tag in fonts.xml). I could give you more details if you want, but look at the /demo/fonts/font.xml file in the JR project distribution package and see some commented lines there.

 

And now, in conlusion, I would say that even if we'll not be able to solve your problem with text being cut when using built-in PDF font, we have introduced some enhancements in the font extension support in JR, in the last few days since this discussion has started. Others would benefit from these enhancements starting with the new release.

 

Thank you,

Teodor