Hi everyone,

As the Engineering Manager of the Reporting team, I want to personally acknowledge the seriousness of this issue and apologize for the impact it has had on your organizations and your clients.

Generating accurate reports is one of the core promises of our product. When reports contain incorrect content, we understand that the consequences extend well beyond a technical problem and can affect customer trust, business operations, and your own reputation. We recognize the frustration this has caused and sincerely regret that our software put you in that position.

For full transparency, I would like to provide some technical context about the issue and the change that introduced it.

The problem was introduced as part of a series of PDF rendering performance improvements added over the last several releases. The goal of these changes was to address performance limitations in the existing CRC-based image deduplication mechanism, particularly when processing very large images.
To improve performance, we replaced the full-buffer CRC calculation with a sampling-based approach that computes the checksum from a limited number of evenly distributed samples within the image data. Based on our testing, we believed this approach would reliably detect differences between images while significantly reducing processing overhead.
After investigating the reported cases, we determined that the probability of false matches increases for certain large, heavily compressed image formats. In these scenarios, different images may produce identical sampling results and be incorrectly identified as duplicates by the PDF rendering engine, causing one image to be reused in place of another in the generated document.

As soon as the problem was identified, we treated it with the highest priority. The issue has been fixed, and we expanded our test coverage with a comprehensive set of regression tests specifically designed to validate image deduplication behavior across a wider variety of image types, sizes, compression ratios, and content variations. We are also reviewing the validation processes around performance-related optimizations to reduce the likelihood of similar regressions in the future.

For customers affected by this issue, we have already provided custom builds upon request and are ready to provide them to any customer who needs immediate access to the fix. The fix is scheduled to be included in the upcoming official release planned for next week.

We know that restoring confidence requires more than delivering a fix. While we cannot realistically promise that software defects will never occur, we can promise that issues affecting the correctness of generated reports receive our highest level of attention. We take this incident seriously, we have learned from it, and we are using it to improve both our product and our engineering processes.

Thank you for your patience and the candid feedback you've provided throughout this investigation.

Hi Derek,

I have sent the custom build in the private ticket I created on your behalf. Please refer to that ticket for the attached files.

If anyone else would like to validate the custom build before the official fix is released, please open a separate private ticket, and I will send the build assets there as well.

Still, I must mention that this custom build has not been fully tested on our end and should not be used in production. The recommended workaround for production environments remains downgrading to version 20.0.26.402, where the regression is not present.

Regards,
Petar
Progress Telerik

Hi Derek, Eli,

I am sorry to hear that this issue has affected your scenario.

I discussed the same behavior with Eli in their private ticket recently, and as a result of that investigation, we logged the current public item so that the issue can be tracked by other affected customers as well.

We fully understand the impact this issue has on you and others, and we have already identified it and are actively working on a fix. We plan to include the fix in the official release, currently planned for August 12th. If you would like to validate the fix before it is officially released, please let me know, and I can provide you with a custom build as soon as it becomes available, hopefully by the end of tomorrow.

As Eli mentioned, the issue occurs specifically when images have similar content and the same pixel dimensions (for example, 1000x1000), in which case, the PDF rendering may incorrectly cache and reuse one image in place of another, which results in duplicated images in the generated PDF.

One way to avoid the issue is to make the affected images have different pixel dimensions, as this prevents them from being treated as identical. However, I fully understand that this is not a practical workaround, especially if your reports contain hundreds or thousands of images that may potentially be affected.

Another temporary workaround would be to downgrade to 20.0.26.402, which is the version before the regression was introduced.

We sincerely apologize for the inconvenience this issue has caused and appreciate your understanding.

Regards,
Petar
Progress Telerik