[Bug 563409] New: fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Baekmuk Gulim

bugzilla at redhat.com bugzilla at redhat.com
Wed Feb 10 06:10:58 UTC 2010


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: fontconfig-2.8.0-1 changes default Monospace font from DejaVu Sans Mono to Baekmuk Gulim

https://bugzilla.redhat.com/show_bug.cgi?id=563409

           Summary: fontconfig-2.8.0-1 changes default Monospace font from
                    DejaVu Sans Mono to Baekmuk Gulim
           Product: Fedora
           Version: rawhide
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: medium
          Priority: low
         Component: un-core-fonts
        AssignedTo: smallvil at get9.net
        ReportedBy: tagoh at redhat.com
         QAContact: extras-qa at fedoraproject.org
                CC: tagoh at redhat.com, petersen at redhat.com, jks at iname.com,
                    besfahbo at redhat.com, mattias.ellert at fysast.uu.se,
                    edgar.hoch at ims.uni-stuttgart.de, pnemade at redhat.com,
                    smallvil at get9.net, fonts-bugs at lists.fedoraproject.org,
                    psatpute at redhat.com, fedora-i18n-bugs at redhat.com
        Depends on: 546490
            Blocks: 507684
    Classification: Fedora
    Target Release: ---
          Clone Of: 546490


+++ 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 at 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 at 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 at 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 at redhat.com on 2010-02-02 23:01:07 EST ---

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

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the fonts-bugs mailing list