bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Dale Sedivec]

[-- Attachment #1.1: Type: text/plain, Size: 5370 bytes --]

Using Emacs master with the NeXTStep interface on macOS, I get display
corruption on lines where features such as Flymake, Flycheck, or diff-hl
display something in the fringe.  This is a bit hard to describe, so I'm
attaching a screen shot, and I've also made a short movie of this happening:

https://www.dropbox.com/s/h9eqixqxst4wg37/emacs_27_small_font_fringe_problem.mp4?dl=0

Steps to reproduce:

1. Build or obtain Emacs from master (I did both, report data below is with
nightly build from emacsformacosx.com[1])

2. ~/Applications/Emacs.app/Contents/MacOS/Emacs -Q

3. Change font to Menlo 9 pt (default font here is Menlo 12 pt)

4. M-x find-library RET flymake RET (or open any file where Flymake will
produce anything in the fringe)

5. Turn on Flymake: M-x flymake-mode RET

6. M-x flymake-goto-next-error RET so that point moves to a line where
Flymake has indicated an error/warning/whatever in the left fringe

7. Move left and right on the line (using arrow keys or C-f/C-b)

Expected results: point moves but the line is otherwise unchanged

Observed results: parts/most/all of the line starts turning grey-on-grey as
you move left/right

[1]:
https://emacsformacosx.com/emacs-builds/Emacs-2018-12-24_01-40-33-fd244507c5ea1e7e425f09585fcf15cc90598e9b-universal.dmg

Just to be clear, this makes Emacs GUI unusable for me on macOS as long as
I want to use anything that utilizes the fringe.

Additional information:

* The display corruption will linger on lines if you have multiple lines
with something in the fringe in the viewport and you move vertically
between them

* This problem does not happen with Flymake and the default 12 pt Menlo font

* I have not seen this problem occur on lines without something in the
fringe, even when using the smaller-than-default Menlo 9 pt font

* This doesn't happen for me on the emacs-26 branch at any font size

* I have also reproduced this with the Fira Mono font at 8 pt (which is my
normal font)

I am using macOS 10.13.6 on a late 2013 MacBook Pro 15" that has a Retina
("high DPI") display.

Happy to provide more information or do more troubleshooting, just let me
know.  Thanks!  Dale


In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin14.5.0, NS appkit-1348.17
Version 10.10.5 (Build 14F2511))
 of 2018-12-24 built on builder10-10.porkrind.org
Windowing system distributor 'Apple', version 10.3.1561
System Description:  Mac OS X 10.13.6

Recent messages:

For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Entering debugger...
Back to top level
nil
Flymake mode enabled in current buffer
Mark set
Mark saved where search started [2 times]
Making completion list...

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  flymake-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt bytecomp
byte-compile cconv dired dired-loaddefs format-spec rfc822 mml mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils misearch multi-isearch autoload lisp-mnt checkdoc
cl-macs gv cl-seq flymake-proc flymake compile comint ansi-color ring
warnings thingatpt help-fns radix-tree cl-print debug backtrace
help-mode find-func cl-loaddefs cl-lib vc-git diff-mode easymenu
easy-mmode elec-pair tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 228548 14897)
 (symbols 48 22728 1)
 (strings 32 36845 2246)
 (string-bytes 1 1015461)
 (vectors 16 44960)
 (vector-slots 8 1500556 164302)
 (floats 8 56 213)
 (intervals 56 719 269)
 (buffers 992 17))

