Fwd: Bug#237877: X's falling back to 75 dpi
Hi everyone, On 22/4/2005 Cristopher Martin wrote : > Recently I took it upon myself to adjust KDE's default fonts > I picked as a default size 10 points, That is the problem. You specify fontsize in points. And then you try to "solve" problem by setting dpi. Dpi represents (or should represent) dots per inch of a display. For each display it is a fixed value. If you change it and use it, it represents something different. Using one global variable to represent two different things is bad. If original meaning of dpi is completely useless, then dpi only represents one thing, but has a confusing name, which is bad. A 'point', when used as a measure of fontsize, as defined by creators of Postscript, is exactly one 72ndth of an inch. It is a very usefull measure for output printed on paper. It is not usefull for specifying output on a monitor, because it is an absolute measure (it is also a relative measure, in that it specifies relative size of one font compared to another if both are specified in points, but that is not relevant here), and while output printed on paper is looked at from a fairly constant distance, this is not true for monitors, where viewing distance depends on monitor and on kind of text viewed. So what measure should be used for specifying fontsize on a display ? As rules of thumb, * viewing distance is proportional to size of display, and * different kinds of text are viewed with different applications, and default font can be set per application. Due to second rule of thumb, we only need consider one type of text ; if that can be handled correctly, then so can all others (provided someone selects appropriate default fonts for them). Due to first rule of thumb, size in meters of a displayed font should increase proportionally with increasing size of display, and as physical dots per inch of displays is fairly constant, a reasonable approximation can be made by specifying font size in pixels, where 'reasonable' means: less than 10% away from ideal size. The BillyBigs pages your email refers to, say that Windows uses an 8 pt font at 96 dpi, MacOS uses a 13 pt font at 75 dpi, 8 [point] * 1/72 [inch/point] * 96 [dot/inch] = 10.66 [dot] 13 [point] * 1/72 [inch/point] * 72 [dot/inch] = 13[dot] * fractional dots can't be displayed; windows's tahoma is probably rendered as 11 pixels. * difference partly reflects different uses these fonts have, Windows being mainly for use in an office, and MacOS more targeted at high-quality visual output, which is similar to different per-application fonts. * remaining difference reflects user-preferences, which may depend on real dpi of their user's monitors ; i would expect MacOS users to have somewhat higher real dpi. Thus specifying fontsizes in pixels always enables to specify a good approximation of ideal font size. But maybe we can do better if real dpi is known. I think that if a user gets a monitor of same size s/he had previously, but with higher real dpi, then s/he will want to use this for two things: better looking fonts, and seeing more text on display. Let's assume that both desires are equally strong, and we can model it by assuming that they will increase their viewing distance by a factor that is square root of ratio of new dpi to old dpi. As far as i know, range of real dpi's is between 75 and 100 (thus 'dotsize' of a monitor is between .25 and .33) (but i could imagine tft screens having smaller dots), thus square root of ratio of extreme dotsizes is 1.15 , and if an average is used, ideal value deviates less than 8% from it. Thus, if default fontsize has been specified in pixels, and it has been specified to a value that is best for average user, then correcting for real dpi would result in max 1 pixel difference. In practice, increasing a font size by 1 pixel can make it look ugly, often because middle bar in E is no longer in middle. While implementing optimization for real dpi could be good (it would require a beauty contest, and a 'beauty' field in XFontStruct), there are currently more important optimizations to be done, as you currently specify fontsize in points, so next thing to do would be to change that to a specification in pixels. Trying to change default dpi for a purpose that is different from making it more accurately represent most common or average dpi of our user's displays, amounts to you pushing a specific (wrong) interpretation of dpi, which goes against wishes of others, who use a different (wrong) interpretation of dpi. This explains why you got complaints. If K applications are not capable of specifying default font in pixels, please fix that, instead of trying to change X in a random unrelated way. The above implies that it is not possible to com
Is the Pain Unbearable?
Need Help To Numb the Pain? http://www.c5t.net/ph/coupon/irishkatidid Stop all future contacts c5t.nett.php He was a verray, parfit gentil knyght.
Bug#237877: Fwd: Bug#237877: X's falling back to 75 dpi
On May 1, 2005 08:26, you wrote: > On 22/4/2005 Cristopher Martin wrote : > > Recently I took it upon myself to adjust KDE's default fonts > > I picked as a default size 10 points, > > That is the problem. You specify fontsize in points. > And then you try to "solve" problem by setting dpi. The most obvious means at my disposal... > Trying to change default dpi for a purpose that is different from >making it more accurately represent > most common or average dpi of our user's displays, That is precisely what I suggested in my message - 96 dpi is much closer to the typical dpi of displays than 75 dpi. >amounts to you pushing a specific (wrong) interpretation of dpi, >which goes against wishes of others, >who use a different (wrong) interpretation of dpi. > This explains why you got complaints. Before this change, the complaints were that the default fonts were too large, since for most people, with correct dpi on modern displays, they were. Many users have also objected to forcing a specific dpi on them (therefore establishing a known relationship between points and pixels) and while I wouldn't mind it myself, it would have to be done either in the manner of GNOME, where users can adjust it themselves with a nice GUI, without superuser privileges, or else in the manner proposed by Mr. Biggs' article, namely an easily editable/removable setting in a global configuration file. > If K applications are not capable of specifying default font in pixels, >please fix that, >instead of trying to change X in a random unrelated way. Your arguments are very interesting, but I have a concrete problem to solve, one that can be substantially ameliorated by an almost trivial change to a specific default value in X. I realize that this change is not a perfect or complete fix to a very general problem, but I'm not about to rewrite the X/KDE font system at the moment. > That are my thoughts on this subject. > Please feel free to point out anything you think is wrong with them. I appreciate your interesting thoughts on the matter of font sizes, and I agree with many of your ideas - but they don't constitute a rebuttal of my request to have a small change to X made (and perhaps they weren't intended to, but it seems that way). You are critiquing the general font sizing system currently in use, and that is fine, but I'm interested in a smaller and easier "patch-up" for the time being. Cheers, Christopher Martin pgpi31ThoGUep.pgp Description: PGP signature
Bug#307216: xterm colorization problems
Package: xterm
Version: 4.3.0.dfsg.1-12.0.1
Severity: important
Tags: patch
Xterm has some colorization problems which are pop-up for example if you
read your eMail in mutt in a screen. The problem is:
From: Thomas Dickey <[EMAIL PROTECTED]>
To: Thomas Glanzmann <[EMAIL PROTECTED]>
Subject: Re: Color problems with xterm-201
Date: Sun, 1 May 2005 15:31:09 -0400
I found the problem (took about an hour). It was when xterm was writing
out pending data, updated the display's colors and didn't restore. That
happened to be in one of those rarely-needed checks - it had some data
leftover telling it to scroll just as it started writing new data.
This fragment in charproc.c:
if (!AddToRefresh(screen)) {
/* make sure that the correct GC is current */
currentGC = updatedXtermGC(screen, flags, fg_bg, False);
if (screen->scroll_amt)
FlushScroll(screen);
doesn't account for that one of the functions called by FlushScroll()
could modify the display's colors as is done in updatedXtermGC().
What's odd is that the code is very old - and no one reported it before.
I see the updatedXtermGC() call from 1996. (On the other hand, I've
encountered bugs that old more than once).
Anyway, the fix for that is to move the assignment past the if
statement:
if (!AddToRefresh(screen)) {
if (screen->scroll_amt)
FlushScroll(screen);
/* make sure that the correct GC is current */
currentGC = updatedXtermGC(screen, flags, fg_bg, False);
I'll check for other occurrences, of course.
The attached patch fixes the described problem. Please apply and
recompile.
--- xterm-201/charproc.c~redraw
+++ xterm-201/charproc.c
@@ -3435,12 +3435,13 @@
InsertChar(screen, cells);
}
if (!AddToRefresh(screen)) {
- /* make sure that the correct GC is current */
- currentGC = updatedXtermGC(screen, flags, fg_bg, False);
if (screen->scroll_amt)
FlushScroll(screen);
+ /* make sure that the correct GC is current */
+ currentGC = updatedXtermGC(screen, flags, fg_bg, False);
+
if (flags & INVISIBLE) {
if (cells > len) {
str = temp_str = malloc(cells);
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (1050, 'testing'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.30
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages xterm depends on:
ii libc62.3.2.ds1-21GNU C Library: Shared libraries an
ii libexpat11.95.8-1XML parsing C library - runtime li
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management
ii libxaw7 4.3.0.dfsg.1-12.0.1 X Athena widget set library
ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte
ii libxft2 2.1.7-1 FreeType-based font drawing librar
ii libxmu6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous util
ii libxpm4 4.3.0.dfsg.1-12.0.1 X pixmap library
ii libxrender1 0.8.3-7 X Rendering Extension client libra
ii libxt6 4.3.0.dfsg.1-12.0.1 X Toolkit Intrinsics
ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu
ii xlibs-data 4.3.0.dfsg.1-12 X Window System client data
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
