Red Hat Bugzilla – Full Text Bug Listing
|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-fonts||Assignee:||Jens Petersen <petersen>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||behdad, edgar.hoch, fonts-bugs, i18n-bugs, jks, mattias.ellert, me, petersen, pnemade, psatpute, smallvil, tagoh|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-04-21 22:43:01 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||546490|
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 email@example.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 firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org 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.