다음 버전 개발 근황 3

<날개셋> 한글 입력기의 다음 버전 8.8은 이례적으로 개발 근황글만 무려 3차분까지 올라오게 됐다.
개발 완료 조건은 "원래 생각하고 있던 굉장히 어려운 기능을 다 구현하는 것"인데.. 원래 목표는 달성되지 못한 상태에서 온갖 자잘한 다른 개발 작업만 애드립으로 엄청나게 쌓이고 쌓였기 때문이다.
이것만 감안해도 8.8을 넘어 8.85나 8.9로 가야 하지 않나 고민될 지경이 됐다.

※ 외부 모듈 분야

1. "조합을 자체 처리하는 프로그램에서만 동작" 옵션

<날개셋> 한글 입력기가 외부 모듈이 개발된 이래로 왜 이런 걸 지금까지 생각 못 했을까 싶은 기능이 사용자의 기능 제안 메일과 갑자기 떠오른 아이디어, 발상의 전환을 토대로 하나 추가되었다.
외부 모듈 제어판의 "시스템 계층 - 고급 시스템 옵션" 탭에 있는 "조합을 자체 처리하는 프로그램에서만 동작" 옵션이다.

IME들은 글쇠 입력을 가로채서 한글 같은 조합을 생성 후, 그 결과를 응용 프로그램으로 보낸다. 워드 프로세서나 에디트 컨트롤은 텍스트 입력을 전문적으로 처리하는 프로그램이니, IME가 보낸 문자열을 즉각 본문에다 삽입하여 화면에 직접 표시한다. 그러나 그런 처리를 하지 않는 프로그램에서는 운영체제 또는 IME가 자체적으로 자그마한 창을 꺼내서 조합 중인 문자열을 표시해 준다.

기술적으로 이런 동작의 차이를 IME-awareness라고 표현한다.
그런데 IME가 자체적인 조합 창을 꺼내야 하는(IME-aware하지 않음) 프로그램이라면 십중팔구 한글을 입력할 일이 없고 한글 모드가 존재할 필요가 없는 상황이다. 문자 입력을 받는 상황이 아니며, 각각의 알파벳 글쇠들이 어떤 기능을 수행하는 단축글쇠인 경우가 대부분이다.

저 옵션이 켜져 있으면.. 먼저 조합을 보내 봤는데 프로그램이 조합 문자열을 제대로 표시하지 않고 IME로 되돌려보내는 경우, 조합을 없애고 원래 글쇠를 응용 프로그램으로 다시 보내 준다~!
가령, 그래픽 툴의 경우 B는 브러시, F는 채우기, X는 텍스트, S는 영역 선택인데, 한글 모드라 하더라도 해당 글쇠를 누르면 쓸데없이 ㄹ, ㄴ 같은 조합 창이 생기는 게 아니라 기능 모드가 바뀐다. 그러면서 텍스트 입력은 곧장 한글 모드로 할 수 있게 된다.

물론, 아주 옛날에 만들어져서 국제화 관념 따위 없고 유니코드조차 지원하지 않을 정도인 구닥다리 외국산 프로그램 중에는 무려 텍스트를 입력받는데도 IME-aware하지 않은 경우가 있다. 옛날에 Visual C++ 6의 IDE조차 그러했다. 그런 프로그램에서 한글을 입력하려면 저 옵션을 켜서는 안 된다. 그러나 저 옵션은 요즘 같은 시대엔 거의 모든 상황에서 사용자의 번거로움을 해소해 주는 매우 편리한 기능이 될 것이다.

그리고 반가운 소식이 이것만 있는 게 아니다.
저렇게 조합이 도로 튕겨서 돌아오는지 감시하기 위해서는 약간의 성능 부하가 필요한데, 이걸 해결하는 과정에서 Google Chrome + 하드웨어 가속에서 조합 덧나는 문제도 같이 해결하게 되었다. 외부에 의해서 조합이 강제 중단되는 상황을 감지하는 방법을 추가적으로 알아냈기 때문이다.

물론, 마소 IME가 날개셋과 동일한 방법을 써서 해결한 것 같지는 않기 때문에 이 역시 완전히 근본적이고 원초적인 문제 해결이라고 여기기는 어렵다. 하지만 "조합을 자체 처리하는..." 옵션을 켜면 일단 Google Chrome 문제도 덤으로 해결되긴 한다는 것을 밝힌다.
이렇듯, '고급 시스템 옵션'에는 구현체들 중 오직 외부 모듈에만 적용되는 온갖 기상천외한 옵션들이 들어있다.

2. 긴 조합이 튕기는 문제 자체 보정

TSF B급 프로그램에서 2글자 이상 길이의 조합을 시작했을 때 조합이 끊기는 골치 아픈 문제 말이다.
단순히 이런 문제가 존재한다고 알려 주기만 하고 "운영체제의 이상한 동작이어서 더 어쩔 수 없음. 사용자가 알아서 조심하시고 조합 시작은 언제나 1글자 단위로 시작하게 노력해 보세요"라고 대응하고 끝내던 것이 이번 버전에서 개선되었다.

처음에 2글자 이상 조합을 덥석 만드는 것만이 문제이지, 처음엔 가상의 1글자 조합을 만든 뒤에 곧바로 원래 길이의 긴 조합으로 대체하는 것은 괜찮다는 특성을 이용하여 내부적으로 일종의 회피, 보정 옵션을 구현했기 때문이다.
이제 두벌식 옛한글 입력기에서 '한' 다음에 곧바로 '하 + ㄴ아래아' 같은 글자를 도깨비불 현상으로 만드는 것도 아무 걱정 없이 할 수 있게 됐다.
비록 조합 중인 문자 자체는 한 글자밖에 안 보이고 그거 제어하는 건 애초에 IME의 영역도 아니기 때문에 어쩔 수 없지만, 최소한 조합이 끊어지고 엉뚱한 동작을 하는 문제는 사라졌다.

세상에 이런 간단한 아이디어를 구현할 생각을 왜 지금까지 안 하고 있었나 모르겠다.
사용자가 굳이 이 옵션을 켜지 않더라도 조합이 끊어졌다 싶으면 프로그램이 알아서 이 옵션을 켜며, 켰다는 사실을 사용자에게 알려 준다.

혹시나 해서 다시 말하는데, 이렇게 2글자 이상의 조합 시작을 막는 건 Windows 운영체제가 거의 일부러 저러는 것이다.
한글 IME는 전통적으로 중국어· 일본어 IME와는 달리, 조합 문자열을 밑줄 대신 깜빡이는 네모 cursor로 표시하는 등 내부적으로 처리가 다르게 돼 왔다. 자체 한글을 구현한 도스용 프로그램들의 관행을 마소에서 벤치마킹 해서 현지화에 반영한 것이다.

그런데 그 대신 한글 IME는 중국어· 일본어 IME와는 달리 조합은 언제나 딱 한 글자 단위로만 만들 거라는 assumption도 들어가게 되었고 그게 한동안은 별 문제가 없다가 유니코드 시대에 옛한글을 구현할 때가 되자 문제가 된 것이다. 옛한글은 내부적으로 여러 개의 글자로 구성되니까.
조합이 한 글자뿐이라는 전제조건이 만족되지 않을 경우 제대로 동작하지 않는 프로그램이 있어서 호환성+방어 차원에서 운영체제가 저런 동작을 하는 것이지 싶다.

3. 한영 상태 동기화 기능의 알고리즘 개선

Windows에서 IME는 dll인 관계로 프로그램들(정확히는 스레드)별로 내부 한영 상태가 다~ 따로 노는 형태이다. 그래서 지난 7.7 버전에서 <날개셋> 한글 입력기의 인스턴스들 간에 사용 중인 입력 설정을 한데 동기화해 주는 옵션이 추가되었다. 한 프로그램에서 ‘세벌식 최종’을 선택하면 다른 프로그램에 가도 세벌식 최종이 자동으로 지정되는 식이다. 그 기능이 이번 8.8 버전에서는 동작이 더 개선되었다. 예전에 별 생각 없이, 혹은 시간이 부족해서 대충 구현했던 기능들을 엄밀하게 다듬었다.

첫째, 이미 실행된 프로그램을 전환할 때뿐만 아니라 갓 새로 실행된 프로그램에 대해서도 아까 전까지 설정되어 있는 글자판을 곧장 따라가게 했다. 이 기능은 지금까지 저게 지원되지 않아서 사실상 반쪽짜리 기능에 불과했다. 새로 실행된 프로그램은 기존 설정을 무시할 뿐만 아니라 자기 설정을 덮어쓰기까지 하기 때문에 동기화 상태를 망가뜨리곤 했다.

둘째, 제어판을 ‘확인’을 눌러서 종료해서 설정을 파일로 저장하고 공통 설정을 확인하는 인스턴스들에 대해서만 글자판이 동기화되고, ‘미저장 확인’을 눌러서 자기 혼자만 독자적인 입력 설정을 쓰는 인스턴스에 대해서는 글자판이 동기화되지 않게 했다. 공통 설정을 쓰는 곳에서 글자판을 바꾼 것이 거기로 가지 않을 뿐만 아니라, 저렇게 고립된 곳에서 글자판을 바꾼 것이 밖으로 나가지도 않는다. 이건 프로그램의 논리 구조상 진작에 당연히 취했어야 할 조치이다.

하지만 어느 곳에서든 제어판을 ‘확인’을 눌러서 종료하고 나면 지금까지 고립되어 있던 인스턴스들까지도 전부 입력 설정들이 한데 동기화된다. 이 논리를 이 기회에 완전히 정립했다.
이거 뭐 양파도 아니고, 2017년이 다 되도록 <날개셋> 한글 입력기는 까도 까도 개선할 게 계속 나와서 내가 심히 힘들다. ㅠ.ㅠ 처음부터 이렇게 엄밀하게 만들어 놓으면 좋았을 것을.

※ 제어판 분야

4. 빠른설정과 유형 파일(*.ist) 열기 기능에 Ctrl+클릭 '복사' 추가

<날개셋> 한글 입력기의 제어판에는 빠른설정이라는 게 있어서 특정 입력 항목(입력 스키마+문자 생성기)에 대해 특정 입력 설정을 곧바로 맞추거나 변형하는 기능이 있다. 다시 말해, 이건 현재 선택돼 있는 입력 항목을 변형해서 A로부터 A'를 만드는 기능이다. 뭐, A를 전혀 참조하지 않고 완전히 새로운 B로 바꾸는 것도 가능하다.

그런데, 빠른설정이 제공하는 대화상자를 Ctrl을 누른 채 '확인'을 눌러서 닫으면..
A로부터 A'를 만들되 기존 A는 그대로 두고 A'를 뒤에다 새로 추가하도록, 다시 말해 새로운 입력 항목을 생성하는 동작을 추가했다.
그러니 '기본 글자판 설정'으로부터 세벌식, 두벌식, 쿼티, 드보락 등등을 계속 추가해 넣고 싶으면 매번 번거롭게 '복사본 생성'을 누를 필요 없이 저 빠른설정을 계속 띄워서 확인 버튼을 Ctrl+클릭만 하면 된다.

ist 파일을 여는 기능도 마찬가지다. 그냥 열면 지금 선택된 입력 항목이 파일의 내용으로 바뀌지만, Ctrl+클릭을 하면 파일로부터 생성된 항목이 지금 항목의 뒤에 추가된다. '복사본 생성' 말고도 새 입력 항목을 간편하게 생성하는 방법이 더 생겼다.

자그마한 개선 사항이지만 넣고 보니 굉장히 편하다.
문자표, 낱자 결합 규칙, 사용자 정의 후보 등에 겉으로 티는 안 나지만 Ctrl+클릭 기능이 지금까지 은근히 많이 들어갔다.
버튼에다 자그맣게 * 표시라도 넣든지 해서 일반 클릭과 차이점이 있다는 시각적인 피드백이 있으면 좋겠는데 아직 그것까지는 신경 쓰지 못했다.

5. 입력 항목의 예전 설정 가져오기 기능 개선

지난 7.7버전부터는 제어판의 어떤 입력 항목에 대해서 스키마나 문자 생성기를 변경(기본 ↔ 고급 사이)한 뒤에도 이전의 입력 설정을 최대한 가져와서 유지시키는 기능이 추가되었다. 하지만 이건 지금까지 미세한 버그가 있었다.
한 입력 항목 A에서 입력 스키마를 먼저 변경한 뒤, 다른 입력 항목 B에서 문자 생성기만 변경하고서 '예전 설정 가져오기'를 시키면..
B가 문자 생성기만 예전 것으로 동기화되는 게 아니라 입력 스키마까지 엉뚱한 A의 것으로 바뀌곤 했다. 이 버그를 고쳤다.

한 입력 항목에서 스키마나 문자 생성기를 변경한 것은 일단 내부 버퍼에 저장되며 이건 다른 입력 항목에서 스키마나 문자 생성기를 또 변경하는 순간 정확하게 사라지게 했다. 이건 위에서 열거했던 아이템들보다는 상대적으로 존재감이 덜한 개선 사항이다.

※ 편집기 분야

6. <날개셋> 편집기 창의 이전 위치와 편집 문서 복원은 첫 인스턴스에 한해서만 적용

본인은 평소엔 <날개셋> 편집기에서 '프로그램의 중복 실행 허용' 옵션을 끄고 지낸다. 하지만 편집기는 구닥다리 MDI 프로그램이며, 창 하나만으로는 멀티모니터를 제대로 활용할 수 없다. Visual Studio 201x의 IDE처럼 문서 창을 도구상자의 도킹 기능처럼 프로그램 창 안팎으로 마음대로 붙이고 떼는 기능이 있으면 좋겠지만, 그런 건 내 프로그램의 관심사가 아니다. 그래서 평소에 프로그램의 중복 실행을 허용하는 걸 염두에 두고 편집기의 동작 방식을 살짝 변경했다.

내 프로그램은 기본적으로 예전의 창 위치와 크기를 기억하며, 옵션을 지정할 경우 예전에 편집하던 문서 목록도 기억하고 다음에 다시 불러들여 준다. 그런데 이 기능은 최초로 실행되는 첫 인스턴스일 때만 동작하고, 그렇지 않은 중복 인스턴스일 때는 무시하게 했다. 둘째 이후의 인스턴스에서는 언제나 임의의 위치에 빈 문서창 하나만 달랑 생긴다.

지금까지는 프로그램의 둘째/셋째 인스턴스도 첫 인스턴스와 완전히 동일한 위치에 생기고(첫 인스턴스의 창의 위치와 크기를 일부러 변경하지 않았다면) 문서도 똑같이 다시 로딩되었기 때문에 프로그램이 중복 실행되었다는 것을 알기 어려웠다. 동일 파일을 서로 다른 인스턴스에서 수정하여 수정 내역이 꼬일 위험도 있었다.

그러나 이제는 편집기가 중복 실행되더라도 창이 서로 겹치지 않으며 이미 열어 놓은 문서가 또 열리지는 않는 게 보장되기 때문에 더 부담없이 중복 실행이 가능하다. 이런 간단하고 유용한 조치를 왜 지금까지 취하지 않았었나 자괴감이 들 지경이다.

7. 기존 창의 활성화 방식 개선

사용자가 어떤 대화상자나 창을 열라는 지시를 내렸는데, 이전에 동일한 창을 열어 놓은 게 존재하고 여러 인스턴스를 생성할 필요가 없는 상황이라면 프로그램은 당연히 기존 창을 활성화시켜서 보여준다. 앞의 6번에서처럼 프로그램을 중복 실행하지 않는다거나, 아니면 날개셋 제어판 같은 modeless 대화상자를 열 때 말이다.

그런데, 그 창이 자체적으로 또 modal 대화상자를 열어 놓은 상황이라면 어떨까?
<날개셋> 한글 입력기의 경우 지금까지 이런 경우에 대한 대비가 돼 있지 않았다. (뭐, 입력기라고 썼는데 주 적용 대상은 사실상 편집기밖에 없긴 하다)
그러던 것이 이번 버전에서 드디어 개선됐다. 제어판에서 빠른설정이나 열기 대화상자를 열어 놓은 상태에서 백그라운드로 갔다가 다시 제어판으로 돌아갈 때..

혹은, 편집 화면 설정에서 색상 대화상자를 추가로 열어 놓은 상태에서 본문 편집 화면으로 갔다가 다시 편집 화면 대화상자로 돌아가라는 명령을 내렸을 때.
이제 <날개셋> 편집기는 해당 대화상자에서 제일 겉에 열어 놓은 modal 대화상자로 알아서 복귀한다. 이런 세밀한 UI까지도 싹 개선됐다.

※ 기타

8. 새로운 한글 입력 예제 데이터

비한글뿐만 아니라 한글 분야의 예제 입력 설정 데이터도 보충했다. (1) 먼저, 예전에 코노 노보루(河野 登) 님이 고안하신 "모음 연타 순아래 두벌식"이 참신함이 인정되어 예제로 들어갔다. 초성 쌍자음은 초성 다음에 중성의 2연타로 입력하는 게 매우 기발하다. 중성의 첫 타는 도깨비불 현상을 일으키니 자연스럽게 종성을 초성으로 분리하고, 그 뒤 2타가 초성을 쌍자음으로 바꾸는 것이다.

한 글쇠가 초성과 중성 경계를 오가기 때문에 이런 입력 방식은 내 프로그램에서 타순 분석 같은 게 제대로 안 될 것이다. 그리고 그 특성상 모음은 동일 글쇠 연타로 결합을 할 수 없기 때문에 ㅒㅖ 같은 것은 ㅐㅐ ㅔㅔ 연타가 아니라 반드시 ㅑㅣ/ㅕㅣ로 입력되게 해야 한다. 그래도 이건 Shift를 안 누르면서 딱히 다른 모호성도 없는 두벌식을 만드는 방법 중 하나로 충분히 고려할 만하겠다.

(2) 그 다음으로 타임스페이스 시스템이라는 회사에서 지금으로부터 10몇 년 전에 고안한 '가림토'라는 입력 방식을 예제로 넣었다. 이것은 모음뿐만 아니라 자음에 대해서도 천지인 스타일의 필획 분해를 시도한 것이다. ㄱ은 가로+세로, ㅂ은 세로+세로+가로+가로 같은 식. 모음은 알다시피 ㅡㅣㆍ 세 요소로 분해되는데 자음은 ㅡㅣ 다음으로 ㅅㅇ 이렇게 네 요소로 분해된다.

한글이 꼬부랑 획이 별로 없고 기하학적으로 굉장히 단순하다 보니 이것도 굉장히 참신하긴 하다. 그러나 빨리 치기 좋은 능률적인 입력 방식이라고 볼 수는 없으며 딱히 실용화되지는 못했다. 더구나 자음을 세벌식도 아닌 두벌식으로 만들면 경계의 모호성을 감당할 수가 없게 되며, 실제로 저 방식은 10키 환경 기준으로 ㅇ만 두벌식으로 두고 세벌식으로 만들어졌다. 뭐, 내 예제에서는 어차피 컴퓨터 키보드로 갖고 노는 거니 ㅇ도 초· 종성 구분하여 세벌식으로 집어넣긴 했다만.

얘는 자음의 입력이 처음 시작돼서 아직 가로줄 세로줄 같은 것밖에 없는 초기 상태가 있다. 이런 미완성 낱자는 가상 낱자+낱자 치환을 이용해 표시한다.
또한, 모든 겹모음과 겹받침을 입력 가능한 상태가 아니라 초성과 중성의 기본 낱자만 입력 가능하며, 나머지는 이번 버전에서 들어갈 핵심 중의 핵심 기능인 '복합 낱자 입력 로직 생성기'를 이용해서 합성해서 생성하면 된다. 이런 입력 방식을 분석하면 얼마나 복잡한 규칙이 파생돼 나오고 모호성이 얼마나 발생하는지를 직접 확인할 수 있다.

Posted by 사무엘

2017/02/09 08:37 2017/02/09 08:37
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1325

<날개셋> 한글 입력기를 사용하는 프로그램들은 입력 설정을 바꾸는 UI인 '날개셋 제어판'을 꺼내는 기능이 들어있다. 그 프로그램으로는 편집기, 외부 모듈, 입력 패드, 그리고 타자연습 이렇게 4종류가 있는데, 제어판을 꺼내는 방법은 일반 메뉴, 입력 도구모음줄, 시스템 트레이 우클릭 메뉴, 대화상자의 버튼 이렇게 형태가 제각각 모두 다르다. 어째 이렇게 전부 다를 수 있는지도 궁금한 지경이다.

그런데 사실은 이 프로그램들이 내부적으로 제어판을 운용하는 방식도 전부 다르며, 미세한 차이가 존재한다. 본인은 이와 관련된 코드 리팩터링 작업을 하다가 차이점들을 글로 한데 정리해 보았다.

1. modality

중앙 집권적인 EXE 프로그램인 편집기와 입력 패드는 modeless 형태로 구동된다. 제어판 창을 띄워 놓은 채로 본문의 입력란으로 얼마든지 이동 가능하며, 제어판의 우측 하단에 '적용'이라는 버튼도 응당 존재한다.

그러나 외부 모듈과 타자연습은 modal이다. 외부 모듈의 경우 중앙 집권이 아니라 각각의 프로세스들에 붙어서 돌아가는 일종의 떨이이며, 제어판이 떠 있는 동안 자기가 담당하던 스레드가 없어지는 것을 포함해 갖가지 상황이 밖에서 벌어질 수 있다. 그렇기 때문에 상황 관리의 복잡도를 제어하기 위해서 제어판 창이 뜬 동안은 원래의 입력란으로 돌아갈 수 없게 했다.

타자연습은 외형은 중앙 집권이긴 하지만, 무슨 텍스트 에디터처럼 문자 입력이 상시 가동 중인 채로 제공되는 프로그램은 아니다. (타자 연습 화면은 메뉴에서 뭔가를 선택한 뒤에만 나타남) 그러니 제어판을 띄워 놓은 채로 타자 연습을 한다거나 메뉴로 돌아가는 상황은 생각하지 않으며, 자연스럽게 modal UI를 채택했다. 날개셋 제어판을 열었다면 이것부터 닫아야 이전 단계 화면으로 돌아갈 수 있다.

2. 입력 설정을 읽고 쓰는 방식

사실, 대화상자의 모달 여부나 다른 것보다도 이게 제일 중요하고 본질적인 차이점이다.

(1) 중앙 집권적인 편집기와 입력 패드는 형태가 제일 깔끔하고 단순하다. 그냥 공통 단일 입력 설정 하나만을 읽고 쓰는 걸로 끝이다.
공통 설정은 <날개셋> 한글 입력기 커널이 관리하며, 이걸 파일로 저장한 게 바로 imeconf.dat이다. 그러면 프로그램을 다음에 실행할 때도 예전의 입력 설정들이 고스란히 보존된다.

