Apache OpenOffice (AOO) Bugzilla – Issue 2613
Bad antialiasing/rendering of fonts with new libvcl (641C build)
Last modified: 2002-08-14 16:53:46 UTC
Followup to issue 2143. The antialiasing is broken (much worse) if I use the new libvcl which was sent to me by Herbert Duerr to fix the issue 2143. See screenshots attached to that issue. Esp.: http://www.openoffice.org/issues/showattachment.cgi?attach_id=844
Is the screenshot in the attachment supposed to show the problem? We cannot see any issues. Can you provide a screenshot with the original vcl, where the problem didn't exist?
If you look at that screenshot and at the screenshot: http://www.openoffice.org/issues/showattachment.cgi?attach_id=845 You'll see that there are subtle differences which are much more visible on other fonts which aren't shown on these screenshots (esp. Times New Roman and Garamond) These fonts are very ugly with the new library. As I've said I'm unable to make the screenshot in 16bpp (which is the only display depth that shows the bad antialiasing). The new antialiasing is so ugly that it's even better to switch it off.
Just to clarify, does attachment 845 [details] look better than attachment 844 [details]? In this regard the main difference between between the original libvcl and the new one is that the new one uses freetype version 2.0.5 with autohinting enabled while the original one used freetype version 2.0.2 with autohinting disabled.
Created attachment 846 [details] Screen shot of an 641b version (fine antialiasing)
Yes but I see the same (as in the attachment 845 [details]) rendering when I use the new libvcl under 24bpp. If it's only the autohinting then it is badly broken because it seems to me it does just the opposite of what it should do. Or maybe the autohinting should be enabled only when autoaliasing is switched off. (That could make sense because the hinting is supposed to work especially when the fonts aren't antialiased.) Do you link the freetype library statically or dynamically because I have freetype-2.0.1 shared library installed in the system? But I don't think it will make any difference because what I see on my screen is just exactly the same as on the attachment 844 [details]).
Just to comment : I have no problem with font aliasing in the body of the document. It seems that something prevents the antialiasing everywhere (even in dialog boxes) but not in the document itself. I cannot see any difference between 16 and 24 bpp : it doesn't look better with 24 bpp. I'm using Freetype 2.0.5. I took the RPM package on rpmfind.net. Do you want me to test with the 2.0.5 source version ?
Rui, do you agree with Tomas that AA looked better in the original vcl? > maybe the autohinting should be enabled only when autoaliasing > is switched off Some people complained about getting headaches looking at the non-autohinted fonts. When I understand both of you correctly you are saying auothinted fonts look worse. I guess these preferences depend on display resolution and monitor characteristics. Since these personal preferences cannot be fixed by a "one size fits it all" solution I suggest to change the issue into a feature request to make autohinting optional. > do you link the freetype library statically or dynamically Because the different releases and compile options have quite an impact on features, problems, their workarounds and also on legal issues we link it statically.
> Rui, do you agree with Tomas that AA looked better > in the original vcl? If you're talking about AA in the menus, etc. : Yes, no doubt that for me it looks much better in the original one. > maybe the autohinting should be enabled only when autoaliasing > is switched off I don't know what autohinting is. Some advanced feature of Freetype ?
Autohinting is automatic grid fitting as opposed to explicit grid fitting, which is not available yet for our Office. You can see the effect of grid fitting when you magnify the screenshot by a large factor and look at the characters. Without grid fitting there is a grey blur around them which some people e.g. on low resolution displays find rather annoying.
I've installed a 641C build an the antialiasing is bad on 24bpp displays too. It seems to me as the hinting of Truetypes was switched off. When I switch off the antialiasing in options completely the fonts are rendered as they weren't hinted (or they were hinted only partially). I'll give you screenshots because now I'm able to make them.
Created attachment 906 [details] Screenshot with antialiasing on (bad hinting)
Created attachment 907 [details] Screenshot with antialiasing off (bad hinting)
Created attachment 908 [details] Screenshot of Mozilla with antialiasing off (good hinting)
The mozilla screenshot looks nicer because it uses a different method of hinting, which we currently cannot use.
Why can't you use it? If it's definitely not possible what about adding a preference option to switch off the current autohinting? Should I file a new issue (enhancement) for adding the pref?
Because of legal issues. Using explicit hinting for Mozilla's fonts has the same legal issues, though this method has some advantages for some fonts as you discovered. But it has the disadvantage that legal implications need to be carefully considered. Since I am not a lawyer I cannot go into details.
> If it's definitely not possible what about adding a > preference option to switch off the current autohinting? Maybe there can be some heuristic like: disable for high resolution, enable for low resolution monitors. But since so many devices lie about their resolution and there are other factors like CRT/LCD and screen gamma that may influence it, I think we need the option to manually enable/disable it.
Added new issue 2792 for the preference option. About the legal issues - it seems to me when mozilla can use it it shouldn't be problem for openoffice too. But it could require to link the freetype library dynamically. So I don't believe it will change soon. Note to self: Maybe it's time to compile my own OpenOffice with a little patch to enable the explicit hinting. Is it possible to compile the libvcl only and add it to the existing installation?
> Is it possible to compile the libvcl only and add it to the > existing installation? Sure, without this possibility developing would be quite painful. See http://www.openoffice.org/dev_docs/source/build_linux.html#BuildingIndividualProjects Please note that the legal issues about explicit hinting mentioned above need to be considered by you when you enable it for your build.
I just HAVE to say this: Fonts in OpenOffice look so bad it's a chore to even start the application. I have no interest in AntiAliasing fonts on OO. Using my installed fonts as unaliased however, look great in all other applications - than OpenOffice. I have turned off all antialiasing in OpenOffice. I have imported Type1 and truetype fonts as links. And everything still looks as bad. Look at the UI for instance: Menus are hardly readable. Letters are "blocked up" and spacing between them seems random. This is the same ugly flaw as in 641C as there was in 641 and 638. I use RH7.1 with xfs as fontserver, and it is tempting to believe that OO doesn't even try to listen to it, but instead tries to act as its its own fontserver. With a result so bad that the applications isn't really usable - the annoyance factor is too high. How can this bug be resolved as fixed? There is nothing special about Mozilla's hinting. Mozilla does the same as most other apps under xfs. Attaching a screenshot showing the Gimp, Gnome Control Center and Gedit - a simple text editor (a'la notepad on Windows). It is only space problems that caused me not to also show off Qt based apps, but trust me: There is NO difference between how Qt and GTK apps render fonts. Both quietly accept to get their fonts from xfs, and are pleasing to the eye. Please also compare to the UI fonts in a Linux screenshot found in attachment http://www.openoffice.org/issues/showattachment.cgi?attach_id=549 from bug 1637. There the fonts look crisp clear. Someone there talks about "a bug in the freetype autohinter that we can't fix" but that has got to be pure rubbish. Why else do other applications utilizing xfs/xfsft (based on freetype) show fonts OK?
Created attachment 1086 [details] the good, the bad, and OpenOffice. (100k)
We will not enable bytehinting as long as legal patent issues remain unresolved. If Mozilla or Gnome think different it's their choice.
Created attachment 1090 [details] what OO and xfd thinks about the same font
Created attachment 1091 [details] comparision: Netscape 4, Mozilla, OO - showing same page.
In the comparision NS/Moz/OO i edited the middle cell in OO and made the font as small as to match the visible size that NS and Moz was showing. Something is wrong in that picture. Netscape 4 was (is) and old Motif based application. It has no other "knowledge" of truetype fonts than the one it gets directly from xfs. If an outdated app like that can show crisp clear tt fonts - why can't OO? Again: This is NOT about anti-aliasing.
Attaching screenshot from KDE showing how OpenOffice.org 641C looks by default AND how it appears if one instead install the fonts from StarOffice 6 beta. The original screenshots are by a KDE user who discovered this workaround. Notice how "Thorndale" looks like "Thomdale" in a default installation, but improves when using real fonts. Notice how the "o" looks like a garbled "D", again before installing the StarOffice fonts. Even if the fonts from SO6 are far from perfect, the difference is striking. I reiterate: The ONLY difference between these screenshots is that the StarOffice fonts are used instead of OO's own. I find the screenshot interesting because it proves that there is a "missing link" here somewhere, other than in hinting code. I installed a "default" installation. Am I correct when I say that there is only ONE display font distributed with OO 641C? Why is the default font in Writer set to a font not even included? ("Thorndale"). The OpenOffice.org641/programs/soffice script has these lines regarding fonts: sd_fonts="$sd_inst/share/fonts" SAL_FONTPATH="$sd_fonts/75dpi:unscaled;$sd_fonts/75dpi" SAL_FONTPATH_PRIVATE="$sd_fonts/truetype;$sd_fonts/type1;$sd_fonts/serverfonts;$userinst/user/fonts" In "OpenOffice.org641/share/fonts" there is one single subdirectory, called "truetype". The only font there is sun-OpenSymbol: fonts.dir opens___.ttf Under "OpenOffice.org641/user" there is no directory called "fonts". Nor are there directories called "75dpi", "serverfonts" or "type1" anywhere under the installation dir. Are users expected to create these directories and add fonts there on their own? It seems strange to me that some Linux users manage to upload OO screenshots with wonderfully crisp clear fonts, while others seemingly are stuck with fuzzyness forever.
Created attachment 1092 [details] OO under KDE before and after installing the StarOffice6 fonts
> I find the screenshot interesting because it proves that there is a > "missing link" here somewhere, other than in hinting code. The "missing link" is that SO6 fonts contain embedded bitmaps that are optimized for readability. When using these bitmaps there is no need for any hinting. > Why is the default font in Writer set to a font not even included? > ("Thorndale"). Our font license does not allow to distribute the fonts with OOo. So there are no fonts included. On the many different linux distributions there is also no common set of nicely scalable fonts. So setting the default font to "Thorndale" is as good as any other font. If you don't feel that way feel free to open a bug against the SW module.
Previous to builds of Feb 18, 2002 mozilla/netscape6 (M/NS6) only used fonts rendered by the X server or a font server such as xfs. After this M/NS6 has a pref (off by default) to allow users to enable client side TrueType font rendering. The fact that the M/NS6 screenshot preceeds that date implies that the font rendering was done by the Xserver/Xfs not M/NS6 which is beyond the control of M/NS6. In general M/NS6 tries very hard to use bitmap fonts and not to use scaled fonts as scaled fonts often look so poor.
Thanks for the info Brian. That explains a lot: - M/NS6 gets the fonts from an X11 server that accidentially uses instructions for grid fitting. XFree86 servers with TT support usually behave this way (at least up to 4.2.0) - OOo prefers scalable fonts because the document layout is very dependent on the printer metrics and matching them to the display is best accomplished by getting the font information from the same font file. As Brian agrees the display quality of scalable fonts is often inferior on X.
Fonts look crisp clear in current Mozilla builds on XFree86 4.2.0. I don't enable antialiasing, and use xfs. This provides fonts as crisp clear as when rendered iunder Windows. Except in OO.
This bug needs to be re-opened -- it was never fixed. Can someone with issuezilla permission re-open it?
Reopening because it wasn't really fixed.
But it was rather WONTFIXed. It's a shame :-(.
Firstly, it is hard to overstate the importance of this issue. The current quality of screen fonts will be simply unacceptable to many potential users. As far as I can see, apart from this, OOo on Linux is a viable competitor to Microsoft Office on Windows. I fully appreciate the legal issues here, and I understand that simply enabling TrueType hinting is not an option at the moment for legal reasons. However, I think you are taking an excessively narrow view of the range possible technical solutions. The underlying problem is the screen font quality with OOo Writer on Linux is terrible. It is a non-sequitur to say: we cannot hint TrueType, therefore we have to have bad screen font quality. > OOo prefers scalable fonts because the document layout is very > dependent on the printer metrics and matching them to the display > is best accomplished by getting the font information from the > same font file. This is where your logic is, I believe, flawed. You are treating the use of screen fonts and the use of printer fonts as being mutually exclusive, but they're not. Yes, I agree you should get the metrics from the font that the printer will use. But this doesn't imply that the bits you display on screen have to come from the font you will send to the printer. If a printer font will look bad at low resolutions on screen, then you should substitute a different font for screen display. This is by no means straightforward, but it is pretty standard practice. For example, on Windows, some printer drivers for PostScript allow the user to specify a mapping from fonts used on screen to fonts used in the printer. When you do this kind of thing, there are a couple of technical issues you have to deal with: 1. You have to figure out what font to substitute. I don't know enough about X to know whether it provides enough information to do good font matching automatically. But it seems like you could often find a good substitute by looking at the font name and seeing how closely the X metrics match the printer font metrics. However, I suspect you would need to allow the user to specify a mapping explicitly. 2. You have to deal with the fact that the inherent metrics of the font being used for display do not exactly match the inherent metrics of the font being used for printing. If you simply use the printer metrics for displaying the font on screen, you will get ugly spacing. If you do the opposite, line ends and tables will be ragged. I would make the following observations. (a) You have to deal with this problem anyway. When a truetype font has embedded bitmaps, the width in pixels will not be exactly equal to the rounded horizontal width. (b) Many programs have found good solutions to this problem. For example, every TeX driver ever written deals with this. The widths used by TeX for composition (from the TFM file) may not exactly width the device widths (in the PK file). The standard technique in the TeX world is (approximately) to use the device widths for character spacing and adjust the interword space so that the line lengths match the width as seen by TeX.
> But this doesn't imply that the bits you display on screen > have to come from the font you will send to the printer. The glyph shapes are always optimized for the display. Issues like embedded bitmaps, explicit hinting and byte hinting cause different qualities of the resulting shapes though. > If a printer font will look bad at low resolutions on screen, > then you should substitute a different font for screen display. Whether a font will look bad on display is almost impossible to know from an algorithmic standpoint. For cases where it is known that a font looks bad the substitution is already possible: Tools->Options->Office->Font_Replacement and select "Screen Only" replacement. Distribution vendors that know which fonts they are shipping could already could preset these configuration settings. > The standard technique in the TeX world is (approximately) to use > the device widths for character spacing and adjust the interword > space so that the line lengths match the width as seen by TeX. We are doing exactly that. The problem is getting good glyph shapes. One issue that might have given you the impression that OOo has abysmally bad fonts is that OOo<1.0.1 had the famous issue 4366 which prevented psprint's font cache from collecting regular fonts and reported to other layers only bold and italic fonts were available. Also OOo<1.01 didn't search behind font servers for font files, so on Redhat and Mandrake almost no fonts were found by psprint's font manager. I'm very glad this got fixed. Without font files we had no chance to get printer metrics except the few PS standard font's metrics. Since Writer defaults to only show printable fonts and we had to display these using X11 fonts which were metrically quite different to the builtin PS fonts, the results were quite unpleasant. But with OOo>=1.0.1, a few nice *ttf files lying around and antialising enabled things look quite better. Autohinting is still not as good as everyone would like to have it, and there is a feature request to make it optional. Also on older X11 servers with less than 24bit display depth antialising still doesn't work. Try it out with using OOO>1.0, ttf-fonts and antialiasing.