Bug 381779

Created attachment 209195 [details]
screen shot w/ weird ㅇ's

The problem is also present on SL103.

On the second look, the bold ones seem to be from UnDotum.  The font is configured to be Gulim and the non-bold characters are in Gulim but it seems to be falling back onto UnDotum for bold characters.  The weird thing is that this doesn't happen if Undotum is selected.  I'll attach correct rendering.

Created attachment 209196 [details]
Correct rendering

Same for me. Weired Gulim Bold rendering in firefox 3.0b5. I tried to disable hinting for Gulim font (MS hangul font) in ~/.fonts.conf but didn't help.

Ubuntu 8.04 Hardy Heron correctly renders it without any configuration.

Tejun Heo> but it seems to be falling back onto UnDotum for bold
Tejun Heo> characters.

How do you know that it falls back to UnDotum for the bold characters?

Gulim doesn’t have bold, i.e. any Gulim you see in bold is
artificially emboldened. UnDotum has a true bold version:

mfabian@magellan:~$ fc-list : family style file | grep Gulim
/home/mfabian/.fonts/gulim.ttc: Gulim,굴림:style=Regular
/usr/share/fonts/vista/gulim.ttc: GulimChe,굴림체:style=Regular
/local/fonts/vista/gulim.ttc: GulimChe,굴림체:style=Regular
/local/fonts/vista/gulim.ttc: Gulim,굴림:style=Regular
/home/mfabian/.fonts/gulim16.pcf.gz: Baekmuk Gulim Wide:style=Regular
/usr/share/fonts/vista/gulim.ttc: Gulim,굴림:style=Regular
/usr/share/fonts/truetype/gulim.ttf: Baekmuk Gulim,백묵 굴림:style=Regular
/home/mfabian/.fonts/gulim.ttc: GulimChe,굴림체:style=Regular
mfabian@magellan:~$ fc-list : family style file | grep UnDotum
/usr/share/fonts/truetype/UnDotumBold.ttf: UnDotum,은 돋움:style=Bold,Regular
/usr/share/fonts/truetype/UnDotum.ttf: UnDotum,은 돋움:style=Regular
mfabian@magellan:~$

I can reproduce the problem by the way.

Created attachment 209397 [details]
bnc381779.html

Simple test html file to reproduce the problem.

Created attachment 209399 [details]
bnc381779.html.png

screenshot which shows how firefox renders the test file
bnc381779.html on my machine.

The font “Dotum” is one of the faces in gulim.ttc (from Windows
Vista):


mfabian@magellan:~$ fc-list : family style file | grep Dotum
/usr/share/fonts/truetype/UnDotumBold.ttf: UnDotum,은 돋움:style=Bold,Regular
/usr/share/fonts/truetype/dotum.ttf: Baekmuk Dotum,백묵 돋움:style=Regular
/home/mfabian/.fonts/gulim.ttc: DotumChe,돋움체:style=Regular
/usr/share/fonts/vista/gulim.ttc: DotumChe,돋움체:style=Regular
/usr/share/fonts/vista/gulim.ttc: Dotum,돋움:style=Regular
/local/fonts/vista/gulim.ttc: DotumChe,돋움체:style=Regular
/usr/share/fonts/truetype/UnJamoDotum.ttf: UnJamoDotum,은 자모 돋움:style=Regular
/home/mfabian/.fonts/gulim.ttc: Dotum,돋움:style=Regular
/usr/share/fonts/truetype/UnDotum.ttf: UnDotum,은 돋움:style=Regular
/local/fonts/vista/gulim.ttc: Dotum,돋움:style=Regular
mfabian@magellan:~$ ftdump /local/fonts/vista/gulim.ttc | grep family
   family:     Gulim
   family:     GulimChe
   family:     Dotum
   family:     DotumChe
mfabian@magellan:~$ 

Created attachment 209402 [details]
Dotum-weight-200-displayed-with-xfd.png

Screenshots of

    xfd -fa "Dotum:weight=200:size=20"

(size=20 is pixelsize=27.2365 at my dpi).

You can see in the right half of the last screenshot that
some hanja are not rendered correctly as well when emboldened.

Without the artificial emboldening, i.e.  with

    xfd -fa "Dotum:weight=100:size=20"

it looks OK.

