4 Aug
2017
4 Aug
'17
6:31 a.m.
Felmon Davis composed on 2017-08-04 01:15 (UTC-0400):
Felix Miata wrote:
...
>> apt-cache policy libgtk2.0-0
>> I get: "Installed: 2.24.31-2"
> Only the GTK3 version is relevant to the potential
problem of GTK3-built apps
> not obeying your TDE font settings, which may have nothing to do with the tiny
> fonts you are actually seeing.
I can't seem to get anything on gtk3 although it
looks like some
programs invoke it.
Jessie never shipped with GTK3 AFAICT, so likely its missing from Exegnu as
well. Current Firefox and SeaMonkey versions downloaded directly from
Mozilla.org depend on it. Linux distros, older versions at least, for the time
being have the option to keep building with GTK2 instead, and probably all that
provide ESR versions are doing so. LO might be using GTK3 already that far back,
I don't know, but it provides its own means of manipulating font sizes anyway
(and defaulting in every one of my installations to tinier than anything else).
I wrote that I wasn't sure what the display size
should be to which
you responded:
> Save
http://fm.no-ip.com/Share/Linux/xorg.conf-minimal-EDID-workaround to use as
> an /etc/X11/xorg.conf template. Create in it an uncommented DisplaySize line.
> Using half the values reported above that produce 96x96 /should/ produce 192x192
> as a place to start your experiments:
> DisplaySize 423 213 # 192 DPI @ 3200x1800
I tried this value and the fonts were grotesquely
large on the login
Not a surprise to me.
page but once logged in I saw no difference.
Shock. :-( What did/do "xrdb --query | grep dpi" and "xdpyinfo | egrep
'dimen|ution'" report? Do they match what is reported if you load
http://fm.no-ip.com/Auth/dpi-screen-window.html
in a Gecko browser (Firefox, SeaMonkey, others) or Konqueror w/ KHTML, but not
Chrom* or Opera.
...
I fooled a bit with HorizSync and VertRefresh and at
one point I got a
fair font size but Horizontal was too short. not sure if this is
what I should play with and if so, how to calculate the correct
values.
am I right that I should fool with HorizSync and
VertRefresh?
I should have told you that you should be able to comment away those
lines. If
that doesn't work, and it should, those values should be in the full specs for
that laptop.
hwinfo --monitor | grep -A6 'river Inf'
should tell you what they are, and if it does, then it confirms they /should/
not be necessary, that is, if hwinfo even ships in Exegnu. Try:
ddcprobe ! grep monitorr
You can manufacture working ranges from the timings listed in Xorg.0.log, or
from verbose xrandr output. OTOH, because that display is such high resolution,
proper ranges might be unusual.
I have also entered:
Option "PreferredMode" "3200x1800"
It's probably superfluous, but couldn't hurt either.
any further guidance welcome.
Another option is to /not/ use the native 3200x1800 display mode. On a 13.3"
inch screen that's way out of normal range for most developers to try to emulate
to make everything work nicely visually. Unless your eyes are extraordinary, you
are likely not to notice much if any difference by employing 1920x1080 instead:
Option "PreferredMode" "1920x1080"
With any luck and good eyes, you wouldn't need to fuss with DPI or suffer extra
tiny fonts. To go this route you should be able to dispense with xorg.conf
entirely and make select that resolution in Trinity Control Center ->
Peripherals -> Display -> Size & Orientation -> Screen Size. On such a tiny
screen, you might find you like 1600x900 better yet.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/