stijndewitt

At the moment this *is* possible (although difficult). I just implemented it. You will have to do some dirty work though. I plan to make a blog post of this. Once done, I will post a link here.

Ok, I did some research and now are able to provide some more info on this. First, about the enhancements to the API: normalPdfFont boldPdfFont italicPdfFont boldItalicPdfFont I wonder whether these methods are really necesarry... I was tracing through the code and noticed this in SimpleFontFace.getInstance: if (fontName.trim().toUpperCase().endsWith(".TTF")) { fontFace = new SimpleFontFace(fontName); } else { JRFontUtil.checkAwtFont(fontName, JRPropertiesUtil.getInstance( jasperReportsContext ).getBooleanProperty( JRStyledText.PROPERTY_AWT_IGNORE_MISSING_FONT )); fontFace = new SimpleFontFace( new Font( fontName, Font.PLAIN, JRPropertiesUtil.getInstance( jasperReportsContext ).getIntegerProperty( JRFont.DEFAULT_FONT_SIZE ))); } There is a hardcoded check on .TTF here that explains why these fonts do work out-of-the-box, without resorting to the special setXxxPdfFont methods. All other font types, including .ttc (TryeType Collection) fonts go into the else branch, where we see that JRFontUtil.checkAwtFont is called. That is the method that throws the JRFontNotFoundException. However, I think the call to this method is programmed in the wrong way. The checkAwtFont method is expecting a font name, but the SimpleFontFace.getInstance method accepts a font *file* name and it just passes that along directly. Teodor's solution fixes that. You set the font name in the setNormalFont method and set the font *file* name in the setNormalPdfFont... However, why not just fix this check? Second, about figuring out the path to the individual font faces within the TrueType Collection (.ttc) file: I was able to make it work by leveraging some existing code in iText (support lib that comes with Jasper). Basically, what we do is call some method on iText to get the names of the font faces that are inside the .ttc file and then loop through them to see which one corresponds to the font that we are trying to find. We then append the index of the face whose name matches to the path to the .ttc. Font font; // Assume font is set to the Java Font instance corresponding to the font face we are trying to set (e.g. Arial Bold) String path; // Assume path is set to a valid .ttc file containing the faces of the font family (e.g. "arial.ttc") // Get the names of the individual font face files within the TrueType Collection String[] names = BaseFont.enumerateTTCNames(path); // Loop through the names to determine the index of the current font face within the collection. for (int idx = 0; idx < names.length; idx++) { // My testing indicates that font.getPSName() corresponds to the names returned by enumerateTTCNames... if (font.getPSName().equals(names[idx])) { // Found the current font face at index 'idx' inside the collection, update path to reflect this path += "," + idx; break; // done! } } The 'path' variable will end up looking like this: "arial.ttc,2" Now I don't think Arial is in a TTC actually, but it's just an example. When I complete my code, I am planning to post some more details on my blog about this. I will put a link here by then. -Stijn

Hi. I realize this thread is old, but it comes up high in a Google search for "jasper reports ttc support". It seems Jasper Reports, since Teodor's changes, *does* support TTC, but it requires some special handling. I get most of Teodor's explanation above, but I'm missing one tiny (but important) piece of information. I figure in this line, [font_index_or_font_name] should be filled in by me to tell Jasper/iText which of the TTF fonts in the TTC font collection should be used for the normal face font. Now I can hardcode 0 (zero) here, but that probably isn't always right... So how to figure out the index? Also it talks about font name. That sounds very good for my purposes, because I already have a (the?) font name, but a bit more explanation wouldn't hurt. So question: When we use the name as the index, is that the name as we get it from AWT when calling GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames() Or, is that the font name that we can get from a Font instance 'someFont' by calling: someFont.getFontName() ? And lastly a remark. I notice that Jasper checks which fonts are available to the JVM by calling: GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames() I guess this means (in case of .ttc font files) that we should set the 'normal' property to the name of the font *in the default locale* right? Because we have a system where individual users can override the default locale with their own preference, but we should not use the name of the font in that user locale because then this check will fail. Is that right? It might be nicer if there was a way to indicate to Jasper which locale to use, just like most JVM code that uses a locale somewhere has a overloaded method that allows you to specify a locale other than the default one to use. If I figure out how it all works exactly, I will come back here with some clarification. However if in the meantime someone sees this and can answer right away, that would save me a lot of digging around in the Jasper code. :)

One-and-a-half year later, and still there are no docs. Shame.

Seems like this answer is in fact wrong. I removed all calls to this method, but after I did that I got some errors on JUnits and robot tests that I did not understand. Stuff wasn't working correct anymore. When I reverted my changes, all was well again. So I'm not sure what side effects the method is causing, but it is doing *something*. This kind of stuff makes me itchy. The method is deprecated, but there is no explanation why, no hints on what to replace it with etc. It makes my life as a developer using Jasper harder and I don't see what benefit I am getting in return.

A small explanation on that in the Javadoc of the actual method would be great. Saves us having to Google it. If you look at the current Javadoc for this method, it just says "Deprecated. To be removed.". No explanation on what the method does / did or why it is deprecated and what (if anything) to call in it's stead... Post Edited by stijndewitt at 06/04/2012 10:17