Column Widths Discrepancy When Missing Font

During the conversion of a worksheet to HTML, the column widths of the exported HTML change between Windows and Linux OS. The conditions that produce this behavior are:

  • The “Normal Style” of the worksheet is modified - specifically the “standard font” assigned to the Normal Style is "Times New Roman 9 pts
  • The “default column width” is un-altered (at 8.5)
  • The font for the “Normal Style” does not exist in the Linux environment.
  • There seems to be a font substitution that occurs during the process that generates the HTML. However, the “WarningCallback” feature does not notify that the substitution happens.
The files necessary to reproduce the behavior are attached, here are the steps:
1. Create a Java class with the following code:

public static void main(String[] args) {

// assumes the Workbook is in the classpath
Workbook wb = new Workbook(“ColumnWidthsBug.xlsx”);
wb.getWorksheets().setActiveSheetIndex(0);

// export the worksheet
HtmlSaveOptions options = new HtmlSaveOptions(SaveFormat.HTML);
// use UTF-8 encoding
options.setEncoding(Encoding.getUTF8());
options.setHtmlCrossStringType(HtmlCrossType.DEFAULT);
options.setPresentationPreference(true);
options.setExportActiveWorksheetOnly(true);
options.setExportImagesAsBase64(true);

// implement anonymous callback class
IWarningCallback callback = new IWarningCallback() {
@Override
public void warning(WarningInfo info) {
System.out.println(info.getDescription());
}
};
options.setWarningCallback(callback);

// save HTML file to current folder
File file = new File(“ColumnWidthsBug_” +
System.getProperty(“os.name”).replace(’ ', ‘_’) +
“.html”);
try (FileOutputStream out = new FileOutputStream(file)) {
wb.save(out, options);
}
if (file.exists()) {
System.out.println("Successfully generated HTML file: " +
file.getAbsolutePath());
}

}

2. In a Windows environment, copy the attached Workbook file ‘ColumnWidthsBug.xlsx’ to a folder where the Java class is compiled.
3. Execute the Java class - it should produce an HTML file that represents the converted worksheet.
4. Repeat steps 2 and 3 but on a Linux environment. It is important that the Linux environment does not have the “Times New Roman” font available to the Aspose Cells library.

Summary of the issues:
  • If you compare the text from two generated HTML files, you should see that the only deltas are related to the column widths. Note that the attached file ‘HTMLComparison.html’ contains a summary of the comparisons between the two HTNL files generated from my environments.
  • You can visually see that the HTML generated in the Linux OS produces unexpected results with the text wrapping within the cells as well as elongated columns. As a visual reference see the screen shots from attached files “HtmlOutputLinux.jpg” and "
    HtmlOutputWindows.jpg"
  • Note that although an IWarningCallback was implemented in the method, the “Times New Roman” font is not reported as being substituted. Since the “default font” (from the “Normal Style”) affects the “standard column width”, I would expect that the WarningCallback mechanism should report the font substitution during the conversion process.

Environment:
* Aspose Cells version 8.6.0
* Windows 7 64-bit (used to generate ‘ColumnWidthsBug_Windows_7.html’)
* Oracle Linux Server release 5.8 64-bit (used to generate ‘ColumnWidthsBug_Linux.html’)

Attachments:
  • ColumnWidthsBugFiles.zip - contains:
    • ColumnWidthsBug.xlsx: Workbook which is the source of the conversion to HTML
    • ColumnWidthsBug_Windows_7.html: HTML file that was generated from my Windows 7 OS
    • ColumnWidthsBug_Linux.html: HTML file that was generated from my Linux OS
    • HTMLComparison.html : Comparison summary of the two HTML files above.
Thanks in advance for looking into this.

Hi,


Thank you for providing the detailed description & samples.

We are performing a few tests on Linux against the latest version of Aspose.Cells for Java 8.6.0.3 and we will keep you posted with updates in this regard. However, by reviewing the problem description and checking the samples, we are sure that the problem is caused due to the unavailability of the required font (Times New Roman) in the Linux environment, this is because Aspose.Cells APIs require the exact font (used in the spreadsheet) to correctly calculate the glyph size (width & height) and consequently the size of the cell for rendering purposes. Could you please provide us the following artifacts/information?

  • PDF files generated with Aspose.Cells for Java 8.6.0.3 on both Linux & Windows environments. Please use the SaveFormat.PDF in Workbook.save method to generate the PDF files. Please note, you can easily view the embedded set of fonts by checking the document properties (File > Properties > Fonts) in Adobe Reader. It will give you a good idea on what fonts are embedded as compared to the used fonts in the spreadsheet.
  • Don’t you wish to install the fonts on the Linux machine, if not, could you please explain why? As discussed earlier, Aspose.Cells APIs require the fonts used in the spreadsheet to be present in the environment otherwise the rendered result could have different cell sizes and different text appearance. If you do not have any problem installing the fonts on the Linux machine, you can use the CellsHelper.setFontDir method to point the Aspose.Cells for Java API to pick those fonts, however, the aforesaid statement should be executed before initializing any objects from Aspose.Cells for Java API.

Hi again,


This is to update you that I have performed tests on the Linux machine (CentOS 6.5) and I can confirm that the presented problem is related to the missing fonts. Please find the attachment for the HTML files generated with and without setting the fonts folder before the conversion process. You will be able to see that when font directory is not set the column widths are greater than the HTML with setting the font directory.

That said, please note that I have only placed the Times New Roman font files (TTFs) in a folder and passed the directory location to the CellsHelper.setFontDir method at the very start of the test application.

Please feel free to write back in case you have further questions or need our assistance with Aspose APIs.

Hi Babar,

Thank you for looking into this issue and providing the feedback. I may have misstated the issue that we’re facing in the subject of this thread. I understand that the missing font is the culprit that causes the column widths to be modified. I also understand that adding the font to the Linux environment (within a folder registered via the CellsHelper.setFontDir method) will resolve the column width issue. However, the main problem that we need to resolve is not so much the installation of the missing font - but rather how we detect that the font is missing in the first place.

In reality, the “Times New Roman” font is empirical, since any Workbook can use a different font which may not be available in the Linux system. So we need to determine if the font assigned to the “Normal Style” of the exported worksheet is available to the Aspose Cells library. If it is being substituted (and therefore affecting the column widths) we should at least be getting a notification via the IWarningCallback framework.

Hopefully you saw from the sample program (provided above) that under Aspose 8.6.0 - the font substitution is not reported. As such, we currently have no way of knowing that the font assigned to the “Normal Style” of an exported worksheet will be substituted and therefore affected the output (i.e. column widths) of the generated HTML file.

If you have any suggestions of how we can determine that the font exists, via Aspose Cells, please let us know.

Thanks again.

Hi,


Thank you for explaining your concerns further.

You are correct, as during my testing, I did’t receive the font substitution warnings while converting the spreadsheet to HTML with required fonts missing. However, the warnings work well when rendering the spreadsheet to PDF or image formats. In order to look further into this matter, I have logged a ticket with Id CELLSJAVA-41503 in our bug tracking system. Please allow us some time to properly analyze the scenario and get back to you with updates in this regard.

Hi Babar,

Just wondering if you have any updates on ticket CELLSJAVA-41503, which is related to this bug.

Thanks.

Hi,


Thank you for writing back.

I am afraid, the ticket logged earlier as CELLSJAVA-41503 is currently unresolved. However, I have requested the concerned member of the product team to share some insight of the problem, and preferably an estimated release schedule for the fix. As soon as we receive any updates in this regard, we will post here for your kind reference.

Hi Babar,

I was hoping this issue (CELLSJAVA-4150) would be resolved under the latest Aspose Cells 8.7.2; but it looks like it wasn’t. Were you able to get any updates regarding this issue?

Thanks.

Hi,


I am afraid, the ticket logged earlier as CELLSJAVA-41503 isn’t resolved yet. I have recorded your comments on aforementioned ticket and I will follow-up with the concerned member of the product team to get an estimated release schedule for the fix. I will shortly get back with updates in this regard.

Hi again,


This is update you that the product team has announced the release schedule for the fix of ticket CELLSJAVA-41503, that is; 25th of April 2016. If everything goes by the plan, we will share the fix with the upcoming major release of Aspose.Cells for Java. As soon as the fix is available for your testing, we will notify you here in reference to the aforementioned ticket.
Hi again,

This is to inform you that we have resolved the ticket logged earlier as CELLSJAVA-41503. We will share the fix here after ensuring the quality and incorporating other enhancements.

Hi,

Thanks for your using Aspose.Cells.

Please download and try the latest fix: Aspose.Cells for Java v8.7.2.5 and let us know your feedback.

The issues you have found earlier (filed as CELLSJAVA-41503) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by Aspose Notifier.