This seems to be a problem with the artificial emboldening
in freetype2 (or maybe a bug in the font) but not a problem
in firefox.

→ Reassign to me.

Might be related to bug #158573.

Tejun Heo> My friend says turning off hinting for Gulim in .fonts.conf
Tejun Heo> in Ubuntu does the trick but it doesn't work on suse (maybe
Tejun Heo> some difference in system font configuration?).

That is strange because hinting is already turned off on SuSE if fonts
are artificially emboldened, see /etc/fonts/conf.d/90-synthetic.conf.
This change was introduced by Zhe Su for SuSE to fix
bug #158573, see bugzilla-158573-turn-off-hinting-when-embolden.patch
in the fontconfig package.

So it is not surprising that turning off hinting doesn’t change
anything anymore fore artificially emboldened fonts on SuSE.
It is surprising though that it fixes the problem on Ubuntu
because if switching off the hinting helps, the problem
wouldn’t have occured on SuSE at all.

This is a FreeType bug, probably related to

  https://savannah.nongnu.org/bugs/index.php?19873

Please extend this report or make a new one if you think that this would be more appropriate.

Tejun Heo's friend here... hehe ;)

Exactly say, I had to turn off hinting for Dotum myself in Ubuntu Gutsy (7.10), but Hardy (8.04) doesn't require that. It renders Dotum well by default.

Hardy's current fontconfig package version is 2.5.0-2ubuntu3.

I think this is a freetype2 bug which most likely has nothing at
all to do with fontconfig.

Hinting for artificial emboldening is already switched off in the SuSE
fontconfig setup. I don’t think Ubuntu has more workarounds in the
fontconfig setup.  Just to make sure I looked into the
fontconfig-config_2.5.0-2ubuntu3_all.deb from Ubuntu Hardy and there
is really nothing which could be a workaround for this problem.

Do you have the gulim.ttc from Windows installed?

Of course gulim.ttc from Windows XP installed. ;)

I have no Ubuntu Hardy installed at the moment but I checked that
the problem exists on Ubunty 7.10 (Gutsy) and it is *not*
fixed by switching of the hinting in ~/.fonts.conf.

Alex,

do the commands

     xfd -start 63744 -fa "Gulim:weight=200:size=20"

     xfd -start 63744 -fa "Dotum:weight=200:size=20"

work for you on Ubuntu Hardy? Or do they show broken glyphs
like those in the right half of the screenshot attached to
comment #12?

Created attachment 209613 [details]
requested xfd results on hardy

Ok. Tested on my hardy installation. xfd shows broken glyph as you see, but firefox's rendering is fine.

To be sure, I created a new account and put gulim.ttc only in ~/.fonts dir, then did same test, results were same.

I'm gonna install gutsy to my vmware and test again, since it was fine for me when using gutsy with hinting off.

Alex> Ok. Tested on my hardy installation. xfd shows broken glyph as
Alex> you see, but firefox's rendering is fine.

I think that proves that the problem exists on Ubuntu Hardy as well.

The reason that it works in Firefox is most likely that
Firefox does *not* use Gulim or Dotum from gulim.ttc but some other
font which doesn’t have this problem. For example UnDotum works.

Folks,

it's not really clear to me what you are arguing about.  It's definitely a bug in FreeType (and probably not going to be fixed soon), regardless whether you use hardy or gutsy or flipsy or mopsy :-)

Yes Werner, I just tried to convince Alex that this is a bug in
freetype, not in fontconfig and that it is not fixed in Ubuntu Hardy
either. That it happens to work in Firefox sometimes must be because
other fonts happen to be used which don’t suffer from that freetype
bug.

Werner Lemberg> It's definitely a bug in FreeType (and probably not
Werner Lemberg> going to be fixed soon)

Alex could use the following as a workaround in ~/.fonts.conf:

	<match target="pattern">
		<test name="family">
                	<string>Gulim</string>
                	<string>GulimChe</string>
                	<string>Dotum</string>
                	<string>DotumChe</string>
		</test>
		<!-- check to see if the pattern requests bold -->
		<test target="pattern" name="weight" compare="more">
			<const>medium</const>
		</test>
		<edit name="family" mode="prepend" binding="same">
			<string>UnDotum</string>
		</edit>
	</match>

