bug#52929: 27.1; Images are sometimes not fully displayed

bug#52929: 27.1; Images are sometimes not fully displayed

[Markus Triska]

Dear all,

to reproduce this issue, please download the following image:

    https://www.metalevel.at/ei/202202.png

Then start Emacs with

    $ emacs -Q

and evaluate the form that follows below.

Please note that the image has geometry 202x202. The form creates a
frame with this height and width. It uses a default face with height 1px
to allow pixel exact resizing of the frame. The snippet then waits for a
keypress, and then deletes the frame again.

The frame is large enough to display the image fully, including the thin
border that is drawn around the image. This can be seen by changing
"(setq cursor-type nil ..." to "(setq cursor-type t ..." in the snippet,
in which case the image is fully shown in the frame.

Yet, with the snippet as shown below, the thin border around the image
is not shown at the right margin of the image: You can see that the
frame appears fully white at the right, whereas all other margins of the
image (left, top and bottom) do display the very thin black border fully.

If the following line, which is commented out in the snippet, is
enabled, i.e., if the width is increased by exactly 1 pixel, then also
the thin border on the right is fully shown:

    (set-frame-width frame (1+ width) nil t)

If possible, I would prefer Emacs to show the image fully also if its
exact dimensions (202x202) are used for the frame size. Is there a way
to do this?

Thank you a lot, and Happy New Year 2022!
Markus

    (let* ((width 202)
           (height 202)
           (frame (make-frame `((parent-frame . ,(selected-frame))
                                (minibuffer . nil)
                                (left . 100)
                                (top . 100)
                                (internal-border-width . 0)
                                (vertical-scroll-bars . nil)
                                (left-fringe . 0)
                                (right-fringe . 0)
                                ;; not setting the width/height causes
                                ;; mode line flickering (see #52666)
                                (width . (text-pixels . ,width))
                                (height . (text-pixels . ,height))))))
      ;; set 1 pixel height default face, to allow pixel exact resizing
      ;; of the frame
      (set-face-attribute 'default frame :height 10) 
      ;; set the height and width again, since set-face-attribute
      ;; resizes the frame
      (set-frame-width frame width nil t)
      ;; enable the following line to display the border fully
      ;; (set-frame-width frame (1+ width) nil t)
      (set-frame-height frame height nil t)
      (with-selected-frame frame
        (switch-to-buffer (get-buffer-create "Happy New Year 2022!"))
        (setq cursor-type nil
              mode-line-format nil)
        (erase-buffer)
        (insert-image-file "202202.png"))
      (read-key)
      (delete-frame frame))


In GNU Emacs 27.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
 of 2020-12-12 built on macbook
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
System Description:  Mac OS X 10.11.3

Configured using:
 'configure --prefix=/opt/local --disable-silent-rules --without-ns
 --without-dbus --without-gconf --without-libotf --without-m17n-flt
 --with-gmp --with-gnutls --with-json --with-xml2 --with-modules
 --infodir /opt/local/share/info/emacs --with-x-toolkit=lucid
 --without-xaw3d --without-imagemagick --with-xpm --with-jpeg
 --with-tiff --with-gif --with-png --with-lcms2 --without-rsvg
 --with-xft 'CFLAGS=-pipe -Os -arch x86_64'
 CPPFLAGS=-I/opt/local/include 'LDFLAGS=-L/opt/local/lib
 -Wl,-headerpad_max_install_names -lfreetype -lfontconfig -Wl,-no_pie
 -arch x86_64''

Configured features:
XPM JPEG TIFF GIF PNG GSETTINGS GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2
FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM
MODULES THREADS JSON PDUMPER LCMS2 GMP

bug#52929: 27.1; Images are sometimes not fully displayed

[martin rudalics]

 > Yet, with the snippet as shown below, the thin border around the image
 > is not shown at the right margin of the image: You can see that the
 > frame appears fully white at the right, whereas all other margins of the
 > image (left, top and bottom) do display the very thin black border fully.
 >
 > If the following line, which is commented out in the snippet, is
 > enabled, i.e., if the width is increased by exactly 1 pixel, then also
 > the thin border on the right is fully shown:
 >
 >      (set-frame-width frame (1+ width) nil t)
 >
 > If possible, I would prefer Emacs to show the image fully also if its
 > exact dimensions (202x202) are used for the frame size. Is there a way
 > to do this?

Please try with adding a (no-special-glyphs . t) entry to the parameters
of the child frame.

martin

bug#52929: 27.1; Images are sometimes not fully displayed

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> Please try with adding a (no-special-glyphs . t) entry to the parameters
> of the child frame.

This solves the issue completely, thank you a lot for this! Could you
please briefly explain why this is necessary to fully show the image? In
particular, which glyph was shown here that used the 1 pixel width?

Thank you again,
Markus

bug#52929: 27.1; Images are sometimes not fully displayed

[martin rudalics]

 >> Please try with adding a (no-special-glyphs . t) entry to the parameters
 >> of the child frame.
 >
 > This solves the issue completely, thank you a lot for this! Could you
 > please briefly explain why this is necessary to fully show the image? In
 > particular, which glyph was shown here that used the 1 pixel width?

When a window has no right fringe, Emacs by default usurps the rightmost
character on each text line so it can indicate there whether that line
is truncated or continued.  The maximum width of the special glyph to be
displayed there (typically a "$" or a "\") is subtracted from the
maximum width of the display area of that window.  So with the right
fringe turned off, you as a rule always lose one column to the display
engine even when displayed lines are never truncated or continued.

But Eli can explain it better.

Note that with current master you need not calculate the size of your
image yourself.  Emacs can do it for you as with

(with-current-buffer (get-buffer-create "Happy New Year 2022!")
   (setq cursor-type nil mode-line-format nil)
   (erase-buffer)
   (insert-image-file "/home/martin/Downloads/202202.png")
   (let* ((size (buffer-text-pixel-size))
	 (width (car size))
	 (height (cdr size))
	 (frame (make-frame `((parent-frame . ,(selected-frame))
			      (no-special-glyphs . t)
			      (minibuffer . nil)
			      (left . 100)
			      (top . 100)
			      (internal-border-width . 0)
			      (vertical-scroll-bars . nil)
			      (left-fringe . 0)
			      (right-fringe . 0)
			      (width . (text-pixels . ,width))
			      (height . (text-pixels . ,height))))))
     (read-key)
     (delete-frame frame)))

