Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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: ---
Embargoed:


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


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