Please give a brief summary of your issue:
SaveViewerOptimized does not allow to set compatibility flags
Please describe your issue and provide steps to reproduce it:
We are currently using the SDK at the backend to perform linearization and set some compatibility flags on documents to produce PDFs that work well with other features of the system, including web viewer. The sample call is:
using var pdfDoc = new PDFDoc(source);
pdfDoc.Save(output, SDFDoc.SaveOptions.e_linearized | SDFDoc.SaveOptions.e_compatibility | SDFDoc.SaveOptions.e_hex_strings);
We are considering using the Viewer-optimized saving instead, which is supposedly even faster to display in the web viewer for complex documents and also includes linearization. The sample call is:
using var pdfDoc = new PDFDoc(source);
using var options = new ViewerOptimizedOptions();
options.SetMinimumInitialThumbnails(1);
options.SetThumbnailRenderingThreshold(50);
options.SetThumbnailSize(1024);
pdfDoc.SaveViewerOptimized(output, options);
However, there is no possibility to set the low-level compatibility flags as we did in the previous example. Some files produced this way are currently breaking one of our other features. Specifically, I narrowed it down to not having the e_hex_strings flag set.
I’m looking for a possibility to set the compatibility flags on the viewer-optimized version or any other workarounds to having a resulting PDF be both viewer-optimized and compatible. Thanks!
P.S. I have considered doing a two-pass, SaveViewerOptimized followed by the old save, but I’m afraid it will negate the optimizations done by SaveViewerOptimized or otherwise break the document
The option to add different save flags is most likely an intentional choice as the compatibility options save it as PDF version 1.4 with no compressed objects which may impact the actual viewing experience.
However, I have gone ahead and reached out to our development team to further inquire about the specifics.
In the meantime, could you share a bit about how not having e_hex_strings set breaks one of your features? Was there a reason you choose to originally save with this flag on?
We appreciate your patience while we look into this.
Hi! Its quite an old system in this regard but I assume these decisions were made to ensure other stuff worked with the generated PDFs. The feature is related to PDF encryption and the native library that is used is also quite old with no newer versions available, sadly. It basically crashes with memory corruption for some files unless we apply this “encode string as hex values” transformation which is enabled by that flag.
We just heard back from the team in regards to this. As mentioned, not being able to pass the save flags to the SaveViewerOptimized method is expected. This is because we use the recommended flags, and other optimizations, to get the best accuracy, speed, and compatibility for modern viewing on the web.
With that being said, the two pass saving you mentioned previously may actually still result in some improvements as well. However, the second save will lose some of the improvements like the compressed objects so you may see increased file sizes, and you may not be able to take full advantage of all the features but this should still give you page thumbnails for rendering in WebViewer.
So, if you need the hex strings, you can try the two pass save by first saving with SaveViewerOptimized, and then a second save with your previous flags. This should give you as close to both options as possible, but we would still recommend running your own tests to verify.