This will prefer the bold version of UnDotum to the
artificially emboldened Gulim, GulimChe, Dotum, and DotumChe
fonts.

I.e. as long as the unfonts package is installed, this
should workaround the bug. 

If the freetype bug is not going to be fixed soon, it might
be useful to add the above workaround the the SuSE fontconfig
setup.

What do you think? Is this a reasonable idea?
Does this workaround help you?

Sorry but that workaround doesn't work.

I didn't disaggreed that it's a bug of freetype but just wondered why ubuntu is fine and suse is not. After a few tries, found something interesting.

 * Firefox doesn't draw another font instead. (in websites like http://www.naver.com). It definitely uses Dotum font in gulim.ttc

 * Fabian's workaround doesn't work but I don't know why. 

 * There is an interesting difference in /etc/fonts/conf.d/90-synthetic.conf of Ubuntu and SuSE. See embolden section. SuSE put additional workaround through line 71~73, which seems turning off hinting for embolden. I tried to remove those 3 lines & confirmed it solves my problem.

Of course just removing the lines is not a good idea (yeah it must be a another workaround, right?), but I hope it helps you to make a better one. :)

Alex, thanks a lot for the detailed response.  Can you please attach 90-synthetic.conf from ubuntu?

Created attachment 209772 [details]
90-synthetic.conf in ubuntu hardy.

Alex> * Fabian's workaround doesn't work but I don't know why.

I tested again, you are right, this workaround only works for the
test page I attached to comment #9 but not for http://news.naver.com.
Strange.

Alex>  * There is an interesting difference in
Alex> /etc/fonts/conf.d/90-synthetic.conf of Ubuntu and SuSE. See
Alex> embolden section. SuSE put additional workaround through line
Alex> 71~73, which seems turning off hinting for embolden.

Yes, I know. I wrote that in comment #15 already.

Alex> I tried to remove those 3 lines & confirmed it solves my
Alex> problem.

That would mean turning the hinting *on* helps. Checking …

Doesn’t work for me.

Removing these lines doesn’t solve the problem for me, neither
for my test page from comment #9 nor for http://news.naver.com.

Replacing these lines with

		<edit name="hintstyle" mode="assign">
			<const>hintfull</const>
		</edit> 
		<edit name="hinting" mode="assign">
			<bool>true</bool>
		</edit> 
		<edit name="autohint" mode="assign">
			<bool>true</bool>
		</edit>

to make sure hinting is turned on doesn’t help either.

Alex's workaround wokrs on my computer too.  I wonder where the difference comes from.

Thank you for checking Tejun.

If Alex’s workaround works for you, does it work for you as well
if you replace the lines in 90-synthetic.conf which switch off the
hinting with

A)

                <edit name="hintstyle" mode="assign">
                        <const>hintfull</const>
                </edit> 
                <edit name="hinting" mode="assign">
                        <bool>true</bool>
                </edit> 
                <edit name="autohint" mode="assign">
                        <bool>true</bool>
                </edit>


(full hinting using the autohinter) or

B)

                <edit name="hintstyle" mode="assign">
                        <const>hintfull</const>
                </edit> 
                <edit name="hinting" mode="assign">
                        <bool>true</bool>
                </edit> 
                <edit name="autohint" mode="assign">
                        <bool>false</bool>
                </edit>

(full hinting using the byte code interpreter).

?

Yeah both work for me.

This is quite strange because this confirms that it works
for you and Alex when hinting is turned *on* not off, i.e. just
the opposite of what Alex claimed originally.

*And* both versions of Ubuntu, Gutsy and Hardy have a freetype
with the bug and have the same 90-synthetic.conf file, i.e. both
use hinting for artificially emboldened fonts. On Gutsy I verified
with

     xfd -start 63744 -fa "Gulim:weight=200:size=20"

     xfd -start 63744 -fa "Dotum:weight=200:size=20"

that the problem exists there as well and that changing the hinting
settings doesn’t make any difference whatsoever.

Do these xfd commands work on your openSUSE system?

On my openSUSE system they don’t work, no matter which hinting
settings I use.

Are we all using the same version of gulim.ttc?

Actually I have two versions of gulim.ttc on my machine:

