오늘도 역시 한글 문제가 터져주셨습니다. 하지만 그리 큰 문제는 아니었고 그냥 영문폰트와 한글폰트가 연결이 안되어서 생긴 문제였기에 큰 문제는 아니었습니다.

http://linuxmint.kr/5848

여기서 보면 ~/.fonts.conf 파일을 만들고 아래와 같은 내용을 적어서 설정파일을 만듭니다.

내용을 보시면 Nimbus Sans L과 DejaVu Sans를 UnDotum 폰트와 연결하는 내용입니다.

그리고 터미널에서

fc-cache -fv 한번만 쳐주시고 로그아웃 했다가 다시 스팀에 접속하시면 한글이 멀쩡히 나오는 것을 확인 하실 수 있습니다.

이전에는 포탈시리즈나 레프트4데드 시리즈를 할 때 그냥 영문(...)으로 했었는데 생각보다 간단했었군요.

2015.2추가

위의 팁은 민트에서만 통하는 것인지 루분투에선 안 통하네요.

http://www.ubuntu-kr.org/viewtopic.php?p=121681#p121681

위의 글에 의거.

ttf-wqy-zenhei 이 패키지를 깔면 잘 나온다고 합니다. 해보니...잘 되네요.

역시나 까탈이는 오늘도 까탈스럽게 굴었습니다. 이유는 잘 모르겠지만 fglrx가 설치된 우분투에서 wine을 설치하려하니 fglrx를 지워야 한다고 뜨더군요.

이건 또 뭔가 하니까 wine 1.6이후에 추가 패키지로 설정된 opencl관련 패키지가 fglrx를 지우려고 드는 것이었습니다. 마음 같아서는 오픈소스로 갈아타고 싶었는데 아직 오픈소스 드라이버가 안 나온 상황이라(비마 기반 APU입니다.) 어쩔 수 없이 fglrx에 기댈 수 밖에는 없습니다.

 어쨌건 저랑 비슷한 상황이 있는 듯 하는 사람이 많은 듯 하여 일단 wine만 무시하고 설치하는 법만 알려 드리겠습니다.

 http://askubuntu.com/questions/540780/14-10-wine-and-fglrx-conflict

출처는 여기입니다.

 여기서는 fglrx의 패키지 설정을 바꾸는 것으로 해결하기도 하는데 그건 그거대로 삽질 같아서 wine을 그냥 강제로 설치하는 것을 알려드리겠습니다. 어차피 opencl은 fglrx 설치하면서 다 설치 되어서 필요없거든요.

 우선 wine을 deb형태로 다운로드 받습니다.

sudo apt-get download wine1.6-amd64 wine1.6-i386 wine1.6 playonlinux

여기서 playonlinux는 따로 설치하려면 설치하시고 아니면 굳이 설치 안 하셔도 됩니다. 그리고 32비트 사용자 분들은 wine1.6-amd64는 지워주세요.

이제 다 다운로드가 되었는지 확인 되셨으면 설치를 해야겠지요? 여기서 일부 옵션을 넣어줍시다.

sudo dpkg --force-all -i *.deb

이제 강제로 설치를 하려고 할텐데 그냥 메시지는 무시하셔도 됩니다. fglrx가 다 설치해 놓은 것들입니다. 구동에 아무런 지장 없습니다.

하지만 제일 좋은 것은.... fglrx를 안 쓰는 것이 가장 좋다고 생각합니다. Gallium3D가 제 칩셋을 빨리 지원해 주길 기다리면서....

2014. 1. 2

 지금 확인해보니 wine때문에 패키지 설정이 꼬여버립니다. 그냥 Playonlinux를 설치해서 이를 이용합시다. 처음 실행할 때 wine이 없다고 뭐라 뭐라 할텐데 가뿐히 무시하고 Wine versions기능으로 wine을 따로 설치해서 굴리면 됩니다.(단, PlayonLinux가 저장소에 있는 구버전이면 안 됩니다. 이건 Wine을 무조건 적으로 설치합니다.) 즉 System wine을 안 쓰면 된다는 소리.

아니면 fglrx의 패키지 설정을 수정해도 문제는 없을 것이라 믿습니다. 그런데 OpenCL 관련해서 문제가 일어날지도 모르기 때문에... 일단 Gallium3D 드라이버가 나올 때까지 기다리는 걱이 최선인듯...

2014.2.

 이미 오픈소스 드라이버는 나와있었습니다. 그동안 검색 부족과 14.10을 거들떠도 안 본 죄로(...)몰랐던 것일 뿐. 그냥 커널을 3.15로 올리고 Xorg를 PPA를 통해 버전업하면 됩니다. 아니면 oibaf PPA를 이용하시면 안정적이면서 편리한 드라이버를 설치하실 수 있습니다. 그러니까 쉽게말해서 그냥 Catalyst를 버리시면 됩니다.

