I found a possible fix. Edit /usr/share/applications/xpdf.desktop and change the Exec line to something like this:
Exec=xpdf -geometry 640x420-0+0 -z 'width' /mnt/ide3/documents/media/reference/Ferry_English.pdf
Explanation:
-geometry 640x420-0+0 is standard option understand by (most/all?) X programs, this sets size and location of window
-z 'width' this is xpdf specific and sets zoom to page width
/mnt/ide3/documents/media/reference/Ferry_English.pdf opens this document, the purpose of this is to actually set xpdf's working directory to where most of my PDFs are stored. I tried using a Path entry in xpdf.desktop but that doesn't seem to have any effect, hence this kludge.
A similar technique could be used for other programs which are clueless about the window size/location was used the last time you ran them. For example, with gnumeric you would use: --geometry 640x420-0+0, note the double hyphen as opposed to xpdf which requires single hyphen. Use <program> --help on the command line to see what options a particular accepts.
Here's my observations on how this bug manifests itself:
When xpdf starts up the initial size of the window depends on the document opened.
- If the size of the window is wider/taller than the screen and you then maximise the window (which in this case makes it smaller), xpdf will still think it has the original window size to work on and hence scale the drawing accordingly. Thus when you view it on your smaller window parts of it is cutoff
- If the size of the window is narrower/shorter than the screen and you then maximise the window (which in this case makes it bigger), xpdf will still think it has the original window size to work on and hence scale the drawing accordingly. Thus when you view it on your larger window parts of it grey - xpdf will not use those parts and they will not get refreshed.
So by making xpdf startup with the specific window size that you want to use these scaling problems can be avoided.
-- cheers
