bugGNU gv - Bugs: bug #29993, Aspect ratio too wide

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #29993: Aspect ratio too wide

Submitter:  Volker Kuhlmann <vok>
Submitted:  Sun 30 May 2010 02:23:11 PM UTC
   
 
Category:  Graphical User interface Severity:  3 - Normal
Item Group:  None Status:  In Progress
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  3.6.3

Jump to the original submission

Sun 24 Apr 2011 07:12:07 AM UTC, comment #11: 

A partial fix is available in GNU gv 3.7.1.90: Remote ssh connections now have a separate ~/.gv entry for the aspect ratio.

Markus Steinborn <msteinbo>
Group administrator
Thu 10 Jun 2010 09:22:14 AM UTC, comment #10: 

Tested gv 3.6.90 with xinerama 2x 1280x1024 after deleting ~/.gv, and the aspect ratio was ok. Debug output was:

Locale1=en_GB
Locale2=en_GB
Locale3=en
Your detected screen size is: 684 mm x 271 mm
That does not look like a single monitor, as the ratio is 2.52.
Your detected screen resolution is: 2560 x 1024


gv 3.6.91 on a 1680x1050, no ~/.gv: aspect ratio ok, debug output:

Locale1=en_GB
Locale2=en_GB
Locale3=en
Your detected screen size is: 431 mm x 272 mm
That looks like a single monitor, as the ratio is 1.58.
Your detected screen resolution is: 1680 x 1050
Xinerama's resolution of screen 0 is: 1680 x 1050


All (my tested) monitors should have functional DSC.
HTH.