[-- Attachment #1.2: Type: text/html, Size: 7456 bytes --]

[-- Attachment #2: Screen Shot 2018-12-24 at 23.39.15.png --]
[-- Type: image/png, Size: 291029 bytes --]

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Eli Zaretskii]

> From: Dale Sedivec <dale@codefu.org>
> Date: Tue, 25 Dec 2018 00:01:58 -0600
> 
> Using Emacs master with the NeXTStep interface on macOS, I get display corruption on lines where features
> such as Flymake, Flycheck, or diff-hl display something in the fringe.  This is a bit hard to describe, so I'm
> attaching a screen shot, and I've also made a short movie of this happening:
> 
> https://www.dropbox.com/s/h9eqixqxst4wg37/emacs_27_small_font_fringe_problem.mp4?dl=0

Looks like the cursor's line is being cleared without telling Emacs
about that.

Does it help to decrease the size of the Flymake's fringe indicators
when you switch to a smaller font?  From the screenshot it looks like
the indicator keeps its original size although the font becomes a lot
smaller.

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Dale Sedivec]

On Tue, Dec 25, 2018 at 7:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Dale Sedivec <dale@codefu.org>
> > Date: Tue, 25 Dec 2018 00:01:58 -0600
> >
> > Using Emacs master with the NeXTStep interface on macOS, I get display corruption on lines where features
> > such as Flymake, Flycheck, or diff-hl display something in the fringe.  This is a bit hard to describe, so I'm
> > attaching a screen shot, and I've also made a short movie of this happening:
> >
> > https://www.dropbox.com/s/h9eqixqxst4wg37/emacs_27_small_font_fringe_problem.mp4?dl=0
>
> Looks like the cursor's line is being cleared without telling Emacs
> about that.
>
> Does it help to decrease the size of the Flymake's fringe indicators
> when you switch to a smaller font?  From the screenshot it looks like
> the indicator keeps its original size although the font becomes a lot
> smaller.

I think I did what you ask by making a bitmap with just a single pixel
turned on:

