Load font issue

csaisset · June 4, 2014, 4:18am

Hi,

We’re producing png files from aspose.cells java-generated workbooks, and we’re experiencing some problems loading the needed fonts since we changed our environment.

We’re working with Aspose-cells-8.0.2-java on a linux CentOS release 6.2 (64bits).

We’re using the com.aspose.cells.CellsHelper.setFontDir(pathFonts) method to load our font.

The first environment uses java 1.5.0.19, while the second uses the 1.7.0.17 version.

On the first environment, we’re setting the path to “/myApp/param/Fonts” and it works just fine.

On the second, the font doesn’t load and Aspose.cells uses the default system fonts.

On this second environment, we found a workaround by putting our fonts in “/usr/java/jdk/jdk1.7.0_17/jre/lib/fonts”.

Any insight on this issue ?

The workaround is OK, but our client really need to keep the fonts in the application directory.

Best regards.

Charles

babar.raza · June 4, 2014, 5:19am

Hi Charles,

Thank you for contacting Aspose support.

Following is the workflow that Aspose.Cells API follows behind the scene while converting spreadsheets (Excel files) to PDF and images,

In case the proper fonts are placed in the environment (where conversion has to take place), and API is pointed to these font using the CellsHelper.setFontDir method, the API will use the exact fonts and render the text properly as displayed in MS Excel application.
When required fonts (used in the spreadsheet) are not found in the environment, the API will try to substitute these font(s) with the default font of the workbook. Normally the default font is Calibri unless you change it in the MS Excel application before creating a spreadsheet.
If API does not find the required font(s) as well as the default font of the workbook, it will use the Arial font to render the text and to calculate the cell height etc.

In your particular scenario (second environment) its seems that Aspose.Cells API is unable to find the required fonts on the path specified with CellsHelper.setFontDir method therefore it uses the fonts available on the system’s font directory and/or substitute the required fonts with available ones. We would suggest you to confirm the presence of the required fonts on the path specified with CellsHelper.setFontDir method. In case you still face the same problem again, please give a try to the latest version of Aspose.Cells for Java 8.0.2.3 to see how it performs in your environment because the said behavior could also be a bug in your current version of the API.

csaisset · June 4, 2014, 7:21am

Hi Babar,

And thanks, as always, for the quick answer.

Our two environments are absolutely identical, except for the java version and java server, as it is a copy of the same virtual machine with a different server installed on it.

This excludes any problem related to a bad path or file name since neither the font file nor its location changed between the two systems.

In any case, I checked for you and confirm that the paths, file names and method calls are identical on both environments.

We’re going to test Aspose.Cells 8.0.2.3 and let you know as soon as possible if it changes anything.

Regards,

C.

csaisset · June 4, 2014, 8:17am

Hi Babar,

It’s confirmed : the problem is reproduced with the 8.0.2.3 library.

Do you have any idea as to why it is working with the “/usr/java/jdk/jdk1.7.0_17/jre/lib/fonts” directory and not with “/myApp/param/Fonts” ?

Thanks.

C.

babar.raza · June 4, 2014, 9:52am

Hi Charles,

We are sorry to know that the latest build didn’t help at your end. We may now need to simulate the environment as of your problematic server to dig deep into your presented scenario. Could you please execute the following commands on terminal and provide the output here?