mfabian@magellan:~$ ll /home/mfabian/.fonts/gulim.ttc
-rwxr--r-- 1 mfabian suse 13518660 2004-05-13 16:03 /home/mfabian/.fonts/gulim.ttc*
mfabian@magellan:~$ ll /usr/share/fonts/vista/gulim.ttc
-r--r--r-- 1 mfabian suse 13525204 2006-07-03 15:57 /usr/share/fonts/vista/gulim.ttc
mfabian@magellan:~$

The file size is slightly different but the version number is 2.21 for
both of them. The gulim.ttc with the slightly smaller file size is
from an older version of Windows.

Confusing... anyway, I'm using gulim.ttc 13518660 bytes from Windows XP.

And yes, xfd result of my openSUSE you asked shows broken glyphs but at least firefox works fine both of your test page & other korean sites specifying Dotum font in their css.

However, it looks like firefox draws Dotum font without anti-aliasing. Outline is quite rough. See firefox window in the screenshot (https://bugzilla.novell.com/attachment.cgi?id=209613) I attached before.

I'll try another gulim.ttc font in vista. 

It could be that I misunderstood what Alex told me, so the hinting related part of the original report could be wrong.  Here's what my gulim.ttc looks like.

  $ ls -l gulim.ttc
  -rw-rw-r-- 1 ftp devel 13518660 2002-09-17 21:35 gulim.ttc
  $ sha1sum gulim.ttc
  d4005cfc4a8dbca06f75dc10b84936d58a968ff1  gulim.ttc

Both xfd commands give me broken characters.  Fabian, do you have unfonts installed?  FWIW, font-wise that's something I and Alex have in common but you probably don't.

Alex> However, it looks like firefox draws Dotum font without
Alex> anti-aliasing. Outline is quite rough.

gulim.ttc contains embedded bitmaps for pixelsizes from 11 pixels to
25 pixels. If you are within that size range and embedded bitmaps are
enabled in the fontconfig setup (they are by default on openSUSE), you
get the bitmaps and no anti-aliasing.

If you prefer the outlines rendered you can disable embedded bitmaps
by adding the following to your ~/.fonts.conf:

 <match target="font" >
  <edit mode="assign" name="embeddedbitmap" >
   <bool>false</bool>
  </edit>
 </match>

Tejun Heo> Both xfd commands give me broken characters.

I think that shows that the hinting settings don’t fix the problem.

I really don’t understand why fiddling with the hinting makes
a difference for you in firefox, but if the xfd commands don’t
work, I think the problem is still there and firefox apparently
uses another font accidentally or maybe the embedded bitmaps
of gulim instead of the outlines. 

Tejun Heo> Fabian, do you have unfonts installed?  FWIW, font-wise
Tejun Heo> that's something I and Alex have in common but you probably
Tejun Heo> don't.

Yes, I have both gulim.ttc *and* the “unfonts” package installed.

Hmmm... I wonder what's the difference between my and your installations.  I can set the things up the same way in vmware so that the 90-synthetic.conf workaround actually works around the problem and send the image to you.  Would that help?

Even in your case the workaround helps only for firefox, not for xfd.

Checking your vmware image might help.

Okay, here's vmware image.  I commented out the hinting configuration in 90-synthetic.conf and all the characters are rendered correctly.

  http://htj.dyndns.org/export/bug381779-debug-vmw.tar.bz2

"user/pass" are "tj/asdf" and the root password is asdf too.  It's default gnome desktop installation + Korean language packages and ~1.3GB.

Thank you, I’ve downloaded it.

I have some problems with the vmware player, see bug #386778.

TeJun do you still seeing this problem? I could not see this problem with my SLED11SP1. Let me know it is openSUSE specific. 

Thanks

It renders okay on openSUSE 11.2.  Resolving as FIXED.  Thanks.

Oops, I was too quick.  I see the problem again in openoffice.  Will attach screen capture.

Thanks.

Created attachment 341715 [details]
OO Calc screen shot with broken 'ㅇ' rendering.

Okay, the 'Gulim' font is being rendered correctly but the 'Dotum' font shows the same problem.  Maybe the same workaround needs to be applied to Dotum too?

Thanks.

The version with which you had the bug is now obsolete. I'll close this as NORESPONSE. If you can still reproduce it in current 11.4, please reopen the bug and move it to the appropriate version. Thanks!