Apache OpenOffice (AOO) Bugzilla – Issue 6562
Glyphs from TrueType font (Arial) are sometimes rendered mirrored
Last modified: 2003-07-28 09:42:35 UTC
With antialiasing disabled (or truetype fonts smaller than "Extras" -> "Optionen..." -> "Ansicht" -> "Bildschirmschriften glätten"), OO 1.0.1 sometimes displays mirrored glyphs from truetype fonts. This often happens with the "Arial" TrueType font included with Solaris 8, either the one in /usr/openwin/lib/X11/fonts/TrueType/ or the one in /usr/openwin/lib/locale/iso_8859_15/X11/fonts/TrueType/ Btw. I get exactly the same problem with StarOffice 6.0 PP1 on Solaris 8 (SPARC and x86).
Created attachment 2346 [details] OO text document using all iso8859-1 characters from Arial font
Created attachment 2347 [details] Screendump showing mirrored glyhs from "Arial" font
This is Xsun's fontpath, which produced the mirrored glyphs /home/jk/.dt/sdtfonts/de_DE.ISO8859-1/Helvetica__adobe_gPaOmy,/usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/openwin/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi/,/usr/openwin/lib/X11/fonts/TrueType/ Please note the mirrored glyphs in the attached screendump for Arial 12pt: a e Arial Italic 12pt: a c e s u v z Arial Bold 12pt: a c s Arial Bold Italic 12pt: c s z By changing the font size ("Select All" text -> change font size via context menu) you can also produce other mirrored glyphs (e.g. Arial Bold 8pt has problems with uppercase letters B G S Z ....) ------ I've experimented a bit with the "freetype" code included in OO 1.0.1. By updating OO's "freetype 2.0.5" code to the latest (stable?) release of freetype2 ("freetype 2.1.2"), the problem can be fixed. I also tried other versions of freetype2 (2.0.9, 2.1.0 and 2.1.1) but all of them suffered from the same "mirror glyph problem".
Created attachment 2348 [details] freetype/freetype-2.1.2.patch : New file to compile OO 1.0.1 with freetype2 version 2.1.2
Created attachment 2349 [details] Patch to enable freetype 2.1.2 in OO's "freetype" module; and update required for "vcl" module to use new freetype2 code
Build instuctions for OO 1.0.1 with the updated freetype 2.1.2: - Add attachment ID=2348 as new file "freetype/freetype-2.1.2.patch" to OO's "freetype" directory - Download freetype-2.1.2.tar.gz from www.freetype.org and place it into "freetype/download/freetype-2.1.2.tar.gz" - Apply the two patches from attachment ID=2349 to OO's modules "freetype" & "vcl"
Very interesting problem that we haven't seen yet. I couldn't recreate it here though and this is the first time I hear from this problem, so it seems to get triggered only in rare circumstances. Can you tell us more about your environment like distribution, XFree version, bitdepth, ...? The symptoms you describe suggest that probably FT's autohinter did this flip. Thanks a lot for the patch. We plan to upgrade soon for a lot of reasons but one has to be very careful, e.g. because new versions sometimes also have regressions, e.g. 2.1.2 is reported to have regressions like problems with text rotation.
> Can you tell us more about your environment like distribution, > XFree version, bitdepth, ...? Hmm, this is on the Solaris 8 platform, not on linux. OS: Solaris 8 (SPARC Ultra60, Creator 3D) OS: Solaris 8 (x86, Tyan Tiger S2460, ATI Radeon 7500) OS: Solaris 8 (x86, Asus A7V, ATI Xpert98) X Server is Sun's official Xsun server, not XFree. The PC Solaris versions are running at 24-bit depth, the Creator has multiple visuals (8 & 24bit)
Are these glyphs mirrored independently of the zoom factor? e.g. change View->Zoom to "Optimal" and slowly resize; do the problematic glyphs suddenly flip?
> Are these glyphs mirrored independently of the zoom factor? It depends on the zoom factor. > e.g. change View->Zoom to "Optimal" and slowly resize; do > the problematic glyphs suddenly flip? Yes, with Zoom == Optimal and a scale factor of 90% the glyhs look OK; resizing the window a bit more so that the scale factor is set to 91% flips some glyphs.
This is weird. We really need to find the root cause of this. It may be that it happens only with glyphs that have a width divisible e.g. by seven. The move to the new FT might just have caused different rounding so the problematic case doesn't occurr up so often. Candidates are: - FT's autohinter has problems with this font - FT's monochrome rasterizer on big endian machines - X11GlyphPeer::GetPixmap in vcl/unx/source/gdi/gcach_xpeer.cxx - XCreatePixmapFromData on this X11 server - XDrawRectangle with a tiled GC on this X11 server
US->JK: curious bug. But we can't reproduce it (yet). I'd really like to know which font exactly shows this behaviour. If I got you right the trouble causing font is the Arial from /usr/openwin/lib/X11/fonts/TrueType/ resp. /usr/openwin/lib/locale/iso_8859_15/X11/fonts/TrueType/. Pls. set this path on top of your font path and verify the issue again. It's not that I don't believe you, but from my point of view I can't be 100% sure that the font does not belong to /home/jk/.dt/sdtfonts/de_DE.ISO8859-1/. When you clearly identified the font, pls. attach its files to this bug. Are you really sure you saw this also with an original libvcl as eg. in SO 60 PP1? What more can you tell us about your system? What is e.g. the resolution of the Creator, dpi ... Pls. do an xdpyinfo and attach it to this task. Thank you.
JK->US: Yes, both the Arial fonts from /usr/openwin/lib/X11/fonts/TrueType/ and /usr/openwin/lib/locale/iso_8859_15/X11/fonts/TrueType/ show this behaviour. I've stripped down the fontpath to just include /usr/openwin/lib/X11/fonts/TrueType/ /usr/openwin/lib/X11/fonts/75dpi/ /usr/openwin/lib/X11/fonts/100dpi/ (in that order) and the problem is still present. These Arial fonts should be part of every solaris installation since at least Solaris 2.6. They are part of the Solaris package "SUNWi1of". I've compared checksums for these truetype files on various Solaris installations (2.6 & 8, SPARC & x86) and these files are identical on all systems: % sum /usr/openwin/lib/X11/fonts/TrueType/Ar*ttf 53029 139 /usr/openwin/lib/X11/fonts/TrueType/Arial-Bold.ttf 64170 153 /usr/openwin/lib/X11/fonts/TrueType/Arial-BoldItalic.ttf 29290 131 /usr/openwin/lib/X11/fonts/TrueType/Arial-Italic.ttf 37436 138 /usr/openwin/lib/X11/fonts/TrueType/Arial.ttf 40460 142 /usr/openwin/lib/X11/fonts/TrueType/ArialNarrow-Bold.ttf 51910 149 /usr/openwin/lib/X11/fonts/TrueType/ArialNarrow-BoldItalic.ttf 59746 150 /usr/openwin/lib/X11/fonts/TrueType/ArialNarrow-Italic.ttf 58192 150 /usr/openwin/lib/X11/fonts/TrueType/ArialNarrow.ttf -------------- Btw. I've re-tested the problem on several machines now, and have some problems reproducing it myself, esp. when displaying on the Ultra60 with the Creator card. But there's one notable exception: The problem did occur *every* time when I display to a Solaris 8 x86 box using an ATI Radeon 7500 card. The problem occurs with: 1. - SO 60 PP1 SPARC displaying to remote S8-MU7 x86 with ATI Rad.7500 2. - SO 60 PP1 Intel displaying to remote S8-MU7 x86 with ATI Rad.7500 3. - OpenOffice 1.0.1 Intel displaying on local S8-MU7 x86 with ATI Rad.7500 4. - OpenOffice 1.0.1 Intel displaying to remote S8-MU7 x86 with ATI Rad.7500 (My OpenOffice 1.0.1 SPARC is still compiling, so no test results at this time) At this time I'm not able to reproduce the problem displaying from {OO 101 Intel, SO 60 PP1 SPARC, SO 60 PP1 Intel} to a local/remote {Creator 3D (SPARC), ATI Xpert@Work (Intel)}. The problematic X11 server is the Xsun from Solaris8 x86 + MU7, with patch 108653-41 installed. I'm using the ATI Radeon driver "Solaris XFree86 Video Drivers and Porting Kit" from Sun for the video card driver: http://soldc.sun.com/developer/support/driver/tools/video/video-index.html
Created attachment 2380 [details] Standalone X11 test program to reproduce the issue
Cool. Thanks for the test program. This shows that it is a driver problem on the X11 side. Can you open a BugTraq bug against the Xserver for this problem? We haven't been able to reproduce the problem yet and would like to avoid the troubles of being a superfluous "man in the middle".
OK, I'm now able to reproduce the issue with a small X11 test program (see sochar.c attachment) using more or less the same X11 calls SO/OO would use to paint non-AA truetype chars. This program displays the same mirrored glyphs when displaying on the ATI Radeon 7500. So, I'd say this is an X11 server (or X11 video driver?) issue, not a OO issue. I'm not yet sure why updating the freetype code inside OO made a difference... I'll have a closer look into that... Btw. the X11 test program shows the same mirrored glyphs when displaying on a linux box, using the same ATI Radeon 7500 card and XFree86 compiled from recent (2-3 weeks old) CVS sources (needed to get ATI Radeon 7500 DFP support which is missing in the 4.2.0 release version).
Found the reason, why the Xfree86 ATI Radeon driver bug isn't triggered with freetype 2.1.1 or newer. It's the following change in freeytpe 2.1.1: 2002-04-30 Werner Lemberg <wl@gnu.org> ... * src/raster/ftrend1.c (ft_raster1_render): Make `pitch' always an even number. % gdiff -u freetype-2.1.{0,1}/src/raster/ftrend1.c --- freetype-2.1.0/src/raster/ftrend1.c Sun Mar 31 20:48:24 2002 +++ freetype-2.1.1/src/raster/ftrend1.c Tue Apr 30 16:26:49 2002 @@ -167,7 +167,7 @@ } else { - pitch = ( width + 7 ) >> 3; + pitch = ( ( width + 15 ) >> 4 ) << 1; bitmap->pixel_mode = ft_pixel_mode_mono; } With the old freetype 2.0.5, the mirrored glyhps have a size of 8x8 pixels, stored in memory with one byte per scanline. Starting with freetype 2.1.1 they still have a size of 8x8 pixels, but stored in *two* bytes per scanline (pitch == 2). I've changed OOs' freetype 2.0.5 patch to include the updated calculation for the 'pitch', rebuild and installed a new libvcl.so and the mirrored glyphs are gone.
Great! It is a pleasure to work with people like you. But I'm worried that the problem might reoccur once the width hits e.g. 16 pixels. Can you verify the fix using "optimal" view and resizing slowly?
By the way, I couldn't find your name on the list of copyright-approved people: http://www.openoffice.org/copyright/copyrightapproved.html Before we can accept patches >=10 lines into OOo's CVS you should consider signing up at http://www.openoffice.org/contributing.html
OK, I've signed and faxed the form.
HDU->US: This used to be a problem on ATI cards on XFree's older than 4.3. Time to close...
Jürgen, as OOo 1.1 now uses the system's libfreetype (exception is Solaris) and it's a bug in FreeType, can you agree to close this one?
Jürgen Keil->US No problem with closing this bug. I'll try to change it to an "invalid" bug report, because it's not an OOo problem. It turned out to be a bug in the XFree86 ati radeon video driver, and the problem should be fixed in XFree 4.2.99.4 and newer. The XFree86 bugfix id is #751 (IIRC): 751. Fix for Mono8x8 patterns on Radeon (#A.1520, Juergen Keil, Kevin Martin). The updated freetype versions where just sending different fill patterns to the X11 server, so the 8x8 mono fill pattern bug in the ati radeon driver wasn't triggered.
Thanks, Juergen. Closing issue as agreed.