java -version
cat /etc/*release

csaisset · June 6, 2014, 2:30am

Hi Babar,

Here are the results of the commands :

java -version :

java version
"1.7.0_17"

Java™ SE Runtime
Environment (build 1.7.0_17-b02)

Java HotSpot™ 64-Bit Server
VM (build 23.7-b01, mixed mode)

cat /etc/*release :

CentOS release 6.2 (Final)

Regards.

C.

babar.raza · June 6, 2014, 3:59am

Hi Charles,

Thank you for providing the requested information. We will try to simulate your environment at earliest to investigate the problem cause on our end. Please spare us little time for that.

Moreover, we have discussed your presented scenario with the core development team, and their suggested solution is to set the fonts directory using the System.setProperty method as demonstrated below. Please note, setting the fonts directory as described below will enforce the API to ignore all other font locations on the machine.

Java

System.setProperty(“Aspose.Cells.FontDirExc”, “FontDirSet”);

Please note, above statement should be at the start of your application, and it does not require setting the font directory using the CellsHelper.setFontDir method. Whereas the string "FontDirSet" should be the complete path to the folder containing the fonts.

Please give the above described solution a try on your end while using the latest version of Aspose.Cells for Java 8.1.0, and feed us back with your results.

csaisset · June 12, 2014, 4:45am

Hi Babar,

We couldn’t get the workaround your team suggested to work.

Please keep us updated on your attempt to reproduce the problem in your simulation environment.

Best regards,

C.

babar.raza · June 12, 2014, 5:22am

Hi Charles,

We are sorry to know that the suggested workaround didn’t work for you.

As far as simulation of your environment is concerned, we have so far tested the presented scenario on two different CentOS versions, that are; 5.9 & 6.5. 5.9 was readily available in form of VM so we just installed the JDK 1.7.0_17 and tested the scenario, whereas 6.5 being the latest version was available through BitTorrent so downloading the Live DVD was very easy. Anyway, our testing on aforesaid platforms didn’t reveal any notable fact, we are unable to notice the problem as mentioned in this thread. No matter where we placed the fonts folder, the latest version of Aspose.Cells for Java 8.1.0 was able to locate & embed the accurate fonts in the resultant PDF files.

We suspect the problem could also be related to the access or rights, so let us discuss the matter with the development team again to provide you a debug Jar so we could pin point the problem cause on your side.

babar.raza · June 12, 2014, 7:56am

Hi Charles,

Just to inform you that we have made an official request to the core team by logging an investigative ticket (CELLSJAVA-40850) in our bug tracking system. As soon as we receive more details, we will post here for your kind reference.

babar.raza · June 17, 2014, 12:10pm

Hi Charles,

Thank you for your patience with us.

In order to troubleshoot the presented scenario, we need your help to identify the differences between the two environments. Please find the attachment for a Java class in an archive with source code snippets extracted from Aspose.Cells for Java API to log the font directories and fonts list. You just need to set the font directory & log file path in the code. Please execute it in your both environments and share the log files for our review.

Moreover, the presented problem could also be related to the relative paths. Firstly, get the absolute path of your font directory, and set the absolute path using Cells.setFontDir method to see how it goes. Please note, Aspose.Cells API can set the font directory using the relative path location just fine, although the above test will confirm if the API can load the fonts from the absolute path in your environment or not. On our end, we have performed tests with a Java project named “cellsJava”, and created a font directory named “fontTest” (the font path: “/cellsJava/fontTest”). The correct relative path in this case is “fontTest” therefore using the Cells.setFontDir(“fontTest”) worked fine on a machine with JDK 1.7 installed. I guess your relative path could be “param/Fonts” so please also try by setting the font directory as Cells.setFontDir(“param/Fonts”).

Please keep us posted with your test results.

csaisset · June 18, 2014, 3:41am

Hi Babar,

Thanks for the test class.

We’re testing it and we will provide the results as soon as possible.

To get the font path in the app, we use the following code (edited) :

String currentDir;

currentDir = new File("…").getCanonicalPath();

currentDir += File.separator + “param”;

…

String pathFonts;

pathFonts = currentDir + File.separator + “Fonts”;

So, with the use of getCanonicalPath(), we were already working with absolute paths and the problems were occurring with this configuration.

We’re going to test using relative paths with the Cells.setFontDir() call.

We have 2 files and 4 test results to bring you :

Test your class on the java 1.5 environment

Get the log file

Test your class on the java 1.7 environment

Get the log file

Test relative paths in our app on the 1.5 environment
Test relative paths in our app on the 1.7 environment

Thanks for your help.

C.

babar.raza · June 18, 2014, 8:33am

Hi Charles,

Thank you for your kind response, and we are looking forward to your test results. However, we would like to add one more that to the list that you have to perform on the environment having JDK 1.7. In this test, please hard code the fonts directory path without involving any of JDK’s method to compute the absolute path for you.

csaisset · July 1, 2014, 4:48am

Hi Babar,

Our dev team did 2 tests only on the Java 1.7 environment.

Each test tested the 2nd (test your class) and 4th (test relative path) tests I described in my previous message, but with different locations for the fonts.

We also added a call to a .png generation of the produced Excel data, in order to check the fonts used in the rendering.

Test 1 :

The fonts are placed in : /appli/bsv/comp/sh/fonts

Relative path is set with :

setFontDir(“fonts”);

Here’s the log file :

jdk version: 3

FontDirs:

fonts

c:\windows\fonts</div>

c:\winnt\fonts</div>

/usr/java/jdk1.7.0_17/jre/lib/fonts

Font dir: fonts

File list: /appli/bsv/comp/sh/fonts/ARIALN.TTF

File list: /appli/bsv/comp/sh/fonts/ARIALNI.TTF

File list: /appli/bsv/comp/sh/fonts/ARIALNB.TTF

File list: /appli/bsv/comp/sh/fonts/ARIALNBI.TTF

Invalid font directory: c:\windows\fonts</div>

Invalid font directory: c:\winnt\fonts</div>

Font dir: /usr/java/jdk1.7.0_17/jre/lib/fonts

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/fonts.dir

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaSansDemiBold.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightDemiBold.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightDemiItalic.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaTypewriterBold.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightRegular.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightItalic.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaTypewriterRegular.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaSansRegular.ttf

Results : with this configuration, the Arial Narrow font placed in “/appli/bsv/comp/sh/fonts/” is ignored, and system fonts are used.

Test 2 :

The fonts are copied in : /usr/java/jdk1.7.0_17/jre/lib/fonts

Relative path is still set with :

setFontDir(“fonts”);

Here’s the log file :

jdk version: 3

FontDirs:

fonts

c:\windows\fonts</div>

c:\winnt\fonts</div>

/usr/java/jdk1.7.0_17/jre/lib/fonts

Font dir: fonts

File list: /appli/bsv/comp/sh/fonts/ARIALN.TTF

File list: /appli/bsv/comp/sh/fonts/ARIALNI.TTF

File list: /appli/bsv/comp/sh/fonts/ARIALNB.TTF

File list: /appli/bsv/comp/sh/fonts/ARIALNBI.TTF

Invalid font directory: c:\windows\fonts</div>

Invalid font directory: c:\winnt\fonts</div>

Font dir: /usr/java/jdk1.7.0_17/jre/lib/fonts

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/fonts.dir

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/ARIALN.TTF

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/ARIALNI.TTF

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaSansDemiBold.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightDemiBold.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightDemiItalic.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaTypewriterBold.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightRegular.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaBrightItalic.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/ARIALNB.TTF

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/ARIALNBI.TTF

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaTypewriterRegular.ttf

File list: /usr/java/jdk1.7.0_17/jre/lib/fonts/LucidaSansRegular.ttf

Results : with this configuration, the Arial Narrow font is used and the output is correct.

As for your request about testing absolute paths hard coded in the app, and the remaining tests in the 1.5 environment, the dev team won’t be available for further testing for some time. Are these results enough to continue the investigation on the matter ?

Best regards,

C.

babar.raza · July 1, 2014, 6:32am

Hi Charles,

Thank you for providing the test results.

Please spare us little time to review the logs on our side. We will keep you posted with updates in this regard.

babar.raza · July 2, 2014, 4:20am

Hi Charles,

It is important to test the Fonts.java on the JDK 1.5 environment as well because we need to compare the logs. Sorry if we haven’t mentioned this in our previous responses.

Moreover, please test the API with absolute paths in your environments. If the results are OK by setting the absolute font path, we may assume the problem is more related to the paths rather than on the part of Aspose.Cells API.

As you have mentioned in your previous message that you use the following code to get the font path.

Java

String currentDir;
currentDir = new File("…").getCanonicalPath();
currentDir += File.separator + “param”;
…
String pathFonts;
pathFonts = currentDir + File.separator + “Fonts”;

Could you please also output the variable pathFonts in both environments to see the differences?

Thank you for your cooperation.