I didn’t see this exception when building/testing on my local Windows/Intellij, and Ubuntu (WSL), but our automated build system is Jenkins running on some other linux box somewhere, and it’s getting this:
com.aspose.pdf.exceptions.FontNotFoundException: Font Times New Roman was not found
The test code is as follows:
@Test
public void fontException_butOnlyUnderJenkins() throws Exception
{
byte[] htmlBytes = IOUtils.toByteArray(this.getClass().getResourceAsStream("/test-source-for-pdf_01.html"));
HtmlLoadOptions htmlOptions = new HtmlLoadOptions();
Document doc = new Document(new ByteArrayInputStream(htmlBytes), htmlOptions);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
doc.save(baos);
}
The sample HTML has Lorem Ipsum in a few different languages. I’m noticing that the presence of Japanese causes the FontNotFoundException, but several others do not, including Chinese, Hebrew, Arabic, Korean.
This test is only a few languages, and only Lorem Ipsum, so it’s not an exhaustive test.
I’m going to try adding the Times New Roman font to the document itself. But this is very disconcerting. Is it documented anywhere what character sets might cause this exception, and what fonts will be needed if they are encountered?
I’ve tried loading the font from the application’s resources and apply it to the document. So far I’ve still been unsuccessful in getting past the FontNotFoundException.
Here is the latest code in that effort:
byte[] htmlBytes = IOUtils.toByteArray(this.getClass().getResourceAsStream("/test-source-for-pdf_02.html"));
HtmlLoadOptions htmlOptions = new HtmlLoadOptions();
htmlOptions.setEmbedFonts(true);
Font font = FontRepository.openFont(this.getClass().getResourceAsStream("/times.ttf"), FontTypes.TTF);
font.setEmbedded(true);
TextState ts = new TextState();
ts.setFont(font);
htmlOptions.getPageInfo().setDefaultTextState(ts);
Document doc = new Document(new ByteArrayInputStream(htmlBytes), htmlOptions);
// The exception happens during Document creation, so it isn't getting this far.
Could you please try to install all windows fonts in the system and run the scenario again. In case issue still persists, please share your sample HTML file with us. We will test the scenario in our environment and address it accordingly.
You can surely use fonts by specifying fonts path. However, we needed to check if other alternative approach could resolve the issue. Nevertheless, please share your sample HTML file in .zip format with us. We will test the scenario in our environment and address it accordingly.
We have logged an investigation ticket as PDFJAVA-39657 in our issue tracking system for your case. We will look into its details and inform you as soon as the ticket is resolved. Please spare us some time.
Meanwhile, would you please try adding font files to application path (for Arial Unicode MS, Times New Roman, and other fonts which support foreign language characters) and use FontRepository.setLocalFontPaths() method to set font path for API. Please let us know your feedback after testing suggested approach.
I have tried using setLocalFontPaths with an absolute path to the fonts. This does appear to work. But this is not a solution for us. Policies around our production environment require we include the any required resources in the deployed jar.
This did work, but doesn’t meet out needs:
List fontPathList = Arrays.asList(new String[] {"/home/builder/.fonts"});
FontRepository.setLocalFontPaths(fontPathList);
I also found API methods FontRepository.openFont(). One override takes a stream, which is perfect, except calling this did not appear to bring the font into FontRepository, it merely returned an instance of Font, which doesn’t appear useful for our case.
We still don’t have a solution here, and I’m forced to consider another library.
You may also check getLocalFontPaths() method which returns the actual directory of the fonts from where API loads them. You can add required fonts into that directory in order to prevent the issue.
Furthermore, we regret to share that earlier logged ticket is not yet resolved. We are afraid that we cannot offer any workaround at the moment as the investigation against the ticket is pending. As soon as the ticket is reviewed completely, we will share updates with you.
Thank you for the advice of using getLocalFontPaths().
The core issue is that we need to distribute the font files as resources in the jar, not as a separate installation at the operating system level. Both our sysadmins and architects push back on the suggestion of installing Windows fonts onto our production linux boxes.
We have updated the ticket information according to the details that you have provided and will investigate it further. We will let you know as soon as the earlier logged ticket is resolved. Please give us some time.
We regret to share that the ticket is not yet resolved. Please note that we will surely investigate and resolve it however, it will be done on a first come first serve basis. We certainly understand your concerns and will consider them during the implementation of your requirements to the API. You may also please check our priority support option in case the issue is a blocker for you. We will inform you as soon as we have additional updates in this regard. Please spare us some time.
Is this issue resolved ? I am getting Times New Roman not found error when running my java app in ubuntu container (which has no msttcore fonts) and i added the times new roman fonts in my container using setLocalFontPaths but its not working. Looks like Aspose is still not looking at my local container directory even though i added it to local font paths
We really regret to share that the earlier logged issue is not yet resolved. However, we have recorded your concerns along with the ticket and will surely consider them during issue investigation. We will inform you within this forum thread as soon as the issue is rectified. Please give us some time.
We apologize for the inconvenience.
PS: Please try to run getLocalFontPaths method in order to get the actual directory where you can place the fonts as a workaround.