제어판을 '확인'으로 종료하면 메모리와 파일이 모두 업데이트된다. 그러나 '미저장 확인'이나 '적용'을 누르면 메모리만 업데이트된다. 이 두 버튼은 대화상자를 닫는지 여부의 차이만이 존재한다.

항목 미저장 확인 확인 취소 적용
설정을 메모리 default로 적용 O O X O
설정을 파일 default로 적용 X O X X
대화상자를 닫음 O O O X

(2) 위의 두 프로그램과는 달리 타자연습은 imeconf.dat를 읽거나 쓰지 않으며, 사용자 계정에 있는 자체적인 입력 설정을 사용한다. 그렇기 때문에 공통 설정이라는 개념을 사용하긴 하지만 메모리 수준에서만 사용하지 imeconf.dat를 다루는 파일 수준은 사용하지 않는다. '확인'과 '미저장 확인'의 구분이 존재하지도 않는다.

(3) 끝으로, 외부 모듈은 타자연습과는 또 정반대다. 외부 모듈은 타자연습 같은 독자적인 원천이 있는 건 아니며 필요하다면 imeconf.dat 파일을 읽고 쓰기도 한다. 하지만 그걸 메모리에 보관할 때는 공통 설정을 사용하는 게 아니라 스레드별로 자신만의 고유한 storage를 사용한다.

다시 말해 외부 모듈은 공통 설정 파일만 사용하지 메모리를 사용하지는 않는다. 이렇게 설계된 가장 큰 이유는 외부 모듈이 자신과 동일한 날개셋 커널을 사용하는 프로그램 밑에서 동작하더라도 EXE/DLL 모듈간에 입력 설정 충돌을 일으키지 않고 서로 입력 설정을 따로 관리할 수 있게 하기 위해서이다. 외부 모듈 혼자만 이렇게 남을 알아서 피해 가면 되며, 다른 프로그램들은 굳이 이렇게 동작해야 할 필요가 없다.

외부 모듈에서 연 제어판은 앞서 언급한 이유로 인해 '적용' 버튼은 사용할 수 없다. 하지만 '미저장 확인'은 있는데, 이걸 누르면 지금 맞춘 입력 설정이 외부 모듈을 사용하는 모든 프로그램들에서 한데 동기화되는 게 아니라 지금 실행 중인 프로그램/스레드에서만 잠깐 사용 가능하게 바뀐다. 한글 표현 방식 옵션도 레지스트리에 영구적으로 기록되는 게 아니라 지금 메모리에만 반영된다. 이런 것도 외부 모듈이 스레드별로 독립된 storage를 갖고 있기 때문에 구현 가능하다.

아, 하나 더.. '미저장 확인'은 제어판을 입력 도구모음줄을 통해서 열었을 때에만 나타난다. 운영체제의 제어판/설정이 제공하는 메뉴를 통해서 연 것은 문자 입력 문맥이 아니기 때문에 '미저장 확인'이 가능하지 않으며, '확인'을 눌러서 파일에 기록하는 영구적인 저장만이 제공된다.

3. 외부 모듈과 패드 공통

편집기와 타자연습은 자체 구현된 전용 에디트 컨트롤에다가만 글자를 생성한다. 하지만 외부 모듈과 입력 패드는 타 프로그램에다가 글자를 생성한다. 그렇기 때문에 이들 프로그램에서는 제어판의 시스템 계층에 '한글 표현 방식'이라는 탭이 존재하며, 빠른설정이나 낱자 결합에서 옛한글을 지정하면 "한글 표현 방식부터 맞춰야 옛한글이 실제로 나타납니다"라는 안내문이 나타난다.

또한 텍스트를 보낼 수만 있지 읽어 오고 고칠 수 없는 환경에서는 이런 동작과 관련된 기능과 옵션들이 몽땅 사용 불가 상태가 된다. 앞 글자로 달라붙는 bksp 옵션이나 단어 단위 한자 변환이 대표적인 예이다.
입력 패드는 이런 기능들이 무조건 사용 불가이고, 외부 모듈은 TSF A급 환경에 한해서 그런 기능들을 사용할 수 있다.

4. 외부 모듈 only

외부 모듈에서 제어판을 띄웠을 때는 유일하게 시스템 계층에 '외부 모듈 관리' 탭이 나타나지 않는다. 그 대신 '고급 시스템 옵션'을 갖고 있다.
또한, 구현체들 중 유일하게 외부 모듈만이 Alt가 섞인 단축글쇠를 전혀 인식할 수 없기 때문에 단축글쇠 대화상자에서 Alt를 나타내는 슬라이더가 사용 불가 상태로 바뀐다.

지금까지 논의한 사항들을 또 표로 깔끔하게 정리하면 다음과 같다. 아래의 4개 항목은 자료구조· 알고리즘의 차이가 아니라 그냥 UI 처리 차원에서의 차이일 뿐이다. 타자연습은 특이사항이 거의 존재하지 않아서 단순하고, 외부 모듈은 동작 환경이 변화무쌍하다 보니 조건부로 동작하는 게 굉장히 많음을 알 수 있다.

항목 편집기 외부 모듈 패드 타자연습
설정 data 저장소 공통 스레드별 따로 공통 계정별 따로
공통 설정(메모리) 조작 O X O O
공통 설정(imeconf.dat 파일) 조작 O O O X
'미저장 확인' 지원 O 입력 문맥일 때만 O X
modeless. '적용' 지원 O X O X
옛한글 설정 필요 안내문 X O O X
입력 기능 제약 처리(TSF A 미비) X IME/TSF B 한정 O X
Alt 단축키, 외부 모듈 관리 숨김 X O X X
2글자 이상 조합 제약 안내문 X TSF B 한정 X X

Posted by 사무엘

2016/12/30 19:35 2016/12/30 19:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1311

다음 버전 개발 근황 2

이번 8.8은 이례적으로 다음 버전 개발 근황을 두 차례나 올리게 됐다. 분량을 나눠야 할만큼 작업이 활발하게 진행 중이라는 뜻이다. 번호를 9부터 시작해야 하나 싶은데.. 첫 근황을 올린 지 시간이 몇 주 정도 지났으니 다시 1로 리셋하도록 하겠다.
난 정말 날개셋 한글 입력기 코딩을 할 때가 제일 즐겁고 행복하다.

1. 사용자 정의 조합 편집 관련 기능 개선

10여 년 전 3.9 버전에서 '고급 입력기'가 첫 도입되었다. 원래 있던 '기본 입력기'의 지원 범위는 한글 한 글자의 조합인데(지금은 방점을 임시로 같이 묶어서 표현하는 것까지만 추가로 더 포함), 고급 입력기는 그 한계를 넘어서 한글이 아닌 글자의 조합도 표현하거나, 한글 하나를 여러 글자(한글 또는 비한글 모두)로 풀어서 표현하는 것을 지원한다. 전자를 위해서 '사용자 정의 조합'이 도입되었고, 후자를 위해서 '한글 출력 치환' 기능이 추가되었다. 이로써 조합 상태와 관련된 추상화 계층이 그럭저럭 완성됐다.

이번 버전에서는 그 중 '사용자 정의 조합' 쪽에 편의 기능이 추가되었다. 먼저, 제어판에서 사용자 정의 조합만 단독으로 파일로 저장하고 불러올 수 있게 했다. 바이너리 형태로 저장하는 것은 별 의미가 없다고 여겨져서 XML 형태만 지원한다.

그러니 이제 글쇠배열은 영문 쿼티로 그대로 두고, 알파벳을 기반으로 여러 방식으로 특수문자들을 입력하고 싶을 때 사용자 정의 조합 로직만 교체해서 문자 입력을 할 수 있게 됐다. 이 달 초에 소개했던 새 기능 중, 글쇠배열 이름뿐만 아니라 입력 스키마의 자체적인 이름을 부여하는 기능도 이런 맥락에서 도입된 것이다.

단, 비슷한 기능을 하는 한글 출력 치환은 여전히 단독 저장을 지원하지 않기 때문에 이건 형평성 문제가 될 수 있다. 그럼에도 불구하고 사용자 정의 조합에만 단독 저장과 불러오기 기능이 추가된 이유는.. 불러오기와 관련하여 큰 개선 사항이 또 생겼기 때문이다.

지금까지 사용자 정의 조합 로직을 설계하기 위해서는 w를 눌렀을 때 분기할 상태, 그 뒤에 a를 눌렀을 때 분기할 상태 등등을 숫자를 생각하면서 사용자가 일일이 설계해야 했다. 이런 불편을 덜기 위해 이번 버전에서는 이 프로그램이 내부적으로 사용하는 자료 구조를 그대로 노출하는 XML 스키마 말고, 사용자 친화적인 일명 '쉬운 문법' 스키마도 추가했다.

"wa = わ" 이런 쌍만 쭉 지정해 주면 w와 wa를 입력했을 때의 중간 과정과 상태 번호를 자동으로 매겨 준다는 것이다. 입력 파일 포맷을 구체적으로 어떤 형식으로 짜면 되는지는 물론 예제에다 소개해 놨다. 쉽게 말해 아래 그림에서 왼쪽처럼 만들어 놓으면 자동으로 오른쪽으로 만들어 준다는 뜻이다.

사용자 삽입 이미지

사실, 현재 예제로 제공되는 일본 문자 입력 로직은 히라가나/가타카나 테이블로부터 로직을 자동으로 짜 주는 툴을 내부적으로 돌려서 생성한 것이다. 사람의 손으로 60개가 넘는 state들을 알파벳 순으로 노가다로 생성한 건 물론 아니니까. 그 툴을 <날개셋> 한글 입력기 내부에 정식으로 포함시킨 거라고 생각하면 된다.

물론, 쉬운 문법은 내 프로그램이 인식하고 변환하는 걸 지원한다는 뜻이지, 프로그램이 내부적으로 사용하는 자료구조는 아니다. 그렇기 때문에 불러오기만 지원되지 저장은 안 된다. 쉬운 문법 원본은 사람이 따로 관리하고 갖고 있어야 한다.

또한 제어판 대화상자에서도 어떤 상태에 대해서 'called from 링크'를 찾아서 보여주는 기능을 추가했다. 30이라는 상태가 있으면 그 30이라는 상태로 분기하는 예전 상태.. 가령, 25번 상태에서 a를 누르면 30으로 간다는 걸 보여준다. 현재는 선택막대를 더블 클릭하면 앞으로 나아가는 calls to 링크만 지원되고, 뒤로 돌아갈 수는 없어서 불편했는데 이것 역시 개선됐다.

2. 단어 단위로 한자 변환

단어 단위로 한자 변환을 할 때 지금처럼 '뒤에서 앞으로 탐색'뿐만 아니라 '앞에서 뒤로 탐색'도 가능하게 옵션을 추가했다(제어판 - 편집기 계층). 예를 들어, '토선생'이라는 신조어에 대해서 한자 변환을 하면 '선생'이 아니라 '토선'이 블록이 잡힌 상태가 되며, '토선'을 변환한 뒤에 cursor는 다시 '생' 뒤로 되돌아온다.

지금까지는 조합 중인 글자나 cursor 바로 앞에 있는 글자가 반드시 단어의 마지막 글자에 포함돼 있어야 했지만 이제 그런 제약이 없어진 것이다. MS IME 내지 아래아한글이 동작하는 방식을 내 프로그램도 드디어 제대로 지원하게 됐다.

사용자 삽입 이미지

단어 단위로 한자를 변환하는 기능은 2012년에 나온 6.7 버전에서 '시범적으로' 추가되었다. 어차피 TSF A급 프로그램에서나 제공 가능한 기능이고(이건 MS IME도 마찬가지임), 그저 없는 것보다는 낫다는 차원에서 추가된 액세서리 기능일 뿐이기 때문에 동작 방식이 기존의 한 글자씩 변환하는 기능의 연장선 수준을 벗어나지 못했다. 저렇게 cursor가 통째로 앞으로 갔다가 변환 후에 되돌아오는 것은 <날개셋> 한글 입력기의 기존 프로토콜로 표현할 수가 없었다.

그러다가 그 내부적인 한계는 수 년 뒤, 작년에 나온 8.2에서 프로토콜을 확장함으로써 극복되었다. 입력 패드 구현체에다가도 한자 변환 기능을 구현하면서 작업을 싹 다시 했기 때문이다. 이때 테스트 차원에서 한자어가 굳이 cursor 바로 옆에 있지 않은 변환도 구현 가능한 것까지 확인했다.

하지만 이 코드는 말 그대로 테스트 코드일 뿐, 기존 한자 변환 코드와 융합 가능한 형태가 아니었기 때문에 조건부 컴파일로 기존 코드와 테스트 코드 둘 중 하나만 적용 가능했다. 게다가 테스트 코드는 중간에 ESC를 눌러서 한자 변환을 취소했을 때에도 cursor만 곱게 이동하는 게 아니라 변환 대상 텍스트를 불필요하게 덮어쓰는 등 한계도 있었다.

그러다가 8.8 버전에 와서야 오랜 숙제로 남아 있던 한자 후보 변환 관련 코드를 완전히 다시 작성했다. 한글 조합 상태일 때와 그렇지 않을 때를 불문하고 동일한 로직이 동작하게 했으며, 한 글자 한 글자 답답하게 앞으로 탐색하던 것을, 쿨하게 처음부터 맨 앞 글자들을 최대 30자 가까이 가져온 뒤 후처리를 하는 걸로 과정을 단순화했다. 그러면서 기존의 뒤-앞 탐색 부분에다가 옵션으로 seamless하게 병행하는 차원에서 앞-뒤 검색도 구현해 넣었다.
'초성 지향 도깨비불'(예: '간'을 '가ㄴ'으로)이나 호환용 낱자 변환으로 인해 당장 화면에 보이는 글자와 후보 변환 때 사용되는 글자가 서로 같지 않을 때의 보정 처리도 이 기회에 별도의 추상화 계층으로 싹 분리했다.

앞-뒤로 탐색했을 때 단어 단위 한글-한자 변환이 가능하지 않으면 그냥 지금 조합 중이거나 cursor 앞에 있는 한자 한 글자에 대한 한자 변환이 시도된다. 한글을 조합하던 중에 앞-뒤로 탐색하면 뒤-앞 방식으로 동작할 때와는 달리 지금 조합이 종료된다. 왜냐하면 cursor가 잠시 앞으로 이동해 버릴 수도 있으니 지금 조합 상태가 더 유지될 수 없기 때문이다. 그래도 한자로 변환될 예정인 부분이 블록으로 잠시 highlight가 되기 때문에(외부 모듈) 이 방식이 시각 피드백은 더 우수하다.

이런 뜻깊은 기능의 구현과 리팩터링 작업이 왜 이제 와서야 행해졌는지 모르겠다. 작업에 개인적으로 큰 보람을 느낀다.
그리고 이 작업을 하는 과정에서 덤으로 외부 모듈의 버그도 하나 발견해서 수정했다. TSF A급 프로그램에서 한글을 조합하지 않은 상태에서 한글 뒤에서 도구모음줄의 한자 버튼을 눌렀을 때.. 편집기와 같은 저런 한자 변환이 케바케로 되지 않는 문제가 있었다. 적어도 8.x 버전 내내 존재했으리라 여겨지는 문제이다.

3. 비주얼 관련

깨알같은 사소한 변화이긴 하다만, 지난 8.6에서 외부 모듈에서 추가되었던 '키보드 드라이버 변경' UI에다가 방패 아이콘을 추가했다. 이건 변경을 위해 관리자 권한이 필요하다는 걸 강조하기 위해서이다.
버튼에다가는 옵션 하나만 추가하면 문구 옆에다 방패 아이콘을 간단히 넣을 수 있지만, 콤보박스나 static 컨트롤에다가 방패 아이콘을 넣는 기능은 없는 것 같다. picture 컨트롤을 하나 더 집어넣어야 했다.

사용자 삽입 이미지

Windows는 IDI_ERROR, IDI_QUESTION 같은 몇 가지 기성 아이콘을 제공하기 때문에 응용 프로그램에서는 LoadIcon이나 LoadImage 함수를 통해 이것들을 가져올 수 있다. 메시지 박스에다가는 MB_ICON* 형태의 플래그를 지정해서 집어넣을 수도 있다.
그리고 Vista부터는 사용자 계정 컨트롤에 대한 시각 피드백을 제공하라는 취지로 방패 아이콘도 IDI_SHIELD라는 명칭으로 제공한다. 이들은 모두 내부적으로는 user32.dll의 리소스 형태로 존재한다.

IDI_SHIELD는 그 성격상 32*32 이상의 크기보다는 글자와 어울리는 16*16, 20*20 같은 아담한 형태로 훨씬 더 많이 쓰인다. 그런데 문제는 얘는 LoadIcon이나 LoadImage 같은 재래식 함수로는 제대로 그릴 수 없다는 것이다.

옛날부터 있었던 IDI_ERROR 같은 메시지박스 아이콘들은 최대 크기가 끽해야 48*48이 고작인 반면, 21세기에 추가된 IDI_SHIELD는 무려 256*256 크기까지 존재한다. 구조가 특이해서 그런지 LoadIcon은 물론이고 LoadImage로 크기를 지정해 줘도 작은 크기가 로딩되지 않고 제일 큰 놈으로만 그려진다. 큰 그림을 16*16, 20*20으로 강제로 줄이면 보기가 아주 흉측해진다.

그래서 방패 아이콘은 내 경험상 Vista에서부터 추가된 LoadIconMetric이라는 특수한 함수를 써야만 작은 크기로 보기 좋은 HICON을 가져와서 그릴 수 있다. 이 함수는 user32도 아니고 생뚱맞게 comctl32.dll에 있다. 세월이 흐르면서 API 설계의 일관성이 좀 깨지고 뒤죽박죽이 된 것 같다.

게다가 리소스에 있는 아이콘을 있는 그대로 read-only 공유 형태로 가져오기만 했다면 대개는 DestroyIcon을 할 필요가 없는데 저 함수의 리턴값은 언제나 소멸 처리도 해야 해서 더 불편하다. 뭐, Windows 프로그래밍에는 아이콘 나부랭이 하나 찍는 일에도 이런 복잡한 사정이 있더라.

그리고.. 진짜 사소한 거다만, 도움말에 있는 프로그램 스크린샷들을 드디어 Windows 10 기준으로 다 교체했다.

4. 옛한글 입력 설정이 되지 않았을 때의 알림 메시지

이제 더 고칠 게 없을 것 같은 입력 패드에도 improvement가 있었다.
트레이에 있는 입력 패드 아이콘을 마우스로 가리키고 있으면 현재 선택돼 있는 글자판의 이름이 툴팁으로 뜨는데, 이게 제어판의 실행으로 인해 글자판의 이름이 변경된 것은 같이 업데이트 되지 않는 걸 뒤늦게 발견하여 수정했다.

그리고 외부 모듈과 입력 패드는 옛한글을 입력하기 위해서는 제어판 시스템 계층의 '한글 표현 옵션'부터 먼저 설정해 줘야 한다는 공통점이 있다. 비트맵 자체 글꼴 전용 환경인 편집기와는 달리, 밖에서는 사용자가 옛한글을 지원하지 않는 글꼴을 사용하고 있을 수 있으며, 또 옛한글을 표현하는 방식도 역사적인 이유로 인해 여러가지가 존재하기 때문이다.

하지만 이런 사정을 모르는 사용자의 입장에서는 분명히 옛한글 입력으로 설정을 했는데 옛한글이 찍히지 않는다면 프로그램의 이상이라고 생각할 수 있다. 물론 제어판도 편집기가 아닌 타 환경에서 동작할 때는, 사용자가 빠른설정이나 낱자 결합 규칙을 옛한글과 관련된 것으로 변경할 때 "옛한글을 사용하려면 한글 표현 방식도 맞춰 주세요"라고 짤막한 메시지를 출력하긴 하지만 이것만으로는 좀 부족한 감이 있다.

입력 패드는 키보드 포커스를 건드리지 않고 시스템 트레이에다 말풍선 형태로 메시지를 찍는 아주 편리한 UI를 갖추고 있으니 이런 기능을 추가하는 게 아주 용이하다.

사용자 삽입 이미지

(layered window든 동영상이든 화면에 보이는 건 무엇이건 print screen으로 간단히 캡처하는 시대가 된 지 오래인데, 시스템 트레이의 말풍선 윈도우는 의외로 고전 테마에서는 print screen 캡처가 안 되더라..! DWM이 동작하는 AERO 테마를 띄워야 캡처가 됐음..)

참고로 지금까지 입력 패드는 입력과 관련된 기술적인 에러 메시지를 찍는 기능만 있었다. 권한 차이로 인해서 입력 패드가 메시지를 보낼 수 없는 윈도우일 때, 그리고 해당 윈도우가 IME 컨텍스트가 존재하지 않아서 문자 입력이 가능하지 않을 때 말이다.

다 외부 모듈/IME 말고 입력 패드에서만 존재하는 상황을 가리킨다. 외부 모듈은 애시당초 로그인 화면에서도 동작할 정도로 권한 걱정 따위는 할 필요가 없으며, IME 컨텍스트가 존재하지 않는 윈도우에서는 처음부터 버튼들이 다 흐리게 바뀌고 입력이 차단되기 때문에 사후에야 이런 상황을 알아채고 에러 메시지 처리를 할 일도 없기 때문이다.

사용자 삽입 이미지

다만, 옛한글 설정을 해 달라는 메시지는 입력 패드와 외부 모듈이 공통으로 출력할 명분이 있는 것들이다.
외부 모듈은 어떤 경우에도 시스템 트레이를 건드리지 않고 동작하기 때문에 다소 투박하긴 해도 그냥 메시지 박스를 이용한다.

사용자 삽입 이미지

외부 모듈은 TSF B급 프로그램에서 어쩔 수 없는 기술 한계로 인해 조합이 튕긴 것을 감지해서 메시지 박스를 찍어 주는 게 있었다(처음에 2글자 이상 길이의 조합을 만들 수 없음). 히스토리 문서를 보니 저건 그리 오래 되지도 않은 8.5 버전에서 추가된 기능이다. 이건 IME가 아닌 TSF 프로토콜을 취급하는 외부 모듈에서만 유일하게 발생하는 현상이다. 그런데 이제 이런 식으로 메시지를 찍어 주는 상황이 하나 더 추가된 것이다.

사용자 삽입 이미지

이런 식으로 예전에 만들어 뒀던 체계를 확장하여 유용한 UI가 간단하게 추가되는 건 참 뜻깊은 일이다.

Posted by 사무엘

2016/12/25 19:35 2016/12/25 19:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1309

다음 버전 개발 근황

2016년 12월 현재, <날개셋> 한글 입력기 8.8이 한창 개발 중이다. 내년 2~3월쯤에 나올 예정이다.

