bug#70093: Remove unnecessary `image-tests--map-equal'

> Date: Thu, 16 Jul 2026 15:35:28 +0200
> Cc: [email protected], Stefan Kangas <[email protected]>
> From: David Ponce <[email protected]>
> 
> Le 2026-07-16 à 14:51, Joseph Turner a écrit :
> > David Ponce <[email protected]> writes:
> > 
> >> Le 2026-07-16 à 11:45, Joseph Turner a écrit :
> >>>> Hello,
> >>>>
> >>>> This bug report has been waiting for a resolution for a long time!
> >>>>
> >>>> I have done some further investigation recently, and I believe I have
> >>>> found the cause of the failure that I encounter in the
> >>>> `image—compute-map-and-original-map' test in certain cases
> >>>> (`rotated-map' and `flipped-map').
> >>>>
> >>>> It stems from the use of the `pt' unit in the SVG source to specify
> >>>> the image dimensions.  It turns out this unit is unreliable because it
> >>>> depends on the DPI of the image rendering environment.
> >>>>
> >>>> In my case, the DPI is around 142.  This means the test image
> >>>> dimensions—125pt wide and 116pt high—result in an image size of
> >>>> 246x228 pixels, which the test figures (rectangle, circle, and
> >>>> polyline) only partially fill.
> >>>>
> >>>> It turns out the DPI used to produce the test data is around 96.5,
> >>>> which corresponds to an image of 167x155 pixels, that perfectly frames
> >>>> the test figures (rectangle, circle, and polyline).
> >>>>
> >>>> Please, also note that Firefox for example use a DPI of 96.667 and
> >>>> displays the test SVG as expected with the test figures perfectly
> >>>> framed.  In fact, only Emacs displays the SVG image in a larger
> >>>> viewbox, because it uses the actual display DPI.
> >>>>
> >>>> So, in my case, the rotation and image flip are computed based on a
> >>>> larger image than the one used to produce the test values.  Hence, the
> >>>> failure when results are compared.
> >>>>
> >>>> To confirm, I changed the SVG size definition from:
> >>>>
> >>>> <svg width="125pt" height="116pt" viewBox="0.00 0.00 125.00 116.00"
> >>>>
> >>>> to:
> >>>>
> >>>> <svg width="167px" height="155px" viewBox="0 0 167 155"
> >>>>
> >>>> And—miracle of miracles—all the tests passed! :-)
> >>>>
> >>>> If you can confirm they pass for you as well using the pixel
> >>>> dimensions (see attached patch), I suggest to use that unit for the
> >>>> SVG image size and to finally close this bug.
> >>>>
> >>>> I think the `image-tests—map-equal' function remains necessary to
> >>>> account for rounding errors that lead to slight coordinate variations,
> >>>> visually negligible yet different as far as the `equal` function is
> >>>> concerned.
> >>>>
> >>>> I hope my explanations are clear enough and, above all, that they make
> >>>> sense ;-)
> >>> Hi David!
> >>> Thank you for following up on this issue!
> >>> I think it would be a good idea to additionally test SVGs which use
> >>> `px` like
> >>> <svg width="167px" height="155px" viewBox="0 0 167 155" ...>
> >>> But... perhaps there is also an underlying issue that we would be
> >>> ignoring if we got rid of the current test for SVGs which use `pt` like
> >>> <svg width="125pt" height="116pt" viewBox="0.00 0.00 125.00 116.00"
> >>> ...>
> >>> since users will likely expect Emacs to handle both units.
> >>> I wonder if the tests fail due to a bug in the tests or in image.el.
> >>> Would you be willing to uncomment the end of the
> >>> image--compute-map-and-original-map test?  This part:
> >>>       ;; (with-current-buffer (get-buffer-create "*test image map*")
> >>>       ;;   (erase-buffer)
> >>>       ;;   (insert-image image)
> >>>       ;;   (goto-char (point-min))
> >>>       ;;   (pop-to-buffer (current-buffer)))
> >>> And then switch to the "*test image map*" buffer and see if hovering
> >>> over the images produces the expected change in your cursor?
> >>> If the behavior is wrong, then I suspect a bug in image.el.  In that
> >>> case, perhaps we could use something like org--get-display-dpi to
> >>> calculate the current dpi and factor that in when generating image maps.
> >>> Thank you!
> >>> Joseph
> >> Hello Joseph,
> >>
> >> Thanks for your feedback :-)
> >>
> >> IMO the code in image.el is not the issue; it works as it should.
> >>
> >> The problem lies in the reproducibility of tests using the `pt' unit,
> >> which does not yield an image of identical size in every case; the
> >> size varies depending on the screen DPI used by Emacs, which affects
> >> the coordinate system upon which operations like rotation and flipping
> >> rely.
> >>
> >> For instance, on my system, 125x116pt corresponds to 246x228px.  This
> >> results in something like this, with an expanded frame around the test
> >> figures:
> >>
> >> +------------------+
> >> | A    C           |
> >> | B                |
> >> |                  |
> >> |                  |
> >> +------------------+
> >>
> >> Consequently, rotation and flipping occur within an image larger than
> >> expected, where the test figures end up in the top-left corner. And,
> >> while the rotation and flip results are technically correct, they do
> >> not match the test data, because the coordinates of figures are
> >> transformed based on a larger width and height.
> >>
> >> Rotation 90
> >> +-----------+
> >> |    B    A |
> >> |         C |
> >> |           |
> >> |           |
> >> |           |
> >> |           |
> >> |           |
> >> +-----------+
> >> Flip
> >> +------------------+
> >> |           C    A |
> >> |                B |
> >> |                  |
> >> |                  |
> >> +------------------+
> >>
> >> However, if I adjust the dimensions so the image tightly frames the
> >> test figures, the rotation and flip operations take place within an
> >> image matching the one used to generate the test data, yielding the
> >> expected result (the figures are always tightly framed).
> >>
> >> +--------+
> >> | A    C |
> >> | B      |
> >> +--------+
> >> Rotation 90
> >> +-----+
> >> | B A |
> >> |     |
> >> | C   |
> >> +-----+
> >> Flip
> >> +--------+
> >> | C    A |
> >> |      B |
> >> +--------+
> >>
> >> For my screen resolution, the image size must therefore be 85x79pt or
> >> 167x155px or 29.94x27.79mm for the tests to pass.  I guess that if you
> >> use 85x79pt the tests will fail for you, because your Emacs probably
> >> uses a different DPI than mine.  But you should be able to pass the
> >> tests using the dimensions in px or mm, which are DPI-independent.
> > 
> > Thank you for patiently explaining this issue.  IIUC, the image map
> > generation feature works correctly regardless of variations in DPI on
> > different machines.  However, since the test data currently uses `pt`,
> > which assumes a specific DPI, the tests may break depending on machine
> > DPI.  Therefore, the fix is simply to use `px` instead.
> 
> Exactly :-)
> 
> > 
> > The patch you sent in your last email passes on my machine.  I'm in
> > favor of merging it.
> 
> Thank you for confirming.
>   
> > Thank you for fixing this old bug :)
> 
> You are welcome :-)
> 
> > 
> > Joseph
> > 
> 
> Hello Eli,
> 
> Could you please apply the attached fix to the "master" branch and close
> this ticket at your convenience?

Done.