(define-fringe-bitmap 'smallest
    (vector #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00010000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000))

(setq flymake-note-bitmap '(smallest compilation-info))

Followed by M-x flymake-start RET to re-run Flymake and update the
fringe.  This did not fix the problem: I do see my single pixel fringe
bitmap, but the line still gets corrupted as described in my original
report.

(But please do let me know if you were asking something different.)

Dale

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Eli Zaretskii]

> From: Dale Sedivec <dale@codefu.org>
> Date: Tue, 25 Dec 2018 12:30:01 -0600
> Cc: 33864@debbugs.gnu.org
> 
> > Does it help to decrease the size of the Flymake's fringe indicators
> > when you switch to a smaller font?  From the screenshot it looks like
> > the indicator keeps its original size although the font becomes a lot
> > smaller.
> 
> I think I did what you ask by making a bitmap with just a single pixel
> turned on:
> 
> (define-fringe-bitmap 'smallest
>     (vector #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00010000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000))
> 
> (setq flymake-note-bitmap '(smallest compilation-info))
> 
> Followed by M-x flymake-start RET to re-run Flymake and update the
> fringe.  This did not fix the problem: I do see my single pixel fringe
> bitmap, but the line still gets corrupted as described in my original
> report.
> 
> (But please do let me know if you were asking something different.)

I think I meant to make the indicator bitmap smaller, i.e. have fewer
members in the above vector.  Since you switch to a size-9 font, which
is 3/4 of the default size, how about making the above bitmap have 12
or 13 lines, instead of 17 now?

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Dale Sedivec]

On Tue, Dec 25, 2018 at 12:39 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Dale Sedivec <dale@codefu.org>
> > Date: Tue, 25 Dec 2018 12:30:01 -0600
> > Cc: 33864@debbugs.gnu.org
> >
> > > Does it help to decrease the size of the Flymake's fringe indicators
> > > when you switch to a smaller font?  From the screenshot it looks like
> > > the indicator keeps its original size although the font becomes a lot
> > > smaller.
> >
> > I think I did what you ask by making a bitmap with just a single pixel
> > turned on:
> >
> > (define-fringe-bitmap 'smallest
> >     (vector #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00010000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000
> >             #b00000000))
> >
> > (setq flymake-note-bitmap '(smallest compilation-info))
[...]
> I think I meant to make the indicator bitmap smaller, i.e. have fewer
> members in the above vector.  Since you switch to a size-9 font, which
> is 3/4 of the default size, how about making the above bitmap have 12
> or 13 lines, instead of 17 now?

I reduced the above vector to just 12 lines and the problem still
occurred, same with 10 lines.  Reducing the bitmap to 9 lines,
however, DID FIX the problem.  I saw no corruption on the line when
the bitmap was only 9 lines high.

To be clear, this was the 9 line bitmap that fixed the problem under
Menlo 9 pt font:

(define-fringe-bitmap 'smallest
    (vector #b00000000
            #b00000000
            #b00000000
            #b00010000
            #b00000000
            #b00000000
            #b00000000
            #b00000000
            #b00000000))

(I didn't even realize I could reduce the height of the bitmap in this
way—sorry I misunderstood your original request, I have never used the
fringe APIs before.)

Dale

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Eli Zaretskii]

> From: Dale Sedivec <dale@codefu.org>
> Date: Tue, 25 Dec 2018 13:06:04 -0600
> Cc: 33864@debbugs.gnu.org
> 
> I reduced the above vector to just 12 lines and the problem still
> occurred, same with 10 lines.  Reducing the bitmap to 9 lines,
> however, DID FIX the problem.  I saw no corruption on the line when
> the bitmap was only 9 lines high.
> 
> To be clear, this was the 9 line bitmap that fixed the problem under
> Menlo 9 pt font:
> 
> (define-fringe-bitmap 'smallest
>     (vector #b00000000
>             #b00000000
>             #b00000000
>             #b00010000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000
>             #b00000000))

OK, so I think this has to do with the situation where the fringe
bitmap's height is greater than the vertical size of the default font.

I think this is macOS-specific.

> (I didn't even realize I could reduce the height of the bitmap in this
> way—sorry I misunderstood your original request, I have never used the
> fringe APIs before.)

No need to apologize.  Thanks for taking time to try this.

bug#33864: Acknowledgement (27.0.50; Display corruption with "small" font size when something is in the fringe)

[Dale Sedivec]

I did a "git bisect" on master and I think I traced this to:

commit b58e8b82ededfb314e385d97df1efed2ce84f4db
Merge: febdedfa8d 094fcf62d2
Author: Glenn Morris <rgm@gnu.org>
Date:   Wed Nov 28 07:51:11 2018 -0800

    Merge from origin/emacs-26

    094fcf6 Fix more drawing bugs in NS port (bug#32932)

Strange that I haven't been seeing this in the emacs-26 branch, I will
try and build that again tomorrow to make sure I'm using an Emacs 26
build with the above commit.

Dale

On Tue, Dec 25, 2018 at 12:03 AM GNU bug Tracking System
<help-debbugs@gnu.org> wrote:
>
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-gnu-emacs@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 33864@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 33864: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33864
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems

bug#33864: Acknowledgement (27.0.50; Display corruption with "small" font size when something is in the fringe)

[Alan Third]

On Wed, Dec 26, 2018 at 10:34:32PM -0600, Dale Sedivec wrote:
> I did a "git bisect" on master and I think I traced this to:
> 
> commit b58e8b82ededfb314e385d97df1efed2ce84f4db
> Merge: febdedfa8d 094fcf62d2
> Author: Glenn Morris <rgm@gnu.org>
> Date:   Wed Nov 28 07:51:11 2018 -0800
> 
>     Merge from origin/emacs-26
> 
>     094fcf6 Fix more drawing bugs in NS port (bug#32932)

Ironically I’d expect that commit to fix any issue like this, not
cause it. The previous code would cause the entire line to be redrawn
if there was a fringe bitmap, but the new code should cause just the
bitmap itself to be redrawn.

Although I suppose it might not be the fringe bitmap code that’s
causing this.

> Strange that I haven't been seeing this in the emacs-26 branch, I will
> try and build that again tomorrow to make sure I'm using an Emacs 26
> build with the above commit.

I can’t replicate the issue on either master or emacs-26.

Can you replicate this on any line that has a ‘large’ fringe bitmap,
or is it only certain ones?
-- 
Alan Third

bug#33864: Acknowledgement (27.0.50; Display corruption with "small" font size when something is in the fringe)

[Dale Sedivec]

[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]

On Thu, Dec 27, 2018 at 5:59 AM Alan Third <alan@idiocy.org> wrote:
> On Wed, Dec 26, 2018 at 10:34:32PM -0600, Dale Sedivec wrote:
> > I did a "git bisect" on master and I think I traced this to:
> >
> > commit b58e8b82ededfb314e385d97df1efed2ce84f4db
> > Merge: febdedfa8d 094fcf62d2
> > Author: Glenn Morris <rgm@gnu.org>
> > Date:   Wed Nov 28 07:51:11 2018 -0800
> >
> >     Merge from origin/emacs-26
> >
> >     094fcf6 Fix more drawing bugs in NS port (bug#32932)
>
> Ironically I’d expect that commit to fix any issue like this, not
> cause it. The previous code would cause the entire line to be redrawn
> if there was a fringe bitmap, but the new code should cause just the
> bitmap itself to be redrawn.
>
> Although I suppose it might not be the fringe bitmap code that’s
> causing this.
>
> > Strange that I haven't been seeing this in the emacs-26 branch, I will
> > try and build that again tomorrow to make sure I'm using an Emacs 26
> > build with the above commit.
>
> I can’t replicate the issue on either master or emacs-26.

You would probably know better than I would, but the only possible
relevant differences I can think of are:

* I'm using a smaller font size
* I'm using a Retina (i.e. scaled) display
* I'm using macOS 10.13.6

I tried emacs-26 (9578c2aa2) this morning and I was able to recreate
this problem, though it presents a bit differently than it did on
master: on emacs-26 branch, most any line with a fringe bitmap would
have some portion of the line (I *think* always a prefix of the line)
turning grey-on-grey, as in my original screen shot, but the
grey-on-grey would not change as I scrolled or moved around on the
line.  The corruption was immediately visible when scrolling to the
next error, and it didn't change.

> Can you replicate this on any line that has a ‘large’ fringe bitmap,
> or is it only certain ones?

On emacs-26, I reproduced this on *most* lines with fringe bitmaps
while moving around flymake.el with flymake-mode turned on.  I found
one line that didn't exhibit this problem while on the emacs-26
branch, which was a line with a flymake warning that was something
starting like "  (if ..." as one of the first statements inside a
defun.  (Sorry but I didn't note the line number, and I've rebuilt on
master since then.)

On master, every line with a fringe bitmap seems to exhibit this problem.

I am attaching the Elisp script I used to reproduce this problem while
bisecting, loaded like:

      nextstep/Emacs.app/Contents/MacOS/Emacs -Q --load repro.el

On a bad build, I would see this corruption as soon as I moved the
cursor left/right after running the above script.

Also, here is how I ran configure:

./configure --with-ns \
            --with-modules --with-rsvg --with-imagemagick \
            --with-xml2 --with-gnutls --without-x

Please let me know if I can provide any more information.

Dale

[-- Attachment #2: repro.el --]
[-- Type: application/octet-stream, Size: 131 bytes --]

(set-face-attribute 'default (selected-frame) :font "Menlo 5")
(find-library "flymake")
(flymake-mode 1)
(flymake-goto-next-error)

bug#33864: Acknowledgement (27.0.50; Display corruption with "small" font size when something is in the fringe)

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Thu, Dec 27, 2018 at 09:45:57AM -0600, Dale Sedivec wrote:
> You would probably know better than I would, but the only possible
> relevant differences I can think of are:
> 
> * I'm using a smaller font size
> * I'm using a Retina (i.e. scaled) display
> * I'm using macOS 10.13.6

These are all the same, but...

> I am attaching the Elisp script I used to reproduce this problem while
> bisecting, loaded like:
> 
>       nextstep/Emacs.app/Contents/MacOS/Emacs -Q --load repro.el

This reproduces instantly, like you say. Thank you! It looks to me
like the fringe background colour is being drawn right across the
line, which makes me think that the calculation to work out what to
blank in the fringe is going wrong.

I think that what’s happened is I’ve misunderstood one of the NS
rectangle function’s descriptions and assumed it did more error
checking than it does. It looks like the fix is simply to check that
the area that’s to be cleared is actually a legitimate rectangle.

Patch attached.
-- 
Alan Third

[-- Attachment #2: 0001-Fix-NS-fringe-bitmap-drawing-bug-bug-33864.patch --]
[-- Type: text/plain, Size: 936 bytes --]

From 3d67a10859d68934ff520eeaa660f5e3c55c2c5b Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Thu, 27 Dec 2018 16:23:32 +0000
Subject: [PATCH] Fix NS fringe bitmap drawing bug (bug#33864)

* src/nsterm.m (ns_draw_fringe_bitmap): Check the rectangle to clear
correctly.
---
 src/nsterm.m | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 6c285f0abb..a624f62817 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3062,7 +3062,7 @@ so some key presses (TAB) are swallowed by the system.  */
   /* Work out the rectangle we will need to clear.  Because we're
      compositing rather than blitting, we need to clear the area under
      the image regardless of anything else.  */
-  if (!p->overlay_p)
+  if (p->bx >= 0 && !p->overlay_p)
     {
       clearRect = NSMakeRect (p->bx, p->by, p->nx, p->ny);
       clearRect = NSUnionRect (clearRect, imageRect);
-- 
2.19.1

bug#33864: Acknowledgement (27.0.50; Display corruption with "small" font size when something is in the fringe)

[Dale Sedivec]

On Thu, Dec 27, 2018 at 10:30 AM Alan Third <alan@idiocy.org> wrote:
> On Thu, Dec 27, 2018 at 09:45:57AM -0600, Dale Sedivec wrote:
[...]
> > I am attaching the Elisp script I used to reproduce this problem while
> > bisecting, loaded like:
> >
> >       nextstep/Emacs.app/Contents/MacOS/Emacs -Q --load repro.el
>
> This reproduces instantly, like you say. Thank you! It looks to me
> like the fringe background colour is being drawn right across the
> line, which makes me think that the calculation to work out what to
> blank in the fringe is going wrong.
>
> I think that what’s happened is I’ve misunderstood one of the NS
> rectangle function’s descriptions and assumed it did more error
> checking than it does. It looks like the fix is simply to check that
> the area that’s to be cleared is actually a legitimate rectangle.
>
> Patch attached.

I applied your patch to my master and I can no longer reproduce this
bug.  I'm now able to run master as my daily driver again.  Thank you
very much!

Dale

bug#33864: Acknowledgement (27.0.50; Display corruption with "small" font size when something is in the fringe)

[Alan Third]

On Thu, Dec 27, 2018 at 11:07:46AM -0600, Dale Sedivec wrote:
> I applied your patch to my master and I can no longer reproduce this
> bug.  I'm now able to run master as my daily driver again.  Thank you
> very much!

I’ve pushed the fix to emacs-26. It should appear on master next time
someone does a merge.

Thank you for reporting this and working out how to reproduce it. I’ve
had some trouble tracking down these drawing issues since they’ve been
so hard to reproduce.
-- 
Alan Third

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, so I think this has to do with the situation where the fringe
> bitmap's height is greater than the vertical size of the default font.
>
> I think this is macOS-specific.
>

What do other platforms do? Truncate the fringe bitmap?

Robert

bug#33864: 27.0.50; Display corruption with "small" font size when something is in the fringe

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Dale Sedivec <dale@codefu.org>,  33864@debbugs.gnu.org
> Date: Sun, 30 Dec 2018 13:25:15 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK, so I think this has to do with the situation where the fringe
> > bitmap's height is greater than the vertical size of the default font.
> >
> > I think this is macOS-specific.
> >
> 
> What do other platforms do? Truncate the fringe bitmap?

Yes, I think so.  At least that's what I see on MS-Windows.