With Emacs 27 you would have to use 'window-text-pixel-size' or
'fit-frame-to-buffer' which both have the problem that you first have to
put your buffer into a window in order to resize it appropriately.

martin

bug#52929: 27.1; Images are sometimes not fully displayed

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 1 Jan 2022 17:01:27 +0100
> Cc: 52929@debbugs.gnu.org
> 
> When a window has no right fringe, Emacs by default usurps the rightmost
> character on each text line so it can indicate there whether that line
> is truncated or continued.  The maximum width of the special glyph to be
> displayed there (typically a "$" or a "\") is subtracted from the
> maximum width of the display area of that window.  So with the right
> fringe turned off, you as a rule always lose one column to the display
> engine even when displayed lines are never truncated or continued.
> 
> But Eli can explain it better.

I think you explained it very clearly, I have nothing to add, except
the obvious: the no-special-glyphs frame parameter, if its value is
non-nil, suppresses the display of the truncation and continuation
glyphs, and thus the column that the display engine needs for that is
free for other needs.

bug#52929: 27.1; Images are sometimes not fully displayed

[Markus Triska]

Thank you very much for these explanations, I have closed this issue!

The new function buffer-text-pixel-size will be especially useful for me
in new Emacs versions!

For older Emacs versions, image-size may be useful, I have filed #52931
for an issue I found with it.

Thank you and all the best,
Markus