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