Re: [bug-gv] Incorrect aspect ratio on scaled laptop display (II)

[rajmund . krivec]

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 <address@hidden> on behalf of
> address@hidden <address@hidden>
> Sent: Wednesday, May 22, 2019 4:02 PM
> To: address@hidden
> 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