1. 제어판에 가상 키코드 변환 기능

지금으로부터 10년도 더 된 먼 옛날, <날개셋> 한글 입력기가 3.41 버전에서 지금과 같은 트리 구조의 제어판이 도입된 이래로, '입력기 계층' 탭은 오랫동안 별다른 UI나 기능이 없는 잉여 공간이었다.
어느 글자판(입력 항목)을 사용하건 공통으로 적용되는 옵션이나 기능들은 '편집기 계층'에 있었지, 딱히 입력 항목들만을 한데 싸잡아서 무슨 공통된 명령을 내릴 만한 건 없었기 때문이다.

그러다가 5.0이 나오면서 이 탭이 잠시 쓰인 적이 있었다.
5.0부터는 입력 설정 데이터의 파일 포맷이 바뀌었다. 그래서 이제 지원되지 않는 옛(3~4 버전용) 설정 데이터가 감지되면 제어판은 그 데이터를 읽지 않고 일단 프로그램 설치 직후의 기본 입력 설정을 내놓은 뒤, 처음에 이 '입력기 계층' 탭을 가리키게 했다. 그리고는 이 탭의 빈 공간에다가 "사용자의 예전 입력 설정은 구버전 방식이기 때문에 변환을 해야 불러올 수 있습니다" 이런 메시지를 임시로 출력시켰다.

사용자 삽입 이미지

5.0의 과도기가 지난 이후로 지금까지 파일 포맷이 또 변경된 적은 없다. 그렇기 때문에 이제는 저런 메시지를 볼 일이 없을 것이다. 그러나 먼 미래에 포맷이 바뀐다면 '입력기 계층' 탭은 또 그런 용도로 쓰일 여지가 남아 있다.

입력기 계층 탭이 이런 legacy 포맷 안내문 말고 일상적인 설정 기능을 갖게 된 것은 7.7 버전부터이다. 글쇠배열(key), 입력 설정(ist), 종합 설정(set)라는 세 계층별로 설명문을 넣을 수 있는데, 종합 설정 단위의 설명문을 넣는 기능이 입력기 계층에 들어갔기 때문이다. 여기에다가는 등록되어 있는 각 입력 항목들의 용도와 의미, 글자판 전환 글쇠들의 로직 같은 총체적인 설명을 집어넣으면 된다.

물론 그래도 하이퍼링크 형태로 '설명문 지정' 한 줄 달랑 들어간 게 전부였으니.. 입력기 계층 탭은 여전히 아주 초라해 보이는 건 사실이었다.

사용자 삽입 이미지

그러다가 이번 8.8 버전부터 이 탭에 그럴싸한 명령이 하나 더 추가되었다. 입력 설정들 중에 가상 키코드가 지정된 것들의 배열을 일괄 변환하는 기능이다. 이 기능이 도입된 배경을 설명하자면 다음과 같다.

사용자 삽입 이미지

<날개셋> 한글 입력기는 지난 8.6 버전을 계기로 운영체제의 어떤 키보드 드라이버와도 잘 연계해서 동작하는 기능이 강화되었다.
기본 입력 스키마가 제공하는 글쇠배열은 그 밑에 쿼티 드라이버를 쓰건 드보락을 쓰건 콜맥을 쓰건 47개 글쇠들의 자기 위치가 불변으로 잘 고정되어 있다. 그러나 그 47키 글쇠배열 말고 다른 방식으로 글쇠를 인식하는 기능들은 가상 키코드 기반이기 때문에 키보드 드라이버의 영향을 받는다.

기본 입력 스키마가 제공하는 '추가 글쇠 인식 기능', 고급 입력 스키마가 제공하는 '고급 글쇠 인식', 그리고 편집기 계층에 있는 단축글쇠들도 다 그러하다. 그렇기 때문에 S라는 글쇠를 인식하라고 하면 쿼티에서는 왼손의 A 오른쪽에 있는 글쇠이지만, 드보락에서는 오른손 새끼손가락으로 누르는 글쇠가 된다.

이 문제를 해결하기 위해서는 굳이 글쇠의 인식 방식을 바꾸는 모험을 하기보다는 모든 입력 항목들의 설정에 대해서 저렇게 가상 키코드에 의존하는 부분을 다른 글쇠배열의 동일한 위치 기준으로 값을 변환해 주는 기능을 넣는 게 좋겠다는 결론을 내렸다. 그리고 이 기능이 들어가기 딱 좋은 위치가 바로 '입력기 계층' 탭인 것이다.

내가 지금 드보락 드라이버를 사용하고 있는데 입력 설정은 쿼티 기준이다 싶으면, '변환' 버튼을 누른 뒤 글쇠배열을 '한국어/Korean'이나 'US Qwerty' 같은 걸 선택하면 된다. 즉, from과 to 중에 from만 지정하면 된다. to는 지금 <날개셋> 제어판을 구동한 프로그램이 사용하고 있는 글쇠배열로 자동으로 결정된다.
그리고 to뿐만 아니라 from에 해당하는 글쇠배열도 운영체제에 설치돼 있어야 한다. 이 프로그램은 운영체제가 제공하는 기능을 사용해서 변환하기 때문이다.

사용자 삽입 이미지

이거 한 방이면 입력 항목들뿐만 아니라 편집기 계층의 단축글쇠까지도 변환된다. from이 쿼티, to가 드보락이라면 A,S,D,F 라는 글쇠는 드보락에서 동일 위치에 해당하는 A,O,E,U로 바뀐다. 반대로 from이 드보락, to가 쿼티라면 H,T,N이 J,K,L로 바뀐다. 이런 식이다.

설명문도 마찬가지이지만, '입력기 계층' 탭에서 건드리는 범위는 편집기 계층을 일부 포함할 수도 있다. 그러나 입력기 계층까지 명백하게 포함하는 개념이기 때문에 이것은 편집기 계층 대신 입력기 계층으로 분류된다.

옛날에는 텅 비어 있었지만 지금은 그럭저럭 공간이 채워진 탭들의 선례를 살펴보면 다음과 같다.

(1) 사실은 입력기 계층뿐만 아니라 '편집기 계층'과 '시스템 계층' 탭도 다른 탭들에 비해 널널하긴 마찬가지이다.
편집기 계층은 한자 후보 변환 관련 기능만 빼면, cursor의 이동 방식이라든가 '삽입/겹침' 같은 건 따지고 보면 1.0부터 있었던 기능이 전부이다. 이 방면으로 딱히 기능이 더 추가될 여지가 없었던 듯하다. '단축글쇠'와 '최종 변환'이라는 세부 카테고리 역시 3.0 이래로 지금까지 더 추가된 게 없다.
다음으로 시스템 계층도 글꼴 본뜨기 같은 액세서리밖에 없다가 최근에는 키보드 드라이버 보정 기능이 여기에 추가돼 들어갔다.

(2) 기본 입력 스키마의 '글쇠 인식 옵션' 탭.
오랫동안 유의미한 옵션이라고는 사실상 '빈 입력 스키마와 호환되게' 옵션밖에 없던 안습의 극치였다. 몇 가지 옵션들을 구상해서 넣은 건 있었으나 실제로 구현되지 않아서 사용불가 상태였다. 그러니 탭을 없애고 글쇠배열 탭에다 합병을 해 버려도 할 말이 없었으나... 그 옵션 자체는 엄연히 글쇠배열이 아닌 입력 스키마의 영역이었고, 미래의 기능 추가에 대비해서 탭을 유지하고 있었다.
실제로 후대 버전에서는 변수 인식과 관련된 여러 옵션들이 추가되었으며, 결정적으로 임의의 단축글쇠 리스트를 꾸미는 기능도 추가되면서 이 페이지 역시 꽉 차게 되었다. 옛날에 구상했던 기능들은 대부분 고급 스키마의 형태로 오늘날 실현되었다.

(3) 외부 모듈의 '고급 시스템 옵션' 탭.
4.82 버전에서 'TSF 지원 확장' 옵션 딱 하나가 추가된 걸로 아주 초라하게 시작했으나, 그 뒤로 각종 한영 상태 동기화 옵션과 기본 IME 지정 명령처럼 <날개셋> 외부 모듈이 IME로서 운영체제/타 프로그램과 소통하는 방식을 지정하는 고유한 옵션들이 많이 추가됐다.
최근에는 자신과 연결할 키보드 드라이버를 지정하는 옵션까지 추가되어 페이지가 빈틈이 없이 꽉 찼다. 나중에 옵션을 한두 개 더 추가하려면 'TSF 지원 확장'에 딸려 있는 안내문을 없애거나 분량을 줄여야 할 것이다.

가상 키코드 변환 기능 덕분에 인제 '입력기 계층' 탭은 별도의 독립된 도움말 페이지도 할당받았고 버튼도 두 개나 생겼다.
미래에는 이 탭이 지금보다 더 풍성해지는 날이 오기를 기대해 본다.

2. 글쇠배열의 이름과 별도로 입력 스키마에도 고유한 이름

얘기가 갑자기 딴길로 많이 샜구나. 다시 본론으로 들어오도록 하겠다.
3.0대 버전 이래로 지금까지 굉장히 어정쩡한 관계이긴 했는데.. 어떤 입력 항목에 대해서 '글쇠배열의 이름'과는 별개로 입력 항목 차원에서 고유한 이름을 사용자의 필요에 따라 지정할 수 있게 했다. 입력 항목의 이름이란, <날개셋> 한글 입력기의 여러 구현체들에서(편집기, 외부 모듈 등) '한글 세벌식', '영문 쿼티'처럼 "글자판을 선택하세요" 목록 내지 메뉴에 나타나는 이름들을 가리킨다.

지금까지 입력 항목의 이름이란, 곧 입력 스키마가 갖고 있는 글쇠배열의 이름과 동일했다. 어떤 입력 방식에서 글쇠배열이 차지하는 비중이 워낙 큰 게 사실이니 이런 접근 방식이 지금까지 큰 문제는 없었다.

그러나 글쇠배열은 여느 한글 또는 영문 배열과 다를 바 없고 오토마타나 사용자 정의 조합만 달리해서 여러 입력 방식을 만들어 낸다면 지금 같은 체계는 좀 문제가 있다. 글쇠배열을 바꾼 건 없는데 글쇠배열 탭에 가서 이 입력 방식 특성을 표현하는 이름을 입력해야 하기 때문이다.

이제 8.8버전부터는 제어판을 열어서 입력 항목을 가리키면, 지금까지 읽기 전용이던 이름 입력란에다 이름을 입력할 수 있다.
이게 공란이면 예전처럼 글쇠배열의 이름이 입력 항목의 대표 이름으로 유지된다(회색 글자). 그러나 저기에 문자열이 입력되면 그 문자열이 대표 이름이 된다.

사용자 삽입 이미지

그러므로 쿼티 영문 글자판을 기반으로 한글 로마자 입력 방식을 구현했거나 사용자 조합 기능을 추가해서 다른 문자 입력 체계를 구현했다면, 그걸 나타내는 새로운 이름을 입력 항목 차원에서 써 주면 된다. 이렇게 하면 글쇠배열의 이름을 굳이 건드리지 않고도 자기가 만든 입력 방식이 대외적으로 식별되는 명칭을 새로 지정할 수 있다.

입력 항목의 대표 이름은 설명문과 비슷한 형태로 저장된다. '빈 입력 스키마'는 원래부터 아무 옵션이 없고 아무 동작도 안 하는 스키마이기 때문에.. 설명문과 대표 이름을 모두 지정할 수 없으며, 대표 이름도 그대로 '빈 입력 스키마'로 언제나 고정된다.

저걸 구현하느라 난생 처음으로 에디트 컨트롤에다 EM_SETCUEBANNER 기능을 써 봤다. 이게 지원되지 않는 운영체제에서는 그냥 저 회색 디폴트 텍스트가 나타나지만 않고 다른 영향은 없다. 원래 cue banner는 '여기에 이름을 입력하세요' 같은 고정된 UI 가이드/힌트를 출력하라고 있는 텍스트이기 때문에 저렇게 런타임 가변적인 텍스트를 찍는 건 약간 이질적인 활용이긴 하다.

저 기능이 최초로 추가된 건 Windows XP의 공용 컨트롤 6.0부터다. 수식의 변수 도움말을 출력하기 위해 진작부터 사용해 온 풍선 도움말(balloon text)과 도입 시기가 동일하다. 그런데 참 희한하게도 이 기능은 한중일 동아시아 언어권 에디션 또는 MUI 팩이 설치된 XP에서는 버그로 인해 동작하지 않았다고 한다. 우리 같은 사람은 Vista와 그 이후에서나 cue banner를 구경할 수 있게 됐다.
반대로, Windows XP에 도스용 QBasic이 영미권에서는 삭제됐지만 동아시아 에디션에서는 있었다고 하니 이것도 신기한 노릇이다.

3. 문자표

문자표 대화상자에도 약간의 변화가 생겼다.
맨 위에 '종류'라는 콤보박스가 추가되어, 단순히 글꼴이 존재하는 모든 문자들을 코드값 순으로 나열하기만 하는 게 아니라 다른 임의의 문자표를 제공할 여지를 마련했다. 사실, 이 용도로는 MS Word나 아래아한글의 문자표 대화상자처럼 탭 컨트롤을 쓰는 것도 좋으나 그것보다 더 구현하기 쉽고 만만한(..) 콤보박스를 사용했다.

이것이 예전 무려 3.0 시절부터 있던 'KS X 1001 문자표' 체크박스를 대체했다.
사실, 완전히 다른 문자표를 출력하는 기능이 무슨 옵션인 것처럼 체크 형태로 있던 건 굉장히 이상한 UI 디자인이긴 했다.
마치 성별을 입력받는 UI가 남/녀 라디오나 콤보박스로 있는 게 아니라, "[X] 여자" 체크박스로 달랑 주어지는 것처럼 말이다. 내부적으로 표현되는 정보량이 1비트라고 해서 체크박스가 모든 상황에서 적합한 건 아니다.

체크박스가 콤보박스로 바뀌었는데 문자표가 여전히 두 종류밖에 없으면 좀 심심하니 "모든 한글 자모"라는 문자표를 하나 더 넣었다. 이것은 유니코드에 존재하는 모든 한글 낱자들을 초중종별 사전 순으로 표시해 준다. 여러 영역에 뿔뿔이 흩어져 있는 한글 자모들을 한데 열람하고 옛한글을 문자표로 입력할 때 큰 도움이 될 것이다.

사용자 삽입 이미지

이제 사용자가 별도의 리스트로 작성한 custom 문자표를 뒤에 줄줄이 추가하는 기능도 생각할 수 있으나, 일단 미래의 과업으로 미루기로 한다.

4. 방점 지원

<날개셋> 편집기가 드디어 한글의 뒤에 붙은 방점(U+302E, U+302F)을 한글의 왼쪽에다 제대로 표시해 준다. 또한 cursor의 이동· 삭제 단위를 판별할 때 방점은 앞의 한글과 같이 한 묶음으로 처리된다. 안 그래도 <날개셋> 편집기는 세로쓰기도 지원하니, 방점이 이렇게 세로로 찍혀 나오면 문서가 더욱 볼 만할 것이다.

사용자 삽입 이미지

다만, 방점은 자신만의 고유한 폭을 차지하는 게 아니라 한글 16*16 공간 안에 같이 삽입된다. 그렇기 때문에 한글 글꼴 자체가 큼직하다면 방점이 제대로 보이지 않을 수 있다. 방점과 잘 어울리는 약간 홀쭉한 옛한글 글꼴이 좀 있어야 할 것 같다. 그나마 '한메가는본문'이 이런 범주에 드는 글꼴 같지만 얘는 옛한글을 지원하지는 않는다.

한글 한 글자를 구성하는 덩어리에 초중종성에 이어 방점까지 옵션으로 붙을 수 있다니 이건 무슨 픽셀에서 RGB에 이어 알파채널까지 붙는 것과 비슷해 보인다. 그렇다고 이거 지원을 위해 <날개셋> 한글 입력기의 내부에서 한글 하나를 나타내는데 제4의 성분을 통째로 다 집어넣은 건 아니다. 그런 무모한 짓을 한 건 아니고 그냥 한글 입력 오토마타의 내부 구조만 살짝 확장했다.

내가 처음에 한글을 입력할 때야 그 조합 내부에다가 방점을 같이 넣을 수 있지는 않다. 방점은 입력되는 순간 한글 조합을 종료시켜 버린다. 단지, 이미 방점이 곁들어진 한글에다 달라붙을 때 그 방점을 임시로 유지한 채로 자모를 고치거나 추가로 입력할 수만 있게 했다.
그리고 이 상태에서 bksp를 누르면 언제나 방점부터 먼저 지워지고 그 뒤에 한글 자모가 지워진다. cursor가 이동하는 단위하고 bksp로 글자를 지우는 단위, 그리고 앞에서 뒷글자를 지울 때와 뒤에서 앞글자를 지울 때 동작에 차이가 발생할 수도 있어서 꽤 어려울 수도 있는 작업이었는데 결국 문제를 이런 식으로 깔끔하게 해결했다.

5. 텍스트 필터 추가

"한글 형태 정규화" 필터에는 NFC와 NFD 정규화 둘만 있었는데, 거기에다가 "NFD부터 적용 후 NFC"라는 제3의 동작 옵션을 추가했다.
이렇게 하면 '가ㅿ'처럼 종성이 없는 현대 한글 자모 + 채움 문자 없는 종성 한글 낱자가 한데 이어져서 정규화가 잘못되어 있던 한글이 현대 한글 또는 옛한글로 한데 합쳐진다.

예전 방식으로 이런 문자열을 NFC 정규화 하면 '가'는 그대로 있고 ㅿ는 채움 문자가 추가되어 두 글자가 서로 완전히 분리되곤 했다. 새로 추가된 옵션은 그보다 더 융통성 있게 동작할 것이다.

사용자 삽입 이미지

사실, 텍스트 필터들은 옛날에 6.x 버전 때 잔뜩 추가되고 나서 그 뒤로 변화가 거의 없었다. 그런데 이번엔 "문자 코드값 산술 치환"이라는 새로운 필터가 추가됐다.
그냥 모든 글자들에 대해 코드값을 나타내는 변수 A에 대한 수식을 실행해서 그 수식값으로 문자를 바꿔 준다. 0을 지정하면 그 문자를 지운다. surrogate는 자동으로 처리되기 때문에 A>=0x10000이라고 생각하면 된다.

쉽게 말해 이 기능은 <날개셋> 편집기에 이미 들어있는 '문자 영역 찾기' 기능의 '바꾸기' 버전이라 할 수 있다. 앞뒤 글자를 가리키는 P와 N 변수를 사용할 수 있으며, 여기서 글자를 변경했다고 하더라도 뒷글자의 수식에서 P변수에는 바뀌기 전 앞글자의 코드값이 들어간다.
A - (A>='a' && A<='z' ? 32:0) 이런 수식을 주면 알파벳 대문자를 소문자로 바꿀 수 있으며 전/반각 변환도 그냥 수식으로 처리할 수 있다. 그리고 정규화된 한글 낱자에서 특수 처리를 위해 외형상 잘 보이지 않는 채움 문자만 제거하고 싶을 때도 이 필터를 사용하면 된다.

6. Windows 10 + 구글 크롬에서 발생하는 외부 모듈의 이상한 문제

본인은 근래에 한 사용자로부터 아주 괴이한 현상에 대한 신고를 받았다.
Windows 10 (일단은 64비트) + 구글 크롬의 주소창에서 한글을 입력한다. 그리고 조합이 있는 상태에서 그대로(예: '가' 입력 중) 마우스로 그 주소 입력란을 클릭한다. 그러면 외관상 당연히 조합이 종료돼야 한다.
그런데 그 상태에서 한글을 입력하면 아까 조합 중이던 한글이 덧나서 '가강' 내지 '가가ㄴ'처럼 된다.

<날개셋> 한글 입력기가 개발 짬밥이 몇 년인데 저런 미개하고 원시적인 버그가 있다는 건 말이 안 되는데? 게다가 다양하게 실험을 해 보니 이 버그는 다음 조건 중 하나만 만족해도 발생하지 않는다. 혹시나 해서 말인데, 모든 테스트는 64비트 기준임.

  • 일단 날개셋 말고 MS IME는 어디서든 별 이상 없음.
  • 크롬에서 '가능한 경우 하드웨어 가속 사용' 옵션을 끄면 날개셋 역시 저런 문제 없이 조합 종료 처리가 옳게 됨. 아놔 웹 페이지 렌더링에서 가속을 받는 것하고 IME 프로그램의 동작이 도대체 무슨 상관이냐? -_-;;
  • Windows 10 중에서도 1주년 업데이트를 갓 받은 버전 1607, 빌드 14393.xx대에서만 확실하게 발생하며, 그 이전(버전 1511, 빌드 10586) 내지 이후(버전 1607, 빌드 14971) 버전에서는 발생하지 않는 듯함.

크롬에서 발생하는 문제이긴 하지만 날개셋 + 운영체제 + 크롬이 삼박자로 모두 정밀한 조건을 기가 막히게 만족할 때만 발생하기 때문에 이건 도대체 어떻게 처리해야 할지 모르겠다. Windows 10은 시도 때도 없이 업데이트가 너무 자주 되고 있기 때문에, 만약 후대 빌드에서 문제가 발생하지 않는다면 이건 그냥 '알려진 문제'에다 언급만 하고 넘길 가능성이 높다.

7. 예제 데이터와 도움말

예제 입력 데이터도 몇 개 더 추가하고 Samples 아래에 디렉터리를 더 세부적으로 구분했다. key와 ist 중 한글 입력과 관계 있는 것은 Hangul로, 한글 입력이 아닌 것을 Non-Hangul로 나눴다.
그리고 아직은 예제가 각각 하나씩밖에 없지만 후보 데이터는 Candidate로, 한글 표현 영역 데이터는 Range로 이동해서 배치했다. 확장자가 다 같은 txt이어서 분간이 안 되기도 하니 말이다.
이제 Samples 디렉터리 자체에는 제어판 내장값 예제 데이터인 scheme.xml만 있다. 여기에는 용도가 고정된 파일들만 있을 것이다.

Non-Hangul들은 평범하게 글쇠배열이나 오토마타 수식이 아니라 '날개셋 고급 입력기' 문자 생성기가 제공하는 기능들을 활용해서(사용자 정의 조합과 후보, 출력 치환) 외국 문자나 각종 알파벳 변형 문자들을 입력한다. 알파벳+성조 번호로 성조가 붙은 알파벳을 입력하는 한어병음, X를 덧붙여서 악센트 부호 알파벳을 찍는 에스페란토, 심지어 베트남어 VIQR 입력 방식까지 있다. 내가 만든 건 아님.

