GNU bug report logs - #52929
27.1; Images are sometimes not fully displayed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52929 in the body.
You can then email your comments to 52929 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Images are sometimes not fully displayed
Date: Sat, 01 Jan 2022 10:00:24 +0100

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

Message #8 received at 52929 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Markus Triska <triska <at> metalevel.at>, 52929 <at> debbugs.gnu.org
Subject: Re: bug#52929: 27.1; Images are sometimes not fully displayed
Date: Sat, 1 Jan 2022 11:06:41 +0100

> 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

Message #11 received at 52929 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 52929 <at> debbugs.gnu.org
Subject: Re: bug#52929: 27.1; Images are sometimes not fully displayed
Date: Sat, 01 Jan 2022 11:11:34 +0100

martin rudalics <rudalics <at> 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

Message #14 received at 52929 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Markus Triska <triska <at> metalevel.at>
Cc: 52929 <at> debbugs.gnu.org
Subject: Re: bug#52929: 27.1; Images are sometimes not fully displayed
Date: Sat, 1 Jan 2022 17:01:27 +0100

>> 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

Message #17 received at 52929 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: triska <at> metalevel.at, 52929 <at> debbugs.gnu.org
Subject: Re: bug#52929: 27.1; Images are sometimes not fully displayed
Date: Sat, 01 Jan 2022 18:17:37 +0200

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 1 Jan 2022 17:01:27 +0100
> Cc: 52929 <at> 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.

Message #22 received at 52929 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 52929 <at> debbugs.gnu.org
Subject: Re: bug#52929: 27.1; Images are sometimes not fully displayed
Date: Sat, 01 Jan 2022 18:06:33 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.