System Font Dependencies in Unix (Centos)

GroupDocs.Viewer Product Family
1

I’m using the Java version of Groupdocs.Viewer in a unix (Centos) environment.

I’m noticing that on a bare Centos install with no fonts installed that calls to ViewerHtmlHandler::getPages() will throw an error stating that no fonts are installed the first time that method is called, and will block on all future calls to that method (very frustrating, hard to debug behavior).

I’ve remedied on Centos 7 by installing the font subsystem via ‘yum install -y fontconfig’. This installs a single font package (stix-fonts).

I haven’t noticed any particular quality issues regarding fonts, but this could be due to limited testing I’ve done so far.

My questions:

  • Is Groupdocs.Viewer actually using the installed system fonts (perhaps for calculating character-width?) when generating HTML?
  • Is there a way to use the document->HTML conversion features without having system fonts/font-subsystem installed?
  • Is system fonts are needed, are there a set of fonts that are recommended to be installed?
2

@matttaylor,

Thanks for using GroupDocs.Viewer and sharing your concerns with us. GroupDocs.Viewer does not actually use the installed fonts, instead, it fetches the fonts from the source document and provides you the option to either embed the font in HTML or save it as an external resource. Hence, it is not required to have the fonts installed on the machine.

In order to investigate your reported issue, please provide us the following details:

  • Version of GroupDocs.Viewer
  • Version of installed JDK
  • Details of OS
  • Problematic document
  • Sample console application (source code without compilation errors) that is rendering the document as HTML using GroupDocs.Viewer and can be used to reproduce the issue

We shall be looking forward to your response.

3

Version of Groupdocs : 17.2.0
Version of JDK : Oracle JDK 1.8.0.144 (x64)
OS: Centos 7

Sample Code/Document: https://drive.brainspace.com/s/gTiO9hawJxoZJYo

To reproduce error:

  1. mvn package
  2. Copy groupdocs license file to root of this project
  3. vagrant up
  4. vagrant ssh
  5. install oracle JDK (leaving that as an exercise to the tester)
  6. navigate to /test
  7. run:
    java -jar target/libtest-1.0-SNAPSHOT.jar test-data/native_files/sample.pdf

There is some extra code in this test case that can be ignored, the meat of the code is in the com.brainspace.spike.GroupDocsRenderer class

NOTE: the Centos openjdk package will run fine with this test case as it has a dependency on fontconfig.

4

@matttaylor,

Thanks for sharing the required details. Please spare us some time to replicate your environment and investigate your reported behavior at our end. We shall get back to you shortly.

5

@matttaylor,

We investigated your reported issue but could not reproduce it at our end. GroupDocs.Viewer is rendering the document into HTML as expected without throwing any error. As I mentioned before, the API fetches the fonts from the source document and the text in the resultant HTML appears in the same font as it is in the source document even if the font is not installed. We have also prepared a sample application that renders the source PDF document as HTML with embedded fonts and saves the resultant HTML pages. You can download it and check it at your end. We would also recommend you to use the latest version (17.5.0) of GroupDocs.Viewer for a better experience.

6

Disappointing that you were unable to reproduce. Did you follow my instructions and run my test case in the Vagrantfile I provided or try to reproduce on a freshly installed Centos 7 system?

It is important for reproduction that no other software is installed that may install ithe fontconfig package (for instance openjdk installs fontconfig as a dependency).

7

@matttaylor,

Thanks for your response. We have tried to render the PDF document on a freshly installed CentOS 7. Furthermore, we also checked the scenario by removing all the installed fonts and document is rendering without any issue. As I mentioned before, the API fetches the fonts from the document and it would not have any effect even if the font is not installed on the device. There might be the case when the document does not contain the font in it. In that case, the API will search the required font in the installed fonts and if the font is not found, the API will use some other suitable font. You can also notice that the API creates the required fonts in the resources directory of the document in the API’s cache. We recommend you to try our provided sample application at your end. Hope it helps.