PDF DPI Settings

rbuser

Hi,

This has come up recently so I thought I'd post to find out if there's a solution yet or put in a feature request if not (or we've missed a setting somewhere).

Currently we still use TExtraDevices for PDF as it allows us to set the DPI for the resultant file. If we use the RB one the area we are given to render onto is far too small due to an internal assumption of 72dpi (A full A4 is ony 612x712 at that setting). We allow the user to specify up to 600dpi.

I looked at the RB code about 6 months ago and it didn't look possible to change it without having to maintain a patch against the source (which I'd rather not do, as it becomes a headache making sure everyone has the same version).

If it's not doable already can we put in a feature request?

Tony

--
Free News Reader
http://put.hk
http://put.hk/reader/news.digital-metaphors.com/digital-metaphors.public.reportbuilder.general.html

nicocizik

Hi Tony,

I am a bit unclear about what a DPI setting for PDF would do.

The PDF format renders text, graphics, etc. with specific instructions
(vector graphics) similar to a windows metafile. This way when a PDF
file is zoomed or printed to a high DPI printer, the PDF file itself is
not scaled but rather re-drawn at the new resolution.

Images embedded into a PDF file may benefit from a higher DPI setting
because images are in fact scaled when a PDF is zoomed or printed. This
is due to the fact that most image formats are pixel based and therefore
have a static size. This is something that would be better handled in
the report rather than PDF.

rbuser

On 18/12/2014 15:06, Nico Cizik (Digital Metaphors) wrote:> Hi Tony,
Internally RB calls our TppJITPipeline.GetFieldAsPicture, which expects
a TPicture result. We query the field size in mm, then return a bitmap
that's correct for the DPI setting the user has chosen. These are
rendered on the fly from application data.

Unfortunately RB then rescales it back to 72dpi. This leads to a poor
result when the PDF is printed.

TExtraDevices lets us set the DPI explicitly so the PDF always looks
nice when printed. Since that hasn't really been developed since 2010
it's not ideal from a support point of view to keep using it going
forward, hence my query.

Tony

nicocizik

Hi Tony,

Try setting the PDFSettings.ScaleImages property to False and see if
that solve the problem. This is the only reason an image being exported
to PDF would be scaled in ReportBuilder.

If you are loading templates, be sure to set this property after the
template is loaded.

rbuser

On 19/12/2014 15:41, Nico Cizik (Digital Metaphors) wrote:
Alas that makes no difference - it scales the image down anyway.

After a quick look I suspect the problem is in
TppPDFRendererImage.ProcessImage where it sets ldImageHeight based on
screen resolution, but the time of year is catching up and I don't have
time to run some tests before the holidays..

Here are two PDFs, both printed using the same software/data at 600dpi.
One using RB PDF with ScaleImages = False and One via TExtraDevices.

https://drive.google.com/file/d/0B8PfgNRkTBWpdGJxeDA1QjhaSVk/view?usp=sharing

https://drive.google.com/file/d/0B8PfgNRkTBWpd1pOMGNiYmJESnc/view?usp=sharing

Tony

nicocizik

Tony,

As I mentioned before, the only way an image is "scaled" would be if the
ScaleImages property is set to true. The ProcessImage routine defines
the size of the box the image will be placed inside the PDF page. This
is not related the number of pixels the image contains (which is what
scaling would alter).

ReportBuilder compresses all pixel-based images to JPEG format before
exporting them to save space which could be causing the detail loss.
You can try reducing the compression level using the
PDFSettings.ImageCompressionLevel property or avoid using JPEG
compression altogether by setting the PDFSettings.UseJPEGCompression
property to False.

If, after trying the above, you still get a low resolution image, please
create a simple example with a report that demonstrates this and I will
track down what is happening. Send the example in .zip format to
support@digital-metaphors.com.