Apache OpenOffice (AOO) Bugzilla – Issue 40919
Anti Aliased fonts are illegible
Last modified: 2005-07-25 14:56:30 UTC
I have the same problem with OO-1.1.3 and 1.1.4 package and source version. I am running freebsd 5.3-RELEASE with xorg 6.8.1. Fonts appear to overlap in both the OO interface and documents rendering certain letters illegible. I have a screenshot which I will happily send. I have tried the following fixes, none of which has helped at all: freetype2 pango - OpenOffice ships with own freetype library libfreetype.so.9 - How built? - Not built, it's in LIB_DEPENDS; so where does it end up in the package? during build phase? Referenced in setup log, but copied from package Not in any sonames except: libvcl645fi.so elfdump it, check DT_NEEDED hints - grep reports ref. strings does not. strings not looking in all sections? - elfdump reports refs in dynamic sections. ft_glyphslot_free_bitmap references ft symbols but does not appear to depend on it directly (no DT_NEEDED) -- assume that it's pulled in indirectly, walk DT_NEEDEDS ldd donut werk here persuade it to work: env LD_LIBRARY_PATH=`pwd` ldd libvcl645fi.so Throw an -a in to indirect fontconfig This points the finger at X... use lsof to inspect vm objects -> freetype does not appear to be referenced in ANY WAY!! --> leads me to believe that X is where the truetype rasterization is coming from (using RENDER extension) -> double check symbols (to be sure) -> freetype was compiled STATICALLY!!! Xrender is referenced dynamically, but indirectly interesting symbols? -> so the finger indeed points to X. -> Check xorg.conf font rendering modules in use. Leaving out fonts for now Load module confs: freetype xtt type1 speedo Font paths: default. Check x startup logs [1] + 2895 Suspended sudo view Xorg.0.log - grep for 'Loading fontXXXX' Check font path, fonts.dir errors, etc - Have there been backend changes? Theories - font path problems, missing font.dir, metrics etc -> further research may be needed - corrupt glyphs -> file corruption of .ttfs - wrong charset for ttf file - fonts shadowed in path, ie kosher fonts present, but above behaviour preventing good render - rendering has changed - xtt has been depracated in 6.8.0 check xorg-fonts-encodings port is present - yes, files are present, except for encodings.dir which is zero length - double check, perform 'locate encodings.dir | xargs ls -l" last updated dec 23, many of the encodings.dir files on the affected system are *actually* symlinks pointing to the zero length main encodings.dir file. suggest rerunning mkfontdir appropriately date Dec 23 of zero length encodings.dir - Attempt to resolve encodings.dir issue by: 1. running mkfontdir -e in main encodings dir 2. xset fp rehash - Does not resolve OO problem - Can't confirm it fixes the freetype encodings errors in Xorg.log - No encodings file specified in xorg.conf - Is there such a directive? - No. Font encodings are looked for in one central compiled-in path, and each individual font directory. font path elements reorganized, did not resolve. many invalid font path elements. try removing user font paths et cetera, trim the fat down. xset fp default && xset fp rehash --> does not resolve trimming font path on startup, after eliminating bad font path elements -- no resolve try flip to default to lose kde added user defaults, rehash, and rerun -- no resolve force *all* fontconfig cache files to be rebuilt in the system like we really mean it -- -- does not resolve force all encodings.dir files in the system to be regenerated, including the removal of symlinks bounce x/kde check x error log -- startup ok, no failure mode as known introduced resolution? -- does not resolve truetype font files in a bitmap directory - looks odd. latin2 element may be bunk, try removing it -- no resolve futz with /usr/X11R6/etc/fonts/local.conf to tweak freetype/fontconfig rendering settings, specifically disabling autohinting -- no resolve creating a symlink to encodings.dir in openoffice's fonts directory -- no resolve finally, check freetype and pango versions installed pango-1.6.0 freetype2-2.1.7_4 check for any legacy libraries no freetype version 1 in sight, mine has, unused apparently freetype versions in sync with mine deleted and reinstalled truetype fonts re-installed openoffice no resolve
Created attachment 21645 [details] screenshot of affected openoffice installation
reassigned to US.
FYI: I get antialiasing when running OOo in a regular X-Session, but when running OOo in Xnest on the same machine, the fonts are not antialiased (althoug the fonts in other apps still are) So my guess is that this has do do with Xserver-properties/extensions. Extensions available in regular X session but not when running Xnest: DPMS MIT-SHM RANDR RENDER XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD In Xnest, but not in regular: DEC-XTRAP,RECORD From those modules, I suspect "RENDER" is the one to blame. Please check whether your display provides the RENDER extension. IIRC there were problems with xinerama in the past as well. HTH
thanks for your comment cloph, it appears rendering is enabled, here are my results for glxinfo: %glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20040929 TCL OpenGL version string: 1.2 Mesa 6.2.1 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
oh and here is the info from xpdyinfo where RENDER is working: %xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 60801000 X.Org version: 6.8.1 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x6800007, revert to PointerRoot number of extensions: 31 BIG-REQUESTS DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 1024x768 pixels (347x260 millimeters) resolution: 75x75 dots per inch depths (7): 16, 1, 4, 8, 15, 24, 32 root window id: 0x48 depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0xfa4031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 16 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x24 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x25 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x26 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x27 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x28 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x29 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x2a class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x2b class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x2c class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x2d class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x2e class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x2f class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x30 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x31 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits visual: visual id: 0x32 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 6 bits %
This should not be a problem with OOo 1.1.x any more, but earlier versions required that the display is using 24 or 32 bit color: (from issue 3718) "OOo doing Xlib based AA is currently only possible with truecolor (i.e. 24/32bit color or 8bit grayscale) visuals. Having Xlib based AA on 15 or 16bit displays is planned, but not at a very high priority. The rationale behind this, that a computer with an old release of XFree/XRender and with less than 24bit color is quite probably too slow anyway to do Xlib based GetImage/PutImage antialiasing with acceptable performance."
Thanks Cloph again, My xdpyinfo shows that a TrueColor visual in use, it's running wth a 16 plane TrueColor visual, The box is a thinkpad T41 so it's not old hardware with limited resources. The system is definitely using Xft antialiasling because KDE 3.3 is using it so I don't really know why Xlib would be relevant here. Do you have any suggestions for resolving the issue, I have now installed openoffice.org1.9m71 from a package and have the same problem with that. thanks .nbco
cite "truecolor (i.e. 24/32bit color or 8bit grayscale)" 16 != 24 Why don't you give it a try? I just checked: 16 (my default setup) -> no aa in Xnest - changed to 24 -> AA works in Xnest-session. > The system is definitely using Xft antialiasling because KDE 3.3 is using it so what? My Xnest-Session has antialiasing in Gnome but not in OOo in 16bit. What does this tell us? -> Applications may behave differently. And how do you know that KDE actually is using Xft? > so I don't really know why Xlib would be relevant here. Obviously the alternative (using XRender) doesn't work for some not yet discovered reason. > Do you have any suggestions for resolving the issue Try 24 bit color.
Thankyou very much, Changing my xorg.conf to 24 bit truecolour solved this problem. Thanks again, and sorry for this late response as I have been unable to type.
Thanks for the feedback. Sum-up: Antialiasing fails although RENDER-extension is present. Antialiasing works when using true-color (24bit). I filed a similar issue 41108 (provide antialiasing with <24bit) Now the task is to determine why the XRENDER-bases antialiasing fails.
Seems like the original issue is resolved. Thanks Cloph again for the excellent work.
I'd like to close this issue if there aren't any objections.
Closed