Open nirajan-pant opened 7 years ago
Will it be fixed some day? Is this because it uses the GDI+ Bitmap constructor, which has width and height limitations, and you put a limit to prevent it from crashing?
It looks like this Flag is needed.
PdfRenderFlags.CorrectFromDpi
Does it means that the PDF informations about the size in my file are broken? I noticed that the returned size is wrong both in Pdfium and in PDFNet.
That's correct. The DPI by itself doesn't do anything and the flag is needed to actually increase the resolution of the resulting image. The height and width are then modified from the passed height and width, which are taken from the page size by default. This also causes the height and width of the resulting Bitmap
to increase.
I'm not sure whether this behavior is easily changed, especially since this is part of the public API. Are you able to work around this issue?
There is a place in the main RenderPDFPage method where the difference between the Graphics DPI and the specified DPI creates a ratio that is ultimately PInvoking ModifyWorldTransform (https://msdn.microsoft.com/en-us/library/windows/desktop/dd145060(v=vs.85).aspx) which should multiply the resulting rendered image dimensions by the ratio.
It would be interesting to see what is actually happening which would require debugging the c++ pdfium library with some high values for dpiX / dpiY.
I tried to adjust dpi of image using the statement
var image = document.Render(page, 600, 600, false);
but the result is not promising. There is no changes with the change in parameter. Could you help to tackle with this issue?