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.
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.
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?
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.
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.
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.
Steps to Reproduce: