10:53 a.m.
Hi there,
since years I use xemacs-beta, currently 21.5.34:
https://t2sde.org/packages/xemacs-beta
Except the lack of updates I am quite happy with that setup, however one
details drives me increasingly crazy. Namely HiDPI font scaling when I
switch between old displays and newer, 4k+ HiDPI, 192++ dpi screens.
I have this font selection in my .xemacs/init.el
(set-face-font 'default "Source Code Pro-13") ; or -22 for HiDPI
Ideally I want this -13 to be pt, so that I do not have to edit the file
each time I switch my desk or continue coding on the road.
Googling around suggest others alternative forms which either do not
work in xemacs-beta, or do not prove the situation.
I tried to read the lisp files, but could not find anything that would
help me there either.
Is there anything "pt" like so that a 13pt would result in say 13 pixels
on a low resolution display, and 26 (or whatever) pixels on a HiDPI
screen with the X server dpi set accordingly?
PS: Surprisingly the Xemacs menus and such sale automatically, just not
this most important, main edit buffer, ..?
Best regards – and greetings from Europe,
René
--
René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
http://exactcode.com | http://t2-project.org | http://rene.rebe.de
11:16 a.m.
Hi René --
Ar an ceathrú lá de mí na Nollaig, scríobh René Rebe:
since years I use xemacs-beta, currently 21.5.34:
https://t2sde.org/packages/xemacs-beta
Except the lack of updates I am quite happy with that setup, however one
details drives me increasingly crazy. Namely HiDPI font scaling when I
switch between old displays and newer, 4k+ HiDPI, 192++ dpi screens.
;
I have this font selection in my .xemacs/init.el
(set-face-font 'default "Source Code Pro-13") ; or -22 for HiDPI
Ideally I want this -13 to be pt, so that I do not have to edit the file
each time I switch my desk or continue coding on the road.
In fontconfig theory the -13 is pt, so it seems that the underlying library
isn’t handling it correctly.
Googling around suggest others alternative forms which either do not
work in xemacs-beta, or do not prove the situation.
I tried to read the lisp files, but could not find anything that would
help me there either.
Is there anything "pt" like so that a 13pt would result in say 13 pixels
on a low resolution display, and 26 (or whatever) pixels on a HiDPI
screen with the X server dpi set accordingly?
PS: Surprisingly the Xemacs menus and such sale automatically, just not
this most important, main edit buffer, ..?
... except this suggests it does!?
Xft isn’t my bailiwick, and I don’t have a high-DPI screen available to
reproduce ± debug this issue. Stephen?
Best,
Aidan
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
11:39 a.m.
Hi,
On 12/05/2017 12:16 PM, Aidan Kehoe wrote:
Hi René --
Ar an ceathrú lá de mí na Nollaig, scríobh René Rebe:
> since years I use xemacs-beta, currently 21.5.34:
>
> https://t2sde.org/packages/xemacs-beta
>
> Except the lack of updates I am quite happy with that setup, however one
> details drives me increasingly crazy. Namely HiDPI font scaling when I
> switch between old displays and newer, 4k+ HiDPI, 192++ dpi screens.
;
> I have this font selection in my .xemacs/init.el
>
> (set-face-font 'default "Source Code Pro-13") ; or -22 for HiDPI
>
> Ideally I want this -13 to be pt, so that I do not have to edit the file
> each time I switch my desk or continue coding on the road.
In fontconfig theory the -13 is pt, so it seems that the underlying library
isn’t handling it correctly.
> Googling around suggest others alternative forms which either do not
> work in xemacs-beta, or do not prove the situation.
>
> I tried to read the lisp files, but could not find anything that would
> help me there either.
>
> Is there anything "pt" like so that a 13pt would result in say 13
pixels
> on a low resolution display, and 26 (or whatever) pixels on a HiDPI
> screen with the X server dpi set accordingly?
>
> PS: Surprisingly the Xemacs menus and such sale automatically, just not
> this most important, main edit buffer, ..?
... except this suggests it does!?
Xft isn’t my bailiwick, and I don’t have a high-DPI screen available to
reproduce ± debug this issue. Stephen?
With an xserver, you could just run "xrandr --dpi 192" or so to
"simulate" a "HiDPI" screen, ...
Thanks,
René
--
René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
http://exactcode.com | http://t2-project.org | http://rene.rebe.de
11:03 p.m.
Ar an cúigiú lá de mí na Nollaig, scríobh René Rebe:
> > Googling around suggest others alternative forms which
either do
> > not work in xemacs-beta, or do not prove the situation.
> >
> > I tried to read the lisp files, but could not find anything that
> > would help me there either.
> >
> > Is there anything "pt" like so that a 13pt would result in say 13
> > pixels on a low resolution display, and 26 (or whatever) pixels on
> > a HiDPI screen with the X server dpi set accordingly?
> >
> > PS: Surprisingly the Xemacs menus and such sale automatically, just
> > not this most important, main edit buffer, ..?
>
> ... except this suggests it does!?
>
> Xft isn’t my bailiwick, and I don’t have a high-DPI screen available to
> reproduce ± debug this issue. Stephen?
With an xserver, you could just run "xrandr --dpi 192" or so to
"simulate" a "HiDPI" screen, ...
Ah, thanks for that. My Apple XQuartz 2.3.6 xorg-server 1.4.2-apple56
doesn’t support the XRANDR extension, so it would likely be a question of a
virtual machine for me. I don’t use the Xft support and have made the
decision to favour the GTK support for my gui work.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
9:55 a.m.
Aidan Kehoe writes:
In fontconfig theory the -13 is pt,
That's right. If your X server is providing the right DPI for the
screen, fontconfig will automatically scale points to pixels
correctly.
so it seems that the underlying library isn’t handling it
correctly.
I don't think that's likely, given:
> PS: Surprisingly the Xemacs menus and such sale automatically,
just not
> this most important, main edit buffer, ..?
Most of the "menus and such" have their fonts configured through X
resources rather than XEmacs faces. I think that most likely
something is going on in the face processing, but I don't have a good
idea what that might be offhand. XEmacs *should* be passing the
fontspec directly to fontconfig, which then finds the font, and passes
that and the spec to Xft, which renders at the right scale. I don't
recall that XEmacs tries to adjust fontconfig specs in any way.
On my own system this "just works", and the screens that get switched
are a Mac Book Pro 13" (2560x1600) and a Thunderbolt 26" (2560x1440).
so I should see the same effect that you do. But I don't.
Have you tried other fonts? Do you use this font with other
applications? What are the results in those cases? (I don't mean to
"blame the victim", but with the information I have so far the only
suggestion I have that would give quick resolution is that the font is
somehow broken, and a different font would work.)
If the font does work correctly in other applications and different
fonts show the same behavior in XEmacs, the next step would be to check to
see if XEmacs knows the actual dimensions of the screen. You can get
this information by evaluating
(list (device-pixel-width (selected-device))
(device-pixel-height (selected-device))
(device-mm-width (selected-device))
(device-mm-height (selected-device)))
This doesn't doesn't give the right answers with both screens active
on my Mac although xdpyinfo seems to work correctly. I will
investigate that, but can't promise any results soon. It doesn't
surprise me that something weird would be going on in X since the Mac
will mirror or tile the screens at the Quartz level and authomatically
adjust things, so X doesn't actually know what's going on. But it
does suggest that XEmacs is messed up here somehow.
Regards
Steve
10:04 a.m.
Hi,
On 06 Dec 2017, at 10:55, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp>
wrote:
Aidan Kehoe writes:
> In fontconfig theory the -13 is pt,
That's right. If your X server is providing the right DPI for the
screen, fontconfig will automatically scale points to pixels
correctly.
From my own user of fontconfig in my own software, I do not recall fontconfig interacting
with an X server.
So I guess that is then where the problem lies.
> so it seems that the underlying library isn’t handling it
> correctly.
I don't think that's likely, given:
>> PS: Surprisingly the Xemacs menus and such sale automatically, just not
>> this most important, main edit buffer, ..?
Most of the "menus and such" have their fonts configured through X
resources rather than XEmacs faces. I think that most likely
something is going on in the face processing, but I don't have a good
idea what that might be offhand. XEmacs *should* be passing the
fontspec directly to fontconfig, which then finds the font, and passes
that and the spec to Xft, which renders at the right scale. I don't
recall that XEmacs tries to adjust fontconfig specs in any way.
Yes, I meant the menus and such only.
On my own system this "just works", and the screens that
get switched
are a Mac Book Pro 13" (2560x1600) and a Thunderbolt 26" (2560x1440).
so I should see the same effect that you do. But I don’t.
That sounds you are using macOS? Where the X server probably may do some things the
Apple-way, instead of some more traditional standard Un*x.
Have you tried other fonts? Do you use this font with other
applications? What are the results in those cases? (I don't mean to
"blame the victim", but with the information I have so far the only
suggestion I have that would give quick resolution is that the font is
somehow broken, and a different font would work.)
Yes, I used another font before, and the vector fonts work all the same for me in all
other apps.
If the font does work correctly in other applications and different
fonts show the same behavior in XEmacs, the next step would be to check to
see if XEmacs knows the actual dimensions of the screen. You can get
this information by evaluating
(list (device-pixel-width (selected-device))
(device-pixel-height (selected-device))
(device-mm-width (selected-device))
(device-mm-height (selected-device)))
This doesn't doesn't give the right answers with both screens active
on my Mac although xdpyinfo seems to work correctly. I will
investigate that, but can't promise any results soon. It doesn't
surprise me that something weird would be going on in X since the Mac
will mirror or tile the screens at the Quartz level and authomatically
adjust things, so X doesn't actually know what's going on. But it
does suggest that XEmacs is messed up here somehow.
Which toolkit do you build / recumbent to use?
Btw. any chance for a new tar ball point release to get up to sync with potential changes
in the development source tree from the last years?
Thanks,
René
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org |
http://rene.rebe.de
9:38 a.m.
Hello again,
On 06 Dec 2017, at 00:03, Aidan Kehoe <kehoea(a)parhasard.net> wrote:
Ar an cúigiú lá de mí na Nollaig, scríobh René Rebe:
>>> Googling around suggest others alternative forms which either do
>>> not work in xemacs-beta, or do not prove the situation.
>>>
>>> I tried to read the lisp files, but could not find anything that
>>> would help me there either.
>>>
>>> Is there anything "pt" like so that a 13pt would result in say 13
>>> pixels on a low resolution display, and 26 (or whatever) pixels on
>>> a HiDPI screen with the X server dpi set accordingly?
>>>
>>> PS: Surprisingly the Xemacs menus and such sale automatically, just
>>> not this most important, main edit buffer, ..?
>>
>> ... except this suggests it does!?
>>
>> Xft isn’t my bailiwick, and I don’t have a high-DPI screen available to
>> reproduce ± debug this issue. Stephen?
>
> With an xserver, you could just run "xrandr --dpi 192" or so to
> "simulate" a "HiDPI" screen, ...
Ah, thanks for that. My Apple XQuartz 2.3.6 xorg-server 1.4.2-apple56
doesn’t support the XRANDR extension, so it would likely be a question of a
virtual machine for me. I don’t use the Xft support and have made the
decision to favour the GTK support for my gui work.
I looked at the gtk+ support, is my first impression correct that this is
a decade outdated gtk+ 1.x from like Gnome / gimp 1.x?
Not something newer like gtk+ v2 or v3?
René
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org |
http://rene.rebe.de
7:49 a.m.
Ar an naoiú lá de mí na Nollaig, scríobh René Rebe:
> Ah, thanks for that. My Apple XQuartz 2.3.6 xorg-server
1.4.2-apple56
> doesn’t support the XRANDR extension, so it would likely be a question
> of a virtual machine for me. I don’t use the Xft support and have made
> the decision to favour the GTK support for my gui work.
I looked at the gtk+ support, is my first impression correct that this is
a decade outdated gtk+ 1.x from like Gnome / gimp 1.x?
Not something newer like gtk+ v2 or v3?
The current development GTK code is here:
https://bitbucket.org/jsparkes/xemacs-gtk
Which is, thankfully, a bit more recent. I plan to merge this into the trunk
soon. It’s not as polished as even the Xft code, but has more potential in
the longer term, as it includes Pango support for various scripts that we
would otherwise have to provide ourselves.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
4:05 p.m.
Sorry for the long delay, somehow either I or my Rube Goldberg mail
set up lost it for a couple weeks.
René Rebe writes:
On 06 Dec 2017, at 10:55, Stephen J. Turnbull
<turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
> That's right. If your X server is providing the right DPI
for the
> screen, fontconfig will automatically scale points to pixels
> correctly.
From my own user of fontconfig in my own software, I do not recall
fontconfig interacting with an X server.
I should have said "Xft" rather than fontconfig. Fontconfig doesn't
know anything about glyphs or pixels.
Yes, I meant the menus and such only.
Thank you for confirming.
> On my own system this "just works", and the screens
that get switched
> are a Mac Book Pro 13" (2560x1600) and a Thunderbolt 26" (2560x1440).
> so I should see the same effect that you do. But I don’t.
That sounds you are using macOS? Where the X server probably may do
some things the Apple-way, instead of some more traditional
standard Un*x.
Yes. However, the X server is Xorg, and at least the last time I had
to dig into X internals most of the differences have to do with
interactions with the rootless display feature used by the XQuartz
window manager.
Which toolkit do you build / recumbent to use?
Xt + Xaw3d Athena widgets.
Btw. any chance for a new tar ball point release to get up to sync
with potential changes in the development source tree from the last
years?
Can't bitbucket do that for you?
If you're worried about having something checked for stability, I
don't think that's going to happen soon. Things just aren't stable,
and I don't know how to get there soon. Aidan has merged two
megabranches recently, one, mostly by Ben Wing, to make the internal
encoding be Unicode (configure-time option) and the other, mostly by
Jeff Sparkes, to add preliminary support for GTK2 and GTK3. The
latter is quite broken for me, either due to Mac OS lossage or changes
in GTK semantics. I haven't tried GTK2 yet. Even in my normal
Xt+Xft+Xaw3d configuration, things are noticably unstable.
If you just prefer tarballs for some reason, I'll think about it.
Aidan, any opinions here?
Steve
8:24 p.m.
Hello again,
On 12/06/2017 10:55 AM, Stephen J. Turnbull wrote:
Aidan Kehoe writes:
> In fontconfig theory the -13 is pt,
That's right. If your X server is providing the right DPI for the
screen, fontconfig will automatically scale points to pixels
correctly.
> so it seems that the underlying library isn’t handling it
> correctly.
I don't think that's likely, given:
> > PS: Surprisingly the Xemacs menus and such sale automatically, just not
> > this most important, main edit buffer, ..?
Most of the "menus and such" have their fonts configured through X
resources rather than XEmacs faces. I think that most likely
something is going on in the face processing, but I don't have a good
idea what that might be offhand. XEmacs *should* be passing the
fontspec directly to fontconfig, which then finds the font, and passes
that and the spec to Xft, which renders at the right scale. I don't
recall that XEmacs tries to adjust fontconfig specs in any way.
On my own system this "just works", and the screens that get switched
are a Mac Book Pro 13" (2560x1600) and a Thunderbolt 26" (2560x1440).
so I should see the same effect that you do. But I don't.
Have you tried other fonts? Do you use this font with other
applications? What are the results in those cases? (I don't mean to
"blame the victim", but with the information I have so far the only
suggestion I have that would give quick resolution is that the font is
somehow broken, and a different font would work.)
If the font does work correctly in other applications and different
fonts show the same behavior in XEmacs, the next step would be to check to
see if XEmacs knows the actual dimensions of the screen. You can get
this information by evaluating
(list (device-pixel-width (selected-device))
(device-pixel-height (selected-device))
(device-mm-width (selected-device))
(device-mm-height (selected-device)))
Thank you for this hint. While the output is correct, I now use it in my
.xemacs/init.el to correct for the current xemacs xft shortcomings:
(if
(>
(/ (device-pixel-width (selected-device))
(/ (device-mm-width (selected-device)) 25.4)
)
140)
(set-face-font 'default "Source Code Pro-20")
(set-face-font 'default "Source Code Pro-12")
)
I usually do not write Lisp, so if you have tips for a Lips newbie feel
free to drop them. I probably further tweak this to scale to any HiDPI
in 72/2 steps or so.
This doesn't doesn't give the right answers with both screens
active
on my Mac although xdpyinfo seems to work correctly. I will
investigate that, but can't promise any results soon. It doesn't
surprise me that something weird would be going on in X since the Mac
will mirror or tile the screens at the Quartz level and authomatically
adjust things, so X doesn't actually know what's going on. But it
does suggest that XEmacs is messed up here somehow.
Regards
--
René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
https://exactcode.com | https://t2sde.org | https://rene.rebe.de
9:47 p.m.
Ar an dara lá is fiche de mí Feabhra, scríobh René Rebe:
Thank you for this hint. While the output is correct, I now use it in
my
.xemacs/init.el to correct for the current xemacs xft shortcomings:
(if
(>
(/ (device-pixel-width (selected-device))
(/ (device-mm-width (selected-device)) 25.4)
)
140)
(set-face-font 'default "Source Code Pro-20")
(set-face-font 'default "Source Code Pro-12")
)
I usually do not write Lisp, so if you have tips for a Lips newbie feel
free to drop them. I probably further tweak this to scale to any HiDPI
in 72/2 steps or so.
This way will work better with multiple displays:
(set-face-font 'default "Source Code Pro-12")
(define-specifier-tag 'HiDPI #'(lambda (device)
(> (/ (device-pixel-width device)
(/ (device-mm-width device) 25.4))
140)))
(set-face-font 'default "Source Code Pro-20" nil '(HiDPI) 'prepend)
I’ve tested the above with my local setup, it should just work.
The way to adjust it to work with multiple increments is something like the
following:
(macrolet
((define-tag-and-prepend (&rest points)
(cons 'progn
(loop for point
in points
nconc `((define-specifier-tag ',(intern (format
"point-width-%d"
point))
#'(lambda (device)
(< (/ (device-pixel-width
device)
(/ (device-mm-width
device)
25.4))
,(* point 10))))
(set-face-font 'default ,(format
"Source Code Pro-%d"
point)))))))
(define-tag-and-prepend 10 12 14 16 18 20 22 24 26 28 30))
I haven’t tested this, there may be a bit of bug-fixing involved. F1 f
macrolet or F1 f define-specifier-tag to help debug it.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
1:40 a.m.
Aidan Kehoe writes:
(macrolet
Good grief, Aidan! :-)
I haven’t tested this, there may be a bit of bug-fixing involved. F1
f
macrolet or F1 f define-specifier-tag to help debug it.
That is not easy code. Aidan's good, so even untested it probably
works as you want. ;-) But if it doesn't, please feel free to ask us
for more help.
Steve
--
Associate Professor Division of Policy and Planning Science
http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnbull(a)sk.tsukuba.ac.jp University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
2689
days inactive
2770
days old
11 comments
3 participants
participants (3)
-
Aidan Kehoe -
René Rebe -
Stephen J. Turnbull