그리고 도움말엔 부록의 "한글 낱자 코드 참조표 - 자음" 부분과, 기본 자료 구조의 "한글이 표현되는 방식"에 설명을 보강했다. KS X 1026에서 종성 ㅇ 겹받침이 옛이응 겹받침으로 전격 변경된 것과 관련된 내용을 추가했으며, 현행 한글 코드에 대한 비판에 대한 해명도 넣었다. 한글 11172자와 수백 자의 옛한글 낱자가 유니코드에 일일이 배당된 것이 뭔가 잘못된 것처럼 생각하는 분들이 있는데 본인은 그렇게 생각하지 않는다고 말이다.

이렇듯, 개발 2개월째를 맞는 차기 버전 8.8은 핵심 기능을 제외하고도 겉의 UI와 데이터에 유의미한 변화들이 잔뜩 추가되었다. 다음으로 타자연습 얘기를 하겠다.

8. 타자연습

(1) <날개셋> 타자연습은 현재 최신 버전(입력기 8.6 + 타자연습 3.51)에 중대한 버그가 있다는 걸 이 자리에서 먼저 밝힌다. ‘글쇠 익힘’에서 ‘글자 단위 연습’을 사실상 할 수가 없다. 상자에 있는 글자를 그대로 따라 쳐서 완성하는 순간 프로그램이 뻗어 버리기 때문이다.

이건 타자연습은 잘못이 없고 입력기가 한창 새 기능들이 추가되던 와중에 어이없는 실수가 들어갔기 때문이다. 처음부터 있었던 버그는 아니고 8.5~8.6쯤에서 들어간 것으로 추정된다. 세벌식 커뮤니티에서는 오래 전부터 나돌던 이슈였던 것 같은데 본인은 지금까지 이걸 알지 못했다.

(2) 오랫동안 존재했을 것으로 추정되는 굉장히 어처구니없는 버그를 사용자의 제보 덕분에 발견하여 수정했다. <날개셋> 타자연습에는 사용자 계정 이름을 변경하는 기능이 있는데 그게 사실상 거의 쓸 수 없는 무용지물이었다. 계정을 갓 생성한 직후에는 개명이 가능하지만, 나중에 그걸로 본격적으로 로그인을 한 뒤에는 개명 기능이 동작하지 않았기 때문이다. 이 문제 역시 확인된 즉시 해결했다.

(3) 지난 3.5버전부터 연습글을 관리하는 체계가 리스트 xml이 아닌 디렉터리 기반으로 간소화되었는데.. 이 때문에 지금까지 제공되던 성경 본문 tc 파일을 곧장 사용하는 게 불가능해졌다.
다음 버전에서는 사용자가 지정한 연습글 디렉터리에다 tc 파일이 있으면 그 tc 파일에 있는 모든 연습글들을 별도의 꾸러미에다 자동으로 몽땅 등록해 주는 기능이 들어갈 것이다. 골치 아프게 ProgramData\YmSoft\NgsType 이런 디렉터리 찾을 필요 없이, 자기가 쓰는 연습글 디렉터리에다가 파일을 넣기만 하면 문제가 해결된다.

(4) 문장 연습 중에 현재 사용 중인 글자판의 이름을 표시하는 기능이 추가되었다. 연습 중에는 어차피 화면 좌측 하단의 ‘환경설정’ 버튼에 접근할 수가 없어지니 이 버튼을 아예 숨겨 버리고 여기에다가 <날개셋> 편집기의 상태 표시줄처럼 글자판의 이름이 표시되게 했다.

<날개셋> 타자연습은 세벌식 최종 전용 타자연습(= 한글 전용)을 표방하고 있어서 전통적으로 이런 쪽을 신경쓰지는 않고 있었는데, 이것도 표시하는 기능이 없는 것보다는 있는 게 좋아 보인다. 게임의 경우 글자판이 바뀌면 바뀐 글자판 이름이 화면 좌측 하단에 잠시 떴다가 사라진다.
사실은 앞서 언급했던 입력 스키마 이름과 글쇠배열 이름을 분리하는 기능 역시, 타자연습의 이 작업을 하던 중에 아이디어가 떠올라서 추진한 것이다.

이 정도면 타자연습의 다음 버전도 단순히 3.52 수준이 아니라 3.6 정도로 너끈히 갈 수 있을 듯하다.

Posted by 사무엘

2016/12/08 08:30 2016/12/08 08:30
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1303

날개셋 한글 입력기 8.6

이번에는 으레 관례적으로 하던 중간 보고(다음 버전 개발 근황) 없이 곧장 새 버전 소식을 전하게 되었다. <날개셋> 한글 입력기 8.6이 나왔다.
이번에도 예외없이 왜 2016년이 다 돼서 인제야 도입됐나 싶은 새로운 기능들이 많이 도입되었다. <날개셋> 한글 입력기는 8.5 때보다 더욱 완전함을 향해 나아가게 되었다.
앞으로 최대 두세 번 정도 더 버전업 해서 9.0 정도는 갈 수 있을 듯하다. 무슨 작업을 더 할지 로드맵은 이미 다 잡혀 있다.

※ IME와 연결되는 키보드 드라이버를 변경하는 기능

<날개셋> 한글 입력기에서는 글쇠배열 편집을 통해 드보락이나 콜맥 같은 다른 외국어 글자판을 같이 쓸 수 있다.
그러나 외부 모듈의 경우, 이것은 IME 방식으로 글쇠를 인식하지 않는 환경에서는 무용지물이다. 단축키나 암호 입력을 그런 영문 글자판으로 할 수는 없으며, 잘 알다시피 IME가 동작하지 않는 모드로서 '쿼티 자판' 내지 '빈 입력 스키마'가 언제나 반드시 추가돼야 했다. 이것 때문에 불편하다고 지금까지 사용자로부터 문의도 많이 들어왔었다.

물론 외부 모듈은 IME로서 자기 영역만 책임지면 되지 굳이 키보드 드라이버의 영역까지 개입할 필요는 없다. 하지만 이번 8.6 버전에서는 한글 IME와 연결되는 키보드 드라이버를 간단하게 바꿀 수 있는 UI가 추가됐다. native 빈 입력 스키마 상태에서 드보락 내지 콜맥을 한글 글자판과 병용하는 사용자에게 굉장한 유용한 기능이 될 것으로 보인다.

사용자 삽입 이미지

이제 외부 모듈에서 제어판을 연 뒤 "시스템 계층 - 고급 시스템 옵션"을 가 보면, "한글 IME와 연결할 영문 키보드 드라이버"라는 콤보 상자가 나타나 있다.
디폴트는 한국어 키보드 드라이버인 kbdkor로, 맨 앞에 있다. 자주 사용하는 걸로 판단되는 드보락과 콜맥은 곧장 2~3순위이며, 나머지 외국어 드라이버들은 이름의 알파벳 순으로 등재돼 있다. 운영체제에 존재하는 모든 키보드 드라이버 DLL들을 자동으로 탐색한 것이다.

이걸 변경한 뒤 제어판을 '확인'으로 닫으면.. 외부 모듈이 직접 레지스트리를 고치는 게 아니라 운영체제의 레지스트리 편집기를 통해서 간접적으로 고친다. HKEY_LOCAL_MACHINE 레지스트리 값을 변경하기 위해서는 관리자 권한이 필요한데, 외부 모듈은 자기가 독립적인 프로그램이 아니라 DLL이기 때문이다. (권한이 없을 수도 있음)

확인 질문에 '예'로 대답한 뒤 운영체제 로그인만 다시 하면 바뀐 글자판이 적용된다. 단, 당장 로그인 암호를 입력하는 기준 영문 글자판부터 바뀌기 때문에 절대 주의해야 한다. 잠시 암호를 없애거나 숫자 기반으로 변경할 것을 권함.

한국어 이외의 다른 외국어 키보드 드라이버에서는 (1) 한국어 키보드에 존재하는 고유한 한영/한자 글쇠를 인식하지 못하므로 단축글쇠 차원에서 Shift+Space 같은 다른 방법을 써야 한다.

(2) 또한, Windows XP 이전의 운영체제에서는 <날개셋> 한글 입력기의 기반 드라이버만이 바뀌지만 Vista 이후부터는 모든 한글 IME들의 기반 드라이버가 이걸로 바뀌어 버린다. 내 프로그램은 문제가 없지만 MS 한글 IME의 경우 한글 글쇠배열까지 영문 글쇠배열을 기준으로 뒤죽박죽 바뀌어 버리기 때문에 타 한글 IME를 사실상 제대로 쓸 수 없게 된다는 점을 주의하기 바란다.

※ 키보드 드라이버의 글쇠를 UI에서도 유동적으로 인식

위의 작업은 그 자체만으로는 그냥 일부 매니아 유저가 손으로 레지스트리를 일일이 고쳐야 했던 것을 더 편하게 해 주는 UI 껍데기를 추가한 것에 불과하고..
더 중요한 건 이제부터다. 이 김에 키보드 드라이버와 관련된 추가적인 연구를 진행했다.
<날개셋> 변환기가 콜맥 키보드 드라이버 드라이버를 불러오려 하면 리가처(일명 dead key) 테이블 쪽에서 버퍼 overflow가 나서 죽던데 이 문제를 해결했다. 해당 드라이버가 리가처들을 이례적으로 잔뜩 갖고 있어 보이긴 했지만, 내 프로그램도 어떤 경우든 당장은 죽지 않아야 하므로.

그리고 획기적인 건.. 제어판 포함하여 내 프로그램에서 글쇠배열를 보여주는 부분에서 기준 글쇠배열이 단순 쿼티 고정이 아니라 지금 사용 중인 드라이버의 배열을 보여주게 했다.
다음 그림을 보면 확실하게 감이 올 것이다. 사용자가 배당한 검은 글자 말고 위의 흰 글자들.. <날개셋> 한글 입력기 1.0 이래로 지금까지 이건 무조건 쿼티 고정이었다. 그러나 현재 키보드 드라이버가 드보락과 연결돼 있으면 이제는 드보락 배열로 표시된다. 세벌식 최종 기준으로 초성 ㅇ은 쿼티의 J 자리에 있지만 드보락에서는 H 자리이다.

사용자 삽입 이미지

키보드 드라이버라는 게 그 본질은 스캔코드와 가상 키코드 사이의 대응 규칙에다가 각종 dead key 조합을 담고 있는 '테이블'이다. 실행 가능한 기계어 코드나 매크로· 스크립트가 들어있어서 보안 문제를 걱정해야 하고, 신뢰성 보장을 위해 디지털 서명이라도 받아야 하는 그런 물건은 아니다. 그래서 Windows 9x 시절에는 키보드 드라이버는 실제로 *.kbd라는 형태의 그냥 데이터 파일이었다.

그러나 NT 계열에서는 키보드 드라이버는 그냥 static한 구조체 포인터를 되돌리는 함수를 구현한 DLL 형태이다. 무슨 다국어 UI DLL처럼 리소스/데이터만 들어있는 DLL도 아니고 엄연히 함수 실행 부분이 일단은 있다. 같은 테이블을 되돌리더라도 각 아키텍처에서 메모리로 직통으로 올릴 수 있게 구조체 멤버 같은 건 적절히 align/padding이 처리돼 있어야 한다.

그리고 바로 이런 이유에서.. 같은 32비트 x86용 드라이버라 하더라도.. 순수 32비트 OS용과, x86-64 OS에서 64비트하고 같이 운용되는 32비트 드라이버는 서로 호환이 되지 않는다. 본인은 이걸 이제야 알게 됐다. 후자는 비록 포인터가 4바이트이더라도 구조체의 포인터들은 32비트가 아닌 64비트 단위로 듬성듬성 padding돼 있어야 하더라. 어쩐지 그래서 콜맥 드라이버도 받아 보면 i386, amd64뿐만 아니라 wow64가 따로 있었구나. 통상적인 DLL을 만들 때는 그걸 구분할 필요는 없었는데 굉장히 흥미로웠다.

※ 단항 연산자

다음 버전에서 추가하네 마네 하면서 떡밥만 날렸던 ++ -- 단항 연산자를 그냥 이 기회에 추가해 버렸다. 덕분에 손 놓은 지 꽤 오래 됐던 복잡한 수식 해석 코드들을 다시 실컷 복습했다. 하지만 작업은 생각만치 복잡하거나 어렵지 않았다.
++얘는 문자열로 표현할 때 +가 두 개 있는 것과 형태를 구분하기 위해, 우선순위 조정이 아닌 다른 사유로 괄호가 필요한 첫 사례가 되었다.
물론 공백만 삽입해 줘도 되긴 하지만, 괄호로 확실하게 구분하는 게 더 보기 좋아서 괄호를 사용하기로 했다.

2008년부터 현재까지 쓰이고 있는 5.0 방식 입력 설정 포맷은 구조 확장으로 인해 더 쓰이지 않는 데이터 청크라든가, 호환성 유지를 위해 누더기 땜질식으로 확장된 청크가 늘어나고 있다. 특히 5.0 이후로 backspace 동작 관련 옵션들은 판이하게 확장되었으며 저장 방식도 바뀌어 왔다. 거기에다 연산자의 추가는 레거시 파일 포맷의 무질서도(?)를 더욱 키웠다.

하지만 파일 포맷을 또 변경하는 건 유니코드에 한글 자모가 더 추가되는 정도의 이변이 발생하지 않는 한, 아직까지는 최대한 억제하고 있다. 이건 우리나라 경제로 치면 화폐 개혁을 하는 것과 같은 급의 파격적인 변화이기 때문이다.
<날개셋> 변환기가 이제 오랜만에 대공사를 해야 할 것이다. 지금처럼 3~4.x를 5.x 포맷으로 바꾸는 게 아니라 5~8.x 포맷을 새 포맷으로 바꾸는 일을 해야 할 것이다.

※ UI

사소한 UI 쪽으로 가면, 모든 대화상자들의 외형을 총체적으로 재검토해서 버튼들의 크기와 간격을 최대한 일관성 있게 재조정했다.
마소에서는 Windows 표준 GUI 가이드라인 차원에서 명령 버튼들의 크기(특히 '확인'과 '취소')를 50*14로 할 것을 권하고 있다. (단위는 픽셀이 아니라 dlu라고 대화상자 내부에서만 쓰이는 추상적인 단위임) 내 프로그램은 그건 준수하지 않고 45*16을 쓰고 있으며, 이번에 크기를 다 그걸로 통일시켰다.

달랑 '확인', '취소' 두 글자.. 영어로 표현해도 OK와 Cancel에 불과한 그 단어를 집어넣기에는 50*14는 너무 납작하기 때문이다. 가로만 너무 길고 세로는 짧다. '맑은 고딕'은 그나마 글꼴 metric의 종횡비가 좀 개선됐지만, 과거 굴림의 경우 그 정도가 더 심하다.
요건 내 프로그램이 의도적으로 Windows 표준 GUI와는 약간 다른 정책을 취하는 부분임을 밝힌다. 사실, 국내에 애초에 그런 것까지 일일이 다 신경쓰고 만들어지는 Windows용 프로그램 자체도 별로 없지만.

그리고 오랫동안 암묵적으로 남아 있는 버그라면 버그인데..
잔상이 생기는 문제를 두 군데 해결했다.
하나는 날개셋 제어판 창을 가로로 쭉 키웠을 때, 날개셋 에디트 컨트롤에만 non-client의 테두리 부분에 남는 성가신 잔상이다. (아래 그림에서 오른쪽을 보라)

사용자 삽입 이미지

난 그리라는 이벤트가 왔을 때 그린 잘못밖에 없는데 왜 이런 현상이 생기는지는 개인적으로 잘 모르겠다.
그리고 또 하나는 일단은 고전 테마에서만 존재하는 문제 같은데, 대화상자 우측 하단에 있는 크기 조절 손잡이가 인근의 버튼 영역을 덮어써서 생기는 잔상이다.

사용자 삽입 이미지

근본 원인을 해결했다기보다는 그냥 경험적으로 문제를 피해 간 것에 가깝긴 하지만, 그래도 예전보다는 UI 경험이 더 개선됐을 것이다. 이 두 잔상은 기술적으로 문제를 피해 간 방식도 서로 완전히 달랐다.

※ high-DPI 지원, 기타

그리고 모든 구현체 프로그램들에 내부적으로 high-DPI aware 플래그를 추가했다. 이건 마소가 제시하는 표준을 준수했다는 점에서 장점이 될 수 있지만 일부 사용자에게는 단점 및 악재가 될 수도 있다.
125% 같은 high-DPI에서 대화상자들이 뿌옇게 확대+보정된 저해상도로 나오는 게 아니라 깔끔한 고해상도로 나올 테니 그건 장점이다. 하지만 편집기의 경우 어떤 DPI에서도 본문 글꼴이 무조건 16*16 픽셀로 찍히기 때문에 고해상도 + 대형 모니터에서는 이제 글자가 너무 작아서 알아보기 어려울 수도 있다.

이건 자체 비트맵 글꼴을 사용하는 내 프로그램의 근본적이고 고질적인 문제이므로 당장 쉽게 해결 가능하지는 않다. 요 특정 윈도우만 확대+보정해서 출력하는 기능이라도 써야 하지 않나 싶다. 호환성의 왕중왕인 Windows API 중에 뭔가 있을 것 같으나.. 높은 우선순위로 살펴보겠다고는 장담을 못 하겠다. 앞서 얘기했듯이 <날개셋> 한글 입력기는 문자 입력 관련 기능만 연구하기도 갈 길이 너무 먼 상태여서 말이다.

저것들 말고도..

  • 외부 모듈에서 문자표 대화상자가 가끔 제대로 동작하지 않던 것을 개선했다.
  • 기본 입력 스키마의 추가 인식 글쇠를 수정하면 처음에 날개셋문자 값이 무식한 10진수로 찍혀 나오는 엄청난 버그를 왜 인제 발견했는지.. 당장 고쳤다.
    사용자 삽입 이미지
  • 제어판의 글쇠배열 편집 페이지에서 '상태변수' 수식은 문법이 틀려도 종료 시에 에러가 찍히지 않게 했다. (어차피 설정 파일에 저장되지도 않고.. 창을 닫는 마당에 에러 체크 따윈 전혀 필요하지 않음)
  • 언제부터 이런 어처구니없는 버그가 들어갔는지 모르겠는데.. 편집기가 0바이트인 파일을 아예 열지 못하고 에러 처리하던 버그를 모 사용자로부터 제보 받아서 즉시 개선했다.
  • 현재 편집기는 파일을 저장할 때는 원래 있는 파일의 날짜와 크기를 체크해서 내 프로그램이 아닌 외부에서 변경되었으면 그걸 사용자에게 확인시킨다. 그런데 그 다음으로, 열었던 파일을 아무 변경 없이 그냥 닫더라도 파일이 외부에서 변경되었으면(날짜 크기 변경, 삭제) 재저장할지 사용자에게 확인시키게 했다. 단, 애초부터 읽기 전용으로 열지 않았고 하드디스크에 있는 파일에 한해서이다. (네트웍, 이동식 드라이브에서 연 파일은 제외)
  • Google 단모음 키보드를 예제 입력 방식으로 추가했다. 기존 두벌식에서 겹자음과 ㅑㅕㅛㅠ만을 제거한 간소화 버전인데 나름 모바일에서의 가성비가 좋다. '하꾜'는 연속 입력이 되지만 '학교'는 중간 딜레이가 필요하다. 천지인처럼 모든 종성에서 타이머를 줘야 하는 게 아니라 ㅂㅈㄷㄱㅅ 요 자음에 대해서만 주면 되는데, 그 값을 글쇠배열 수식에서 소문자 변수를 통해 지정하게 했다.

이렇게 사소하게 고치고 더한 아이템들이 더 있다.
두벌식에서 글쇠 수를 지금보다 더 늘리지 않고 shift도 쓰지 않고 쌍자음 음절 경계 구분 문제를 해결하는 방법은.. 어쩔 수 없이 (1) 타이머를 쓰거나, 아니면 (2) 초성은 다음에 이어지는 모음의 특성을 추가로 이용해서 쌍자음을 구현하는 것 정도가 전부인 듯하다.

※ 타자연습

끝으로 타자연습의 경우, 입력기 프로그램들과 마찬가지로 high-DPI 플래그를 넣었으며 이 외에도,

  • 도움말의 '세벌식 만물상 → 운영체제에서 두세벌식 전환을 어떻게 하죠?'에.. Windows 8~10 기준으로 글자판을 전환하는 방법이 지금까지 너무 오랫동안 빠져 있는 것을 확인하여 설명을 추가했다. 확실히 운영체제의 버전이 올라갈수록 전환하는 방법이 더 복잡해져 왔다.
  • 좀 심각한 문제이던데, 타자연습을 종료한 뒤에도 잔여 프로세스가 완전히 사라지지 않고 남아 있던 문제를 해결했다. 구형 운영체제에서는 이런 일이 없는 것 같던데 10에서는 문제가 있었다. Windows에서 프로세스는 단순히 실행을 끝내고 리턴만 하는 게 아니라 ExitProcess를 호출해 줘야 어디서나 확실하게 종료되는 듯하다.
  • 문장/글 연습에서 사용자가 추가한 디렉터리에 있는 연습글들은 우클릭했을 때 해당 연습글을 (1) 바로 편집하거나 (2) 파일이 있는 곳을 탐색기로 열어서 바로 찍어 주는 명령을 메뉴에 추가했다.

지난 3.5부터는 사용자 연습글을 추가하는 방식이 XML 기반에서 디렉터리-파일 기반으로 확 바뀌었기 때문에 이제 사용자가 연습글 리스트 XML을 직접 고칠 일은 거의 없을 것이다. 그렇기 때문에 인제 와서 큰 의미는 없겠지만, 이번 버전에서는 연습글 경로에서 내부 압축 꾸러미 이름을 식별하는 구분자를 @에서 *로 전격 변경했다.
별표는 파일 시스템 차원에서 절대로 들어갈 수 없는 문자이기 때문에 이제 *.tc 파일 자체가 경로 중간에 @가 섞여 있더라도 이제는 아무 문제 없이 취급 가능하다.

※ 맺는 말

<날개셋> 한글 입력기에 대해 대외적으로 들어오는 의견은 크게 다음과 같은 것들이 있다.

  1. 일반 사용자: 타 플랫폼 포팅도 좀 해 달라.
  2. 일반 사용자: 요런 요런 상황에서 외부 모듈이 제대로 동작하지 않는다. 심하면 뻑나기까지 한다.
  3. 좀 컴덕후 기질이 있는 분들: 오픈소스화해 달라.

그런데 잘 알다시피 이것들은 모두 나로서는 전혀 현실성이 없으며, 예측 가능한 미래에 가능하지 않은 것들이다.

