Bug 563409 - fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Baekmuk Gulim
Summary: fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Ba...
Keywords:
Status: CLOSED DUPLICATE of bug 578017
Alias: None
Product: Fedora
Classification: Fedora
Component: baekmuk-ttf-fonts
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 546490
Blocks: F13Target
TreeView+ depends on / blocked
 
Reported: 2010-02-10 06:10 UTC by Akira TAGOH
Modified: 2010-04-22 02:43 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 546490
Environment:
Last Closed: 2010-04-22 02:43:01 UTC
Type: ---


Attachments (Terms of Use)

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@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 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 ***


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