Ok, given that the real fix of having tex4ht work at least partially in pixels is difficult, it still seems like there should be a way to fix this.
Zeroth, the only reason the image is close to right in the browser is because the browser is ignore the 'pt' (and probably the decimal) and taking the number as a pixel count. The reason its not completely "right" is because its outputting TeX points, not PostScript. The attached HTML file demonstrates how different px and pt are in CSS. On my screen, 1 inch and 100 pixels are the same, and 100 points and 1.388… inch are the same. First, I doubt the roundoff error is going to actually happen. It seems to be working with several places after the decimal, and we only have to be right to the integer (can't have fractional pixels). So, it'd take really large numbers before round-to-nearest doesn't produce the correct result. Second, it seems the whatever PNG->EPS->PNG process LyX and tex4ht performed managed to produce a final PNG of the same pixel size as the original. Third, my .bb process (which assumed 1px = 1 PostScript pt) produced the same widht/height output in the HTML file. So, really, all that needs to be done is: Get the width/height from the either generated or supplied PNG image. Use these for the <img> tag. *or* 1. Have tex4ht output the width/height in PostScript points, not TeX points. 2. Round the width/height to the nearest integer. 3. Have tex4ht not output the letters 'pt' at the end. Neither of these are proper fixes, of course, but hopefully they are easy...Title: Test
1 inch
100 pixels
100 points
1.388... inch