Bug 563409 - fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Baekmuk Gulim
fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Ba...
Status: CLOSED DUPLICATE of bug 578017
Product: Fedora
Classification: Fedora
Component: baekmuk-ttf-fonts (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
:
Depends On: 546490
Blocks: F13Target
  Show dependency treegraph
 
Reported: 2010-02-10 01:10 EST by Akira TAGOH
Modified: 2010-04-21 22:43 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 546490
Environment:
Last Closed: 2010-04-21 22:43:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2010-02-10 01:10:52 EST
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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 02:24:22 EST
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 01:37:16 EST
you mean un-core-gulim-fonts?
Comment 3 Jens Petersen 2010-02-25 05:30:53 EST
Hm I thought we already had a baekmuk-ttf-fonts bug but seems not.
Comment 4 Jens Petersen 2010-04-21 22:43:01 EDT
Thanks - baekmuk-ttf-fonts-2.2-25.fc13 fixes this problem for me. :)

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

Note You need to log in before you can comment on or make changes to this bug.