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
