Test output in scale.c (of the Fedora src RPM, after
applying included patches, as the generic sources compile
with an libXaw3d error) shows nothing is obtained from the
"screenSize" resource:
scale.c:
s from XScreenResourceString: (null)
s from resource_getResource(db,app_class,app_name,v,NULL): (null)
s from resource_getResource(db,app_class,app_name,screenSize,NULL) (II):
(null)
s final: (null)
wmm, hmm from s: 0 0
widthP, heightP from WidthMMOfScreen, HeightMMOfScreen: 342 191
(similarly on another machine where the X screen spans the
entire panel). main.c shows more:
main.c:
gv_screen_width, gv_screen_height: 342 191
sizeX, sizeY: 1024 768
default_xdpi (= gv_real_xdpi), default_ydpi: 68.164368 50.757874
Your detected screen size is: 342 mm x 191 mm
Your detected screen resolution is: 1024 x 768
default_xdpi, default_ydpi in main_setResolutions() are
proportional to inverse DPI, consistent with DPI by
xdpyinfo, all being wrong.
Suspecting a missing parameter, I added 'Option "DPI" "143
x 143"' (actual DPI of my screen, 1920/342*25.4) to
xorg.conf. This overrides what Xorg deduces from EDID.
Now gv displays windows properly:
widthP, heightP from WidthMMOfScreen, HeightMMOfScreen: 182 136
gv_screen_width, gv_screen_height: 182 136
sizeX, sizeY: 1024 768
default_xdpi (= gv_real_xdpi), default_ydpi: 36.274605 36.141731
Your detected screen size is: 182 mm x 136 mm
Your detected screen resolution is: 1024 x 768
I realized this should have solved another issue, the
occasional ugly openGL font rendering (including incorrect
pitch/overlapping letters), and indeed it had.
So I found a workaround for one problem and a solution for
another.
Still, xpdf and evince manage to display files correctly
in the absence of the "DPI" option (but I want to stick
with gv as it defaults to single page mode, which recently
became a pain with others and which I find extremely
annoying).
(If there is no Xlib or Nvidia macro or function to report
the physical size of the viewport or the pixel dimensions
of the entire display, as William suggested, and the
gv_screen_width/gv_screen_height and sizeX/sizeY aspect
ratios differ, one may perhaps just use equal DPI in x and
y, perhaps the larger one (102.13). It would not solve the
openGL font rendering but the gv rendering was not really
an issue.)
Rajmund
My guess is that scale_getScreenSize() in scale.c is getting the viewport
pixel dimensions from the "screenSize" resource and the full display size
from WidthMMOfScreen() and HeightMMOfScreen() (which are macros defined
in X11/Xlib.h). You could try using a debugger or throwing in some debug
code to check that, and then looking around to see if you can get either the
MM of the viewport or the pixel dimensions of the entire display.
____________________________________________________________________________
From: bug-gv <bug-gv-bounces+williambader=hotmail....@gnu.org> on behalf of
rajmund.kri...@ijs.si <rajmund.kri...@ijs.si>
Sent: Wednesday, May 22, 2019 4:02 PM
To: bug-gv@gnu.org
Subject: [bug-gv] Incorrect aspect ratio on scaled laptop display (II)
Corrected previous post:
Hi,
I noticed that in a certain X11 setup gv is displaying
files with the horizontal dimension compressed (too narrow
windows and contents).
Setup: laptop with a physical 1920x1080 screen, running in
twinview clone mode for a 4:3 aspect projector (1024x768):
xorg.conf contains a MetaMode for a 1024x768 viewport
(nvidia driver):
Option "MetaModes" "DFP-1: nvidia-auto-select
@1024x768 +0+0 {viewportin=1024x768,
viewportout=1024x768+448+156}, 1024x768 @1024x768"
This results, as intended, in a 1024x768 viewport
occupying the central physical 1024x768 pixels (1-to-1)
and having black borders. xdpyinfo reports conflicting
aspect ratio information (4:3 vs. 16:9):
dimensions: 1024x768 pixels (342x191 millimeters)
resolution: 76x102 dots per inch
The gv windows and their contents are too narrow and would
appear correctly if the 4:3 viewport were stretched
horizontally or compressed vertically to a 16:9 aspect
ratio. The same behavior resulted if the 1024x768 viewport
was uniformly expanded to 1440x1080 physical pixels (...,
viewportout=1440x1080+240+0}, ...). (In these particular
cases, gv should take cue from pixel resolutions, not
physical dimensions.)
Other info;
gv-3.7.4-17.fc29.x86_64
xorg-x11-server-Xorg-1.20.4-1.fc29.x86_64
xorg-x11-drv-nvidia-418.56-1.fc29.x86_64
The PS or EPS files are self-generated (gnuplot) and
the BoundingBox comments exist, e.g. %%BoundingBox: 50
50 554 770 or 50 05 554 856.
Everything else (text, images, etc.) is displayed
correctly. evince displays PS, EPS at the correct
aspect ratio in the same setup. PDF files converted
using ps2pdf are shown correctly by xpdf and evince
(and incorrectly by gv).
Thanks and best regards,
Rajmund
