Excel to PDF Rendering issues

Are there external influences that can effect how an Excel file gets rendered to a PDF?
Display Driver? Printer Driver? OS Version?

We have a customer that has a layout issue with a rendering to PDF that we can't seem to reproduce in-house. It only seems to happen on their systems.

I've examined their systems to see if they somehow obtained alternate versions of the Aspose DLLs. I can only find the versions we redistribute with our software.

Hi,


I think these things (Display Driver, Print Driver) should not have any significant effect on Excel to PDF feature provided by Aspose.Cells. Anyways, we will check and evaluate your issue further.

In the mean time, please take care of the following things if possible.

1) DPI (to display text and other items) issue that is set on their system, e.g it might be “Medium - 125%” or larger than this. It should be set to “100% (default)” (e.g under control panel, “…Appearance and Personalization|Display”)

2) Make sure that all the relevant fonts (used int he workbook) are installed on the client systems. Also, please set the fonts directory accordingly – You may use the line at the start before using other Aspose.Cells APIs.
e.g
CellsHelper.setFontDir(stringFontDirPath);


Let us know if you still find any issue.

Thank you.

Why would the font directory not be the standard directory?

Hi Dwight,

Aspose.Cells for .NET component require Full Trust permissions set. The reason is, Aspose.Cells for .NET component needs to access registry settings, system files other than virtual directory for certain operations like parsing fonts. Whereas in the a medium trust environment, the application can only access the files in the current application directory. If you set CellsHelper.FontDir to appropriate Font Directory on your system, an inner FileIOPermission exception will be handled by Aspose.Cells component.

Please check the below linked technical article on this subject.
http://www.aspose.com/docs/display/cellsnet/Declaration

My application is configured as a ClickOnce full trust application.

Never the less, I'm adding the following line in my initialization :

CellsHelper.FontDir = Environment.GetFolderPath(Environment.SpecialFolder.Fonts);

Hi Dwight,

Thank you for your response.

Could you please provide us the system details where you are experiencing the problem? It could be due to the reason that some operating systems such as Windows Server 2008 R2 does not allow direct access to the registry or fonts.

The customer is using Windows 7. This is a .Net forms based application that does the conversion and launches acrobat reader to view the document. It is not a web based application.

They are logged on with a user that is a member of the local administrators group.

Hi Dwight,

Sorry for a bit delayed response.

I have tried to replicate your presented issue on my Windows 7 Home Premium based operating system with latest fix version of Aspose.Cells for .NET v7.6.0.6, by creating several types of applications (Windows Forms, Web, Console) with simplest code to convert the MS Excel spreadsheets to PDF. System’s resolution is set to “Smaller - 100% (default)”, and I never changed it. I switched between setting the font directory for a few test runs but most of the times I didn’t set it because the output was already OK. So far I am unable to observe any layout issues in the output PDF files. Although this does not make any difference but still it is worth noting that I am verifying the output with Adobe Acrobat X Pro.

May be a sample application along with a template file from your end could help us replicating the issue. If possible, please also provide snapshots highlighting the problem, and desired results that you could get by manually converting the spreadsheet through MS Excel.

Like I said in my inital post, we can't reproduce it. It only happens on their systems (they've tried multiple systems).

That is why I was asking what other things on their systems could cause the issue.

I've attached a sample screen shot of their results.<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /> <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Hi Dwight,

Thank you for sharing the screenshot.

Factors that could effect the result while converting a spreadsheet to PDF have already been discussed here. The best way to troubleshoot this problem is by getting all details of problematic system and try simulating the environment to replicate the issue.

As per your comments, it seems that the issue is happening on more that one machine. Although Aspose.Cells should behave similarly in all conditions but still it relies on System Fonts to render the PDF correctly according to the input template. Please check that the font in resultant PDF matches the font in template file. If the font is different, it could be due to the missing font, due to which Aspose.Cells component picked up another similar/generic font to replace the missing one.

  • The spreadsheet is using the Arial font. It is present on the workstation.
  • The display is set to 100%.
  • The conversion to PDF is being done on the same workstation that created the spreadsheet.

We are unable to recreate the problem at our office.

It appears that someone else is reporting the same issue, here.

Are they any other things that could cause this? In order to duplicate the issue we need to know every possible influence on how the conversion is done. The alternative of taking blind stabs will not likely be successful.

Hi Dwight,

Thank you for sharing more details.

As discussed earlier, there are a few factors that could effect the conversion of spreadsheet to PDF format while using Aspose.Cells component. We have got a test project from this post that we are currently testing on our end in Windows Server 2008 R2. Hopefully, we will be able to replicate the issue, and hence move forward to fix the problem in our component (if applicable). Least we could suggest a workaround for this situation in case there isn’t a permanent fix. We will keep you posted with updates in this regard.

I would request you to please share a sample project so we could test it as well.

Hi Dwight,

Just to let you know that we were unable to replicate the issue in Windows Server 2008 R2 Enterprise edition with the project shared in this post. Now we are moving forward to setup Windows Server 2008 R2 Standard edition to see if we could replicate the problem. Moreover, I have logged an investigative ticket (CELLSNET-42154) in our bug tracking system to probe further into this matter.

I would request you to please provide a sample application replicating the problem, along with output PDF files. We will test it in different environments at our end for investigative purposes.

Our customer is using Windows 7. Our product is NOT a server based rendering system. Everything is happening on the workstation. Having you try to use a server is NOT going to replicate the customer’s environment.

Hi again,

Thank you for your response.

Well, we are trying to replicate the issue on our end considering all the possibilities, so that we could move forward to fix it for you. A ticket has been logged and attached to this forum thread for frequent investigation updates and automated notifications regarding the fix. We will keep you posted in this regard.

Please feel free to share anything that you think may help us in identifying the problem cause.

Hi again,

As narrated earlier, we are looking into the matter of spreadsheet conversion to PDF for possible text formatting issues. We have done everything we could to replicate the issue on our end but so far we haven’t succeeded. We need a sample application from you to properly investigate, and to isolate the problem cause. Please help us in this regard. Thank you.