1. 리눅스, 맥 OS, 심지어 안드로이드까지 하나씩 골고루 다 요청을 받았었다. 특히 안드로이드는 그냥 화면 터치만 지원하는 게 아니라 외부 키보드를 연결할 수도 있다. 그렇기 때문에 PC 키보드 지향 입력 시스템인 내 프로그램도 이제 충분히 진입할 여지가 있다.
하지만 알다시피 <날개셋> 한글 입력기는 여러 플랫폼을 지원하는 프로그램이 아니라 반대로 단일 플랫폼에서 여러 구현체(편집기, 외부 모듈, 입력 패드)를 제공할 정도로 Windows에만 특화돼 있다. 한 플랫폼에 올인하면서 입력 기능 연구만 하기에도 본인은 시간이 부족하다. 포팅은 나 혼자서 할 수 있는 일이 아니다.

2. 이런 신고는 십중팔구가 내 자리에서 재연이 안 되는 것들이다. 내 프로그램도 외부 모듈의 짬밥이 이미 10년 가까이 돼 가는데, 기본적인 안정성은 이미 충분히 확보했다. 한글 입력이 전혀 안 되거나 아예 crash가 발생할 정도의 치명적인 문제는 내 프로그램 단독이 아니라 같이 돌아가는 백신이나 보안 프로그램과의 충돌 때문에 발생한다. 그리고 본인은 백신 같은 거 전혀 안 쓰는 사람이다.
내 프로그램이 디지털 서명이 된 채로 배포된다면 이런 문제가 더 줄어들 수 있겠지만 이 역시 아마추어 개인 개발자 차원에서 가능한 일은 아니다. 디지털 서명을 발급받으려면 돈이 드는 건 둘째치고라도 신원 보증을 위해 사업자 등록증 같은 것도 있어야 한다. =_=;;

3. 전에도 한번 입장을 밝힌 바 있지만, 무슨 전세계 오픈소스 진영의 해커 덕후들이 다 한글과 세벌식 자판을 쓰기라도 하지 않는 이상, 오픈소스화한다고 해서 누가 내 프로그램을 타 OS로 짠 포팅해 준다는 보장도 없다. 또한 내 노력에 대한 보상이 돌아오는 것도 아니다. 명예 보상쯤이야 지금 같은 클로우즈드 소스 체계에서도 이미 충분히 받고 있다.
내 프로그램은 심하게 갈라파고스화된 1인 독재 체제에서 폐쇄적으로 개발되고 있긴 하지만, 현실적으로는 이게 최선의 조치이다.

Posted by 사무엘

2016/10/08 08:33 2016/10/08 08:33
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1281

보다시피 요즘 운동을 빙자한 등산과 여행을 많이 다니느라 올해 상반기엔 프로그램 개발이 많이 더뎠다. 그래서 이번엔 4개월이라는 시간 동안에 버전을 0.1밖에 못 올렸다.
그 와중에도 개발 아이디어는 계속 떠올라서.. 8.x 중후반 정도까지 갈 것 같던 버전업 이정표가 9.0까지는 너끈히 갈 지경이 됐다. 이게 불행인지 다행인지.. 참 총체적인 난국이구나.

입력기와 타자연습의 변화 사항은 지난달에 공지한 것 그대로이고 더 변한 게 없다. 그러니 이전 글을 참고하면 된다. 이벤트 처리 수식은 글쇠배열의 추가 옵션으로 이렇게 깔끔하게 구현됐다. 옵션 3개밖에 없던 대화상자가 옵션이 8개로 늘면서 덩치가 제법 두툼해졌다.

사용자 삽입 이미지

그러니 여기서는 이벤트들 중 "문자 연속 입력 단절 감지하기"라는 개념에 대해서만 추가 설명을 좀 하겠다.

<날개셋> 한글 입력기는 지금까지 전통적으로 조합 상태 여부에 따라서 동일한 글쇠가 서로 다른 문자를 입력하거나(T변수), Bksp가 서로 다른 단위로 한글을 지우는(글자 or 낱자) 것을 지원했다.
그런데 이번 8.5에서는 이에 덧붙여, 굳이 한글이 아니더라도 일명 '타이핑'이라고 불리는 연속된 문자열 입력을 시작했는지, 아니면 그게 단절됐는지 그 타이밍을 알 수 있게 했다. 이것은 굉장히 의미심장한 새로운 기능이다.

연속 입력의 단절은 마우스 클릭이나 화살표 키로 cursor의 위치가 일괄 변경됐을 때, 윈도우의 키보드 포커스가 바뀌었을 때 같은 외부 요인에 의해 발생한다. 텍스트 에디터/워드 프로세서들은 undo도 연속된 문자열 입력은 한번에 없애 버리지만, 이런 단절이 일어나면 보통 undo 단위를 분리한다.
그러니 연속 입력이라는 건 이 undo 단위와도 완전히 같지는 않지만 얼추 비슷한 개념이다. 또한, 한글이 입력(=조합) 중이라면 응당 문자 연속 입력 중이지만, 문자 연속 입력 중이라고 해서 반드시 한글 조합 중인 것은 아닌 것으로 관계가 성립한다.

8.5에서는 Backspace 동작방식 설정 대화상자가 아래와 같이 바뀌었다. 제1동작과 제2동작을 세로로 배열하던 걸 가로 형태로 바꿨기 때문에 대화상자가 예전보다 좀 커졌다.

사용자 삽입 이미지

이번에 새로 추가된 기능은 '연속 입력 상태 여부'이다.
이전 버전까지는 오로지 '한글 조합 중 여부'에 따라서 제1동작(조합 중일 때)과 제2동작(그렇지 않을 때)을 구분했다. 거기에다가 '한 번 정해진 동작을 계속 적용'하는 옵션 하나만이 지원되었다. 이 옵션을 켜면 1과 2 중 한번 정해진 동작이 Backspace를 연타하는 동안 계속 유지되었고, 그렇지 않으면 이전 Backspace의 결과로 인해 한글 조합 여부가 달라지기만 해도 동작 방식이 바뀌었다.

그런데 상태 판단 기준을 '연속 입력 상태 여부'로 바꾸면, 조합 상태를 막론하고 연속 입력 중일 때는 제1동작이 선택되고, 그렇지 않으면 제2동작이 선택된다. 굳이 Backspace만을 연타하고 있지 않아도, 당장 한글을 조합 중이지 않아도 타이핑 중이라면 낱자 단위로 지우고 달라붙기 기능 같은 걸 쓰고 싶다면 이 기능이 굉장히 유용하게 쓰일 것이다. 즉, 한 Backspace 동작의 지속성은 '연속 입력 상태 여부'가 가장 길고, 그 다음이 '조합 여부 + 연타'이며 제일 짧은 건 그냥 '조합 여부' 옵션인 것이다.

그럼 이 '연속 입력 상태' 정보를 Backspace에서만 활용 가능한가 하면 물론 그렇지 않다. 지우기뿐만 아니라 입력에서도 활용 가능하다.
다만, 연속 입력 상태라는 아무래도 한 글자 입력이라는 단위를 초월하는 영역의 정보이다. 그렇기 때문에 이건 <날개셋> 한글 입력기를 사용하는 구현체가 공급해 주지, 한글 입력기가 직접 관리하고 있지는 않는다.

글쇠배열 수식에서 T 변수는 "지금이 조합 중인가?"를 나타내는데, 그런 것처럼 "지금이 연속입력 상태인가?" 같은 정보가 변수로 따로 주어지지는 않는다. 단지, 연속입력 단절이 발생했을 때 이벤트가 발생하고, 그 이벤트 때 특정 수식을 실행시킬 수 있다. 여기서 뭔가 사용자 변수(소문자)의 값을 변화시켜서 그 값의 변화를 감지함으로써 연속입력 단절을 간접적으로 알 수 있다. 이 수식은 글쇠배열의 추가 옵션 대화상자에서 설정 가능하다.

세벌식 글쇠배열과 관련해서 내가 당장 머리에 떠오르는 활용 방법은 최종 배열에 있는 쉼표와 마침표이다.
쉼표와 마침표는 평소에 문장 부호로 많이 쓰이지만 자리수 구분이나 소수점 때문에 숫자 입력 중에도 많이 쓰인다. 그렇기 때문에 Shift를 누른 상태에서도 계속 그대로 입력 가능한 게 좋다. 하지만 그런 제한된 경우 말고 평소에 쉼표와 마침표가 한 글쇠배열에 중복 등재되어 있는 것은 낭비이다.

마치 / 자리에 /와 ㅗ를 조건부로 모두 배당하는 것처럼, Shift+쉼표/마침표는 숫자를 연속 입력하는 중일 때에만 쉼표와 마침표가 찍히고, 나머지 상황에서는 다른 기호나 특수글쇠가 입력되게 할 수 있다. '공통 전처리'와 '연속 입력 단절 이벤트' 수식에다가는 어떤 소문자 변수 플래그를 끄고, 숫자가 입력된 직후에는 그 플래그를 켜게 해서 Shift+쉼표/마침표는 그 플래그의 존재 여부에 따라 서로 다른 문자가 입력되게 하면 된다.

이거 작업을 하면서 Backspace 설정을 저장하는 방식이 바뀌었다. 8.5에서 저장한 입력 설정은 8.4 등 이전 버전에서는 Backspace 옵션이 보존되어 있지 못할 것이다.
그럼 새 기능 소개는 이 정도로 마치고, 지금부터는 미래의 떡밥이랄까 썰이나 좀 나누고자 한다.

썰1. 제5의 빠른설정

<날개셋> 한글 입력기에 '빠른설정'으로는 두벌식/세벌식, 쿼티/드보락이라는 가장 널리 쓰이는 글쇠배열을 낱자 결합과 오토마타까지 한번에 세팅해 주는 '기본 글자판 설정'이라는 게 3.0 시절부터 존재했다. 그 뒤엔 복벌식· 신세벌식과 한글 로마자 입력 방식을 세팅해 주는 추가적인 빠른설정이 2006년에 나온 3.9에서 추가되어 이 형태가 지난 10년 간 유지돼 왔다. 그 뒤, 이번 8.5의 바로 다음 버전에서는 아주 중요한 빠른설정이 하나 더 추가될 예정이다.

내 프로그램 내부에서는 낱자 결합 규칙이라는 걸 오로지 A+B → C 한 형태만을 규정하고 있다. 그러나 한글 입력 방식에서 낱자 결합 규칙이라는 건 한 낱자를 만드는 미시적인 규칙과, 낱자와 낱자를 결합해서 겹낱자를 만드는 거시적인 규칙으로 구분되는 경우가 대부분이다.

PC에서야 키보드에 글쇠 수가 충분히 많으니 어지간한 낱자는 한 타 만에 바로 입력되고 미시적인 규칙은 별로 중요하지 않다. 그러나 글쇠 수가 매우 적은 모바일용 입력 방식에서는 ㅁ+가획 → ㅂ(나랏글), ㅇ+ㅇ → ㅁ(천지인) 같은 미시규칙이 제각각이고, 그 반면 거시규칙은 어느 입력 방식이나 차이가 없다. ㅂ이나 ㅅ 각각의 낱자를 어떤 방식으로 입력하건 겹받침 ㅄ의 입력은 가능해야 하며 ㅂ+ㅅ의 결합으로 ㅄ을 입력한다는 건 변함없다는 뜻이다.

그리고 도깨비불 현상은 미시규칙이 아니라 언제나 거시규칙 단위로 발생한다. ㅄ은 ㅂ과 ㅅ으로 분리되지만 ㅂ이 ㅁ과 가획으로 분리되지는 않으니 말이다. 그리고 휴대전화 입력기들은 backspace도 각각의 입력 단계가 스택에 저장되는 게 아니라 저 거시규칙 단위로 적용되는 편이다. 이런 미시/거시규칙 구분이 없이 정말 임의로 특수 도깨비불을 처리해야 하는 입력 방식은 한글 로마자 방식 정도밖에 없다(ch, l, x 등;;).

물론 <날개셋> 한글 입력기는 특수 도깨비불 규칙과 결합 축약 규칙들을 이용해 저런 동작들을 모두 구현할 수 있다. 그러나 사용자가 거시구조 단위에서 발생하는 파생 동작을 미시적으로 일일이 다 세팅을 해 줘야 한다. ㄶ, ㅀ의 입력을 구현하기 위해 나랏글이라면 중간의 ㄴ+ㅇ, ㄹ+ㅇ 같은 가상의 상태를 모두 넣어야 하고 그런 임시 낱자는 가상 낱자에다 한글 출력 치환까지 써서 표현하는 방법을 정해 줘야 한다. 일종의 노가다이다.

'초· 종성 공유 낱자 결합 규칙' 옵션을 쓰면 초성에는 미시규칙만 존재하고 종성에는 이를 바탕으로 최대 2단계의 거시규칙이 존재하는 일종의 'special case'에만 한해서 위의 작업들을 모두 자동화할 수 있다. 현대 한글을 입력하는 대부분의 휴대전화 입력 방식들이 이 기능의 혜택을 입을 수 있다.

그러나 옛한글까지 동원되면 어떨까? 초성과 종성에 서로 다른 거시규칙이 적용돼야 하고 그 단계수도 3단계까지 있을 수 있는데 이건 답이 없다.
이럴 때 미시규칙으로부터 거시규칙을 곱한 product들을 자동으로 관리하고 가상 낱자, 특수 도깨비불, 낱자 축약, 다단계 낱자 분리 등의 규칙들을 임시 낱자까지 감안하여 일관되게 자동으로 생성해 주는 것이 제5의 빠른설정이 하는 일이다.

제5의 빠른설정은 종성을 입력하는 중에 종성에 존재하지 않는 초성을 입력하려는 시도가 감지됐을 때(예: 옛한글의 정치음· 치두음) 이것을 종성에다 임시로 표현하거나 아니면 초성으로 옮겨 준다.
그리고 '허용 한글 범위' 제약에 걸리지만 중간 과정에서 불가피하게 입력되는 글자들을 자동으로 찾아 주며(예: '썅'을 입력하는 과정에서 '쌰'를 불가피하게 입력해야 하므로),
종성-초성 음절간 연속입력이 불가능한 경우는 말할 것도 없고 미시결합과 거시결합이 충돌하는 경우를 모두 찾아 준다(예: 천지인에서 ㅝ와 ㆌ는 입력 순서가 동일하기 때문에 충돌함)

그야말로 <날개셋> 한글 입력기가 지금까지 꾸준히 추가해 온 복잡한 고급 기능들을 총괄제어하는 끝판왕이 될 것이다.

썰2. 한자의 추가 지원 가능성

말이 나왔으니 말인데..
<날개셋> 한글 입력기는 공식적으로 유니코드의 BMP(기본 외국어 평면) 영역에 있는 28000여 자의 한자에 대해서 독음과 부수에 의한 입력을 지원한다. 한중일 통합 한자, 호환용 한자, 그리고 확장 A까지이다. 그 이상 확장 B부터는 지원하지 않고 있다.

물론 유니코드에 등록된 모든 한자들은 부수, 획수, 음 같은 기본적인 신상 정보가 Unihan이라는 이름으로 인터넷에 공개돼 있기 때문에 소프트웨어 개발자들이 이를 활용 가능하다. 그러나 <날개셋> 한글 입력기에서 유니코드의 모든 한자들을 그렇게 지원하는 것은 현실적으로 쉽지 않으며, 그래야만 할 필요도 없다.

그도 그럴 것이 확장 B부터는 코드 번호가 16비트 범위를 초과하는 surrogate 영역에 있기 때문이다. 이것까지 받아들이려면 한자 처리와 관련해서 16비트 크기를 전제하고 만들어진 파일 구조나 API를 여러 군데 확장해야 한다. 단순히 데이터만 추가로 집어넣어 주면 되는 게 아니라는 뜻이다.

그런데 그 확장 작업이 꼭 필요할 정도로 명분과 가성비가 성립하느냐 하면 그렇지 않다. 내 프로그램은 엄연히 중국어 입력기가 아니라 한글 입력기이고, 한국어 문화권에서는 이미 있는 BMP 영역의 확장 한자도 일상생활에서 거의 쓸 일이 없기 때문이다.
괜히 쓸데없이 한자 후보 목록만 복잡하게 만들고 목록을 불러오는 시간을 잡아먹는다고, 평상시에는 이미 있는 것조차도 오히려 숨기고 4888자 상용 한자만 불러오게 하는 옵션이 따로 있을 정도이다.

독음 입력의 경우 확장 B까지 추가되면 '가, 이, 사' 같은 음은 정말 헬게이트 수준으로 딸려 나오는 한자 후보가 너무 많아질 것이고, 무엇보다도 이런 한자들의 한국어 한자음은 누가 무슨 근거로 제정하느냐 하는 문제가 생긴다. 본인은 이와 관련된 자료를 지금까지 접하지 못했다. 이제 surrogate에 있는 한자들은 현대 중국어에서 막 쓰인다기보다는 그냥 옛 문헌에서나 아주 가끔 등장한 레어템 벽자(僻字)들이거나, 아니면 어디서 인명용으로 인위로 만들어진 듣보잡 글자들이 아닐까 생각도 한다.

다만, 한글 독음은 그렇다 치더라도 '부수로 한자 입력' 기능은 그래도 확장 B의 모든 한자를 입력할 수 있으면 좋긴 하겠다는 생각을 한다. 물론 이건 언제까지나 '한글' 입력과 관련된 다른 기능들이 모두 구현되고 완성된 뒤에나 해 볼 만한 생각이다. 우선순위가 아주 낮은 희망사항일 뿐이다.

한자는 현재 전세계에서 현역으로 쓰이고 있는 문자들 중 유일한 표의/표어문자이며, 정말 다른 문자들은 엄두도 못 낼 엄청난 양의 글자 수를 자랑하고 있다. 자세히 뜯어 보면 한자도 정사각형 안에서 뭔가 심오· 오묘한 제자 원리를 갖추긴 한 듯하지만, 근본적으로 배우기가 너무 어렵고 숫자로 치면 아라비아 숫자가 아니라 로마 숫자 같은 접근을 한 문자이다.
문자라는 게 정해진 유한한 틀과 체계가 없이 중구난방으로 임의 생성이 가능하다면 그건 엄밀히 말해 문자가 아니라 아직 그림의 범주를 못 벗어난 상태가 아니겠는가? 문자표에서 끝도 없이 펼쳐져 있는 한중일 통합 한자 리스트를 보면.. 뭔가 참 막막하다는 느낌이 든다.

썰3. 파일 포맷이 또 바뀐다면?

<날개셋> 한글 입력기가 현재 사용하는 입력 설정 파일 포맷은 2008년에 나온 5.0 버전 때 큰 틀이 잡혀서 지금까지 이어지고 있다. 3.0 방식이 나온 이후로 4년 만에 바뀐 것이다.
이 포맷은 압축을 하지는 않지만(어차피 무슨 이미지나 문서 포맷도 아니고 파일 크기가 굉장히 작음..) 날개셋문자 수식 같은 정보들을 최대한 조밀하게 기록하고 나름 확장성도 생각해서 설계되었다. 하지만 긴 세월이 흐르면서 새로운 chunk들이 덕지덕지 추가되면서 내부 구조가 좀 지저분해져 있긴 하다.

유니코드에 한글 자모가 더 추가되어서 내부 자모 순서가 재조정되는 이변이라도 발생하지 않으면 이 파일 포맷이 가까운 미래에 또 바뀔 일은 매우 희박하다.
만약 파일 포맷을 바꾸게 되면, 그때는 지저분한 chunk들을 정리하고 다음 사항을 반영하려 한다.

첫째, 내부에 저장되는 데이터 중 (1) 한글 입력기의 동작을 실제로 바꾸는 설정/옵션과, (2) 동작에 영향을 주지는 않지만 사용자에게 표시되는 데이터(후보 설명문 같은), (3) 제어판을 열지 않은 이상 사용자에게 전혀 보이지 않는 단순 주석 데이터(오토마타 상태 설명문 같은) 영역을 더 엄격하게 구분해서 필요하다면 (2)나 (3)은 손쉽게 생략 가능하게 할 것이다.

둘째, 이때쯤 수식에 ++와 -- 단항 연산자를 추가해 넣을 의향이 있다. C언어가 제공하는 것처럼 전위형과 후위형 모두 말이다. <날개셋> 한글 입력기의 수식은 C언어 스타일이지만 이런 단항 증가/감소 연산자를 현재 지원하지 않기 때문이다.
이 연산자가 제공되지 않은 이유는.. 단항 연산자는 프로그래밍에서 반복문을 구현할 때 사실 가장 많이 쓰이는데 내 프로그램의 수식은 그렇게 프로그래밍까지 가능한 환경이 아니기 때문이다. 그리고 사용자 변수라 하더라도 한도 끝도 없이 1씩 증가/감소시키는 것보다는 a=(a+1)%N처럼 순환을 전제로 하는 증가가 더 많이 쓰이기 때문이다. 이런 여건을 감안했을 때 ++와 -- 연산자는 딱히 유용하지 않다고 판단되어서 넣지 않았다.

사실, 먼 옛날에는 +=, -= 같은 합성 대입 연산자조차 지원하지 않았다가 지난 4.4 버전에서 10종이 대거 추가되었다. 가감승제 4, 나머지 1, 비트 3 (and or xor), 비트 좌우 이동 2 이렇게 총 10종류이다.
내 프로그램은 내부적으로 연산자의 식별 번호를 우선순위 순으로 부여하고 있는데 새로 추가된 연산자들은 메모리에 저장되는 코드값과 디스크에 이미 저장된 코드값이 달라서 번거롭게 보정을 해 줘야 했다. 마치 문자의 코드값과 사전 배열 순서가 동일하지 않게 되는 것처럼 말이다.

3.x 파일 포맷에서는 합성 대입 연산자들이 나중에 추가된 관계로 그런 보정이 존재했지만, 5.0에서 파일 포맷이 바뀔 때 연산자 저장 방식을 동기화시켰다. 지금 또 연산자가 추가되면 나중에 파일 포맷이 바뀔 때 새로운 순서가 반영될 것이다. ++와 --는 고려 대상이긴 하지만 위에서 언급한 이유도 있고 해서 우선순위가 막 높지는 않다.

썰4. 게임 체계의 개편

예전에 말한 적이 있나 모르겠는데.. 장기적으로는 현재 타자연습에 있는 게임도 체계를 크게 고치려 생각 중이다.
방어력 업그레이드를 없애고, 둠/퀘이크의 아머 내지 스타크래프트의 실드 같은 보조 맷집 정도만 넣지, HP와 관련하여 그 이상 더 복잡한 다단계 체계를 두지는 않을 것이다. 체력을 100 이상으로 비정상적으로 많이 비축해 놓을 수 없게 할 것이다.

