This is not possible because this window belongs to the TWAIN Data Source Manager, it is not a GdPicture window nor a device driver window.

Hi Igor, DocuVieware has been designed to be primarily used with a mouse (or a finger in case of touch device). Those are simply the browser default behavior when the focus is on a scrollable DIV element and we did not implemented specific keystrokes outside of the regular browser behavior as we don...

Hello It seems that it might be a bug, I don't see anything wrong with your code. Could you please open a support ticket on the support platform here: https://support.orpalis.com/index.php?/Tickets/Submit/ and provide the full working code snippet as well as a sample input document so the developmen...

Yes, this is correct, COM components usually require this procedure to be updated without facing issues with registration.

I was thinking about registering on annotation added/edited event, executing JS custom action with annotation ID in params, reading all properties of annotation on the server-side and storing them in DB. Unfortunately, I didn't find any server-side method which could let me to set default propertie...

Unfortunately this is not possible by design, you can't alter any of the built-in elements (whether it is a snap-in or even the toolbar).
The only option is to implement your own palette with the elements you need, all the methods are provided for this purpose.

There is unfortunately not much we can do with so little information. You should consider using the overload that takes an extra parameter that is the file name, in case the file you're truing to load does not have any header for instance, in that case if the file name is omitted, DocuVieware won't ...

Hi Mark,

I will submit this request to the development team and let you know as soon as a decision has been made.

Hi Mark, I don't think this is supported at the moment, I am willing to add this request to the roadmap though. Could you please open a ticket on the support platform and provide every relevant information about this issue? This way I will be able to provide clear and accurate information to the dev...

Hello,

The issue is probably that you do not save the result file after adding the page to it, you just add it (in memory) and then dispose and close the document without saving the modifications. You are missing a call to the TiffSaveMultiPageToFile method before closing the document.

Now the question is if Orpalis recommends the use of RenderPageToGdPictureImage in Windows services or not? The issue is much bigger than just RenderPageToGdPictureImage. For instance DocuVieware, being hosted on a IIS instance, it runs as a service thus it is also impacted by the blank pages issue...

It looks like Microsoft has fixed the issues in the October updates.

Yes, GDI+ rasterization engine is not impacted by this Microsoft blunder, the difference could be about the performances as GDI+ is supposedly slower.
That being said, the difference should be barely noticeable if at all, GDI+ has been greatly improved since a few months.

It seems that "PdfRasterizerEngineWPF" is used by default. Or in some cases "PdfRasterizerEngineHybrid" one? That's correct, default is PdfRasterizerEngineHybrid. This one seems to be the trouble-maker: KB 4040972 This is only partially true for Windows Server 2012 R2, other versions have different...

This is a known problem introduced by Microsoft lately. See https://connect.microsoft.com/VisualStudio/feedback/details/3141218 You can of course uninstall the problematic Windows update patch and wait for Microsoft to fix it properly or implement a workaround. The workaround is to use the overload ...