제목은 한글문제입니다. 이번에 이야기 할 것은 한컴의 워드프로세서가 아니라 우리가 지금 사용하는 바로 이 한글을 말합니다.

리눅스는 아시다시피 오픈소스로 공개된 커널을 기반으로 이리저리 손을 대서 만들어낸 물건입니다. 따라서 모든 세계인들이 활용 할 수 있게 만들어야 하고 또 그렇게 되고 있습니다. 그런데 워낙 리눅스 이용 인구가 적은 한국은 한글 문제에 자주 봉착합니다. 아니 한글 자체가 문제가 아니라 UTF-8과 EUC-KR의 호환문제, 게다가 Microsoft만 만들고 쓰는 CP949같은 코드 파편화 문제입니다. 사실 한글을 읽고 쓰는 것은 전혀 문제가 없습니다. 유니코드라는 국제 표준이 나오면서 전세계의 언어를 통합 관리하게 되었기 때문에 이 유니코드만 사용한다면 한글문제, 아니 전세계의 모든 언어의 문제는 해결이 가능합니다.

문제는...... 표준을 지키지 않는 것들입니다. 저는 "비표준"이나 "사실상의 표준"을 참 싫어합니다. 비표준이야 어쩔  수 없는 경우가 많다고 해도(예를 들면 M5.5같은 애매한 나사라던가....이건 M5나 M6을 쓰면 안 되나?) 사실상의 표준이라고 이를 고수하는 것도 좀 웃기다는 생각이 듭니다. 사실상의 표준이라면 이를 표준으로 지정하면 되는데 ISO에서 이를 표준으로 지정하지 않는다?

대체 무엇이 문제일까요? 대표적인 것이라면 플래시가 있습니다. 브라우저 플러그인 방식인데다가 멀티코어 사용에 문제가 있고, 어느 한 회사(Adobe)의 독점 형태로 제공되고 있다 보니 문제가 참 많습니다. 하지만 그래픽적 효과를 이렇게 쉽게 보여줄 수 있는 녀석도 없어서 플래시는 지금 웹 그래픽에서는 표준이다시피 합니다. 하지만 HTML5에서 플래시의 기술은 들어가지 않았습니다. 넣으려면 넣을 수도 있었을텐데 말입니다. 그 이유는 모바일 플래시를 써보신 분들은 아시겠지만 엄청난 연산량에 따른 문제라고 하는군요.

그러고보니 반대로 한 회사에서 만들어서 쓰다가 ISO의 표준지정으로 바뀐 기술도 있습니다. 바로 PDF! 그러고 보니 이 물건도 Adobe의 결과물이군요. PDF는 현재 문서표준으로 지정되어 있어서 모든 기술이 공개되어있습니다. 위의 플래시 기술이 완전공개가 되지 못한 것(플래시 기술의 일부는 공개가 되어있습니다. 오픈소스의 결과물이라고는 하지만...)과는 차원이 다르지요.

자 다시 한글 표준으로 돌아와서 이제 어떤 문제가 있는지 확인 해 봅시다. 먼저 MS는 CP949라는 뭔가 해괴한 EUC-KR호환 한글코드를 사용합니다. 그 와중에 내부에서는 유니코드를 사용합니다. (뭐하는 짓이야...) 그리고 KS표준에 보면 EUC-KR과 유니코드를 동시에 올려놓았습니다. 그리고 UTF-8이라는 유니코드와 아스키 호환 코드도 존재합니다. ISO는 당연히 유니코드만이 표준입니다.

네 점점 가관입니다. 특히 KS표준이 참 막장이네요. EUC-KR과 유니코드를 같이 표준으로 채택하는 바람에 통일이 이루어지지 못했습니다. 그럼 CP949는? 이건 표준 아닙니다. 그냥 MS가 만들어낸 확장 완성형 기반입니다. 마치 옛날에 조합형 vs 완성형 싸움 비슷한 생각이 드는군요. 현재로써는 완성형이 이긴 것 같기는 하지만 한/글 워드프로세서가 조합형을 썼기에 지금의 위치에 오른 것을 생각해보면....

이러한 문제는 멀리 갈 것도 없이 UTF-8을 기본으로 사용하는 리눅스/OSX에서 윈도에서 압축한 ZIP파일을 풀면 여실히 드러납니다.한글 파일명이 대책없이 깨집니다. CP949는 EUC-KR 호환이라고 했지요? 원인은 여기있습니다. 때문에 반디집같은 프로그램은 UTF-8환경을 한번 거치는 것 같기는 합니다만,(한글이 아닌 다른 외국어로 쓰인 파일명을 읽기 위함 그런데 이것이 UTF-8에서 압축한 한글에도 먹히는 것입니다.)

언제나 매번 문제를 일으키지만 해결될 기미가 안 보이는 한글문제... ISO의 권고사항만 지키면 큰 문제는 없을 것 같은데 왜 안 지키는 사람들이 많을까요? 제발 적당히 배운티 내지 않았으면 좋겠습니다.