[tex-k] Problem with "mf" online display in GNOME

[Igor Liferenko]

Hi all,

This example from MetaFont Book (page 31) does not work with online
display (run as "mf test.mf"):

drawdot (35,70); showit;

I traced down the problem to GNOME. On MATE desktop everything works properly.
There is also a report that it works in MobaXterm (X-Server on Windows 10):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862943#10

The problem is not in TeX Live (I tested on official TeX Live ISO),
because this example works everywhere except GNOME. Thus, the problem
is with GNOME. Can you please point me to the code in TeX Live which
interfaces with window system so that I could trace down the bug
myself?

Thanks,
Igor

[Paul Vojta]

Hi Igor,

First, for your original question: it's probably either
Build/source/texk/web2c/window/x11-Xlib.c or
Build/source/texk/web2c/window/x11-Xt.c .
Probably the former, given the short output of "ldd .../mf"

However, I don't think the problem is specific to GNOME. I use fvwm as
my window manager, and the bug affects me.
In fact, I tried the test file on seven different Linux machines before
finding one in which the bug did *not* occur. For the seventh machine, the
bug sometimes occurred and sometimes did not.

I think that the problem is that mf is not handling expose events correctly
(or at all?). I suspect that because on the seventh machine, when the dot
appeared, I switched to a different virtual desktop and back, and the dot
disappeared. So I think that the presence or absence of the bug could be
a timing thing, and that maybe it occurs with GNOME because GNOME is bigger
and slower, so mf issues the draw requests before the window is fully
realized.

Here are some additional tests you can do (even under GNOME).

1. Without using a file test.mf, type mf, \relax at the ** prompt, and
drawdot(35,70); showit; at the * prompt. Then, try drawing other dots
(for example drawdot(20,20); showit; ). Do they appear?

2. If you are able to draw additional dots, are they redrawn on the screen
if you cover them with another window and then uncover them?

In my own tests (not done on machine #7 since it's a really old machine and
hard to use), I do get the additional dots in #1 above, and they are not
redrawn in #2 (so they disappear after covering and uncovering them).

Paul Vojta, vojta at math dot berkeley dot edu

Post by Igor Liferenko
Hi all,
This example from MetaFont Book (page 31) does not work with online
drawdot (35,70); showit;
I traced down the problem to GNOME. On MATE desktop everything works properly.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862943#10
The problem is not in TeX Live (I tested on official TeX Live ISO),
because this example works everywhere except GNOME. Thus, the problem
is with GNOME. Can you please point me to the code in TeX Live which
interfaces with window system so that I could trace down the bug
myself?
Thanks,
Igor

[Paul Vojta]

Dear all,

I have my own suggestion for a patch (attached).

I can work up a similar patch for x11-Xlib.c (I think).
Expose events can be handled via backing-store, as is done in Xt.
But not tonight.

As for slimming down the build, I can't offer any suggestion. However,
once it's built, you can cd to texk/web2c and type "make mf" to re-build
just mf.

Paul

Hi Karl and all,
I have found the solution which works perfectly for me. The patch is attached.
For now, this is all that I have to offer. But I'm ready to help with testing
if you have any ideas.
I suggest that TL will use --with-mf-x-toolkit (like it is done in Debian
build), because with Xlib the drawing is erased when it is overlapped by
another window (as described by Paul Vojta), whereas with Xt this does not
happen.
For those who may need this, here are the steps which
sudo apt-get install libxt-dev texinfo
mkdir mydir && cd mydir
rsync -a --delete --exclude=.svn --exclude=Work
tug.org::tldevsrc/Build/source/ .
mkdir Work && cd Work
../configure --disable-all-pkgs --disable-native-texlive-build
--enable-web2c --with-mf-x-toolkit
make
cd texk/web2c/
MFINPUTS=/usr/share/texlive/texmf-dist/metafont/base/:/usr/share/texlive/texmf-dist/metafont/misc/:.
./mf -ini -jobname mf '\input plain input modes dump' # or download
plain.mf and modes.mf from internet
MFBASES=. MFINPUTS=. ./mf test
Many thanks to Karl and Paul for your help and ideas.
Igor
P.S. Is it possible to reduce the present build even more, to a bare
minimum - just to get a working "mf" binary? (for example, how to exclude
luatex and libicu builds?)
--- mydir.orig/texk/web2c/window/x11-Xt.c
+++ mydir/texk/web2c/window/x11-Xt.c
@@ -168,6 +168,8 @@
screendepth > mf_x11_resources.mf_height
? screendepth : mf_x11_resources.mf_height);
+ usleep(100000);
+
return 1;
}

[Karl Berry]

Please recommend which one should be used: Xlib or Xt

Xlib

[Paul Vojta]

Your output of ldd indicates that your copy of mf uses x11-Xt.c.
This seems quite strange, since when I compile texlive myself, it uses
x11-Xlib.c.

Ah. I see: there is an option in the configure script: --with-mf-x-toolkit

Paul

[Paul Vojta]

Hm... It looks like this copy of mf uses x11-Xt.c, but when I compile texlive
myself, it uses x11-Xlib.c.

Paul

Sorry, forgot to attach the file with ldd output.
linux-vdso.so.1 (0x00007ffcb0549000)
libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007f7e76c9e000)
libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007f7e76a35000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f7e766f5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7e763f1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7e76053000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f7e75e49000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f7e75c2c000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f7e75a04000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7e75800000)
/lib64/ld-linux-x86-64.so.2 (0x000055721b1af000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f7e755fb000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f7e753e5000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f7e751df000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f7e74fd9000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7e74dd1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7e74bb4000)

