HTML Rendering of a PDF File is including wrong CSS in .NET

GroupDocs.Viewer Product Family
, ,
1

Hello,

I have been using GroupDocs.Viewer 19.12.0 NuGet package to render .PDF Files as HTML content to display in our web application.
The result is render properly, and, for each page of a PDF, a tag containing various css classes and css rules is added.
Among those CSS rules, two of them (for the moment) are interfering with the rest of our web application rendering. Indeed, for each page of any PDF file, the following :
image.png (1.7 KB)
are removing all text decoration of our application.
I find it strange that, even when the rendered PDF file does not include any links, those CSS Rules are present, and can affect the rest of the DOM.
Is there any way to either :

  • Remove those rules that does not seem to have any impact on the document rendering.
  • Block any kind of side effect on the DOM for the CSS generated for the document rendering.

Thanks for the time you will take to consider my problem,
I remain available for any question you may have.
Julien.

2

@BASSETTI

Can you please share the sample code and the PDF? We’ll then further look into this scenario.
Note: We’d recommend you to use latest version of the API and let us know if you face same issue there. Have a look at the HTML rendering documentation article.

3

Hello,

Thanks for the short time answer.

You will find here //Main controller ViewerController.ashx/// <summary>/// Get document page/ - Pastebin.com the following code used in a ASHX codebehind controller which is requested by our frontend to fetch the PDF Content.
Also, please find attached two PDF file which cause problem. I did not mention that in the initial ticket, but any PDF File seems to be problematic regarding links.tryout.pdf (138.9 KB)
tp1aut2020.pdf (257.3 KB)

Also, just to clarify how we are displaying result from our backend and how the issue is present, here is a screenshot of our interface :
image.png (57.1 KB)

As you can see, both the email and the link “New” should be underlined by default, but don’t get this because of the initial problem I am describing.

We can’t really migrate towards your lastest version, for budget purposes, and because migrating from 19.X towards 20.X seems like a big workload.

Thanks again,
Julien.

4

@BASSETTI

This issue is reproduced at our end. We are now investigating it with ID VIEWERNET-2717. You’ll be notified in case of any progress.

5

@BASSETTI

We have an update on **VIEWERNET-2717.

The only way that we see would be removing the rules with custom code or overriding the rules with the !important exception.

To block any kind of side effect(s) you can use iframe element or the alternatives as a container for the output pages.

6

Hello,

Thanks again for your answer.

The only way that we see would be removing the rules with custom code or overriding the rules with the !important exception.

That’s the first dirty fix we thought about when we first identified the issue. However, as I mentionned, those CSS rules are (correct me if I am wrong on this point) useless since, for any PDF document rendered as HTML by your library, those are presents, even when no links are present in the document (like the tryout.pdf file I provided). I was actually talking about removing it on your side. Adding custom code to remove those from our side seems like a really bad practice since it’s not maintainable code and clearly an open door to multiple dirty fixes in the future.

To block any kind of side effect(s) you can use iframe element or the alternatives as a container for the output pages.

For multiple of reasons, those options are not available to us.
My best guess is to make your library generate custom CSS classes for any rules you generate, as it’s already the case for a lot of the generated CSS rules.

1 Like
7

@BASSETTI

We’re investigating the possibility. You’ll be notified as there’s any update.

8

@BASSETTI

Unfortunately, the workarounds we shared with you are only applicable for now. However, we will try to implement a fix in some upcoming releases of the API and let you know.

9

Hi,

Thanks for the investigation and your work on this topic.
Just to clarify what

implement a fix in some upcoming releases of the API

Means, can I expect an upcoming release of the 19.x.x version of this fix? Or will It be mantadory to upgrade my license?

1 Like
10

@BASSETTI

Once the fix is added, it’d be in 20.x. You may then need to upgrade your license.

11

The issues you have found earlier (filed as VIEWERNET-2717) have been fixed in this update. This message was posted using Bugs notification tool by Atir_Tahir