Apache OpenOffice (AOO) Bugzilla – Issue 12705
Installation GUI uses nearly unreadable fonts
Last modified: 2003-09-11 09:52:50 UTC
I'm using a near-stock RedHat 8.0 machine with the display resolution set to 1280x1024 (on a 21" monitor). The installation dialogue box and the subsequent full-screen window with the progress meter uses a small, and perhaps garbled, font that is nearly unreadable. If I can attach a file to this ticket, I'll include a gif showing you what I see.
Created attachment 5257 [details] Installation screen with nearly unreadable font.
*** Issue 12784 has been marked as a duplicate of this issue. ***
I can't reproduce with my RH7.2 machine. Please give more information about your hardware.
Created attachment 5374 [details] Output from xdpyinfo
Created attachment 5375 [details] XF86Config file
Created attachment 5376 [details] XF86Config file
Created attachment 5377 [details] XFS font server configuration file
I've attached the xdpyinfo output and my XF86Config for my display. The monitor is an HP A4431A (older 21" monitor at 1280x1024). The machine itself is based on an MSI KT266A motherboard with an NVidia MX200 64MB. I am using the NVdriver Kernel Module 1.0-3123 for the video driver. FONT SERVER INFORMATION: (I've also attached my xfs configuration file: /usr/X11R6/lib/X11/fs/config) keithh@kph [134]* xfsinfo -server unix/:7100 name of server: unix/:7100 version number: 2 vendor string: The XFree86 Project (experimental version) vendor release number: 6600 maximum request size: 8192 longwords (32768 bytes) number of catalogues: 1 all Number of alternate servers: 0 number of extensions: 0 If you have any more specific information requests, just ask.
Thanx for your help. The only thing I can see that might cause trouble is the color depth 'DefaultDepth 24' setting in XF86Config. If it won't cause to much trouble please retry with 16 or 32 bit setting.
I tried depth 16 and the problem persisted - nearly unreadable fonts. My card doesn't support depth 32 at 1280x1024.
I can't reproduce on RH 7.2 and RH 9.0. Herbert, do you have any idea what might happen here?
The line in the xdpyinfo which says > resolution: 83x89 dots per inch looks like the core reason. When OOo uses to these resolution settings to scale the fonts the pixel sizes in x- and y- direction are different, which makes it very difficult for the font renderers to produce highest quality glyphs. Most other apps don't have this problem because they ignore the x-dpi value and since they don't do the adjustments the problem doesn't show up. HDU->Keithh: Can you confirm that it looks better when you start the X server with the -dpi 72 argument? HDU->CP: With the new Xservers that query the monitor directly via DDC or when the user entered a physical display size in the Xserver config the previously rather uncommon situation that x-dpi and y-dpi resolution differ is getting more common. We should rethink our strategy to adjust slavishly to the Xserver because the fonts + have renderers a lot of problems to generate high quality glyphs when they have to stretched/squeezed. Is a hotfix like if(x-dpi==y-dpi+-30%) then x-dpi=y-dpi acceptable?
cp->hdu: as discussed, we should go for "freetype optimized" resolutions if the deviation is not too high.
Ok, I will try to bin x- and y- resolution to a common value under X11.
When x-/y-resolution disagree by less than 20% setting x-res to y-res.
Fixed in CWS VCL09. Please verify (e.g. on HB's system). Please note the limitation of the x-y tolerance of 20%. If it is more we must assume the differences between the resolutions have a real meaning.
=> set to 'resolved fixed'
SBA: We (OF and me) could noever reproduce this. Therefore we can not really verify the fix. Believing that Herbert knows what he was doing AND not seeing any change during setup ourselves, I will close this one. SBA->Keithh: In case you still have a problem after the integration of CWS vcl09 into a master build (or the next milestone you can access), feel free to reopen this one. Thank you.
I'll recheck when 1.1 is released. Thanks for all the investigation and effort - the explanation and proposed solution sounds good. Great product.
*** Issue 19160 has been marked as a duplicate of this issue. ***