I have to internationalize an application, and therefore have to let a user chose a font for a PDF that I will create at runtime. I want to be able to display a list of font choices from the user's system using
GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts();
This works fine for getting fonts, but then it seems that I have to jump through some hoops to get that font to play nice with FOP, as outlined here. I can follow all the instructions that they've outlined, except I'm not sure how to get the location of fonts in order to run TTFReader.
Does anyone know how to list the path of each font that java gathers with the getAllFonts() command?
Is it a good idea to embed fonts in PDFs? For instance the Arial Unicode MS TFF file is ~ 30 MB.
Is this the only way to create internationalized pdfs with FOP and XSL?
There have been major improvements in font configuration with the last release (FOP 0.95), so please just consult the document there for a much easier approach:
http://xmlgraphics.apache.org/fop/0.95/fonts.html#basics
The XML font metrics files are no longer necessary.
To your questions:
That's impossible. Java won't give you that information. That's partly why FOP has its own font subsystem.
Yes, it's actually recommended. Please note that FOP supports font subsetting so only the glyphs needed are embedded in the PDF.
Not sure what you mean. With the above information and an upgrade to the latest release should make this simple enough.
Related
I'm trying to generate PDF document in Java using iText. link
But I also want to give users an opportunity to choose which font to use for the document. There are many fonts, installed in the system, I can list them using
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
but when I try to pass font names to BaseFont constructor directly
BaseFont.createFont(s, BaseFont.IDENTITY_H, true);
I get an exception like
com.lowagie.text.DocumentException: Font 'Abyssinica SIL' with 'Identity-H' is not recognized.
Another option is to pass to the BaseFont the path to the font file (either stored inside jar or somewhere on the system), but in the first case I have to deploy all the fonts with my application, and in the second case I have to think of a way of getting system font files locations. As far as I know, Java puts a layer of abstraction over fonts - public API doesn't know anything of paths, and usage of private API (something like FontManager) is discouraged.
Yet another option is to use constants, declared in BaseFont , but that gives only 4 fonts (Courier, Helvetica, Symbol and Times Roman).
Is there a way to use system fonts in PDFs, generated with iText without deploying them with application and using workarounds like FontManager?
I need to embed all fonts in my pdf using velocity and ITextRenderer in Java.
Most of the fonts works without problem like
renderer.getFontResolver().addFont(
getClass().getResource("fonts/tahoma.ttf").toExternalForm(), true);
I have the same code for Times-Roman and Helvetica, but the generated pdf doesn't have these 2 embedded. I made sure the name of the font matches the name of the missing font in the property of the PDF file.
Flying Saucer is a product built on top of iText. Although the iText companies don't endorse the use of Flying Saucer, I'll make an exception and answer this question (I'm the CEO of iText Software).
You are referring to fonts that used to be known as the Base 14 fonts. Today, these fonts are called the Standard Type 1 fonts.
As opposed to TrueType and OpenType fonts, Type 1 fonts are described in a set of two files. Each font has:
an Adobe Font Metrics (AFM) file. This file contains all the metrics needed to use a font without embedding it.
a Printer Font Binary (PFB) file. This file contains the syntax that is needed to draw each glyph in the font. This is the file you'll need when embedding a font.
As defined in the PDF specification, every viewer should be able to render the 14 Standard Type 1 fonts. That is why people usually don't embed them (unless there are specific reasons to embed the font. PDF/A compliance is one of those reasons).
As for iText, iText ships with 14 AFM files. iText can do so, because the license for the AFM files permits this. iText does not ship with the corresponding PFB files. If it did, that would be illegal because the PFB files aren't available for free. As a result, iText will never embed the 14 Standard Type 1 fonts, even if you set the embedded parameter to true. The only way to embed fonts such as Helvetica, is by providing a font program. That is: not merely the AFM file that ships with iText, but also the PFB file that knows how to draw the glyphs.
Be very careful when using Flying Saucer: if you use it in combination with iText 2, then this applies: https://stackoverflow.com/questions/25696851/can-itext-2-1-7-or-earlier-can-be-used-commercially
If you are using it in combination with iText 5, then you may need a commercial license if you are not distributing your own code under the AGPL.
From Acrobat Help
A font can be embedded only if it contains a setting by the font vendor that permits it to be embedded.
The other fonts (that aren't working) don't permit embedding.
I have some troubles with JasperReports. I generated a formular with iReport including two subreports which generates a grid of values (1 or 2 Characters long).
The compiled PDF from iReport it works fine and looks good, but if i use the same *.jrxml and *.jasper files for my web app the generated PDF has some minor differences. One big problem is, that some cells of the grid now are 2 lines high. Values like "NB" only use one line but "GS" for example uses 2 lines.
For me it is not possible to find the error. Workarounds with smaller font size or wider cells didn't help.
Make sure the font you are using in the template is available on the JVM generating the report. If the font doesn't exist then a different font will be used. If changing the font isn't an option then you can create a font extension package. Creating a font extension is documented here: JasperReports Font Reference
Sound like you could have a different version of iReports in your web application. Making the cells sufficiently wide enough should at least allow the text to span just one line.
Create a Java Desktop test that generates a PDF based on the .jrxml and make sure it has the same results. If it does then there is something with the way iReports is working, if it doesn't then you know it is something with how you are viewing or creating the PDF in the web app.
I'm running across a problem trying to print a crystal report in java where all of the text is being replaced with the little box characters. The report blob is stored in an Oracle database, and I can preview it using adobe reader and see that it is properly formed with actual text. This blob is passed to a java applet that uses the PDFRenderer to print it.
My theory is that the problem lies in the fact that the crystal reports that we generate use version 1.2 of PDF. There are also a number of jasper reports that are generated as version 1.4 and these print correctly - it's only the 1.2 pdfs that have this problem.
Does PDFRenderer not support printing this version or is there some additional steps I need to take to successfully print those?
Any help is greatly appreciated.
It's very unlikely that you encounter an issue that's due to PDF version.
Especially with text content the PDF spec get's very complex and probability is high that crystal reports creates content that either
relies on some strange encoding
uses CID (multibyte) font techniques
and pdf renderer has a blind spot there.
You may try to play around with settings on the report side regarding the
encoding
font (Type1 / TrueType9)
font embedding
and maybe you find an option better suited.
Does PDFRenderer display the PDFs if you use it as a viewer? PDFRenderer does not have support for later PDF versions (ie compressed objects) but 1.2 is fairly straight-forward.
A PDF I generate with jasper reports renders Ok in my MAC but some labels show wrong on Linux. For example, I have a static label that doesn't show completely on linux (only a part of the whole word) but yes on Mac. Can the OS be somehow related? What is the usual source of this kind of problems?
Missing fonts on your linux machine may cause such problems. I had the same when creating pdfs with iText.
Always embed fonts in generated PDFs! It saves you alot of hassles...
And notify the following slight difference: If you create a PDF with Arial as font it shows good in Windows, and will very likely use Helvetica on Linux (which is nearly the same font), but since it has some other metric properties your bounding boxes will not fit.
Again: Always embed fonts in generated PDFs!
If you have time you can look at Docmosis, it generates PDFs with the fonts embedded, so cross-platform rendering isn't an issue. Beware though if you cross-platform generate doc or odf files, then the fonts will be potentially different showing up in pagination or layout changes. Like has been said above, you need to take care that the destination will have the fonts to display those that were used to generate the document (or embed the fonts if possible).
The closes fotn to the PDF Helvetica (SansSerif) is MS Arial.ttf. The problem is that it is not available on the Linux machine by default. Copy it to the /usr/share/fonts (and update fonts.dir) or put it to your Linux JRE installation to fonts/ directory (and update fonts.dir). If you do not want to use MS Arial, try GNU FreeFont http://ftp.gnu.org/gnu/freefont/
You can embed the fonts in the PDF as Daniel has adviced, but it makes PDF larger.