In my fvwm3 (1.0.7) config, I have the following function
AddToFunc Maximize_Func
+ I Maximize 100 100
which is called from a window menu accessed via a button in the title bar:
DestroyMenu Window_Ops
AddToMenu Window_Ops "Window Ops" Title
+ ...
+ "(Un)Maximize%mini-max1.xpm%" Function Maximize_Func
+ ...
This works as expected for all windows except Adobe Reader (V9.5.5) (yes, I realize this is an ancient program, but bear with me). In that case, the window frame is expanded, but Adobe Reader doesn’t seem to understand that its window has changed size: it keeps using the same amount of space as before, leaving the rest of the window unused.
Further, if I resize the window with the corner handles, it remains confused. However, when I unmaximize the window, it then once again understands and responds to window size changes.
I did not have this problem in fvwm2, so it doesn’t seem like Adobe reader is completely brain-dead, vis-a-vis maximizing its window.
Does anyone have any insight into why this is happening, and/or a way to get this to work?
It depends on what system you are using. This page
shows how to install it on ubuntu, including downloading a .deb which you might be able to install on any debian-type system.`
If your system is pure 64-bit it won’t work. It is a 32-bit program, so your kernel needs to have 32-bit support and you will need a collection of 32-bit libraries installed.
If this turns out to be too much effort because of whatever system you use, if there is any “remote debugging” I could do, I’d be happy to do so.
This might be a good option. Note that this isn’t about 32 vs 64 bit for me, because the bug is in the window placement which could happen in any window. It just so happens in your case, you see it with a 32bit application.
No, I didn’t think that the problem had anything to do with the fact that it is a 32-bit program (although I reserve the right to be surprised), I mentioned that because it could be an impediment for you to install and run it.
In any case, if you have any suggestions of things I could try (or debug statements to put in the code, or …) I’ll be happy to try them out. While I have poked at the odd spot of the fvwm3 code, I am by no means close to being “familiar” with it.
Why someone would want to use a version of Adobe Acrobat that has been unsupported since 2013 and relies in 32bit libraries in 2024 is beyond me.
I think trying to find out why it works fine in fvwm2 and not in fvwm3 is a waste of time and effort that could be expended in tracking down other lingering issues that does not involve unsupported/deprecated software.
There are plenty of PDF readers to choose from that even support more features than what you an get from that old Acrobat Reader from 2013. You should take a look at: Okular, Atril, Evince (aka GNOME Document viewer)… just to name a few. There are plenty more, including LibreOffice Draw. Even modern Web Browsers can work as pdf readers this days.
So… Why bother? There is nothing to win from using an outdated Acrobar reader. Now I suppose that if is the GUI the reason you use it, well… you could always use wine and get run the windows version.
Well, why didn’t you just ask? Here are some of the reasons:
(1) Adobe reader does sub-pixel rendering (and, I believe, better rendering of fonts and thin lines) than any other PDF viewer I have on my system. (In fact, some browsers seem to do almost as good jobs, but they are not as convenient to use when I am creating PDFs with TeX.)
There is no (non-broswer) PDF reader I have found for Linux which comes close to the looks of Adobe reader.
(2) Adobe reader integrates better with some of my other workflow than other PDF viewer I have found for Linux.
(3) Adobe reader remembers information which I can no longer convince evince (a distant second choice) to remember (or even be told). For example, I can tell acroread the DPI of my screen, and it will remember that, and thus I can easily select 100% zoom if I want to see something at its actual size (which is something I frequently want to do, for reasons that are not germane to this discussion.) For evince, the zoom setting to get something shown at “actual” size on my screen is not even some obvious function of the actual DPI.
It is certainly your prerogative to decide that you aren’t interested in any particular bug. But if there is a bug in fvwm3, at some point it may affect someone else who is using some other program.
I’ve looked at Okular and maybe at Atril. I’ve looked at everything I could find in previous hunts. But the lack of SPR makes the fonts look crappy, and I will happily put up with using some ancient version of acroread because it looks so much better. I have asked around (in different places) before, and no-one has suggested that they have a (non-browser) PDF viewer that does SPR. Perhaps that is no longer true, but until I find one which renders text as clearly as acroread, I will continue to use it.
So I have my reasons. If you are happy looking at mediocre font rendering, that’s fine. But I’m not.