Apache OpenOffice (AOO) Bugzilla – Issue 15507
DPI / font weirdness
Last modified: 2003-10-15 11:31:25 UTC
Hi there, So - variants of these patches worked better for OOO_1_0_3, it seems the font size is not set for internal widget fonts somehow with these; this basically removes a load of fudging the DPI settings, and replaces it with a more 'standard' set of fudges ;-) fixes a misunderstanding about Gnome's font size number [ points, not pixels ], and sets OO.o to use the system font by default [ for better integration ]. I'm interested (in passing) as to how the 'Font' structure represents non-integer point sizes; eg. '7.5', perhaps I'm missing something. HTH,
Created attachment 6800 [details] Sync with system font by default.
Created attachment 6801 [details] Bin some DPI fudge evilness
Created attachment 6802 [details] simplify & correct font size bits.
cp->pl: please have a look at it. I think you or hdu have already massaged the dpi settings to prevent small differences between x and y dpi (for freetypes sake)
The first patch will enable system fonts by default; i know this would enable more integration but needs discussion with e.g. lho (i'll set him on notify for this). Actually i think it would be a "good thing" to turn system fonts on by default for OOo. The second and third patch are only valid if applied together; contrary to the misnamed variable "nPixelHeight" the code patched in patch 3 originally only corrects for the different resolutions that VCL and gtk "see" on the device but still a point size is achieved (and set on the Font object), so the third patch will only work if the second is also applied. But i'm not quite sure about the usage of XGetDefault to get the resolution; we currently do not use the Xresource database at all - should we load a resource database then ? Also a quick look on my system - which is a SuSE 8.1 and actually uses Xft - shows there is no Xft.dpi inside the RESOURCE_MANAGER property of the root window (which is the default resource database). So I'm not quite sure whether this XGetDefault of Xft.dpi is really a good idea.
> I'm interested (in passing) as to how the 'Font' structure represents > non-integer point sizes; eg. '7.5', perhaps I'm missing something. The size in the font structure is in mapmode units. That means when using TWIPS mapmode the height is set to 20*7.5=150. When the mapmode is PIXELS fractional a font size is not possible. In your patches I don't understand where the binning step that is supposedly there is performed? I also don't really understand what the original problem is that is to be solved? Is it better Gnome integration or something like issue 12705?
Created attachment 6962 [details] Screenshot of what I *think* is the problem
So - yes; the first patch sets the default to sensible system font integration instead of some random accessibility option that 99% of people don't want ;-) - it'd be great if lho could comment on that. The Xft.dpi setting is always set on RedHat - it's also included in the Xft rendering library - hence, in order to reliably get the same font size as Gnome (and KDE, & mozilla) - you have to use the Xft.dpi setting, and fall back to calculating it from the X dypinfo. The vcl/source/window/window.cxx section of gui-font-scale.diff is perhaps redundant; it only re-hashes some of that code to gain precision. the vcl/unx/source/gdi/salgdi.cxx, and vcl/unx/source/app/saldisp.cxx sections bin another two of the egregious scattered "the dpi setting is not what I like, so I'm going to clobber it" chunks of code - how can those be justified ? I can ~perhaps understand the 20% difference thresholding, but setting a known-wrong, un-tweakable DPI setting is ghastly surely. it's interesting that gui-ft-pt-not-pixel.diff is broken; I don't understand Herbert's comment. It seems to me that most of the time GetScreenFontResolution == GetResolution and hence the aToken.ToInt32 will be eg. '12' and thus, we end up with a: aFont.SetHeight( 12 ); The signature suggests this value is a long, and yet this is a reasonable on-screen font size; so I am still acutely puzzled by a missing factor of 20 in here.
The "egregious 'i clobber the dpi setting because i don't like it' code" is exactly there because so many displays deliver pure nonsense.
Well - fair enough ;-) can we consider clobbering it only once, and use the same (predictable) logic that Xft uses, instead of a cook-our-own version ?
I'd like to. I just don't know yet who sets this resource - should we read an XResource database file ? Or does the session manager set it it on the root window ? I just wonder, because i'm using KDE with Xft all day long and the resource is not set on the root window.
Poking at that resource was done on advice from Keith Packard - who knows a little about Xft I believe. Owen Taylor - says most likely you have no Xft Xsetting - short of using Xft2 for rendering we just have to copy the algorithem - which if you look at Xft does what we do here: first use this setting, then fall-back to the screen's idea of DPI. OO.o should certainly not be parsing X resources itself; the Xft setting is down to the distribution vendor - I can only assume that your distro vendor is either a) very confidant in their X server's DPI setting or b) not aware that they could/should tweak this 'logical DPI' setting themselves. Either way - it'd be good to have in.
Yet more from Owen: Xft.dpi comes from a) Gnome sets it, b) Outside of Gnome distributions are responsible for setting it; prolly no-one but RedHat does though. Also "root window property" isn't really quite the right way to think about it since it could be in ~/.Xdefaults and then it wouldn't appear on the root window. HTH.
I thought the RESOURCE_MANAGER property on the root was the thing to go for, as it says in the man-page that $HOME/.Xdefaults is only read if it does not exist; i have not yet seen a desktop session where it doesn't. I just wanted to be sure. I'll apply your dpi patches anyway as it can do no harm on machines where the Xft.dpi resource doesn't exist. The man page for XGetDefault says: To create a database, XGetDefault uses resources from the RESOURCE_MANAGER property on the root window of screen zero. If no such property exists, a resource file in the user's home directory is used. On a POSIX-conformant system, this file is $HOME/.Xdefaults. After loading these defaults, XGetDefault merges additional defaults specified by the XEN- VIRONMENT environment variable. If XENVIRONMENT is defined, it contains a full path name for the additional resource file. If XENVIRONMENT is not defined, XGetDefault looks for $HOME/.Xdefaults-name, where name specifies the name of the machine on which the application is running.
Great :-) thanks for agreeing to apply the patches - it's great to get shrink the diff to HEAD & make Gnome(&KDE) integration that much better. Interesting how XGetDefault works under the hood - I'd never gone into that really.
i applied the DPI stuff (or rather adapted it to the current code) in CWS vcl15. That leaves the default system font issue; i suggest making a separate issue (assigned to lho) for this as it is User Experience's call to say what the default should be (IMHO you're right, it would probably be better in the name of system integration to use the font that everybody else uses).
Thanks so much Philip, that's great - I've opened a new bug: #16683, looking forward to seeing this in HEAD.
Philip - when is CWS vcl15 scheduled for re-merge to a live branch ?
I don't consider vcl15 dead :-). But the target integration date is 8/8/2003. I take it, for you the sooner would be the better ? I will see what i can do about it.
Michael: Sorry, but vcl15 needs to be resynced to SRC680 (which won't be available before tomorrow) and then has to pass through QA; i think it won't be much earlier than 8/8/2003, but i'll keep pushing.
verified in CWS vcl15. Sorry for the delay; they made the SRC680 available only yesterday.
code is in 680m3, closing