그 대신 체력 보충 바이러스가 더 자주 나오고 위력이 강해진다. 한 번만 받아도 어느 주인공이든 전체 체력의 절반이나 전부가 곧장 회복된다. 어려운 레벨에서는 죽기 직전이 됐다가 바이러스 한 방 먹고 살아나는 스릴이랄까 '들쭉날쭉' 기복이 더 커진다. 이를 위해 어쩌면 레벨의 난이도를 지금보다 더 낮출 수도 있다.

현재의 게임 체계는 레벨 1부터 시작해서 체력과 방어력 업그레이드를 무슨 경험치처럼 채워야만 상위 레벨에서 버티기가 더 수월해지는 구조이다. 이걸 타파하려 한다.
주인공들 중 '한별'은 오타 페널티가 있는 대신 저렇게 맷집을 축적하는 게 가장 유리한 주인공이었다. 그 메리트가 없어지는 대신, 점수가 가장 높다거나 다른 방법으로 보상을 줄 생각이다.

한별은 어려운 대신에 잘 다루면 가장 강력한 주인공이고, 미르는 오타를 내도 되는 대신에 다른 페널티가 큰 주인공, 그리고 아름은 그 중간.. 이 구도는 변함없이 유지된다.
그런데 떨어지는 단어를 쳐서 없애는 게임에서 현실적인 변수는 저런 타자의 용이성과 체력 맷집밖에 없는데.. 체력 맷집 체계를 단순화· 평준화시키고 나니 다른 방법으로 주인공별 차별화를 어떻게 시킬지가 고민이다.
현재로서는 머리가 아파서 구상 단계에 머무르고 있다. 아이고~ =_=;;

Posted by 사무엘

2016/06/15 08:31 2016/06/15 08:31
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1238

다음 버전 개발 근황

<날개셋> 한글 입력기 8.4의 다음 버전은 8.5이다. 6월 말쯤에 나올 예정이다. 아울러, 타자연습도 3.5가 나올 예정이다.

8.5의 변화 사항들은 대부분 GUI 등 사소한 것들이다. 그러나 예전보다 센스 있게 동작하도록 기능이 추가되거나 변경된 건 있어도, 지난 8.4에서 뭔가 크게 잘못 동작하던 것이 바로잡혔다거나 버그가 고쳐진 것은 없다. 그만큼 8.4는 완성도 높게 잘 만들어졌으며 <날개셋> 한글 입력기도 '더 고칠 게 없는' 안정화 고정 단계에 근접한 듯하다.

8.5의 존재 의미라 할 수 있고 한글 입력 엔진 차원에서 바뀐 유일한 과업은 바로 '이벤트 핸들러'의 구현이다. 사실, 8.4에서 들어가려 했으나 이론 검증과 확신이 서지 않아서 차마 마무리를 못 하고 한 버전 더 거쳐 가게 됐다.
입력 스키마(현재 사용 중인 놈 한정)와 보조 입력 도구는 한글 입력 엔진으로부터 다음과 같은 상황에서 7종류의 이벤트를 받아서 이때 자신만의 처리를 할 수 있다. 주로 사용자(소문자 a~z) 변수를 초기화하는 수식이 실행된다.

(1) 시스템: <날개셋> 한글 입력기를 사용하는 프로그램 전체가 활성/비활성화됐을 때. 그리고 외부 모듈의 경우, 해당 UI 스레드 차원에서 IME가 날개셋으로 바뀌었거나 해제됐을 때. on/off 경우에 모두 호출된다. 단, 입력 패드는 언제나 시스템 차원에서 global하게 구동 중이므로 이 이벤트를 따로 보내지 않는다.

(2) 포커스: 한 프로그램 안에서 <날개셋> 한글 입력기를 사용하는 창의 포커스가 여기서 딴 데로 바뀌었을 때. 그리고 외부 모듈의 경우 창 포커스는 여전하더라도 내부적으로 사용하는 컨텍스트가 바뀌었을 때(HIMC). 역시 on/off 때 모두 호출된다.
포커스/컨텍스트가 바뀌었으며 잃었다가 얻었다는 사실 자체만 알 수 있지, 구체적으로 그 값을 구분해서 인식할 수 있지는 않다.

(3) 입력 항목(글쇠배열) 전환: 원래 있다가 교체되는 놈(off)과 새로 지정되는 놈(on)이 모두 이벤트를 받는다. 또한, 제어판을 구동하여 입력 설정이 바뀐 뒤에도 디폴트로 지정된 입력 항목은 처음에 on 이벤트를 받는 게 보장된다.
보조 입력 도구에는 요런 통지를 받는 게 이미 있다. 그래서 '화면 키보드' 도구가 지금 사용 중인 글쇠배열을 실시간으로 업데이트 해서 표시해 준다.

(4) 외부에 의한 조합 강제 종료: 한글 입력 중에 마우스 클릭, 포커스 변경, 우리 입력 스키마가 처리하지 않는 글쇠 등의 이유로 조합이 종료되었을 때 이벤트를 받는다. on/off 개념은 없고 그냥 단일.

(5) 문자 연속 입력 단절: 조합 강제 종료와 비슷하지만 이와 완전히 동일하지는 않은 개념이다. 굳이 조합을 만들지 않더라도 문자를 계속 입력하거나 bksp 하고 있었는데 갑자기 비문자 글쇠나 마우스 클릭, 포커스 변경 등이 감지되면 이 이벤트가 한번 날아온다.

지금도 "bksp 연타 시 한번 정해진 동작을 계속 적용" 옵션이 이 이벤트 비슷한 개념을 사용하고 있다. 그런데 이를 개념적으로 더 확장하여, 굳이 한글 조합 중일 때가 아니라 연속 입력 중일 때에 '낱자 단위로', 연속 입력이 끊어졌을 때는 '글자 단위로' 한글을 지우도록 할 수도 있게 했다.

(6) 변수값 변화: 입력 스키마의 글쇠배열 내지 문자 생성기의 오토마타에서 수식 계산으로 인해 변수값이 바뀐 것을 보조 입력 도구가 알 수 있게 한다.
그래서 보조 입력 도구를 이용해 변수값 디버거를 만들 수 있게 된다. 그리고 '화면 키보드' 도구가 아예 context-sensitive하게 지금 입력되는 문자를 화면에다 업데이트 가능하게 된다. 즉, 복벌식 입력기라면 내부 변수값에 따라 두벌/세벌 모드가 됐을 때 글쇠배열 전체가 두벌식이나 세벌식 모양으로 바뀐다.

(7) 타이머: 지금은 천지인 모바일 입력기처럼 특정 상황에서 일정 시간이 경과했을 때 조합을 강제 종료시키는 기능을 구현할 때 타이머가 제한적으로 지원되고 있다. 타이머는 그 기능을 더 일반화해서 겉보기로 조합은 유지하더라도 오토마타의 내부 상태만 바꾸는 것, 임의의 글자를 입력시키는 것, 타이머를 1회가 아니라 계속 동작시키는 등 더 다양한 처리를 할 수 있게 된다.

이렇듯, 통합적인 이벤트 핸들러는 한글 입력기의 아키텍처에서 매우 중요한 기능이다. 오랫동안 필요성만 인지하고 있었을 뿐 작업을 할 엄두를 못 내고 있던 곳에 대대적인 수정이 가해졌다. 이 기능 하나에다가 다른 UI 쪽의 변화 사항들을 합치면 +0.1 버전업은 충분한 가치와 의미를 지닌다.
이벤트 핸들러 수식을 지정하는 UI는 글쇠배열의 추가 옵션을 지정하는 대화상자에 들어갈 예정이다. 어차피 글쇠배열 내부에서 쓰이는 변수들을 초기화하는 수식이 들어갈 테니 말이다.

이것 말고 가볍게 읽을 만한 새 버전 변화 사항들은 다음과 같다. 8.5가 어서 완성됐으면 좋겠다.

1. 한글 낱자 종류 변환에 filler를 안 집어넣는 옵션

텍스트 필터 중에 '한글 낱자 종류 바꾸기'라는 게 있는데, 이건 호환용 한글 자모(U+31??)와 표준 한글 자모(U+11???) 사이를 변환하는 나름 중요한 기능이다.
표준 한글 자모에는 정규화 규칙이라는 게 적용되기 때문에 자음 하나, 모음 하나만 있을 때에도 초/중성의 빈 자리에는 채움 문자(filler)가 꼭꼭 들어간다. 하지만 채움 문자 없이 호환용 자모를 문자 그대로 표준 한글 자모로 일대일 치환만 해 주는 옵션이 이번 버전에서 추가되었다.

이 옵션을 사용하면 정규화 규칙에 어긋나는 문자열을 생성할 수도 있지만, 한편으로 "ㅎㆍㄴ" 같은 풀어 쓴 호환용 자모로부터 모아 쓴 옛한글을 곧바로 만들어 낼 수 있다. 채움 문자가 없으니 각 자모가 그대로 한 글자를 구성하게 됐기 때문이다.

2. 외부 모듈에서 문자표 대화상자의 동작 방식 변경

<날개셋> 편집기와 외부 모듈은 모두 문자를 입력하는 프로그램이니 키보드에 없는 특수문자를 입력하는 '문자표' 기능이 있다.
편집기야 내부의 모든 데이터 입출력이 100% 자가통제가 가능하기 때문에 문제될 게 없지만 외부 모듈은 문자표로부터 받은 문자를 응용 프로그램에서 보내는 것만 가능하고 그 프로그램이 실제로 문자를 접수하는지를 완벽하게 알 수는 없다.

그래서 문자표라는 대화상자가 키보드 포커스를 얻어 있는 상태에서 본문 창에다가 계속해서 문자를 보내는 게 기술적으로 가능한 프로그램도 있고 가능하지 않은 프로그램도 있었다. 즉, 외부 모듈에서 문자표 대화상자는 사실상 반쪽짜리 기능이었던 것이다. 텍스트 필터가 TSF A급에서만 사용 가능한 반쪽짜리 기능인 것처럼 말이다. 이런 이유로 인해, 이 버튼은 프로그램을 처음 설치했을 때는 기본적으로 도구모음줄에 나타나 있지도 않았다.

이 점을 감안하여 이번 버전에서는 외부 모듈의 문자표의 동작 방식을 바꿨다. 연속 입력 기능을 희생시켰다. 엔터를 누르면 문자표 대화상자는 곧장 닫혀 버린다.
그 대신 글자 단 하나를 입력하더라도 그 기능만은 IME, TSF A/B 등을 가리지 않고, 또 BMP와 surrogate를 가리지 않고 모든 프로그램에서 제대로 동작하게 정책을 바꿨다. 동작을 차라리 이렇게 바꿔 버릴까 오랫동안 고민했는데 결국 이제야 결정을 내렸다.

문자표를 꺼내 놓은 채로 여러 문자를 입력하고 싶으면, 이런 대화상자가 아니라 '보조 입력 도구' 중 하나인 문자표를 사용하면 된다. 얘는 반대로 문자표 내부에서 키보드 조작을 할 수는 없지만, 키보드 포커스를 차지하지 않기 때문에 창이 떠 있는 상태에서도 다른 프로그램의 UI에 영향을 주지 않는 게 가능하다.

3. 문자표에 Ctrl+클릭

요즘은 그냥 클릭에 뭔가 2% 부족한 면모가 있을 때 Ctrl+클릭을 추가하는 게 새로운 UI 트렌드인 것 같다.
후보 데이터를 추가할 때 Ctrl+클릭을 하면 입력된 문자열이 각각의 글자 단위로 따로 후보로 추가된다. 그리고 낱자 결합 규칙에서도 Ctrl+클릭을 하면 추가 후에 입력란의 값과 키보드 포커스가 그냥 클릭과는 다르게 바뀐다.
외부 모듈의 후보 목록에는 Ctrl+클릭(Ctrl+엔터 포함)뿐만 아니라 Shift+클릭도 있어서 단순히 한자 변환뿐만 아니라 한글(한자) 또는 한자(한글) 형태를 지정할 수도 있다.

이와 같은 맥락에서, 문자표에도 Ctrl+클릭 동작을 추가했다.
그냥 '추가'를 누르면 선택된 문자가 본문에 삽입되고 대화상자가 그대로 남아 있는 반면, Ctrl+클릭을 하면 이제 문자가 삽입됨과 동시에 대화상자가 닫히게 했다. 이 기능이 있으니 정말 편하다. 물론 애초부터 연속 입력이 가능한 편집기의 문자표 같은 곳에서 말이다.

4. 글자가 많이 존재하는 부수는 진하게 표시 (부수로 한자 입력 기능)

오늘날 수만 자에 달하는 한자들을 분류하는 데는 부수라는 게 쓰인다. 부수는 총 214개가 존재하는데, 한자에 식견이 있는 분이라면 다 아시겠지만 이 부수들이 골고루 쓰이는 게 아니다. 분포가 전혀 균일하지 않으며, 소수의 특정 부수에만 쏠림이 매우 심하다.

예를 들어 요일을 나타내는 한자들(火, 水, 木, 金 같은. 단 月은 제외), 人, 車, 言, 鳥처럼 만만하고 보편적인 뜻을 가진 부수에는 한자가 수백~심지어 1000개가 넘게 들어있고 새로운 글자가 또 만들어지기도 한다. 그러나 匕, 至, 臣, 牙, 首, 父, 龜, 鼠 같은 나머지 대부분의 부수들은 듣보잡이다. 그 제부수자 자체는 首, 父, 高, 非, 長처럼 아주 기초적이고 친숙한 반면, 거기서 파생된 한자는 거의 없는 경우도 있다.

이 점을 감안하여, 다음 버전에서는 "부수로 한자 입력" 도구에 한자가 매우 많이 들어있는 상위 10% 정도의 부수는 약간 진하게 표시해서 사용자의 눈에 미묘하게 더 잘 띄게 했다.
이것도 시각 피드백을 어떻게 줄지 무척 고민했다. 색깔을 달리 하는 건 제일 간단하긴 하지만, 실험 결과가 좋지 않아서 관뒀다. 이미 색깔로 변별하는 다른 요인들도 있는데(한자의 등급, 현재 선택된 부수와 획수가 같은 부수) 거기에다 색깔 변화를 더 주면 비주얼이 너무 튀고 더 혼란스러워졌다.

그 다음으로 생각한 건, 글자 크기에 변화를 주는 것이었다. 하지만 이 역시 결과가 별로 좋지 않아서 최종적으로는 '볼드' 속성이 낙찰됐다. 요렇게 해 주니 딱 봤을 때 너무 튀지 않으면서도 자주 쓰이는 메이저 부수만 빨리 찾는 데 확실히 도움이 된다. 나만 그렇게 생각하는 게 아니었으면 좋겠다만..;;

5. 타자연습: 계정 import/export, 그리고 파일 기반 custom 연습글

타자연습에는 로그인 화면에서 계정 파일을 다른 디렉터리로 내보내거나 거기서 계정 파일을 가져오는 import/export 기능을 추가했다.
단순한 파일 copy 기능에 지나지 않지만, 사용자 계정을 컴퓨터끼리 옮길 수 있게 하는 건 진작부터 필요했던 기능인데 이제야 도입됐다.
궁극적으로는 서버를 통한 동기화도 지원해야 할 텐데 그건 내 혼자 할 수 있는 일은 아니고..

그리고 거의 10년 가까이 유지되던 연습글 목록 관리 방식이 바뀌었다.
XML 파일 기반인 것은 변함없지만, 이것은 프로그램이 기본 제공하는 고정 붙박이 연습글에만 적용된다.
이전처럼 사용자가 XML 리스트를 직접 고치는 것은.. 이제는 더 권장되지 않는 지저분한 관행으로 deprecate됐다. 프로그램 UI에는 예전과 같은 '연습글 추가/삭제' 같은 버튼과 기능이 사라졌다.

그 대신, 사용자의 custom 연습글은 특정 디렉터리에다가 txt 파일들을 갖다 놓기만 하고 '새로 고침'을 누르면 거기에 있는 것들을 프로그램이 알아서 추가로 등록해 주는 형태로 바뀌었다. 하위 디렉터리가 있으면 물론 그것까지 알아서 찾기 때문에 재귀적인 트리 구조를 만들 수 있다. 디렉터리는 꾸러미, 파일은 연습글로 그대로 대응되는 거다.

custom 연습글은 크게 두 종류가 있다. (1) 이 컴퓨터를 사용하는 모든 사용자가 똑같이 공유하는 놈, 그리고 (2) 현재 사용자 계정에서만 보이는 놈.
(1)의 위치는 답정너로 고정돼 있다. "운영체제의 공용 문서\YmSoft\NgsType"이다. 여기에다가 txt 파일들을 심어 놓으면 <날개셋> 타자연습에서 어느 계정으로 로그인 하건, 아니 로그인하지 않고 익명으로 사용하더라도 연습글들을 볼 수 있다.

또한, 여기에 덧붙여 임의로 지정된 디렉터리를 하나 더 동일한 방식으로 수색하게 할 수 있다. 이 위치는 각 계정별로 달라질 수 있다.
기본 제공되는 보급 연습글은 맨 위에 표시되며 꾸러미가 예전처럼 자주색이다. 그러나 (1) 공용 custom 연습글은 꾸러미가 밝은 분홍색이며, (2) 개인용 custom 연습글은 꾸러미가 파란색이다.

"문장/글 연습" 탭에 가 있는 상태에서 '환경설정' 버튼을 누르면, 예전에는 '외형'과 '타자 연습'이라고 탭이 2개 있는 대화상자가 떴는데, 이제는 '추가 연습글'이라는 제3의 탭이 추가되었다. 여기에서 공용 연습글 디렉터리가 어디인지 정확한 경로를 확인하고 그 창을 탐색기로 열어 볼 수 있다. 그리고 개인 연습글 디렉터리는 위치도 사용자가 지정하고 탐색기로 여는 것도 가능하다. 이제 나만의 연습글을 추가하는 건 이런 식으로 하면 된다.

여담이지만, 이번 버전에서는 기본 제공되는 연습글들도 좀 현실화했다.
잉여도가 너무 높아 보이던 옛한글 연습글을 삭제하고, 성경도 잠언과 요한복음만 남겼다. 잠언은 '슬기로운 이야기' 카테고리에 있던 것을 '영적 생활'로 옮겼다.
우리말 우리글 카테고리에 있던 글들을 삭제하고 '한글 노래' 하나만 남겨서 '마음의 양식' 카테고리에다 옮겼다.
그래도 <날개셋> 타자연습은 안 창호 선생의 글과 김 성모 화백 어록, '어둠에다크에서'가 한 자리에 놓여 있는 타자 연습 프로그램이다. 제작자가 인터넷 병맛 개그를 좀 좋아하기 때문에..;;

* 그 밖에,

(1)
 <날개셋> 편집기는 상태 표시줄(status bar)에 있는 글자판(입력 항목)을 우클릭하면 글자판을 선택하는 메뉴가 나타난다. 그래서 한영 내지 Shift+Space 같은 단축글쇠를 안 누르고도 마우스로 입력 모드를 전환할 수 있다.
그 중 '빈 입력 스키마'는 아시다시피 <날개셋> 한글 입력기가 제공하는 특정 입력 모드가 아니라 그냥 운영체제가 제공하는 IME를 그대로 받아들여서 문자를 입력하는 모드이다.

빈 입력 스키마를 사용하고 있는 상태에서 이 메뉴를 통해 동일한 빈 입력 스키마를 또 선택하면 그때는 운영체제의 한영 상태를 전환하는 기능을 추가했다. 중국어나 일본어 IME를 사용하고 있다면 해당 언어의 자국 문자 모드와 영문 모드가 전환된다.

(2)
대화상자에서 리스트 박스의 아이템을 더블 클릭하면 그 아이템을 고치거나, 그걸 선택한 채로 '확인'을 바로 누르는 shortcut 동작이 수행되곤 한다. 그에 비해 라디오 버튼의 더블 클릭은 잘 알려져 있지 않지만, 이 역시 MS가 권장하는 UI 동작이다. 대표적인 예가 MS Office 프로그램에서 화면 확대 대화상자인데, 100, 200같은 퍼센트를 라디오 버튼으로 선택하고 그걸 더블 클릭하면 곧바로 대화상자가 종료된다.

<날개셋> 한글 입력기는 다음 버전부터 주요 UI에 라디오 버튼의 더블 클릭이 지원될 예정이다. 라디오 버튼의 선택이 해당 대화상자의 동작 방식이나 옵션을 거시적으로 결정하는 대화상자들이 그 대상이다. 대소문자 전환(전환 방식), 기본 입력기 빠른설정(사용할 글자판) 등등에서 아이템을 더블 클릭하는 것만으로 대화상자를 확인 종료할 수 있게 된다.

(3)
Windows의 한글 IME 지원 체계에는 좀 이상한 문제가 있다.
TSF를 응용 프로그램이 직접 지원하는 A급 환경 말고, 그냥 IME 호환 계층을 통해 지원하는 B급 환경에서는..
처음에 2글자 이상의 조합을 만들면 조합이 그냥 끊어져 버린다. 이건 이유는 모르겠지만 운영체제가 한글 IME에 대해서 거의 일부러 강요하는 동작이다. 9x/XP 시절, IME 모듈조차도 안 이랬는데 말이다.

이런 이유로 인해 TSF B급 프로그램에서는 한글 조합은 반드시 1글자짜리 호환용 한글 자모로 시작해야 하고, 2~3글자짜리로 정규화된 표준/옛한글 자모로 시작할 수 없다. 첫 타 이후에 다음 타로 인해 계속된 조합의 길이가 2글자 이상으로 가는 건 괜찮다.
이번 새 버전에서는 TSF B급 프로그램에서 2글자 이상의 조합을 만들려 해서 조합이 끊어졌다면 이를 감지해서 이 현상에 대한 간단한 안내 메시지와 도움말 링크를 표시하게 했다. 그래서 이건 설정 문제이지 프로그램의 버그가 아님을 사용자가 알 수 있게 했다.

(4)
좀 어이없는 실수이긴 한데..
드보락이라는 영문 글쇠배열을 만든 사람은 미국의 교육심리학자인 '어거스트 드보락' 박사이다. Dvorak Simplified Keyboard라는 이름으로 이 글쇠배열이 공표된 것은 1932년이고 특허를 얻은 것은 1936년이다.
하지만 지금까지 <날개셋> 한글 입력기의 빠른설정 UI와, 타자연습 도움말의 '세벌식과 드보락의 관계는?'에는 이게 '안톤 드보락이 1930년에 고안한 글쇠배열'이라고 잘못 소개되어 있었다.

이 사람의 이름은 체코의 작곡가 이름인 '안토닌 드보르작'과 매우 혼동되는 편인데, 그거 영향을 받은 것 같다.
우연히 간단한 구글링을 하다가 이 사실을 발견하고는 바로잡았다. <날개셋> 한글 입력기와 타자연습의 다음 버전에서 반영될 것이다.
이거 실수의 근원을 추적해 보니.. 어이없게도 아래아한글의 도움말이었다. 2007 버전만 해도 글자판 소개에서 드보락 설명을 보면 "쿼티 글자판의 단점을 보완하여 1930년 안톤 드보락 박사가 고안한 글자판"이라고 설명되어 있기 때문이다.