(Btw gv doesn't decompress lzma extensions, but does gzip + bzip2.)

Volker Kuhlmann <vok>
Wed 02 Jun 2010 12:49:26 PM UTC, comment #9: 

Thanks Markus! The setting is obviously useful. Perhaps add some text to the window along the lines of "delete this and save options if the aspect ratio of the gv window is wonky"?

Isn't the number of pixels of the X display always known, with DSC or not? Their ratio would be the aspect ratio, multiplied by the aspect ratio of a pixel if that isn't square. But a config value for that only moves the problem.

Volker Kuhlmann <vok>
Wed 02 Jun 2010 09:50:10 AM UTC, comment #8: 

Well, sometimes the autodetection is wrong. Especially in a setup with two monitors used at the same time (you know, each with different video output) it happens that the cummulated size of both monitors is detected. Or the soze of the "wrong" monitor is taken of the wrong monitor. Because of this, I wanted to check that.

1. The resoilution is detected correctly (you would have told me if not).

2. A single monitor is assumed (it is, your modification creates a monitor smaller than height, quite unusual, so it's more likely to assume two mintors, each of half the height.)


Another reason for the aspect ratio setting is that gv is quite old - at these times non DSC aware monitors were quite common.


This setting is the only chance to correct wrong autodetection.

Now having some more details I have to admit tht this problem is somehow different than the fixed one.


Well, I have to think about the details, but it seems to be a good idea to save the resolution detected by "--debug" into ~/.gv. I've to think about how...

Let's assume that on a 4:3 display, a standard resolution is used and on a 16:10 resp. 16:9 a widescreen resolution is used.

Then the following make sence:

Option 1: Extra resource just containing the resolution. If it changes, ignoire the screen size.

Option 2: Save several aspect ratio's - one for each resolution.
The problem is that the code is not prepared for this.

But as I've just written, I've to thinkk about it. Currently I'm working on a security realted update for GNU gv - some details can be read on the public archive of bug-gv.

Markus Steinborn <msteinbo>
Group administrator
Wed 02 Jun 2010 09:29:31 AM UTC, comment #7: 

:/tmp/gv/gv-3.6.90> ./src/gv --debug
Locale1=en_GB
Locale2=en_GB
Locale3=en
Your detected screen size is: 431 mm x 400 mm
That looks like a single monitor, as the ratio is 1.08.
Your detected screen resolution is: 1680 x 1050
Xinerama's resolution of screen 0 is: 1680 x 1050

Change the 400 to 500, then save setup options, to simulate a different size monitor. Next start (the gv window has a noticably different size):

:/tmp/gv/gv-3.6.90> ./src/gv --debug
Locale1=en_GB
Locale2=en_GB
Locale3=en
Your detected screen size is: 431 mm x 500 mm
That does not look like a single monitor, as the ratio is 0.86.
Your detected screen resolution is: 1680 x 1050

Ok you can argue that the $DISPLAY is saved into ~/.gv with the screen size, but that fails each time I change monitor, or the screen from a remote connection changes. The fix is easy, but one doesn't know it. My ~/.gv was from Sep 2006 when I must have upgraded to a widescreen monitor, since then I've put up with a substandard gv because I didn't know better.

What is the aim of this config value? Is what xdpyinfo reports sometimes wrong? Then it needs a more elaborate solution. If it's just for scaling at magnification=1.00, why not use a scale value and default to 1.0? There have been other incompatible changes in the X resources anyway.

Volker Kuhlmann <vok>
Wed 02 Jun 2010 09:13:58 AM UTC, comment #6: 

Please start gv with the (undocumented) optiuon "--debug" and send me the output (should only be 6 lines or so).

Markus Steinborn <msteinbo>
Group administrator
Wed 02 Jun 2010 09:10:39 AM UTC, comment #5: 

Ok, I compiled 3.6.90 (x86_64). The bug appears not to be fixed. The screen size is auto-filled, and is saved to ~/.gv when saving the setup options. Quitting and starting gv then loads the saved screen size from ~/.gv. This won't work when using a different monitor, e.g. remote logins.

I started gv from the compile directory with ./src/gv, if that changes things.

Btw the ./src/gv-update-userconfig has a closing square bracket instead of a brace on line 204, resulting in a perl compilation error.

Thanks!

Volker Kuhlmann <vok>
Wed 02 Jun 2010 08:55:30 AM UTC, comment #4: 

Thanks for your feedback.  We can close the bug.

Markus Steinborn <msteinbo>
Group administrator
Wed 02 Jun 2010 08:46:35 AM UTC, comment #3: 

Thanks Markus - splendid! That was the problem, I must have logged in from another computer with a 5:4 monitor and saved the setup. Deleting the GV.screenSize_... lines from ~/.gv solves the problem as the value is auto-filled from xdpyinfo when absent. Aspect ratio follows that value exactly.

Volker Kuhlmann <vok>
Sun 30 May 2010 02:38:59 PM UTC, comment #2: 

For older GNU gv releases, the following workaround should work:

Go to "State - Setup Options". There you'll find "Screen size (mm)". Double the first value. On my setup, I change it from "332 x 212" to "664 x 212". Report me your results. Have you two displays connected to your PC? Normal displays or widescreen? Which resolution?

Then test halving the second value and reseting the first to the unmodified value. In my example, that would be "332 x 106". Please report me your results for that test, too.

I think one of the two mentioned modifications should resolve your problem. In this case, save your settings by the "save" button.

Markus Steinborn <msteinbo>
Group administrator
Sun 30 May 2010 02:31:58 PM UTC, comment #1: 

We believe that the bug you reported has been fixed with version 3.6.5.90. Is there any possibility that you try a newer version of GNU gv? Actually GNU gv 3.6.90 is available on ftp://alpha.gnu.org/gnu/gv . It's released on alpha.gnu.org because translations are missing, but the release itself is stable.

Markus Steinborn <msteinbo>
Group administrator
Sun 30 May 2010 02:23:11 PM UTC, original submission:  

When using a widescreen monitor, the rendered screen display is stretched horizontally.
On a 1680x1050 display, the tiger.eps picture is about 30% wider than the same file displayed with e.g. kghostview on the same monitor. It happens with every file, PS or PDF.
That stretch is about the same factor as 1680x1050 is to 1280x1024. Is there an implicit assumption somewhere in gv that the display ratio is 5:4?

This is on openSUSE 11.1 with GPL Ghostscript 8.62 and gv 3.6.3, but I'm pretty sure it was the same on openSUSE 10.3 and gv 3.5.8.

Volker Kuhlmann <vok>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by msteinbo (Posted a comment)
  • -email is unavailable- added by vok (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-04-24 msteinbo StatusNeed Info In Progress
    2010-06-02 msteinbo StatusWorks For Me Need Info
        Open/ClosedClosed Open
    2010-06-02 msteinbo StatusNone Works For Me
        Open/ClosedOpen Closed
        ReleaseNone 3.6.3

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code