Bug 563409

Summary: fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Baekmuk Gulim
Product: [Fedora] Fedora Reporter: Akira TAGOH <tagoh>
Component: baekmuk-ttf-fontsAssignee: Jens Petersen <petersen>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: behdad, edgar.hoch, fonts-bugs, i18n-bugs, jks, K9, mattias.ellert, petersen, pnemade, psatpute, smallvil, tagoh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 546490 Environment:
Last Closed: 2010-04-22 02:43:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 546490    
Bug Blocks: 507684    

Description Akira TAGOH 2010-02-10 06:10:52 UTC
+++ This bug was initially created as a clone of Bug #546490 +++

Description of problem:
I did a yum update and discovered emacs was using the Baekmuk Gulim font.  Code editing needs to be done in a fixed-width font!  Baekmuk Gulim is not fixed-width. Directory listings look horrible because the fields are not aligned.  I changed my emacs settings back and everything is fine for me now, but I bet a bunch of people will have no idea what font to change back to.  I was only able to figure it out because I had an emacs running from before the yum update.

Version-Release number of selected component (if applicable):
fontconfig-2.8.0-1.fc11.x86_64

--- Additional comment from tagoh on 2009-12-14 03:52:56 EST ---

This issue is easily reproducible with fc-match "monospace:lang=en" though, there are two things introduced in 2.8.0:

1. the above command matches lang="ko" too
2. Baekmuk Gulim has been added to the pattern with the strong binding somehow. which has ever been added with the weak binding.

--- Additional comment from tagoh on 2010-02-02 06:26:00 EST ---

This might be the configuration file issue in 65-baekmuk-ttf-gulim.conf. as I pointed out current behaviour in the list [*1] and due to the issue we have in Bug#518161 too perhaps dunno, comparing the lang with 'ko' behaves wrongly in current implementation of fontconfig at least. modifying like the following works expectedly:

<test name="lang">
  <string>ko-kr</string>
</test>

FYI

*1 - http://lists.freedesktop.org/archives/fontconfig/2009-November/003275.html

--- Additional comment from petersen on 2010-02-02 11:42:55 EST ---

Behdad said he would look into the lang= issues but
maybe we should reassign to baekmuk-ttf at least as
a workaround for f13?

--- Additional comment from tagoh on 2010-02-02 23:01:07 EST ---

maybe. we could clone this to keep both on track.

Comment 1 Jens Petersen 2010-02-11 07:24:22 UTC
I just reproduced the old baekmuk-ttf issue with emacs and removed it,
but I have un-core-dotum-fonts and didn't see a problem with it?

Comment 2 Akira TAGOH 2010-02-24 06:37:16 UTC
you mean un-core-gulim-fonts?

Comment 3 Jens Petersen 2010-02-25 10:30:53 UTC
Hm I thought we already had a baekmuk-ttf-fonts bug but seems not.

Comment 4 Jens Petersen 2010-04-22 02:43:01 UTC
Thanks - baekmuk-ttf-fonts-2.2-25.fc13 fixes this problem for me. :)

*** This bug has been marked as a duplicate of bug 578017 ***