Posted by 사무엘

2016/05/21 08:24 2016/05/21 08:24
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1229

날개셋 한글 입력기 8.4

<날개셋> 한글 입력기 8.2가 나온 지 거의 4개월 만에 또 새 버전인 8.4가 나왔다.
이번 버전도 짬밥이 어디로 간 게 아니라 정말 많은 부분이 개선되고 중요한 기능들이 많이 추가되었으므로 많이 사용하시기 바란다.

API 구조의 변경으로 인해 타자연습도 3.45로 살짝 업데이트가 됐다.

1. 사용자 정의 후보 문자열에 @ 탈출문자 추가

지난 7.0 버전에서는 사용자 정의 후보 기능이 추가되었다. 덕분에 고급 입력기의 사용자 정의 조합이 아니라 일반적인 한글을 입력하고 있을 때도 한자 키를 눌렀을 때 나타나는 변환 문자들을 사용자가 임의로 정할 수 있게 되었으며, 원래 있던 한자 변환 기능과도 병용이 가능해졌다.

한자 후보에 대해서 한자의 훈과 음이 나오듯이 사용자 후보에 대해서도 사용자가 설명문을 기재할 수 있다. 그런데 어떤 문자에 대해서 들어갈 만한 설명 정보라는 게 뻔할 뻔 자인 경우가 많은 관계로, 이번 버전에서는 그 절차를 간편하게 해 주는 탈출문자를 추가했다. 후보 문자열이 딱 한 글자로만 구성되어 있다면 탈출문자를 사용할 수 있다. 기본 입력기의 사용자 정의 후보와 고급 입력기의 사용자 정의 후보에서 모두 동일하게 쓸 수 있다.

탈출문자는 @로 시작한다. @N은 이 문자의 유니코드 번호이다. 그리고 문자가 BMP 영역에 있는 경우, 문자의 유니코드 명칭을 나타내는 @C를 사용할 수 있다. 이건 내 프로그램이 아니라 운영체제로부터 얻어 오는 명칭이다.
다음으로 @H는 이 문자가 BMP 영역의 한자인 경우 훈과 음이다. @ 자체를 표현하려면 @@이라고 쓰면 된다.

사용자 정의 후보의 설명문과 관련하여 뭔가 2% 부족한 게 있다고 지금까지 생각해 왔는데 그걸 탈출문자를 통해서 해결하게 됐다.
그러면 이제 여러 후보들에 대해서 설명문을 획일적으로 [@N] @C/@H 이런 식으로 지정할 필요도 생기는데, 이것도 대화상자 UI 차원에서 가능해졌다. 후보 목록에서 1개 이상의 후보 문자열들을 선택한 후, 위의 ‘후보 문자열 입력란’은 비우고 설명문만 입력한 뒤 ‘추가’를 누르면 선택된 후보들의 설명문이 모두 동일하게 바뀐다.

2. Alt+=를 끄는 보정 기능 추가

지난 8.2에서는 시스템 계층에 ‘키보드 드라이버의 동작 보정’ 기능이 추가되어서 type 1 키보드에서도 오른쪽 Ctrl/Alt를 인식할 수 있으며 반대로 type 3에서도 Shift+Space와 한영을 구분해서 인식할 수 있게 되었다. 이번 버전에서는 그에 덧붙여 Alt+=도 전/반각이 아니라 있는 그대로 인식하는 기능이 추가되었다.

전통적으로 Windows의 한국어 키보드 드라이버는 Alt+=를 전/반각 전환 글쇠로 인식해 왔다. 하지만 오늘날은 이건 거의 안 쓰다시피 하는 잉여 기능이며, 오히려 자기도 모르는 사이에 저걸 누른 뒤에 알파벳과 숫자가 엉뚱하게 입력되어서 사용자를 놀라게 하는 경우가 많다.
이 보정 기능을 켜면 <날개셋> 외부 모듈에서 Alt+=가 눌려도 전/반각 전환을 하지 않게 만들 수 있으며, 편집기 같은 다른 구현체에서는 거기에다 아예 다른 기능을 배당할 수도 있게 된다.

단, 보정 기능은 언제나 택일 형태이기 때문에 이 기능을 기존 type 1/3 한영 관련 보정과 같이 사용할 수는 없다.

3. 다단계 입력 분리

두벌식 글자판에서 음절 경계에 도달했을 때 앞글자 종성과 뒷글자 초성을 구분하는 방법은 여러가지가 있다.
보통은 자음은 종성에 최대한 붙을 수 있는 데까지 결합시켰다가 안 되면 다음 글자로 넘어가고, 모음은 직전에 입력되었던 종성 한 타만 다음 글자의 초성으로 이동하는 '도깨비불 현상'을 일으킨다. 그것보다 더 세밀한 제어가 필요하다면 크게 다음과 같은 방법들을 사용하면 된다.

  • 특수 도깨비불(3.9에서): 중성이 입력되어 도깨비불 현상이 일어날 때, 종성 입력 순서와 무관하게 아무 종성과 초성으로 쪼개지게 한다. 한글 로마자 입력기에서 ch, l, x 같은 건 이걸로 구현하는 게 제일 무난하다.
  • 초· 종성 공유 낱자 결합(6.0에서): 종성을 2개의 초성을 합성하여 입력하는 구도로 만들어 준다. 낱자 결합 규칙을 훨씬 더 간단하게 만들어도 후속 처리를 프로그램이 알아서 해 주며, 도깨비불도 오른쪽 초성 덩어리 단위로 떼어서(치는 데 몇 타가 들었든) 해 주니 매우 편리하다. 휴대전화 입력 방식은 이걸로 구현하면 된다.
  • 조합 종료 타이머(6.0에서): 특정 오토마타 상태에서 일정 시간 이상 동안 타자를 안 하고 가만히 있으면 자동으로 조합이 끊긴다. 천지인 같은 입력 방식에서 '국가/구카' 구분을 위해 사용하면 된다.

그 뒤 이번 버전에서는 "다단계 입력 분리"라는 제4의 메커니즘이 추가되었다.
이것은 도깨비불과는 달리, 초중종 등 동일한 성분의 낱자가 계속 N-1단계까지 입력되었는데.. 제 N째 낱자가 기존 낱자와 결합이 불가능할 때, N만 다음 글자로 빼는 게 아니라 M<N을 만족하는 임의의 M~N단계의 낱자 결합을 몽땅 다음 글자로 옮기고 앞글자는 1~M-1단계까지만 남기는 역할을 한다.
쉽게 말해 ㄺ 다음에 ㅅ을 입력했는데 ㅩ으로 갈 수는 없을 때, ㄺ+ㅅ으로 있는 그대로 분리되는 게 아니라 느닷없이 ㄹ+ㄳ으로 가게도 해 준다.

도깨비불은 두벌식 종성이 입력된 상태에서 두벌식 "중성"이 입력되었고 이로써 오토마타가 0으로 바뀌었을 때 발생한다. 하지만 저건 초중종 같은 성분의 낱자가 입력됨으로써 낱자 결합이 65531이라는 낱자로 도달했을 때 발생한다. 조합 중인 낱자를 0으로 만드는 역할을 하는 65530에 이어 또 다른 특수 낱자가 추가된 것이다.

그런데 세벌식이나 '종성 두벌식'이 아니라 일반 두벌식 형태의 종성이 분리되었을 때는 다음 글자는 종성이 아니라 초성으로 바뀐다. 그렇기 때문에 다단계 입력 분리로 할 수 있는 일의 일부가 바로 도깨비불과 동일하지는 않지만 비슷한 형태의 '두벌식 음절 경계 구분'이 된 것이다. 개념적으로 종성과 다음 글자 초성을 동시에 결합시키는 날개셋문자와도 좀 비슷하나, 형태가 간편한 대신에 자유도가 그것만치 높지는 않다.

현대 한글에서 초성 ㅃㄸㅉ, 옛한글에도 정치음· 치두음 같은 건 초성에만 존재한다. 이걸 초성과 종성에 공통으로 존재하는 낱자의 결합으로 입력할 수 있는데 두벌식으로 종성을 결합하는 도중에 인위적인 음절 구분(조합 종료) 없이 자동으로 초성으로 넘어가는 형태로 입력하고 싶다면 딱 이 기능을 사용하면 된다.

예전 같았으면 '한글 출력 치환'을 이용해서, 여전히 조합이 끊어지지 않은 종성 상태이지만 겉보기로는 정치· 치두음 초성이라고 글자를 임시로 표시해야 했다. 그 뒤 모음이 입력됐을 때 특수 도깨비불 현상 같은 걸로 정치· 치두음 부분을 떼어냈겠지만 지금은 좀 더 직관적인 방법도 생겼다. 자세한 설명은 프로그램의 도움말에 나와 있다. 연속 입력 가능성 판별 기능도 다단계 입력 분리까지 감안해서 동작하도록 알고리즘이 수정되었다.

요건 원래 개발 계획에는 없던 아이디어였는데 꽤나 무겁고 중요한 기능이 되어 버렸다. 이런 기능이 지금까지 없었다. 예정에 없던 기능 때문에 한 달에 가까운 시간이 그냥 훅 가 버렸지만..ㅠㅠ 투자한 시간이 아깝지는 않다.

4. 허용 한글 범위 관련 처리

아무 한글이나 조합이 되지는 않게 하는 '허용 한글 제약'과 관련하여 여러 기능들이 추가· 강화됐다.
먼저, '다단계 입력 분리'가 이 기능과도 연계된다. 가령, '쌰'를 조합할 수 없는 'KS X 1001 완성형 제약'을 사용하고 있는데 ㅑ를 ㅏ+가획으로 입력해서 '쌰'를 만들려고 시도했다면.. '가획'만 넘어가는 게 아니라 "ㅏ+가획"이 한꺼번에 다음 글자로 넘어가게 할 수 있다. 이전까지는 그게 가능하지 않았기 때문에 이 상황에서 그냥 '싸'와 함께 조합이 중단돼 버리곤 했다.

65031 낱자 결합을 통해 일어나는 다단계 입력 분리와는 달리 저 분리는 별도의 옵션이 지정되어 있을 때만 수행된다. 그리고 앞의 분리는 A+B+C+D와 C+D가 모두 가능하다면 A부터 시작해서 최대한 많은 타수를 분리하는 반면, '허용 한글 제약' 관련 분리는 C+D처럼 최대한 적은 타수를 분리한다. 분리의 성격이 서로 다르기 때문이다.

단순히 낱자 결합 규칙이 더 존재하지 않아서 결합 불가일 때랑, 허용 한글 범위 제약에 걸려서 결합 불가일 때를 구분 인식이 가능해진 것은 예전 글에서 이미 언급했으므로 참고하시고..

끝으로, <날개셋> 한글 입력기가 제공하는 "문자열을 글자판 입력으로" 필터는 '허용 한글 범위 제약' 기능을 전혀 감안하지 않고 동작한다. 즉, '똠'이라는 문자를 조합할 수 없는 상태에서도 '똠'을 입력하는 순서를 구해 준다.
그 동작을 약간 변경하여, 이걸 부분적으로 감안하여 동작하게 로직을 바꿨다. 이제는 KS X 1001 제약이 적용된 상태에서는 '똠'은 입력할 수 없는 글자로 간주하여 입력 순서를 찾아 주지 않는다.

그러나 이 기능은 중간 과정에서 생성되는 모든 글자들을 일일이 체크하지는 않는다. 즉, '썅'은 중간의 '쌰'를 입력할 수 없음에도 불구하고 최종 결과물이 입력 가능하기 때문에 입력 순서를 찾아 준다.

5. Backspace 3과 4 지원

<날개셋> 한글 입력기는 한글 입력 과정에서 사용되는 Backspace와 후보(≒ 한자) 변환이라는 명령을 내부적으로 특수글쇠의 일종으로 취급한다. 그런데 그게 하나만 있는 게 아니라 각각 4종류씩 있다.

먼저 후보 변환의 경우, 지난 7.0 버전에서 4개의 용례가 완전히 정착했다. 1은 고정적으로 제공되는 한자 및 특수문자 변환이며 2와 3은 각각 입력기 계층에서 제공되는 내장 및 외장형 후보 변환이다. 4번은 편집기 계층에서 제공되는 공통 후보 변환이며 형태는 내장과 외장 어느 것이든 될 수 있다.
후보 변환 데이터의 성격에 따라(공통인가, 아니면 특정 입력 방식에 종속인가?) 원하는 변환 방식을 고를 수 있다. 그리고 어떤 단계에서 후보가 존재하지 않을 때 이전 단계로(1) 갈 것인지 다음 단계로(4) 갈 것인지 포워딩 방식도 지정할 수 있게 했다. 이런 식으로 후보 변환과 관련해서 생각할 수 있는 customization 방식을 모두 구현했다.

이번 버전에서는 후보 변환에 이어 Backspace에 대해서도 손을 봤다. 예전부터 Bksp 1은 통상적인 bksp 글쇠에 대응하고 Bksp 2는 Shift+bksp에 대응한다는 관행이 정착해 있었지만, 3과 4는 영역이 배당만 됐고 실제로 쓰이지 않았다.
이제는 Bksp 동작 방식에서 '자세히'를 누르면 1, 2뿐만 아니라 3, 4도 다 제각기 동작 옵션들을 지정할 수 있다. 그리고 아무 글쇠에나 Bksp 3/4를 뜻하는 C0|0x8A 또는 0x8B를 배당하면 그 옵션대로 Bksp가 동작한다.

원래 Backspace는 한글 입력기(IME 프로그램)와 응용 프로그램이 공용하는 글쇠이다. 한글을 조합하는 중일 때는 IME가 Bksp를 가로채지만, 조합 중이지 않고 앞 글자에 딱히 달라붙거나 할 필요도 없을 때에는 IME가 Bksp를 가로채지 않고 그냥 응용 프로그램으로 넘겨 준다. 그렇기 때문에 A나 1 같은 문자 글쇠에다가 Backspace 1 같은 걸 배당하면 평소에는 글자가 지워지는 게 아니라 A나 1이 입력되어 버린다. 앞 글자를 지우고 싶으면 이런 고수준의 Backspace n 특수글쇠를 배당하는 게 아니라, Backspace가 수행하는 저수준 동작인 '한 타 지우기, 마지막 단계의 낱자 전체 지우기, 입력 순서와 관계 없이 마지막 단계의 낱자 한 단계 지우기'를 배당하는 게 보통이다.

Backspace 3과 4는 저런 오동작이 없다. 언제나 글쇠를 가로채며, 구현체의 기술적인 한계로 인해 앞 글자를 건드릴 수 없을 때는 그냥 아무 동작 없이 가만히 있기만 한다. 입력기 차원에서 조합 바깥의 앞 글자를 직접 지울 수 없는 환경에서는 T ? C0|0x8A: KY|8 이렇게.. 한글을 조합하고 있을 때만 bksp 3, 아니면 수동으로 bksp 생성(응용 프로그램이 글자를 직접 지우게) 이렇게 bksp 기능을 혼용해도 된다. 이런 방식으로 bksp가 아닌 자리에 bksp의 기능을 독자적인 동작 옵션으로 온전히 이식이 가능하다.

6. 글쇠배열 편집 UI에 시각 피드백 추가

<날개셋> 한글 입력기는 잘 알다시피 기본 입력 스키마에 글쇠배열을 편집하는 기능이 있다. 그런데 상위 옵션의 영향으로 인해, 여기서 글쇠배열을 아무리 고쳐도 그게 실제 입력 때 반영되지 않는 경우가 있다.

  • 첫째, '빈 입력 스키마와 호환되게' 옵션이 켜져 있고 현재 편집기가 아닌 외부 모듈/입력 패드 구현체를 사용 중일 때. 이때는 해당 입력 항목은 의도적으로 모든 글쇠를 처리하지 않고 넘기는 '빈 입력 스키마'와 동일하게 동작하므로 자신의 모든 입력 설정들이 무효가 된다.
  • 글쇠 인식 옵션에서 기존 글쇠배열의 문자· 숫자· 기호 47개 자리의 일부를 지정하여 다른 용도로 사용하고 있을 때. 여기에는 가로채지 '않게' 하는 것도 포함된다.

이제는 이런 상황에 속하는 글쇠들은 회색으로 흐리게 표시되며, 전부 또는 일부 글쇠가 이런 이유 때문에 동작하지 않는다는 설명문까지 잠시 표시된다. 그러므로 글쇠배열을 고쳤는데도 그게 동작하지 않고 왜 그런지 사용자가 이유를 알지 못하는 상황을 예방할 수 있다.

사용자 삽입 이미지사용자 삽입 이미지

'빈 입력 스키마와 호환되게'의 영향을 받는 구현체에서 해당 옵션을 켜면 추가 글쇠 인식 옵션이라든가, 고급 입력기의 고급 글쇠 인식 옵션도 다 흐리게 표시되어서 값 편집 불가 상태가 되게 했다. 어차피 이런 기능들이 동작하지 않는 상태가 되기 때문이다. 이번 버전에서는 이런 UI도 추가했다.

7. 그 밖에 사소한 개선과 버그 수정

(1) 편집기에는 한 글자만을 찾는데 찾는 조건을 수식을 이용해서 세밀하게 지정하는 '문자 영역 찾기'라는 기능이 있다.
거기에다가 앞글자 P와 뒷글자 N이라는 변수도 추가해서 사실상 최대 3글자까지 연달아 찾을 수 있게 했다. 마침표가 이어지지 않는 '다'를 찾는다거나, 한글 다음에 이어지는 한자를 찾는 식으로 활용이 가능하다. 문단의 앞에서는 P는 0, 문장의 끝에서는 N은 0이 된다.
또한 내정값으로도 한글 낱자 중에 유니코드 5.2 새 낱자만 찾는 수식도 추가했다.

(2) "한글 낱자 정규화" 텍스트 필터에 꽤 황당한 버그가 있는 것을 발견하여 고쳤다.
NFC 정규화를 시켜서 현대 한글이 옛한글처럼 자모 형태로 풀어져 있는 것을 바로잡고 나면, 그 뒤에 등장하는 옛한글들은 이상한 쓰레기 문자로 바뀌곤 했다.
한글의 정규화 방식이 바뀐 지난 8.0 버전에서부터 존재한 버그였다. 내가 스스로 찾아 낸 건 아니고 사용자의 제보를 통해 확인했다.

(3) <날개셋> 한글 입력기는 영문 UI에서 '한글'을 표기할 때 과거에는 Hangeul을 쓰다가 나중에 Hangul로 바꿨다. 당장 유니코드의 영역 이름에도 Hangul이 쓰이고 외국에서는 eu보다 u가 훨씬 더 널리 퍼져 있다고 판단되어서다.
그런데 프로그램 UI 중 특별히 콤보 박스 안의 항목이라든가, xml에 들어가는 내정값 같은 데에서 여전히 eu 표기가 남아 있는 것을 뒤늦게 자체적으로 확인하여 고쳤다.

(4) <날개셋> 제어판의 낱자 결합 탭에서 '낱자 결합 규칙'을 등록하는 UI에서..
'추가'를 그냥 클릭하면 지금까지 그런 것처럼 새 항목이 추가되고 입력 포커스는 A+B=C 중에 A의 위치로 간다.
하지만 Ctrl+클릭을 하면 A와 C의 값이 서로 뒤바뀌고 포커스는 A가 아닌 C에 가게(교환으로 인해 A의 값을 갖게 된) 했다.
그래서 A+B=C에 이어서 역으로 돌아오는 C+B=A라든가, C+B=D처럼 연타에 의한 후속 조합을 지금보다 더 수월하게 등록할 수 있게 했다.

(5) 끝으로 낱자 결합 규칙, 각종 사용자 정의 조합/후보 목록 등, <날개셋> 제어판에서 Windows 폰트가 아니라 자체 비트맵 글꼴로 출력되는 모든 UI들은..
뭔가 아이템을 추가/삭제하거나 순서를 조정하고 나면 지금까지는 스크롤 위치가 엉뚱하게 바뀌고 선택 막대도 화면 맨 아래에 어설프게 걸친 위치로 바뀌곤 했다. 이것 때문에 지금까지 무척 불편했는데 이걸 드디어 원천적으로 개선했다. 스크롤이 필요 없으면 스크롤이 발생하지 않으며, 선택 막대도 언제나 화면 안에 온전히 출력되게 했다.

Posted by 사무엘

2016/02/27 08:30 2016/02/27 08:30
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1197

날개셋문자 명세서

<날개셋> 한글 입력기는 사용자가 어떤 글쇠를 눌러서 만들어 낸 입력 단위를 ‘날개셋문자’라는 계층으로 추상화해서 표현한다. 영문 같은 간단한 글쇠배열이라면 A~Z까지 입력하는 문자 자체가 그대로 입력 단위이겠지만, 한글 입력은 그 이상의 계층이 또 필요하기 때문이다.

먼 옛날 1.x 시절에는 <날개셋> 한글 입력기는 그냥 조합형이라는 1 또는 2 multibyte 기반이었으며, 기본 입력 단위의 크기는 16비트였다. 그 16비트 숫자가 한글 자모라면 그건 한글을 조합하는 입력이고, 그렇지 않으면 조합을 만들지 않는 비한글 입력이니 아주 단순한 구조였다.
그 시절에도 특정 성분을 바로 지우고 앞뒤로 빼내는 ‘특수글쇠’라는 개념이 있었지만 그건 일반 자리에는 배당이 가능하지 않았고 Ctrl 조합에다가만 따로 배당할 수 있었다. 지금 생각해 보면 정말 원시적이고 미개하기 그지없었다.

그 뒤 2.x에 와서는 입력 단위의 크기가 32비트로 확장되었고 초중종성 성분의 크기도 5비트에서 8비트로 커졌다. 덕분에 옛한글과 간단한 가상 낱자도 표현할 수 있게 됐다. 입력 단위는 문자 아니면 특수글쇠(비문자)라는 이분법적인 구분이 생겼다. 하지만 여전히 내부 체계는 1.x와 별 다를 바 없을 정도로 빈약했다.

뭔가 지금과 같은 체계가 잡힌 것은 3.x에 온 뒤부터이다. 문자 코드는 완전히 유니코드 기반으로 바뀌었고, 날개셋문자라는 명칭이 정립됐으며 그 크기도 64비트로 넉넉하게 커졌다.
같은 문자도 한글과 비한글이라는 구분이 생겼다. 한글을 조합하는 데 쓰이는 ㅏ와, 단순히 있는 그대로 입력시키는 U+1161짜리 문자인 ‘ㅏ’를 구분할 수 있게 됐다는 뜻이다.

