However, for the sake of technical conversation, what would you say to those that say that ppi != dpi, so in effect pixels are not mapped 1 to 1 to dots when printed?
Is it true? Does it matter?
Yes, it's true. Does it matter? It depends...
First off, I'm assuming from your use of the "!=" operator, that you have programming experience, and thus a mathematical/logical/technical bent. Also, you've opened the door to "technical conversation". The above are my excuses for talking about things perhaps not appropriate for "Beginner's Questions".
The process of going from "continuous tone" or "contone" (an image processing word that encompasses pixel encodings of more than one bit per color plane) pixels, to printer "dots" is called "halftoning", a word that dates back to the days when part of the process for making plates for printing presses involved photographing the contone work through a piece of processed film called a screen onto a piece of lithographic film.
Now that printers can produce different sized dots, the dichotomy between the pixels in the file and the ink on the paper is not as stark. But the convention remains: contone data in the image file = pixels, and the data that the printer driver send to the print head = dots. The pitch of the contone file is therefore measured in pixels/inch, and the pitch of the "image" that the driver sends to the print head is measured in dots/inch. And, as you so succinctly put it ppi != dpi, at least not as a rule.
There are many halftoning algorithms. They are usually divided into two categories, which I will call “ordered dither” and “stochastic”. The division is somewhat arbitrary, and some techniques fall outside of the mainstream or borrow from both poles.
In ordered dither, each contone pixel is used to generate a pattern of dots that, when combined on the paper and viewed from a distance by a person, can represent some significant portion of the various tones that contone pixel can take on. Thus, for ordered dither, the original contone image has to be resampled into pixels that the printer driver will turn into groups of dots. A 10x10 array of dots can represent 101 different tones (warning: fencepost situation). If a printer using that sized dot array printed dots on a 1440x1440 dpi grid, the printer driver would want an image of 144 pixels/inch. If it didn’t get the contone image at that resolution from the app doing the printing, it would need to resample the image before printing it. The least computationally intensive resampling algorithm is called “nearest neighbor”, and that algorithm is typically used by printer drivers because it is, in programming vernacular, “inexpensive”.
In stochastic halftoning, there is usually some algorithm that looks at the contone pixel and makes a decision about what dot or dots to put down based on the value of the pixel and the dots that it has already put down, or already decided to put down. One such algorithm is called “error diffusion”, and the printer driver keeps track of the difference between the putative tones of the dot array it’s already generated and the tones in the image. It’s interesting to note that with error diffusion, decisions made by the printer driver at the upper left hand corner of the image can affect the ink that it lays down at the bottom right corner. Error diffusion by itself then to produce some visually unpleasant snaky patterns; spectrally shaped noise (“blue noise” is the term of art) is added to the dot array to break up those patterns. That last operation is what gives stochastic halftoning its name.
When using stochastic halftoning, there is no strict need for the driver to resample the contone image. It’s possible to write code that deals well with different dpi and ppi pitches. However, there will be interpolation operations in the code that algorithmically look like those involved in resampling.
From now on, what I have to say only pertains to Epson printers and Epson drivers, because those are the only implementations on which I claim some expertise. The Epson printer drivers resample images sent to them to 360 ppi, or 720 ppi if the “finest detail” box is checked. About two years ago, I demonstrated that through a series of photomicrographs of test images that you can see in this post
and the preceding ones. The resampling that the Epson driver uses is nearest neighbor, which I demonstrate in another post that part of that series.
Now, finally, we get to the “does it matter part”. In the case of the Epson printer driver, it does. See this post
in which a test image is resampled by nearest neighbor and by other algorithms; if you have a choice, you don't want your images resampled by the algorithm used by the Epson driver, and you should resample to driver resolution before you print with the Epson driver.