Hidden Text Becomes Visible in GroupDocs.Viewer Due to Incorrect Rendering Layer Order

fadip · July 8, 2025, 9:22am

Hi GroupDocs Support,

I encountered a rendering issue using GroupDocs.Viewer when previewing a PDF document.

In the original PDF, there is some text that is intentionally hidden behind a filled rectangle or shape (used for masking or redaction purposes). When I open the document in Adobe Acrobat or Chrome PDF Viewer, the text is correctly blocked/covered and not visible.

However, when the same document is rendered using GroupDocs.Viewer, the text appears visible, because the blocking shape is rendered behind the text, not in front of it as intended. This appears to be a layering issue (Z-ordering) in the rendering engine.

It seems that GroupDocs:

Converts the PDF content to an image (or HTML layout),
But draws the text layer above image-based content (even if the text was originally underneath a shape).

This leads to previously hidden or intentionally blocked content becoming clearly visible, which is a major concern for confidentiality.

Steps to Reproduce:

Open the attached PDF (IN0001_2022-23.pdf) in Adobe Acrobat — observe the text behind shapes is properly blocked.
Render the same document using GroupDocs.Viewer in HTML mode.
Observe that the blocked text becomes visible, because the overlaying shape is rendered behind the text.

IN0001_2022-23.pdf (166.9 KB)

denisgvardionov · July 8, 2025, 10:38am

@fadip

Hi Frangky,

The reported issue with the numbers, which are located in the table cells and are occluded by the shapes, but are visible in the GroupDocs.Viewer, is not a bug, but rather a feature, a default behavior, intended to provide the all the textual data on the page. However, it is possible to mimic the behavior of Adobe Reader (or any other PDF reader) using the HtmlViewOptions class. In particular, need to set the true value to the EnableLayeredRendering flag in the PdfOptions, as it is shown on example below:

HtmlViewOptions embeddedHtmlOpt = HtmlViewOptions.ForEmbeddedResources("page-{0}.html");
embeddedHtmlOpt.PdfOptions.EnableLayeredRendering = true;

using (Viewer viewer = new Viewer("IN0001_2022-23.pdf"))
{
    viewer.View(embeddedHtmlOpt);
}

As a result, you will obtain the HTML-representation of the original PDF page, as it can be seen in Adobe Reader. I’ve attached this output HTML in ZIP archive to this topic, you can find it below.

IN0001_2022-23-embedded-page1.zip (97.7 KB)

Also this flag is described in official documentation here.

Hope this helps.

With best regards,
Denis Gvardionov

fadip · July 10, 2025, 7:58am

Hi Denis,

Thank you for your detailed response and for providing a working solution using the EnableLayeredRendering flag in HtmlViewOptions.PdfOptions.

After testing, I can confirm that setting EnableLayeredRendering = true does solve the issue by preserving the correct visual layering, similar to Adobe Reader. However, we observed a significant downside — enabling this flag drastically increases the rendering time. In our tests, rendering a single-page PDF can take upwards of 1 minute, which is not acceptable, especially when rendering multi-page documents.

We understand this behavior is due to the viewer rendering each graphical object as a separate element for accurate Z-ordering. While this makes sense technically, it’s a major performance bottleneck.

Is there any alternative approach or optimization that can:

Preserve the layer order (Z-index) as in the original PDF (i.e., shapes in front of text remain in front),
Without the heavy performance cost of EnableLayeredRendering?

denisgvardionov · July 10, 2025, 10:46am

@fadip

Hi Frangky,

I’ve measured a performance using provided IN0001_2022-23.pdf (166.9 KB) and tested it on .NET Framework 4.6.2 and .NET 6.0 with flag EnableLayeredRendering being enabled and disabled. And the processing time differs, but not so much. In particular, on .NET Framework 4.6.2, when EnableLayeredRendering is disabled by default, it took approx. 3.6 seconds to convert “IN0001_2022-23.pdf” to HTML, while with EnableLayeredRendering being enabled it took 4.9 seconds. For .NET 6.0 it is even little bit faster - 3.4 seconds when disabled and 4.6 seconds when enabled.

So I cannot reproduce the reported 1 minute timespan during rendering. Maybe you’re using some other PDF or using some other code? If yes then please share it so I can reproduce on my side.

Waiting for your reply.

With best regards,
Denis Gvardionov

fadip · September 3, 2025, 1:32pm

Hi Denis,

Apologies for the late reply, and thank you for your detailed response. I tested again on my side and the issue still occurs. With EnableLayeredRendering = true, rendering a 2-page document takes close to one minute, which is much slower than your measurement.

To help reproduce, I’m attaching the exact file we are using (INBIPO0001_2024-25 (2) (1) (1).pdf ). Could you please check with this file and confirm if you see the same slowdown? Also, if there are any recommended settings or optimizations to improve performance while keeping the correct layering, that would be very helpful.

Thanks again for your support.

denisgvardionov · September 3, 2025, 1:57pm

@fadip

Hi Frangky,

In order to understand each other and to eliminate any misunderstandings and confusions, we need from you a piece of source code, which you’re using to render the INBIPO0001_2024-25 (2) (1) (1).pdf file to the HTML. This is required because maybe we’re using different code to measure the performance.