게다가 종전에는 글쇠배열의 벌식 정보가 글쇠배열 전체에 일괄적으로 적용되는 속성이었던 반면, 3.x부터는 각각의 날개셋문자가 자체적으로 두벌/세벌 정보를 갖게 했다. 도깨비불 현상은 두벌 속성을 지닌 날개셋문자 종성에다가 역시 두벌식 속성을 가진 중성이 결합할 때에만 일어난다. 따라서 한 글쇠배열에 세벌식으로 동작하는 글자(가령, ㅃ, ㅉ, ㄸ)와 두벌식으로 동작하는 글자(가령, ㅂ, ㅈ, ㄷ)가 자연스럽게 공존 가능하다.

3.x에서는 한글의 경우 여러 성분을 한꺼번에 배당해서 입력하는 것도 가능해졌다. 초성+중성 내지 중성+종성 같은 것 말이다. 그리고 자주 쓰이지는 않지만 굳이 한글 자모를 실제로 입력하지 않고도 오토마타의 내부 상태를 강제로 바꾸는 ‘상태 전이’라는 날개셋문자 타입도 추가했다.

그래서 ‘일반 문자, 한글 세벌식, 한글 두벌식, 특수글쇠, 상태 전이’ 이렇게 5종류의 날개셋문자 타입이 정립됐다. 카테고리를 더 나누자면 ‘한글, 비한글, 비문자’ 정도로 요약된다. 그리고 backspace와 한자(후보) 변환은 특수글쇠의 일종인 형태로 개념이 세워졌다.
이 정도면 버전 1~2 시절에 비하면 엄청난 발전을 이룬 것이었다.

그 뒤 날개셋문자에 타입이 또 추가될 일은 거의 없었다. 그러다가 2010년, 5.65 버전에서 다중 입력과 관련된 새로운 타입이 세 종류가 더 추가됐는데, 이것은 모두 나름대로 의미가 있는 것들이었다.

첫째, ‘다중 문자’이다. 기존의 ‘일반 문자’는 문자 하나의 유니코드 포인트 번호를 갖고 있으므로 일종의 UTF-32 스타일이다. 그러나 다중 문자는 UTF-16 방식으로 표현된 유니코드 문자를 최대 6바이트까지 저장하고 있는다.

일반 문자는 숫자 하나로 표현된다는 대표성이 있으며, 최종 변환이나 글쇠 치환등 각종 치환의 영향을 받는다. 그러나 다중 문자는 다수 개의 유니코드 포인트로 표현되는 합자, 옛한글, ‘000’ 같은 문자를 간편하게 표현할 수 있으며, 입력기 내부에서 다른 치환의 영향을 받지 않고 언제나 1~3개의 문자를 있는 그대로 입력하는 역할만 한다. 그러므로 존재의 의미가 충분하다고 볼 수 있다.

둘째, <날개셋> 한글 입력기가 복수 개의 한글 자모를 입력할 수 있다는 점에 착안하여, 그 자모들이 한 글자가 아니라 두 글자에 걸쳐서 입력되게 하는 날개셋문자가 추가되었다. 즉, 초+중+종이 아니라 종부터 입력한 뒤 음절을 끊고 초+중을 입력하는 놈, 그리고 중+종을 입력한 뒤 음절을 끊고 초성을 나중에 입력하는 놈 두 종류가 있다. 얘는 도깨비불과는 무관하므로 세벌식의 파생형이다.

덕분에 2010년대부터는 <날개셋> 한글 입력기가 제공하는 날개셋문자 타입은 8종류로 늘었는데.. 2012년, 버전 6.7에서는 잘 알다시피 두벌식에도 파생형이 하나 추가되었다. 바로 ‘종성 두벌식’ 되시겠다.
C++에서 new operator와 operator new가 서로 다른 용어이듯이, ‘종성 두벌식’과 ‘두벌식 종성’은 <날개셋> 한글 입력기의 내부에서 의미가 다른 개념이다.

지금까지 <날개셋> 한글 입력기가 제공한 두벌식 방식의 날개셋문자는 ‘초성 두벌식’이었다. 종성이 도깨비불 현상을 통해 다음 글자로 넘어갔을 때 초성으로 승격이 됐기 때문이다. 그러나 종성 두벌식은 다음 글자로 넘어갔을 때도 종성이 계속 유지된다.

순서를 바꿔서 ‘두벌식 종성’이라고 하면, 타입이 ‘초성 두벌식’이든 ‘종성 두벌식’이든 무관하게 어쨌든 두벌식이고 종성에 nonzero 값이 있는 날개셋문자를 가리킨다. “두벌식 종성과 두벌식 중성이 만나야 도깨비불 현상이 일어난다. 그런데 그 종성의 타입이 ‘초성 두벌식’이냐 ‘종성 두벌식’이냐에 따라 그 종성은 다음 글자에서 각각 초성이나 종성으로 등록된다.” 이렇게 관계가 정리된다.

세벌식과 두벌식에 대해 각각 이런 파생형 타입을 고안해 낸 것은 개인적으로 굉장히 뜻깊은 업적이라고 생각된다. 전에는 가능하지 않았던 한글 입력기의 새로운 기능이 추가된 것이기 때문이다. 특수글쇠 내지 타자 입력 순서 계산 같은 부수적인 기능들까지 중성 두벌식의 컨셉과 맞춰서 정확하게 동작하도록 로직을 강화하는 작업은 7.x대 중반 버전까지 내부적으로 계속되었다.

그리고 현재까지 <날개셋> 한글 입력기에 마지막으로 추가된 날개셋문자 타입은 바로 2015년 초, 7.9 버전에서 추가된 “글쇠 입력”이다. 비한글과 한글에 이어 ‘비문자’ 분야에도 타입이 또 추가된 것이다.

A라는 글쇠에다가 B를 누르는 날개셋문자를 추가한다면, A를 누른 것 자체는 <날개셋> 한글 입력기가 가로채어지며 응용 프로그램으로 전달되지 않는다. 그러나 이로 인해 B를 누른 동작이 인위로 생성되며, 이것은 <날개셋> 한글 입력기가 처리하지 않고 언제나 응용 프로그램으로 가는 것이 보장된다.

이 기능을 이용하면 간단한 단축키 조작을 할 수도 있고 영문과 숫자의 경우 IME가 아니라 키보드 직통으로 응용 프로그램으로 전달할 수도 있다.
키보드 입력을 생성하는 것 자체를 별도의 날개셋문자 타입으로 독립시키겠다는 생각을 어떻게 하게 됐나 정말 신기하다. 이 타입은 한글 입력과 관계가 있는 게 아니므로 굳이 ‘기본 입력기’가 아니라 ‘빈 입력기’에서도 제약 없이 사용할 수 있다.

이런 긴 과정을 거쳐서 <날개셋> 한글 입력기에는 현재 한글 세벌식 3종류, 두벌식 2종류, 비한글 문자 2종류, 비문자 3종류 이렇게 총 10종류의 날개셋문자 타입이 존재한다. 3.0 시절에 비해 정확하게 두 배로 증가한 것이다.

<날개셋> 한글 입력기의 구현체에 대해 논하자면 1.0때 처음부터 개발되어 온 에디터(since 2000), 2.5 과도기를 거쳐서 3.02때부터 개발된 외부 모듈(since 2004), 그리고 5.3 때부터 등장하여 최근에 많이 발전한 입력 패드(since 2009) 세 종류가 있으며 이들은 특징이 제각각이다.
그런 구현체의 종류 이상으로 <날개셋> 한글 입력기가 입력 단위로 받아들이는 날개셋문자의 타입도 종류가 다양하며 제각각 내력이 있다. 과연 미래에 제11째 타입이 등장할 일이 있을지 궁금해진다.

Posted by 사무엘

2016/02/06 19:34 2016/02/06 19:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1190

다음 버전 개발 근황

<날개셋> 한글 입력기 8.2는 기념비적인 작품이었다. 내부적으로 이것저것 개선 사항이 많았으며, Windows 10 지원에다 후보 변환 프로토콜 관련 작업은 아주 뜻깊은 결실이기 때문이다.

8.2는 한글 조합과 관련된 쪽보다는 키보드 입력을 인식하는 쪽에서 이례적으로 새로운 기능이 많이 추가되었다. 오른쪽 alt/ctrl을 지원하는 것에 대해서 몇 번 건의를 받긴 했지만 지금까지 별 생각을 안 하고 지냈다. 그랬는데 이것을 키보드 드라이버 보정이라는 새로운 기능으로 통합하면 되겠다는 생각이 들자, 결국 예정에 없던 신규 기능으로 들어가게 됐다.
여기에다가 키보드/키패드 구분과 scroll lock 인식 같은 것도 아주 신선한 기능이다.

그 뒤, 8.2의 다음 버전은 8.4로 설정되어 있으며, 이번엔 다시 입력기 내부의 아키텍처를 개편하는 어려운 작업이 한창이다. 내년 2월 말쯤에 내는 것을 목표로 하고 있다.

1. 최종 변환 규칙의 개편

가장 먼저 수술대에 오른 기능은, 지난 3.0 이래로 거의 변화 없이 형태가 동일하게 유지돼 왔던 편집기 계층의 '최종 변환 규칙'이다. 최종 변환 규칙은 수식값을 만족하는 번호에 해당하는 입력 항목에 대해서 아스키 문자의 전/반각을 바꾼다거나 한글 자모를 호환용 자모로 바꾸는 것 같은 간단한 변환을 수행한다.
다음 버전에서는 최종 변환 규칙이 적용되는 조건과 방식이 더 깔끔하게 바뀔 예정이다.

첫째, 수식이 없어진다. A<=2 (첫 세 개의 글자판만), A&1 (짝수 번째 글자판만) 이런 식으로 적용 대상을 지정하는 게 강력하긴 하지만 실제로 쓰이는 경우가 거의 없다고 판단되어서이다. 또한 이런 번호가 붙어 있지 않고 보조 입력 도구가 제공하는 입력 항목에 대해서는 최종 변환 규칙을 적용할지 의문이 생기기도 한다.

그래서 이제는 최종 변환 규칙을 지정하면 모든 입력 항목에 일괄적으로 그 규칙이 적용된다. 수식 같은 거 생각할 필요가 없다. 그 대신, 각각의 입력 항목에서 '기본 입력기' 이상 등급부터는 최종 변환 규칙의 적용을 원하지 않는 경우 옵션을 지정할 수 있다. No라고 옵션이 지정되지 않은 모든 문자 생성기들은 기본적으로 최종 변환 규칙을 적용 받으며, 특히 '빈 입력기'는 그런 옵션도 없기 때문에 규칙이 무조건 적용되게 된다(입력 스키마조차 '빈 스키마'인 경우는 물론 제외. 문자 생성기가 아예 동작하지 않는 상황이므로).

둘째, 조건이 완화된 대신, 적용 범위는 더 좁아진다. 최종 변환 규칙은 (1) '일반 문자' 타입의 날개셋문자, 또는 (2) 한글의 경우 두벌/세벌/종성 두벌식 등등 무엇이건 상관은 없지만 초중종 낱자가 단 하나만 있는 경우에만 한해서 적용된다. '다중 문자' 타입에는 적용되지 않으며, 날개셋문자가 아닌 방식으로 생성된 raw 문자열에도 적용되지 않는다. raw 문자열이란 후보 변환 내지 '고급 입력기'의 '사용자 정의 조합' 같은 걸 말한다.

애초에 반각/전각 변환이나 한글 자모 종류 변환 같은 간단하지만 보편적이고 전역적(global)인 변환만을 의도했던 것이기 때문에 이렇게 범위를 좁히는 게 최종 변환 규칙의 취지를 살리는 데 더 도움이 될 것으로 보인다. 가령, 더 복잡한 형태의 한글을 다른 형태의 문자로 바꾸려면 아예 '고급 입력기'의 '한글 출력 치환'을 사용하면 될 테니 말이다.

이런 이유로 인해 이제는 최종 변환 규칙을 통해 반각을 전각으로 바꾸는 설정을 넣었다 하더라도 '일반 문자' 날개셋문자 외에 다른 방식으로 입력하는 문자/문자열에 대해서는 그런 변환이 일어나지 않는다. 그것들은 언제나 있는 그대로만 입력될 것이다.

2. 오토마타에 T 변수 추가

글쇠배열 수식에서는 잘 알다시피 T라는 변수가 오토마타 상태 번호를 나타낸다. 그런데 이제는 오토마타에도 O에 이어 T라는 변수가 추가되었다. 이것은 한글 조합을 더 계속할 수 없어졌을 때 왜 더 계속할 수 없는지에 대한 추가 정보를 담고 있다.

잘 알다시피 오토마타는 입력된 글쇠의 초중성 정보가 A~C라는 변수에 담겨 있고, 지금 상태에서 무슨 상태로 분기할지를 그 변수 값으로부터 결정하는 수식의 집합이다.
그런데 오토마타상으로는 결합이 계속 가능함에도 불구하고 결합이 가능하지 않은 경우가 크게 두 가지가 있다.

첫째는 말 그대로 낱자 결합 규칙이 더 존재하지 않을 때이다. 가령, ㅋ 다음에 ㅁ을 누른다거나 하면 일단은 답이 없다. 그리고 둘째는 흔한 경우는 아니지만 '허용 한글 제약'에 걸렸을 때이다. KS 완성형 2350자만 조합 가능하게 해 놓은 상태에서 "또" 다음에 받침 ㅁ을 시도한다면 더 진행을 할 수 없다.

이럴 때는 한글 입력기는 A~C에 모두 0을 넣어서 동일 오토마타 수식의 값을 다시 구한다. 이때 수식은 반드시 양수가 아니라 0 이하의 값을 되돌려야 한다. 10여 개의 0 이하 코드값들은 "다음 글자로 자연스럽게 넘어가기", "이 입력을 무시", "무한 낱자 수정" 등 여러 용도로 의미가 예약돼 있다.

A~C 중 적어도 한 성분에 nonzero가 있는 정상적인 상황일 때는 T는 0임이 보장된다. 그러나 오토마타 이외의 사유로 조합을 할 수 없어서 A~C가 0인 상태로 수식이 다시 계산될 때는, T는 1(낱자 결합 불가) 또는 2(허용 한글 제약)가 들어온다.
즉, A|B|C와 T==0은 동치이기 때문에 A~C 낱자 값을 일일이 살펴보기 전에 지금이 정상/비정상 중 어느 상황인지부터 판단하고 싶으면 T 값을 먼저 살펴보면 된다.

T 값을 판단해 보면, '똔' 다음에 '똔ㅁ(받침ㅁ. ㄴ+ㅁ 결합은 없음)으로 가는 것은 허용하지만(0. 다음 글자로) '똠'은 입력되지 않고 ㅁ이 아예 무시되게(-1. 이 입력 무시) 할 수 있다. 두 상황을 구분해서 인식할 수가 있게 되는 것이다. '허용 한글 제약' 기능을 좀 더 창의적으로 활용할 수 있을 것이다.
참고로 진짜로 세 성분 중 단 하나도 nonzero가 없는 빈 한글 날개셋문자는 오토마타에 전달되지 않는다. 새로운 조합을 만들거나 지금 조합을 종료시키지도 않음이 보장된다.

3. 서로 다른 문자의 개수 계산

<날개셋> 편집기에는 블록으로 잡은 텍스트에 대한 간단한 분량 통계를 내는 기능이 도구 메뉴에 존재한다.
줄 수와 UTF16 기준 글자 수는 쉽고 직관적인 통계이고 거기에다 ANSI 인코딩으로(UTF-8도 포함) 변환했을 때의 바이트를 출력해 주는데, 이번에는 텍스트 내부에 존재하는 서로 다른 문자의 수도 추가했다. 즉, "ABCADE"는 글자 수는 6이지만 서로 다른 문자의 수는 5이다.

그래픽 에디터에 이 selection 내부에 존재하는 서로 다른 RGB 색상수가 몇인지 출력하는 기능이 있는 것에 착안하여 저 기능을 구현해 넣었다.
특정 문자 집합으로만 구성되거나 중복되는 문자가 없어야 하는 데이터 테이블을 검증할 때, 혹은 이 문서에 쓰인 서로 다른 한글이나 한자가 총 몇 자인지 궁금할 때 이 기능을 활용하면 된다. 생각보다 요긴할 것이다.
계산 기준은 surrogate까지 감안하여 철저하게 유니코드 코드 포인트이다. 그렇기 때문에 옛한글은 글자 단위가 아니라 낱자 단위로 종류가 계산된다.

4. 정렬 기능의 대소문자 비교 방식 개선

지금으로부터 거의 4년 전에 나온 6.5버전에서는 대소문자 구분이 없이 텍스트를 정렬할 때 문자열을 비교하는 알고리즘을 개선한 바 있다. 동일하게 간주되는 텍스트끼리라도 걔네들 사이에서는 대소문자 기준으로 서열을 둬서 ABCabc가 아니면 AaBbCc가 보장되게 했다. 대소문자 구분을 안 한다고 해서 aABbcC 이렇게 뒤섞이지 않게 했다는 뜻이다.

그런데 그때 작성한 알고리즘에는 좀 문제가 있었다. 그건 같은 문자열들 중에서는 AB Ab ab라고 순서를 딱 보장해 줬지만, AD와 ab를 비교할 때는 여전히 AD를 앞으로 보냈다. 왜냐하면 첫 글자 A와 a 중에서 A가 먼저 처리되기 때문이다.
난 "AB, Ab, ab, AD"를 기대했고 당연히 그렇게 나올 줄 알았는데 실제로 나오는 결과는 "AB, Ab, AD, ab"였다.
왜 이런 문제가 이제야 발견됐는지, 내가 왜 그때 그런 실수를 했는지를 통탄하면서 어쨌든 문제를 고쳤다. 문자열 비교에도 생각보다 교묘한 곳에 복병이 있다.

5. 외부 모듈의 우클릭 메뉴 형태 변경

Windows 8 이래로 외부 모듈은 이제 우클릭 메뉴를 이용해서 입력 항목(입력 모드, 글자판..)을 전환할 일이 많아질 텐데..
입력 항목이 10개보다 적을 때는 입력 항목을 우클릭 메뉴 첫 단계에서 바로 고를 수 있게 했다. 아래 그림에서 왼쪽을 오른쪽으로 바꿨다는 뜻이다. 이렇게 하니까 시각적으로 내지 심리적으로 훨씬 더 좋아 보인다.

사용자 삽입 이미지

'입력 패드'는 키보드 입력도 이제 가능하긴 하지만 그래도 입력 도구가 여전히 더 중요하다 보니, 입력 도구를 우클릭 메뉴의 첫 단계에서 바로 고를 수 있고 글자판은 하위 메뉴에서 고른다.
'외부 모듈'은 반대로 글자판을 첫 단계에서 바로 고르고, 입력 도구는 하위 메뉴에서 고른다. 이런 관계가 딱 정립되었다.

6. 단축글쇠 리스트에서 이동뿐만 아니라 복사도 지원

날개셋 제어판의 설정 중에는 단축글쇠를 관리하는 기능이 편집기 계층에 있고 기본 입력 스키마의 추가 옵션에도 있다. 여기에 등록한 단축글쇠는 딱히 정렬 기준이 있거나 중복 등록 체크를 하지 않으며, 지난 7.7 버전부터는 마우스 드래그로 항목을 이동할 수도 있게 했다. 복수 개의 아이템을 선택해서 끌면 그 아이템들이 한꺼번에 위나 아래로 이동한다.

그에 이어 이번 버전에는 Ctrl+드래그로 복사도 되게 했다.
이미 왼쪽의 입력 항목 트리는 이동과 복사가 모두 지원되고 있었는데 그게 단축글쇠 리스트로까지 범위가 확대된 것이다. 글쇠나 수식이 비슷한 단축글쇠를 여럿 등록할 일이 있을 때 복사를 한 뒤에 다른 부분만 고치는 식으로 편집하면 단축글쇠를 지금보다 더 편리하게 등록할 수 있을 것이다.

이 외에도,
(1) "빈 입력 스키마와 호환되게" 옵션을 지금까지는 '기본 입력 스키마'에서만 지정할 수 있고 '고급 입력 스키마'에는 지정할 수 없었는데, 그 제약이 없어졌다.

(2) 편집기에서 '자동 줄바꿈' 옵션을 끈 상태로 임의의 파일을 열거나, 혹은 스크롤 바가 생기지 않을 정도로 아주 짧은 파일을 연 경우 초기에 문서의 전체 줄 수가 실제 줄 수가 아니라 1로 잠시 잘못 표시되던 버그를 잡았다. 이것 말고도 자체 에디트 컨트롤의 코드를 전반적으로 좀 최적화를 했다.

(3) 지난 7.9 버전부터는 조합 중인 두벌식 한글을 도깨비불 현상이 미리 적용된 형태로 표시하는 옵션이 '고급 입력기'의 '한글 출력 옵션'에 추가되었다. 그래서 일명 '초성 지향 도깨비불'이라는 걸 구현 가능해졌는데, 문제는 "가ㅁ" 상태일 때는 '감'에 해당하는 한자 변환을 할 수 없었다. 지금까지는 그게 가능하지 않다가 이제 다음 버전부터는 글자 단위와 단어 단위로 모두 한자 변환이 가능해졌다.
저 상황에서 예외를 둬서 저것만 가능하게 하는 것은 어렵지 않지만, 더 탄탄한 이론적 근간을 마련해서 문제를 완전히 해결하는 게 쉽지 않아서 지금까지 문제 해결을 보류하고 있었다.

(4) 고급 입력기의 사용자 정의 조합을 이용하여 비한글 외국어 문자를 입력하는 예제로 지금까지 제공된 건 히라가나/가타카나라는 일본어 자료가 거의 유일했는데, 이번에는 일명 'Qwerty Extension'이라는 걸 추가했다.

일본어 자료는 조합 로직 자체가 유의미한 반면, 얘는 후보 데이터들이 본좌이다. 알파벳, 숫자, 기호 등 거의 모든 문자가 곧장 입력되는 게 아니라 조합 형태로 입력되며, a를 조합하는 상태에서 한자 키를 누르면 a에 그야말로 상상할 수 있는 온갖 액센트/변형 부호가 붙은 것들을 선택할 수 있다. -에 대해서는 N-dash, M-dash, 하이픈 등 온갖 바리에이션이 들어있는 식이다.
생각보다 무척 유용하며 예제 입력 데이터로서의 의미도 큰데, 왜 지금까지 이런 게 없었는지 궁금하다. 정 재민 님께서 제공해 주셨다. 설명문 때문에 파일이 생각보다 덩치가 크다.

Posted by 사무엘

2015/12/02 08:30 2015/12/02 08:30
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1166

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 13 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/09   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

Site Stats

Total hits:
1441997
Today:
291
Yesterday:
490