Small visual problem when converting certain PDF to HTML in .NET

GroupDocs.Viewer Product Family
1

One of our customers reported two smaller issues when converting the attached PDF files to HTML.
The “example 1.pdf” has an image that is not correctly shown on page 1. (probably due to layers and transparency)
Converting “example 2.pdf” changes the font.

We were using GroupDocs.Viewer 20.8 with HtmlViewOptions and ExcludeFonts = true.
PDF to HTML conversion.zip (469.7 KB)

2

@Clemens_Pestuka

We have logged this issue in our internal issue tracking system with ID VIEWERNET-2719. It’ll be now further investigated and you’ll be notified about the outcomes.

1 Like
3

@Clemens_Pestuka

As far as this issue is concerned, we are still investigating it.

To resolve this one, please set ExcludeFonts = false and let us know if issue persists.

How ExcludeFonts work?

  • Quality. This is what you have by default (when ExcludeFonts has a default value). All the fonts are embedded or linked as external resources. This is set by default as in most cases you want to have the output as close to the source as possible.
  • Speed. Use this option when the page size and the page loading speed are your priority but you have to pay with the differences in rendering between source and output.
1 Like
4

@atirtahir3

Thank you, this does fix it.

We cannot set it to false, though, as it prevents this issue which is way worse.

Unless there is some way to get both, I’ll rather have the incorrect font.

5

@Clemens_Pestuka

We didn’t get it clearly. Can you please elaborate?

1 Like
6

@atirtahir3

In the linked topic you suggested to set ExcludeFonts to true, which did resolve the problem where the output files were ~70 MB due to included fonts.
If this change causes now some fonts to display incorrectly, it’s not as bad as 70 MB output files.

I was just wondering if there might be a better option.
Honestly I don’t quite get how the output files could become that large. even if you encode the font to base64, it has to be included redundantly to cause such a huge file size.

7

@Clemens_Pestuka

We’ll consider this feedback in ticket VIEWERNET-2716 and notify you if there’s any update.
However, as of the this thread, we’re investigating the issue with example 1.pdf and shared a workaround for example 2.pdf.

1 Like
8

Thank you :slight_smile:

1 Like
9

@Clemens_Pestuka

You’re welcome.