> > We are using iText to generate PDFs from our Java spreadsheet engine. > > We already had printing capability through the Java 1.2 printer > > interfaces, so at the moment I am using iText's createPrinterGraphics > > API to get a Graphics2D which our application can paint to in order to > > create the PDF. > > > > Our application is fully Unicode enabled. A single cell in the > > spreadsheet can contain text in multiple fonts and with any Unicode > > characters. I am trying to figure out what the best way to handle font > > encodings so that I can always get iText to embed the right font > > information into the PDF. > > > > Based on what I turned up in the book, mailing list archives, and the > > website tutorials, right now I am creating a DefaultFontMapper and going > > through and setting the encoding member for all of the > > BaseFontParameters in the map to the special IDENTITY_H encoding. From > > what I understand, there are a couple of downsides to this: 1) the text > > in the PDF is stored as Unicode, making the PDF bigger than necessary, > > The streams are compressed and size increase is not that great.
Thanks for the tip there, I'd forgot those were compressed. I ran some tests today and the compression does make this a non-issue. > > and 2) the IDENTITY_H trick doesn't work with non-TrueType fonts. Are > > The other font types don't have that many glyphs to show. Ok, I understand that now. > > both of those assumptions correct? > > > > Would you suggest a better way to handle the font encoding with iText? > > I thought about making up a dummy Graphics2D object and having our app > > print to it first so that I could see what characters are going to be > > printed, and in what fonts, that way I would know before painting to > > iText's Graphics2D which fonts I would need to apply the IDENTITY_H > > encoding to. This might help solve the file size issue, because I > > wouldn't be embedding fonts as Unicode that were only used to print ANSI > > characters. > > > > Looks like too much work for little gain. After running my tests, I agree. > > For the non-TrueType fonts, I will probably let the user put custom font > > encodings, per-font, in a configuration file, that way if the user is > > using a non-TrueType font with non-ANSI characters, they at least have a > > way to hard-code which encoding each font should use. > > > > If the font is not true type it probably won't have the needed glyphs. You're right, it won't have all the Unicode glyphs. My problem here is that we have no control over which fonts are on the user's system, and no control over which of those they use in the spreadsheet. So ideally, I need to give them a way to set the encoding used for non-TrueType fonts, so they can embed those successfully (if they want to). > > Any help or suggestions would be appreciated, as I am lost in this new > > world of PDF fonts and font encodings. > > > > You'll have to make compromises here as the best solution is not always > possible. Stick with true type fonts replacing other font types and if you > must really use the original non true type fonts, render the pdf using font > outlines. What do you mean by "replacing other font types"? Would I do that in the FontMapper.awtToPdf call? I worked a little more on this today and ran into a few more troubles. I tried using an AFM font in our spreadsheet, and setting its encoding to IDENTITY_H made iText mad, as when a string was painted with that font, the Java String class threw an exception when iText asked it for the bytes encoded in the "Identity-H" charset, which of course, Java knows nothing about. My user getting a random exception when generating the PDF isn't acceptable, so I am in search of a way to identify which fonts I *can* set the encoding to IDENTITY_H on. Should I just use the same file extension check (.ttf, .otf, .ttc,) that iText uses to check to see if a font is TrueType or not? I was hoping the BaseFontParameters class would have an API to ask what type a font was, but it doesn't. Jason Boehle [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://itext.ugent.be/itext-in-action/