[Karl Berry]

without having online display functionality. What would be the
mechanism to get the output from the computer?

Run gftodvi for proof sheets (more or less as in volume E), or typeset
with the font for samples. E.g., testfont.tex.

Are those alternative implementations, or they are just different elements
of one implementation?

Alternatives.

sleep a bit

Sleeping does not sound like the right thing to do, in principle.
Evidently handling Expose events simply has to be handled.
I await patches :).

../configure --disable-all-pkgs --enable-shared
--with-system-kpathsea --disable-native-texlive-build
But "make" does not compile anything after these steps.

Sure, since you disabled everything. Try adding --enable-web2c.

BTW, I doubt you want --enable-shared for debugging. At least, I don't
recommend it.

If you're going to build from sources, see also the tlbuild
document. Not everything is explained perfectly there, or in configure
--help, or anywhere, but it's what peb and I and others have written
over the years. --good luck, karl.

[Karl Berry]

Hi Paul (and Igor and all),

1. Without using a file test.mf, type mf, \relax at the ** prompt, and
drawdot(35,70); showit; at the * prompt. Then, try drawing other dots
(for example drawdot(20,20); showit; ). Do they appear?

Works for me (x86_64-linux, TL pretest, fvwm, CentOS 7).
(drawdot also works from the command line.)

2. If you are able to draw additional dots, are they redrawn on the screen
if you cover them with another window and then uncover them?

Indeed, that fails for me as well. I seem to recall noticing that years
ago, but in the absence of any reports from users, decided not to spend
time on it. (It was frustrating enough to have to deal with x11-Xt
randomly starting to fail one year.)

Of course, a patch would be great. -k

[Karl Berry]

P.S. Is it possible to reduce the present build even more, to a bare
minimum - just to get a working "mf" binary? (for example, how to exclude
luatex and libicu builds?)

In essence, you have to --enable-web2c and then explicitly disable all
the unwanted "subpackages" (engines) under web2c.

Below is a command that disables everything (plus other debugging stuff
at the beginning which should be adjusted to taste) and then enables
mf. I have not actually this with mf, so maybe there are complications.

I hope to work out some new --enable or --disable to avoid having to
explicitly list all the web2c "subpackages", but I won't be able to
think about it for some time. --good luck, karl.

cd .../Build/source
mkdir tryb
cd tryb
./configure CFLAGS=-g CXXFLAGS=-g \
--prefix=`pwd`/Insttest \
--enable-native-texlive-build \
--enable-cxx-runtime-hack \
--disable-shared \
--disable-all-pkgs \
--enable-web2c \
--disable-synctex \
--disable-web-progs \
--disable-tex --disable-etex \
--disable-pdftex \
--disable-ptex --disable-eptex --disable-uptex --disable-euptex \
--disable-aleph \
--disable-luatex --disable-luajittex \
--disable-mp --disable-pmp --disable-upmp \
--disable-xetex \
--disable-mf-nowin --disable-mflua --disable-mfluajit \
--enable-mf --with-x

[Karl Berry]

Thanks Paul and Igor.

I can work up a similar patch for x11-Xlib.c (I think).
Expose events can be handled via backing-store, as is done in Xt.

Well, before you spend your time doing that, I guess I should try to
research why I switched TL from xt to xlib. I did it to fix some
breakage, but have no memory of specifics. Maybe it was just to reduce
crazy compilation dependencies, but I think there was some particular
problem, more likely related to compilation than to runtime behavior.

Norbert, hence, I suppose you are fine using xt in debian (as you wrote
me separately). If you have any patches in this area, let me know ... -k

[Norbert Preining]

Hi Karl,
We do this since 2005 I guess ...

Post by Karl Berry
me separately). If you have any patches in this area, let me know ... -k

No patches at all (at least not for mf/X)

All the best

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Igor Liferenko]

Hello Paul and all,

Post by Paul Vojta
I have my own suggestion for a patch (attached).

I have tested your patch. Works great.

All the best,
Igor

P.S. Is it possible to make it so, that it will be possible to switch
between online-graphics window and the terminal with Alt+Tab? In GNOME
it is not possible (I had this issue from the very beginning, but it
is not critical, so I did not mention it before). This is no problem
if one has a wide monitor, so that it is possible to see terminal and
graphics window simultaneously. But if the screen is small, it would
be rather convenient to switch between graphics window and terminal
with Alt+Tab. (I also checked in MATE - there is the same problem.)

[Paul Vojta]

I don't really know the metafont code all that well, but it sounds like it
would involve some rather extensive changes. Also, currently the graphics
window doesn't process keystroke events, and processing any events at all
in an asynchronous manner would again be an extensive change.

This sounds like something that you should try instead to do using the window
manager. (With fvwm, for example, I use Alt-Shift-Button 3 to push a
window to the bottom of the stack. Or, if a part of a window is visible,
I have it set to raise that window when I move the mouse to the window.)

Paul Vojta

Post by Igor Liferenko
Hello Paul and all,

Post by Paul Vojta
I have my own suggestion for a patch (attached).

I have tested your patch. Works great.
All the best,
Igor
P.S. Is it possible to make it so, that it will be possible to switch
between online-graphics window and the terminal with Alt+Tab? In GNOME
it is not possible (I had this issue from the very beginning, but it
is not critical, so I did not mention it before). This is no problem
if one has a wide monitor, so that it is possible to see terminal and
graphics window simultaneously. But if the screen is small, it would
be rather convenient to switch between graphics window and terminal
with Alt+Tab. (I also checked in MATE - there is the same problem.)