This is a constant problem and recurring thread in this forum, often ending with some unhappiness and frustration. My suggestion is that the very able moderators combine all the threads - there are quite a few! - that refer to this issue into a folder and stick it to the top of the forum or maybe even give it its own forum in the board index.
That way lazy people (like me) don't have to tediously search through all the posts to find and refer to the various proposed solutions.Here
is a topic about this problem and Ivan Louette's very nice filter solution. Another thread
that contains some possibly useful info - not to the OP but perhaps to others.
This might explain the difference between 'combine' and 'union'. CAM output doesn't care if your PNG export has gaps in it so you could have two files, one for CAM and one for PNG export. Admittedly this is extra work.
At one time I did some experimentation and found this solution
. Unfortunately if you read the followup post changes were made to the renderer that resulted in this solution not working and it may not have been a complete solution anyway.(Using multiples of 5 for lineless onscreen display still works, though, if nice clean screenshots are your goal.)
A more complicated way to look at it is to say that if the objects are strokeless and are snapped to the pixel grid, multiples of 90 will always work
. Some other multiples of numbers will work as well. The seam needs to fall on a whole number and the PPI also needs to be a whole number. 300 ppi does not work because 70 (width of the left object)/90 times 300 = 233.33, so the seam does not fall on a whole number pixel. But 72 Ppi works because 70/90 times 72 = 56. If you have more than one seam you can see that only multiples of 90 are going to be practical for export, as Lazur suggested.
The whole subject of bitmap export with sharp edges is troublesome if, as you say, you don't want to 'alter' the drawing. Combining paths is the least destructive solution to exporting at random (in relation to object dimension) DPIs but it also seems to be unsatisfactory...
Although some people have called it a bug in my current build of Inkscape the DPI is altered from what you enter if you make an impossible request. So in this case when I ask for a 300PPI export of an object that is 110 pixels wide at 90 PPI (internal Inkscape resolution), Inkscape corrects the request to reflect that the closest possible export is 367 px wide at 300.27 PPI. (Sometimes you have to click in both the width and height boxes to see this). So in fact I - or anyone! - can't ever export the drawing in question at 300PPI. This upsets some people much more than it should!