It doesn’t have to be a full-fledged complete project, but only a piece of code, which shows us how you specify the input file, how you create and tune the viewing options, and how file is rendered.

Then we will profile this code with the provided file on our side.

Thanks and waiting for your reply.

With best regards,
Denis Gvardionov

fadip · September 15, 2025, 5:22am

Reply to GroupDocs Support

Hi Denis,

Apologies for the delayed reply, and thank you for your patience.

To help reproduce the issue, I’ve prepared a project based on your public sample from GitHub: GroupDocs.Viewer-for-.NET-UI/samples
Please download it from the Google Drive link that I have provided below.

The only changes I made are:

Set PdfOptions.EnableLayeredRendering = true
Set PdfOptions.ImageQuality = ImageQuality.High
Added a cache clear method on index load, so the first load time is always measured without cached results.

With these settings, rendering the attached PDF (INBIPO0001_2024-25.pdf) takes around 40 seconds for just 2 pages, which is significantly slower than expected.

It looks like the performance degradation comes specifically from combining EnableLayeredRendering with ImageQuality.High. Could you please confirm if this is expected behavior, and if there are any recommended settings or optimizations to improve performance in this case while still preserving the correct layering?

Thanks again for your help,
Frangky Adiputra

denisgvardionov · September 15, 2025, 10:51am

@fadip

Hi Frangky,

Thanks for providing the sample project, now things are much more clear for me and I hope in the items below I will answer on all your questions:

1. I’ve investigated and profiled the attached project and I confirm that on my local machine it takes roughly around 35-40 seconds between clicking on filename on the main page and displaying the actual document content.

2. I want to emphasize that in your sample project you’re setting the ImageQuality.High value for the PdfOptions.ImageQuality option — you have mentioned it by yourself, but this option was never mentioned earlier in this forum thread, but only the EnableLayeredRendering. I’ll explain later why this is important.

3. I want to make a step back and describe a clear distinction between the “GroupDocs.Viewer for .NET” and the GroupDocs.Viewer-for-.NET-UI. The first one is a standalone library, a DLL (roughly saying), which has no GUI at all and have only a public API. “GroupDocs.Viewer-for-.NET-UI”, on the other hand, is an open-source project, a demonstration, that provides a web-UI for the “GroupDocs.Viewer for .NET”. Measuring a performance with “GroupDocs.Viewer-for-.NET-UI” is not fully correct, because this project is not intended to be a production-ready solution; it is just a way to show how “GroupDocs.Viewer for .NET” can be used in web applications.

4. In order to address this I’ve developed a pure .NET console application that uses a “GroupDocs.Viewer for .NET” and nothing more, I tried to do it small as possible, it contains only a few lines of code and two methods. What it does - it converts the “INBIPO0001_2024-25.pdf” (already attached inside this project) to the HTML with different combination of options and measures a performance using a Stopwatch and then writes measured numbers to the console. Here it is:

RenderToHtmlPerformanceSol.7z (336.2 KB)

5. I highly recommend to open and launch this tiny project in Release mode on your machine, but just for the reference here are the results on my machine:

GroupDocs.Viewer, Version=25.8.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'default' options took 5,0587496 secs on iteration #1
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'default' options took 1,6499979 secs on iteration #2
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'default' options took 1,6421109 secs on iteration #3
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'enabled layer rendering only' options took 4,6736339 secs on iteration #1
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'enabled layer rendering only' options took 4,6903255 secs on iteration #2
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'enabled layer rendering only' options took 4,6366784 secs on iteration #3
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'high image quality only' options took 2,3161814 secs on iteration #1
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'high image quality only' options took 2,3078476 secs on iteration #2
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'high image quality only' options took 2,3516725 secs on iteration #3
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'enabled layer rendering and high image quality' options took 24,4529227 secs on iteration #1
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'enabled layer rendering and high image quality' options took 24,7342502 secs on iteration #2
Converting 'INBIPO0001_2024-25__2.pdf' to HTML with 'enabled layer rendering and high image quality' options took 24,6336459 secs on iteration #3

From these numbers we can see the most important thing: when the HtmlViewOptions are default, or only the PdfOptions.EnableLayeredRendering flag is enabled, or only the PdfOptions.ImageQuality = ImageQuality.High is set, the performance is pretty good - from 1.6 to 4.6 seconds. But when the PdfOptions.EnableLayeredRendering = true and PdfOptions.ImageQuality = ImageQuality.High are set simultaneously, the performance falls down to the very bottom. It is not the 40 seconds, but still high enough - 24 seconds.

6. So your initial conclusion is fully correct — the specific combination of EnableLayeredRendering and ImageQuality.High drops the performance. This is because these options actually are treated as “maximum quality at the cost of minimum performance”. And the advice here is not to use this combination if possible.

7. However, if such demand of max quality is a mandatory for you, I can create an analysis request for our developers, whether they can optimize it. But, of course, you should understand that it is practically impossible to achive the performance for the max quality to be the same as for the min quality.

Thanks and waiting for your reply.

With best regards,
Denis Gvardionov