Hi Devs,
while investigating an issue about media quality loss in media report I recognized that it happens in all PDF reports. As far as I know the PDF docgen is using cairodoc which is using libcairodoc. I suspect that the draw method of GtkDocPicture in libcairodoc is causing the problem, but I’m unable to understand what exactly is causing it. It’d be great if someone with more knowledge about it could help solving that issue.
Did a bit of searching and found some interesting leads but not a definitive answer yet.
Everything points to Cairo being targeted at vectorized data and strongly biased against rasterized/bitmapped images (such as scanned images & screen captures). So Cairo is excellent for Gramps generated charts in PDFs but not great for including Media of TIFF, PNG, JPG, or GIF file types.
The Cairo docs note that if dpi is set to ‘auto’, the resolution is determined by the backend. Other posting suggest that this defaults to looking at the screen resolution of the device generating the PDF. It then converts rasterized image resolutions to suit web resolution, not print.
Most screen resolutions have been 72dpi while scans (for print) tend to be 300 dpi or better. The net result would be a 76% loss of quality which affects only rasterized insertions. And the loss of quality would not be apparent during previews (which are at screen resolution) but only during print or when zooming in.
All indications are that you REALLY have to push Cairo to generate print-grade rasterized image quality and to properly support transparency.
2 Likes
Are either of these pertinent?:
I think the main reasons why no one recognized this problem before is that all reports only add small-sized pictures where the media quality dosn’t matter that much. My media report allows adding large page-filling pictures, so the loss in quality becomes obvious.
I’ve already created a working fix pull #1 and pull #2, but I’m unsure if it’s a good solution for this problem. Gramps does set the dpi value for the documents to 72dpi, so I added an optional parameter which can be used by addon developer to include images with a higher dpi value into the reports. @prculley suggested that we could just set the default dpi value to 300 instead of using an optional parameter.
1 Like
300dpi was OK for home laser printers a decade ago. Even the under $200 Printers exceed that dpi currently. It is definitely insufficient for commercial reproduction.
If there are aspirations to make Gramps useful for professional Genealogists, then a parameter would be needed. It is a “Judgement call.”
I agree with you on this, and in addition when you know that Epson use another standard dpi than most other printers (360 dpi, 720 dpi, 1440 dpi and so on) and will do a recalculation of the resolution if given a 200, 300, 500, 600 and so on dpi print file that can actually compromise the quality on large rasterprints (inkjet), It cant be seen on “normal” print sizes, but on larger prints, it can be detected in some cases… this is something thats know to any photographer printing large format prints…
(If we use a Canon or other “300 dpi” printer, we use 300, 600 etc. if we use a Epson we make the finished image in formats that can be divided with 360/720 and so on…
So a customizable parameter would be the “professional way” to do any prints, regardless of its to a printer or a file (pdf, raster image)…
the web reports will also benefit from this, by be able to create larger pixel sized images (ppi).
2 Likes
An option to define the output resolution for a pdf file sounds like it would be useful.
1 Like
One thing was noted that was intriguing. It suggests PDF supports being adaptive on rasterized inserts.
There was a mention that considering the original resolution of the inserted images is valuable when generating the PDF.
Cairo will only degrade an image (and needlessly increase the filesize of the PDF) if it tries to increase the resolution above that of the original source. So, if the image is 290dpi & the target parameter is 300dpi, the less degrading choice would be to generate that specific insert at 290dpi. It went on to point out that compression of fractionally scaled bitmaps tends to less efficient.
It also reminds that Cairo was developed as a “toy” and was not originally expected to be used for production. (That seems to often be the case. Don Allingham writes repeatedly that he expected Gramps to be a mere curiosity when he bowed to his father’s push for a public release. He on expected a couple comments & that no one would actually use it.) The posting further suggested that the printer driver would do a better job of interpolating if the image had not been doubly scaled.
However, there was no example code of how to be adaptive nor a technical reference to PDF supporting DPI insertions in this way.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.