Issue 2613

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. 
 

> 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.