On 2015-10-14 16:59 (+0200), Enno R. Oldewurtel wrote:
Just for my own understanding:
This object property is something that gets saved when exporting the svg to a pdf or eps again, correct?
Confirmed for PDF, not tested with PostScript format (unknown to me whether PostScript does know such a interpolation mode for bitmap images, as also mentioned by Jasper in bug #1174651).
Do pdf/eps viewer then render the bitmap according to whichever property was set?
Again, locally only tested with PDF files (and a limited varity of PDF viewers) - results seem to depend on the PDF viewer: - works with Evince 3.16.1, poppler 0.36 - fails with Apple's Preview.app on OS X 10.7.5 Lion (outdated!) - works with Evince 2.30.3, poppler 0.18 (outdated!)
Does that mean that eps/pdf viewer which do not read this property, might render the bitmap with interpolations again, i.e. depending on the viewer program the bitmap might appear blocky or smoothed?
I don't know - you'd have to check details about the specific PDF viewer, as well as whether the PDF specs possibly include details about what to expect if a viewer does not support flags like 'interpolate'. The specific optional interpolation mode for images in PDF files is is already described in the oldest PDF spec available at Adobe's site (PDF Reference, Second Edition, version 1.3 from Jul 3 2000):
Image Interpolation
When the resolution of a source image is significantly lower than that of the out- put device, each source sample covers many device pixels. This can cause images to appear “jaggy” or “blocky.” These visual artifacts can be reduced by applying an image interpolation algorithm during rendering. Instead of painting all pixels covered by a source sample with the same color, image interpolation attempts to produce a smooth transition between adjacent sample values. Because it may increase the time required to render the image, image interpolation is disabled by default; setting the Interpolate entry in the image dictionary to true enables it.
Note: The interpolation algorithm is implementation-dependent and is not specified by PDF. Image interpolation may not always be performed for some classes of images or on some output devices.
(identical text e.g. in PDF 1.3 and PDF 1.5 spec - Inkscape defaults to PDF 1.5 for export).
A quick web search finds results like e.g. http://superuser.com/questions/358134/pdf-rendering-of-images-seems-to-vary-... (it's from 2011, I can't tell whether the situation has improved since then)
That would also mean that the original image/pixel information always gets exported to pdf/eps, but it is only the rendering which make them appear differently, correct?
Yes (AFAIU bug #168434 for PNGs was fixed a long time ago, bug #168708 for JPEGs is fixed in Inkscape 0.91).
Ideally, I would like to produce eps and pdf that will always show the bitmaps blocky (at least when having a zoomed image with very large pixels), independent of the viewer program.
Based on the original topic of this thread ("Subject: when importing pdf/eps (...)"): Please keep in mind that round-trip editing PDF (or PS/EPS) files with Inkscape is not guaranteed to keep appearance 100% identical - the quality might degrade over time (with each round-trip editing) depending on the actual original content (and content added in Inkscape), since the file formats (PDF/PostScript/SVG) differ in how which set of features are supported (not just image rendering mode).
Inkscape's import and export of PDF- and PostScript-based file formats depend on external tools and libraries, so apart from bugs or missing features in Inkscape itself (plenty of those), any upstream issues in specific versions of ps2pdf from Ghostscript (PS/EPS -> PDF)[1], poppler (PDF -> SVG) and cairo (SVG -> PDF/PS/EPS) might additionally affect results.
hth, V
[1] Inkscape's PS/EPS import uses ps2pdf from Ghostscript to convert the PostScript-based files to PDF, and them imports the PDF file using internal routines (based on poppler as parser). Export to PostScript-based formats OTOH is handled internally, based on cairo.