날개셋 한글 입력기 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

Trackback URL : http://moogi.new21.org/tc/trackback/1197

Comments List

  1. 사포 2016/02/29 10:45 # M/D Reply Permalink

    수고 많으셨습니다. ㅎㅎ

    1. 사무엘 2016/02/29 23:19 # M/D Permalink

      감사합니다. 세벌식이나 더 일반적인 한글 입력 방식 customization 같은 데에 관심 있으시면 유용하게 사용하세요. :)

Leave a comment

날개셋문자 명세서

<날개셋> 한글 입력기는 사용자가 어떤 글쇠를 눌러서 만들어 낸 입력 단위를 ‘날개셋문자’라는 계층으로 추상화해서 표현한다. 영문 같은 간단한 글쇠배열이라면 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

Trackback URL : http://moogi.new21.org/tc/trackback/1190

Leave a comment

다음 버전 개발 근황

<날개셋> 한글 입력기 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

Trackback URL : http://moogi.new21.org/tc/trackback/1166

Comments List

  1. 꼬마집오리(코노 노보루)(河野 登) 2015/12/31 20:33 # M/D Reply Permalink

    김용묵 님, 처음 뵙겠습니다.
    저는 코노 노보루(河野 登)라고 합니다.

    윈도 컴퓨터를 새로 산 후 계속 <날개셋>을 써서 새로운 버전이 될 때마다 개신하고 있습니다.
    대학교에서는 컴퓨터 공학을 전공했지만 IME 프로그램을 스스로 못 만든 저에게는 한글 입력법을 사용자가 새로 만들 수 있는 앱이 있으면 좋을텐데고 오래동안 생각해 왔습니다.
    대단히 감사합니다.

    1991년 쯤 일본의 신문을 보니 한국에서는 많은 가정에 타자기가 있다는 기사를 찾아내서 처음으로 한국을 여행했을 때 수동식 외솔타자기를 샀습니다. 전기도 프로그램도 안 써서 한글 글자마디 11272가지를 다 표시되는 것에 큰 충격을 느꼈습니다.
    그 후 한글을 입력되는 컴퓨터를 샀는데 2벌식 입력법은 외솔타자기 입력법보다 입력이 쉽지만 왜 시프트키를 쓰는 경우를 남겼는지 생각하게 됐습니다. 중국어나 일본어를 로마자로 입력하는 경우는 시프트키를 쓰는 필요가 없습니다.

    현행 두벌식 자판대로 시프트키를 안 써도 한글 글자마디를 입력하는 방법을 생각해 봤습니다. '글걸이' 사이트의 글쓴이 팥알 선생님께 소개드렸는데 이 입력법을 "두벌식 순아래"라고 이름지어 주셨습니다.
    두벌식 순아래는 현행 두벌식에 다움 기능을 추가한 입력법입니다.
    .1. ( 겹닿소리로 시작하는 글자마디(문자)는 닿소리 키를 누른 다음에 잇따를 홀소리 키를 거듭칩니다.
    겹홀소리가 잇따를 경우는 먼저 눌려야 할 홀소리 키를 거듭칩니다.
    예. 뜻 은 ㄷㅡㅡㅅ 이라고 입력합니다.
    꽥 은 ㄱㅗㅗㅐㄱ 이라고 입력합니다. ).
    .2. ( ㅒ는 ㅑ키를 누른 다음에 l키를 누릅니다. ㅖ 는 ㅕ키를 누른 다음에 l키를 누릅니다.
    예. 옛 은 ㅇㅕㅣㅅ 이라고 입력합니다. ).
    .3. ( 겹받침 ㄲ 은 ㄱ키를 거듭칩니다. 겹받침 ㅆ 은 ㅅ키를 거듭칩니다.
    예. 꺾 은 ㄱㅓㅓㄱㄱ 이라고 입력합니다. ).
    .4. ( 현행 두벌식과 혼용할 수 있습니다.
    예. 꺾 은 ㄲㅓㄲ 혹은 ㄲㅓㄱㄱ 혹은 ㄱㅓㅓㄲ 이라고도 입력됩니다. ).
    벌써 현행 입력법에 충분히 익숙해진 사용자가 새로운 입력법을 "거절"해서 받아들 수 없는 겨우가 대부분이지만 현행 두벌식 자판과 같고 현행 입력식과 혼용할 수 있으면 "조금씩" 새로운 입력법에 익숙해질 수 있게 됐습니다.

    이번에 <날개셋>으로 두벌식 순아래 입력법을 구현들었습니다.
    혹시 시간이 있으시면
    http://tinyduckn1.zpat.info/dubeolsik_sunarae/Nalgaeset_dubeolsik_sunarae/dubeolsik_sunarae20151203beta.zip
    에서 다운로드하셔서 dubeolsik_sunarae20151203beta.zip 파일을 푸신 dubeolsik_sunarae20151203beta.set 을 가져오셔서 시도해 주시면 뭣보다도 고맙게 느낍니다.

    "'까' 다위를 입력하기 위해 모음 키를 연타해서 자음에 변환한다고는 부자연그럽다"라고 생각하시는지 몰겠습니다.
    또 예들면 "까"를
    시프트키를 누르면서 ㄱ키를 친 후 ㅏ키를 친 경우와
    ㄱ키를 친 후 ㅏ키를 연타한 경우
    "까"가 표시한 직후 bksp키로 자소마다 지워갈 때 다른 표시가 됩니다.
    전자 경우 까 -> ㄲ ,
    후자 경우 까 -> 가 -> ㄱ
    식으로 됩니다.
    이런 문제점은 있는데 시프트키를 쓰면 오타가 생기기 쉬운 저 같은 사람에게는 어느 정도는 효가가 있다고 생각합니다.

    여기서 한글 입력법을 개개인이 새로 개발되고 컴퓨터에서는 구현되는 환경을 만들어 주신 김용묵 님께 다시 한번 감사의 말씀을 드리겠습니다.
    앞으로도 더욱 진화한 소프트웨어를 실현하시독 빌겠습니다.

    1. 사무엘 2015/12/30 23:24 # M/D Permalink

      안녕하세요! 제 프로그램을 사용해 주셔서 대단히 반갑고 고맙습니다. ^^
      우와, 이렇게 거대한 입력 설정 파일은 처음 봅니다.
      Shift가 아니면 초성은 "후행 중성의 연타"로, 종성은 "종성 그 자체의 연타"로 구분하는 게 굉장히 기발하군요. 이렇게 하니 '닦가', '닥까', '닥가'도 Shift나 조합 수동 종료 없이 모두 구분 가능하고.. 좋습니다.

      중성의 연타로 초성을 고치는 건 '고급 입력기'로 갈 필요 없이 글쇠와 오토마타의 수식으로 구현하는 게 더 간편하고 나을 것 같습니다. 여기서는 아주 간략하게 아이디어만 설명 드리오니 더 궁금한 사항은 제게 메일로 연락을 해 주세요. 누리집에서도 선생님의 이메일 주소는 찾을 수 없네요. 일반 두벌식 글자판에서,

      1. 초성의 낱자 결합 규칙에는 ㄱ+500=ㄲ ... ㅈ+500=ㅉ을 등록함. 종성의 낱자 결합 규칙에는 ㄱ+ㄱ=ㄲ, ㅅ+ㅅ=ㅆ을 추가로 등록함.

      2. 중성 ㅏ 자리엔 E==1&&!F ? H2|0x1F4 : H2|A_
      중성 ㅣ 자리엔 E==73&&!F ? H2|0x1F4 : H2|I_
      이런 식으로 각 모음에 대해서 E==??만 달리하면서 글쇠들을 등록함. 현재 받침이 없고 자기 모음이 입력되어 있을 때는 초성 500을 보내고 그렇지 않으면 ㅏ을 또 보낸다는 뜻임. 받침이 없는지도 체크를 반드시 해야 '까'도 입력하고 '간'에서 '가나' 같은 글자를 입력할 수 있게 됨.

      3. 오토마타는 일단 '이어치기'를 선택한 뒤, 다음과 같이 수정한다.
      상태 2는 초성+중성이 입력된 상태인데, 이때의 수식을 A==500 ? 4 : B ? 2 : C ? 3 : 0 이라고 입력. 다른 자음은 받아들이지 않지만 쌍자음 가획이 입력되기 전과 후를 구분하기 위한 조치임.
      그리고 상태 4를 추가하여 B ? 2 : C ? 3 : 0 를 입력.

      외국인으로서 한글 기계화에 대해서 이 정도로 조예가 깊은 분이 계신 것에 무척 놀라움을 느낍니다. 일단 제 팁이 도움이 됐으면 좋겠습니다. 다시 한 번 감사드립니다.

    2. Lyn 2015/12/30 23:28 # M/D Permalink

      초성빼고는 구글 단모음키보드의 입력방식이랑 같네용.

  2. Lyn 2015/12/30 23:35 # M/D Reply Permalink

    단모음의 단점인 자음연타로 인한 구별 불가능 단점(ㄱㅜㄱㄱㅏ ==> 국가 or 구까) 을 해결 한 좋은 방식인듯 합니다.

    단모음의 장점인 키의 갯수를 줄이는 의미는 상실했지만...

  3. 꼬마집오리(코노 노보루)(河野 登) 2015/12/31 22:15 # M/D Reply Permalink

    김용묵 님, 일직 답장해 주셔서 대단히 감사합니다.

    제가 두벌식 순아래의 <날개셋> 설정 파일을 만들고 나기 위해 약 1년 걸렸지만 김용묵 님은 1시간 이내에 만들 수 있는 방법을 가르져 주셨군요!! 정말 놀랐습니다. 저는 대학생 시절 오토마타 강의의 시험은 불합격였는데 지금도 오토마타를 잘 못해서 경원해 버렸습니다.
    500란 자모를 마련해서 초성으로서 자음자모와 모음자모를 자음자모로 변환되도록 하신 점도, 모음자모키의 정의와 오토마타에 낱자처리를 방영시키신 점도 저는 전혀 생각 못 냈습니다.
    지금 새로운 설정 파일로 입력하고 있습니다. 감사합니다.

    <날개셋> 8.4도 기대하고 있습니다.

    Lyn 님, 외국인이고 한글이나 한글 기계화에 대해 지식이 모자란 제가 만든 입력법에 관심을 가겨 주셔서 대단히 감사합니다. 아직 문제점이 있는데 보다 좋은 입력법을 향해 노력해 갑니다.

    제 메일 주소는 tinyduckn@gmail.com 입니다. 답장은 제 휴무일에만 쓸 수 있어서 늦어지는 경우도 있는데 승낙해 주시기 바랍니다.

    1. 사무엘 2016/01/04 11:33 # M/D Permalink

      외국인이 제 입력기를 사용하는 건 십중팔구가 로마자 입력법을 사용하기 위해서이거든요(saram → 사람). 그래서 저도 영어로 써 놓은 프로그램 소개 페이지에서는 딴 거 다 제끼고 로마자 입력법을 지정하는 순서를 단계별로 써 놨을 정도입니다.
      그런데 도움말 읽으면서 제 프로그램 사용법을 직접 익혀서 흔치 않은 한글 입력 동작을 재현해 놓은 분이 계시니 저로서는 무척 놀랍고 반가웠답니다.

      제가 저렇게 말로만 써 놓은 것도 바로 적용을 잘 해 놓으셨으니 제가 따로 메일을 드릴 필요가 없을 듯합니다. ^^
      감사드리고요, 새해 복 많이 받으세요.

  4. 꼬마집오리(코노 노보루(河野 登)) 2016/01/05 21:13 # M/D Reply Permalink

    새해 복 많이 받으십시오.

    윈도 컴퓨터에서 한글 입력법을 새로 만들기 위해 필요한 오려운 프로그래밍이 <날개셋>을 쓰면 조건 설정과 데이터 입력으로 구현되는 것이 가장 근사한 점입니다.
    미안하지만 저는 <날개셋> 도움말의 겉을 본 뿐입니다. 특히 오토마타나 글쇄 정의에서 쓰는 수식을 아직 이해하거나 짤 수 없는 단계입니다. 또 옛한글 처리에 대해서는 처음으로 접합니다.
    앞으로 질문드리고 싶은 것이 있다고 생각하는데 잘 부탁드립니다.

Leave a comment

날개셋 한글 입력기 8.2

<날개셋> 한글 입력기가 8.0이 나온 뒤 거의 4개월 만에 8.2로 버전이 올라갔다. 1.0 이래로 개발 10주년을 자축한 지가 엊그제 같은데 벌써 15주년이 됐다. ㄷㄷㄷㄷ 이번에도 여느 버전업 때와 마찬가지로 온갖 부분에서 자잘한 개선과 변경 사항이 생겼다. 이 8.2는

  • 1.0 이래로 개발 15주년 돌파
  • 전체 소스 코드가 7만 줄 돌파
  • 32비트 msi 배포 패키지가 정확히 2MB 돌파
  • 32비트 ngs3.dll 커널 크기가 700KB 돌파

라는 여러 기록을 보유하게 되었다.

타자연습은 변화 사항이 없지만 API 구조와 폰트 로딩 방식의 변경 때문에 불가피하게 재컴파일 업데이트를 하게 됐다. 입력기는 8.2인데 타자연습은 구버전을 계속 사용한다면, 실행은 되겠지만 이제 글꼴 리스트에 글꼴들이 제대로 표시되지 않을 것이며, '고급 입력 스키마/입력기'는 로딩이 되지 않을 것이다. 그러니 타자연습도 부득이 같이 업데이트를 해야 한다.

1. Windows 10 지원

이번 8.2는 Windows 10에서 정식으로 테스트된 최초의 버전이다.
Metro UI에서는 제어판이나 텍스트 필터처럼 데스크톱 GUI를 사용하는 기능들을 모두 사용할 수 없게 막았다. 이건 뭔가 새로운 기능을 추가한 것도 아니고, 지금까지는 굳이 필요하지 않던 안전 체크 오버헤드만이 추가된 것일 뿐이다. 본인은 개인적으로 Metro UI는 왜 존재하는지 모르겠다.

명령 프롬프트에서 한글 입력이 더 진행되지 않던 문제를 고쳤고, 그 상태에서 제어판이 동작하지 않던 문제도 해결했다. (명령 프롬프트는 Metro 앱이 아니기 때문에 제어판 접근이 가능해야 한다.) 두 문제 모두 Windows 10의 명령 프롬프트는 예전 버전과는 영 다른 방식으로 동작하기 때문에 발생했었다.

이 정도 보완만 해 주면 되는 듯하나, Edge 브라우저에서 페이스북의 댓글란에 한글 입력이 제대로 안 되는 것은 기술적으로 해결 불가능한 문제로 남았다. 도대체 입력 문자를 어떻게 넘겨 줘야 MS IME 와 동일하게 동작할 수 있는지 현재로서는 알 수 없다. Edge의 버그에 더 가까운 것 같다.

늘 느끼는 것이지만, Windows에서 한글 입력기를 만드는 일은 프로토콜이 IME에서 TSF로 바뀌면서 무질서도와 난관이 한 10배 가까이 뛰고 더 복잡하고 어려워졌다. 예전에는 뭔가 static하고 write-only이기만 하던 고정 프로토콜에다가 문자열을 넣어서 메시지만 쏴 주면 됐지만 지금은 스레드 동기화부터 시작해서 온갖 복잡한 COM 객체 관리, 게다가 레거시 프로그램에 대한 호환 유지, 스펙대로 동작하지 않는 프로그램에 대한 보정.. 등 지저분함이 이루 말로 표현할 수 없다.
극소수 프로그램에서 드디어 텍스트의 임의 조작이 가능해진 것은 분명 큰 발전이지만, 그것 말고 똥싸 놓은 걸 치워야 하는 것도 많다.

2. 입력 패드에 후보 변환 기능 추가

요 근래엔 <날개셋> 한글 입력기의 제3의 구현체인 입력 패드가 장족의 발전을 거듭해 왔다.
7.9에서는 '화면 키보드' 기능에 눌린 글쇠 표시 기능이 추가되었으며, 이 작업을 발전시켜 8.0에서는 입력 패드가 여타 구현체와 대등한 수준으로 키보드 입력이 가능해졌다. 그리고 이번 8.2에서는 조합 중인 글자 하나에 한해서 한자 후보 변환까지 가능해졌다. 그리고 이 기능을 구현하기 위해 후보 변환 프로토콜을 전반적으로 재설계· 확장하는 대공사가 선행되었다.

지금까지 <날개셋> 한글 입력기가 내부적으로 사용하는 프로토콜은 중간에 후보 변환 요청이 있는 경우, 사용자가 무슨 후보로 변환할지 완전히 응답을 해야(취소하는 것도 포함해서) 다음 단계로 진행이 되는.. 일종의 순차· 동기적인 진행만을 지원했다.

이것은 편집기처럼 한자 후보 목록이 별도의 modal 대화상자로 출력되는 구현체에는 곧장 적용 가능한 만한 반면, 외부 모듈처럼 (1) 후보 목록이 뜬 채로 key 입력을 계속 받아들여야 하는 구현체에는 적합하지 않은 구조였다. 그렇기 때문에 동일 코드의 중복 같은 지저분한 편법이 필요했다. 그런데 외부 모듈과 비슷하게 동작하는 구현체(= 입력 패드)가 또 추가되고, 적합하지 않은 프로토콜을 여기에 또 적용할 수는 없기 때문에 이 기회에 리팩터링을 왕창 하게 되었다.

또한, 기존 프로토콜은 한자 후보 선택을 받은 뒤에 cursor를 이동시키거나 텍스트를 조작할 수만 있었지, (2) 반대 순서의 동작을 시킬 수는 없다는 한계도 지니고 있었다. cursor를 이동시켜서 다른 위치에 있는 글자에 대해 후보 변환을 할 수가 없었다.

아래아한글이나 MS IME에서 '토선생'이라는 단어를 입력해서 '생'을 조합하고 있는 상태로 한자 키를 누르면.. 앞의 '토선'이 선택되고 土船이 후보로 제시된다. 그거 변환을 하고 나면 cursor는 다시 '토선'이 아니라 '생'의 뒤로 딱 되돌아온다.
그러나 <날개셋> 한글 입력기는 cursor 위치는 변함이 없고 뒷부분의 '선생'이 선택되고 先生이 후보로 제시된다. 전자와 같은 동작은 프로토콜 차원에서 근본적으로 구현할 수 없기 때문이었다.

8.2부터는 드디어 이런 한계가 없어졌다. 내 프로그램 역시 MS IME와 완전히 동일한 방식으로 자유자재로 텍스트를 조작하면서 원하는 때에 후보 변환 UI를 modal 형태든 그렇지 않은 형태든 꺼낼 수 있다. 단, 실제로 MS IME와 동일한 방식으로 동작하는 기능 자체는 당장 반영되지 않았고 <날개셋> 한글 입력기의 소스 내부에 #ifdef ... #endif의 형태로 막혀 있다. 일단은 이론적으로 구현 가능해졌다는 것만 입증하고 넘어갔다.

<날개셋> 입력 패드에 후보 변환 기능은 이런 최신 프로토콜을 기반으로 구현되었다. 외부 모듈에 존재하는 후보 선택 UI를 그대로 가져다 쓰는 것을 고려했지만 현실에서의 여러가지 문제점으로 인해 그렇게 하지 않고 또 자체 구현을 했다. 외부 모듈의 후보 선택 UI는 운영체제의 프로토콜과 맞물려서 패드에는 필요하지 않은 오버헤드가 너무 많기 때문이었다.

사용자 삽입 이미지

입력 패드의 후보 선택 UI는 <날개셋> 한글 입력기의 GUI 엔진이 자체 제공하는 리스트박스 컴포넌트를 이용하여 최대한 간결· 단순하게 구현되었다. 외부 모듈의 것과 거의 동일하지만 확장 모드(tab 키)는 지원되지 않으며, 세로쓰기 모드의 지원도 기술적으로 불가능하지는 않으나 구현을 과감히 생략했다.

그 대신 입력 패드의 후보 리스트는 스크롤 막대를 마우스로 누르거나 끌어 보면, 줄 단위 스크롤이 가능하여 좀 더 직관적이라는 차이가 존재한다. 외부 모듈의 그것은 언제나 페이지 단위 스크롤만 된다. 물론 마우스가 아니라 키보드 화살표로 선택막대를 움직이면 페이지 단위로 스크롤된다. 페이지 단위로 이동 후 1~9 숫자를 선택하는 동작도 여전히 고려했기 때문이다.

후보 UI를 구현할 때 같이 구현돼야 하는 중요한 요소 중 하나는 후보 윈도우를 어디에다 표시할지를 결정하는 것이다. cursor 근처 아래에다가 표시해 주는 게 원칙인데, 이걸 hook 프로시저를 통해 알아 와야 한다. 이때는 IME 쪽 인터페이스만 사용하는 게 아니라 오버헤드를 감수하고라도 정확도의 향상을 위해 TSF 인터페이스도 사용한다. 훅킹으로 응용 프로그램에서 TSF edit session까지 요청해 보는 것은 처음이어서 프로그래밍이 굉장히 흥미로웠다. 32비트와 64비트를 구분 없이 모두 잘 지원하는 건 물론이고.

단, 이미 사용하고 있는 시스템의 IME가 한영 내지 한자 키를 가로채고 있으면 키보드 입력 모드에서도 이 입력 패드가 그 key들을 가로챌 수 없다. 그러므로 입력 패드에서 한자 변환을 하려면 F9 같은 다른 위치에다가 C0|0x82 같은 후보 변환 기능을 배당해 놓고 있어야 한다.

3. 글꼴 쪽의 변화

'한메가는본문'이라고 타자기 자형처럼 생긴 한글 글꼴이 지금까지 있었다. 개인적으로는 이것과 Lucida Console 영문 글꼴이 같이 잘 어울린다고 생각했는데, 이번 8.2에서는 이것과 같은 계열인 '한메굵은본문'이 추가되었다. 도스용 한메한글이 출력하던 글꼴을 그대로 재현한 것이다.

한메 계열 글꼴은 초성 5, 중성 2, 종성 3벌로 되어 있어서 도깨비 8*4*4보다 구조가 더 간단하다. 특히 '고'의 ㄱ과 '공'의 ㄱ이 동일해서 더욱 타자기 글꼴 같은 느낌이 나지만, 그렇다고 진짜 샘물이나 타자기 계열만치 과격한 모양은 아니다. 또한, '한솔바탕'과도 좀 비슷해 보이지만 그래도 엄연히 차이가 느껴진다.

그리고 이번에 굵은본문을 분석하고 추가하는 과정에서, 기존 가는본문의 조합 규칙이 몇 년째 잘못되어 있던 것도 같이 발견하여 고쳤다. 당장 '메' 자를 보면 차이를 발견할 수 있다.

사용자 삽입 이미지

잘 알다시피 <날개셋> 한글 입력기는 컴퓨터에서 한글을 '입력'하는 모든 아이디어와 기술을 구현하는 기반 시스템이다. 그런데 편집기는 다른 구현체와는 달리 독자적인 한글 글꼴 출력 시스템도 갖추고 있으며, 특별히 과거에 존재했던 다양한 독창적인 비트맵 글꼴들을 몽땅 한데 재현하는 일에도 덤으로 관심을 두고 있다. 아래아한글, Windows 3.x, mshbios 등. 입력 방식뿐만 아니라 글꼴도 보존 가치가 있는 옛날 데이터가 또 발견된다면 얼마든지 채택되고 추가될 것이다.

그리고 이번 버전에서는, 겉으로 차이가 느껴지지는 않겠지만 글꼴의 전반적인 로딩 방식을 memory-map 기반으로 바꿨다. 그래서 여러 프로그램에서 <날개셋> 한글 입력기 외부 모듈을 사용하고 있고 여러 프로그램들이 동일한 한자 글꼴 같은 걸 중복해서 로딩하더라도, 메모리가 제각각 따로 할당되는 게 아니라 1파일 1메모리가 보장되어 더 효율적으로 동작하게 했다. 뭐, 요즘처럼 메모리가 넘치는 환경에서는 겨우 16*16 비트맵 글꼴 나부랭이는 중복 로딩을 한다 해도 별 부담이 되진 않겠지만 말이다.

4. 변수 N의 의미 확장

기본 입력 스키마가 글쇠배열에다 제공하는 변수로는 P (caps lock 여부), N (num lock 여부), T (오토마타의 조합 상태), D~F (입력 중인 한글 자모)가 있다. T, D~F는 정수인 반면 P와 N은 일종의 0 아니면 1의 boolean값이었다.
그런 키보드 램프의 상태에 따라 서로 다른 문자를 되돌리고 싶으면 해당 변수 값을 토대로 ? : 조건부 수식을 지정하면 된다. caps lock은 그렇다 치더라도 num lock의 경우, 세벌식 글쇠배열의 숫자 자리를 키패드처럼 바꾸는 용도로도 활용할 수 있어서 매우 편리하다.

본인은 이 생각을 아주 오래 전부터 했기 때문에 저건 <날개셋> 한글 입력기의 1.0때부터 있던 기능이었다. 단지 그때는 지금 같은 입력 스키마와 문자 생성기의 계층 구분이 없었기 때문에, 그 기능이 입력 스키마의 변수가 아니라 그냥 입력 옵션 중 하나로 제공되었을 뿐이다.

그런데 이번 버전에서는 옵션을 추가로 줄 경우, N에 num lock (비트 1)뿐만 아니라 scroll lock (비트 2)도 같이 줄 수 있게 했다. 이 옵션이 지정되어 있으면 N은 앞으로 키보드의 상태와 관련된 다른 유의미한 비트 플래그가 도입될 경우 4, 8, 16 같은 식으로 의미가 계속 추가될 것이다.

scroll lock은 사실 굉장한 잉여 램프로 전락해 있으며 caps lock만치 문자 입력에서 중요한 역할을 하지는 않는 게 현실이다. 그렇기 때문에 별도의 독립된 변수를 할당하지는 않고 기존 N에서 비트만 추가하는 것으로 의미를 정했다.
그래도 기능을 일단 만들어 놓으면 이것도 아주 창의적으로 활용하는 사용자가 분명 있으리라고 생각된다.

따라서 이 옵션을 켠 상태에서 num lock만 인식하려면 글쇠 수식을 N ? A: B 이렇게 작성할 게 아니라 번거롭지만 N&1 ? A: B라고 써 줘야 한다.
세벌식 키패드 수식을 생성해 주는 빠른설정 기능은 여기에 맞춰 &1이 추가되도록 알고리즘이 수정되었다.

5. 키보드 드라이버 보정

이번 버전에서는 입력기나 편집기 계층이 아니라 시스템 계층에서 꽤 참신한 기능이 하나 또 추가되었다. 바로 키보드 드라이버의 글쇠 인식을 인위적으로 변조하는 기능이다.
내 프로그램의 내부에는 Shift+Space를 '한영'으로 바꿔서 인식하는 type-3 키보드의 동작을 도로 무효화하는 보정이 있었다. 그런데 이 로직이 편집기와 외부 모듈과 패드의 구현체에 몽땅 중복으로 존재하며, 이것도 켜거나 끌 수가 있게 해야겠다는 생각에 별도의 계층으로 빼냈다.

그리고 type-3 보정뿐만 아니라 type-1 보정도 추가했다. 바로, 오른쪽 Ctrl/Alt를 한영/한자가 아니라 있는 그대로 인식하는 것 말이다. 이로써 한국어 키보드에서도 Ctrl/Alt의 좌우 구분이 가능해졌다. 물론, 아무 보정을 하지 않는 것도 가능하고 말이다. 왜 이런 유용한 기능을 진작에 넣지 못했나 하는 아쉬움이 느껴진다.

그리고 여기서 키보드 드라이버 보정을 한 것은 물론 응용 프로그램이 아니라 <날개셋> 한글 입력기 내부에서만 통용된다. type-1 보정을 했다고 해서 오른쪽 Alt로 응용 프로그램의 메뉴를 바로 열 수 있는 건 아니다.

시스템 계층 설정에는 지금까지 글꼴과 관련된 설정과 기능 몇 가지만 있었는데 '보정 없음, type 1, type 3'이라는 세 항목 중 하나를 선택하는 UI도 추가되었다.
시스템 설정의 내용은 사용자 컴퓨터의 레지스트리에 저장되지, ist/st 같은 파일에는 저장되지는 않는다. '미저장 확인'을 누르면 해당 프로그램이 실행되어 있는 동안만 유효하니, '확인'을 눌러야 레지스트리에까지 저장되어 다음에 프로그램을 재실행할 때도 반영된다.

6. 키패드 글쇠와 키보드 글쇠의 구분 기능

Scroll lock 지원과 키보드 드라이버 보정. 이번 버전엔 어쩌다 보니 키 입력 인식과 관련된 기능이 여럿 추가됐는데, 이것만 들어가기에는 좀 아쉽다.
이번 8.2에서는 <날개셋> 한글 입력기의 개발 역사상 최초로 일부 글쇠에 대해 키패드 글쇠와 키보드 글쇠를 구분해서 인식할 수 있게 되었다.

그 대상은 바로 상하좌우 화살표(4) + Home/End/Pg Up/Pg Dn(4) + Ins/Del(2) + 엔터 이렇게 총 11개이다.
단축글쇠 배당 대화상자를 열어서 이들 키를 누르면.. 오른쪽에 종류를 묻는 콤보 상자가 추가로 뜬다. 사용자는 종전처럼 "구분 없이 아무 거나 인식"을 선택해도 되고, 키보드 것만 혹은 키패드 것만 인식하게 설정할 수 있다. 문자 키와 키패드 사이에 따로 몰려 있는 구역도 '키보드' 영역이다.

그리고 고급 입력 스키마에서는 바로 N 변수에서 1(num lock), 2(scroll lock)에 이어 4가 이 글쇠의 변별을 담당한다.
Windows의 키보드 메시지에서 extended key 플래그가 바로 여기에 전달된다. 다른 글쇠들은 키보드 글쇠일 때 플래그가 켜져 있지만, 엔터만 유일하게 키패드 글쇠일 때 플래그가 켜져 있다. 여기에는 사연이 좀 있다.

extended key란 예전의 84/86키 키보드에는 없다가 지금과 같은 101/103키 키보드에서 중첩되어 새로 추가된 key를 나타내는데, 예전에는 키패드에 엔터가 없다가 나중에 키패드에 새로 추가됐기 때문이다.
그 반면, 나머지 home, end 같은 건 원래 키패드에만 있다가 나중에 별도의 구역이 또 추가된 것이기 때문에 '키보드'에 속하는 구역의 글쇠들이 extended이다.

아무튼 이런 옵션과 변수를 통해서 단축글쇠와 고급 입력 스키마에서 모두 키보드와 키패드를 구분해서 글쇠를 인식할 수 있다.

7. 보조 입력 도구

끝으로, 사소한 사항으로는..
보조 입력 도구인 '부수로 한자 입력'에서 부수나 한자를 우클릭했을 때 해당 글자를 클립보드에 복사하는 명령을 추가했다. 지금까지는 이 명령이 문자표에만 있지 부수 한자 입력에는 없었다.

그리고 문자표에는 알다시피 문자를 운영체제의 특정 글꼴로 출력하거나 내장 비트맵 글꼴로 출력하는 옵션이 있는데, 제어판의 시스템 계층에서 설정된 그 후보 출력용 글꼴을 지정하는 옵션도 추가했다. 지금까지 이런 기능이 왜 없었는지 모르겠다.
이들 보조 입력 도구는 지금으로부터 5~6년 전, 5.5x 시절에 처음으로 도입되었다. 참 격세지감이다.

위의 신규 기능들을 구현하는 과정에서 꽤 황당한 버그가 오랫동안 남아 있던 것을 발견했다.
원래 날개셋 제어판을 열었다가 '확인'을 눌러서 닫으면 입력 설정만 저장되는 게 아니라 모든 플러그 인들의 설정도 파일로 저장된다. 텍스트 필터들의 내부 설정들이 여기에 포함되며, 문자표는 사용자가 예전에 선택한 글꼴과 view 모드를 이 방식으로 기억하고 있는다.
그런데 64비트 에디션은 그런 플러그 인 기능들을 설정을 변경한 뒤 사용하고, 날개셋 제어판을 '확인'을 눌러서 닫았는데도 해당 프로그램(편집기 같은..)을 재실행했을 때 예전 설정이 보존되어 있지 않았다. 파일 오프셋과 관련된 착오가 있는 것을 확인해서 즉시 고쳤다.

Posted by 사무엘

2015/10/27 08:22 2015/10/27 08:22
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1153

Trackback URL : http://moogi.new21.org/tc/trackback/1153

Comments List

  1. 박한철 2015/10/27 14:45 # M/D Reply Permalink

    이번에도 많이 애쓰셨습니다~ 단축글쇠 배당하다 보니 pgup 을 누르면 Num 9 로 인식되었던 게 키패드 글쇠와 구분을 두지 않으셔서 그랬던 것이군요!

    1. 사무엘 2015/10/27 18:55 # M/D Permalink

      예, 그쪽 글쇠는 운영체제가 보내 준 추가 정보를 참고하지 않으면 기본적으로 키보드 것이나 키패드 것이나 모두 동일한 것으로 인식됩니다.
      이번 8.2 버전은 문자 입력 내부 아키텍처나 한글 조합 쪽보다는 글쇠 자체의 인식과 관련된 기능이 추가된 게 많았지요.
      다음 버전은 다시 아키텍처 쪽 공사가 진행될 겁니다.

  2. ㄱㄴㄷㄹ 2015/10/28 11:54 # M/D Reply Permalink

    정말 항상 감사드립니다
    김용묵님 같은 열정적인 분이 계셔서 참 다행이라는 생각이 듭니다

    1. 사무엘 2015/10/28 17:16 # M/D Permalink

      '한글스러운' 닉이 인상적입니다.
      저도 감사드립니다. 프로그램을 유용하게 사용하시고 세벌식 자판과 함께 많이 알려 주셨으면 합니다. ^^

  3. 신세기 2015/10/29 21:50 # M/D Reply Permalink

    안녕하세요? 날개셋 입력기의 버전을 업데이트 해 주셔서 감사합니다.
    그리고 Scroll Lock의 여부를 확인하는 변수를 추가해 주셔서 감사합니다.
    Scroll Lock 을 사용할 수 있게 되었으니, Caps Lock 은 Shift Lock 의 기능으로 사용하고,
    Scroll Lock 은 특수기호를 확장하거나 현대한글/옛한글 입력 모드 전환에 사용하려 하고 있습니다.
    편리한 기능을 추가해주셔서 감사합니다 ^^

    오늘 밤도 평안한 밤 되세요!

    1. 사무엘 2015/10/29 23:32 # M/D Permalink

      네, 새 기능을 창의적으로 마음껏 활용하셨으면 합니다. ^^
      입력 스키마의 '글쇠 인식 옵션'에서 'N 변수에 scroll lock 정보도 넣기' 옵션을 지정하시는 것 잊지 마시고요.

  4. 신세기 2015/10/30 17:27 # M/D Reply Permalink

    일러주셔서 감사합니다. 글쇠 인식 옵션에 체크하는 걸 생각 못 했었어요 ^^;

Leave a comment

Windows 10 사용기 외

1. Windows 10

그 이름도 유명한 Windows 10을 본인도 드디어 입수했다. Mac OS와 Windows 모두 10을 최종 메이저 버전으로 설정했다는 게 무척 흥미롭다.

개인 컴은 물론이고 회사 컴도 평소에 활발하게 쓰던 물건은 "Windows 10 다운로드 준비가 끝났는데 설치할까요?"가 진작부터 뜬 반면,
평소에 잘 안 쓰고 "여기에나 한번 10을 깔아 볼까?"라고 정작 비워 놨던 컴은 한참을 기다려도 Windows 10 설치 말이 없었다. "준비되면 알려 주세요"를 몇 번이나 클릭했는데도 감감 무소식. 이것도 평소에 로그인 횟수나 네트워크 트래픽을 감안해서 업데이트 순서를 짠 건지는 모르겠다.

참다못해 Windows 10 설치 프로그램을 직접 다운로드 해서 실행한 뒤에야 운영체제를 7에서 10으로 바꿀 수 있었다. 다운로드와 설치는 물론 금방 끝난 건 아니지만, 그렇다고 Windows 8.1을 설치하던 시절보다 터무니없이 오래 걸리지는 않았다.

설치 직후에는 바탕 화면의 personalize가 되지 않았다. 인증이 필요하대서.. "으잉? Windows 10은 완전 무료 아니었나? 자동 업데이트를 안 하고 수동 설치를 해서 그렇나?" 어리둥절했는데 재부팅을 한번 하고 나니 인증은 저절로 패스 됐고, 까맣던 배경 그림은 10을 설치하기 전의 모습으로 되돌아왔다.

비주얼에 대한 소감은..
프로그램의 제목이 가운데가 아니라 왼쪽 정렬로 돌아왔으며, 글씨 크기도 약간 더 크다가 다시 메뉴 글씨 크기와 동일하게 돌아왔다. 또한 화면을 부분만 차지하는 시작 메뉴가 되돌아왔으며 프로그램 창 주변에 그림자 그러데이션이 생긴 것은 일면 과거의 Windows Vista/7 시절로의 회귀를 떠올리게 한다.
창의 최소/최대화와 닫기 버튼이 굉장히 커지긴 했는데 정작 _ □ X 모양은 너무 대충 그려 넣은 듯. -_-;;

명령 프롬프트가 가로폭 조절이 가능해진 것이 무척 인상적이다. 하지만 글꼴은 여전히 제대로 customize가 안 된다. 하다못해 먼 옛날 9x 시절에는 코드 페이지가 무엇이냐에 따라 Courier New나 Lucida Console이라도 볼 수 있었는데 너무 칙칙한 글꼴은 오히려 NT 계열이 9x보다도 퇴보했다.

운영체제를 업데이트 한 직후, 이전까지 사용하던 프로그램들은 10에서도 거의 그대로 곧장 사용이 가능했다. 그러나 <날개셋> 한글 입력기는 편집기만 남아 있고 외부 모듈은 운영체제의 IME 목록에서 사라졌다.
허나 이건 프로그램을 재설치만 하면 해결되니 그리 심각한 문제는 아니다. 또한 지금까지 파악한 바로는 Windows 10은 문자 입력에 관해서 딱히 기술적으로 크게 바뀐 게 보이지 않는다. 심지어는 세벌식 파워업도 10의 MS 한글 IME를 대상으로 잘 동작한다.

2. <날개셋> 한글 입력기에서 발견된 문제

다만, <날개셋> 한글 입력기가 Windows 10에 대비하여 개선해야 할 사항은 크게 두 가지가 발견됐다.

(1) 첫째, Windows 10은 Metro 앱도 데스크톱에서 뭔가 일체형으로 연계하며 동작하게 된 듯하다. Windows 10의 상징이라 해도 과언이 아닌 엣지(Edge) 브라우저도 기술적으로는 Metro 앱이다. Metro 모드에서는 클래식 데스크톱 GUI를 사용하는 기능들이 동작하지 않는다. 고로 <날개셋> 제어판이나 About 대화상자 같은 것도 못 띄운다. (그걸 시도하면 그냥 씹히거나 프로그램 전체가 그냥 튕긴다)
8 시절에는 메트로 앱들은 데스크톱의 입력 도구모음줄에 접근을 할 수 없으니 신경 쓸 필요가 없었는데, 이제는 메트로 모드에서는 이런 기능들을 건드릴 수 없도록 도구모음줄 버튼이나 메뉴를 흐리게 처리해 줘야겠다.

날개셋 말고 다른 IME들은 이 문제를 어떻게 해결했느냐 하면 한글 IME는 아예 대화상자가 출력되는 명령들을 모조리 없애 버렸다. 심지어 8에는 있던 About 명령조차도 없앴다. 일본/중국어 IME는 GUI가 나오는 기능들은 몽땅 다른 프로그램을 통해 실행되게 되어 있다.

사실, 한글 IME도 부수/획수 한자나 필기 인식 같은 보조 입력 도구는 별도의 프로그램을 통해 구동한다. 그러나 내 프로그램은 이런 것들이 다 in-process 형태로 구동된다. 그래서 Metro 모드 같은 데서는 여러 제약이 걸리는 것 같다. 금방 해결 가능한 문제는 아닌 것 같고 프로그램 구조를 앞으로 어떻게 유지할지 생각을 해 봐야겠다.
참고로, 엣지 브라우저 자체는 크롬의 마소 버전이라고 생각해도 좋을 정도로 "빠르고" 산뜻해서 느낌이 굉장히 좋았다. 그거 하나는 인정한다.

(2) 둘째, 엣지에서 페이스북에 접속해서 댓글을 써 보니, 한참 글자를 입력하다가 비한글 문자를 입력하는 순간, 예전에 입력 중이던 글자가 몽땅 사라지는 문제가 있었다. "가을에." -> "에."만 남는 식.
또한 명령 프롬프트에서도 내 프로그램으로 한글을 입력해 보면, 조합하던 글자가 덮어써진다. "가" "가을" "가을에"가 되는 게 아니라 "가" "을" "에". 신기하게도 MS IME로 한글을 좀 입력하다가 다시 날개셋으로 돌아오면 명령 프롬프트는 이 문제가 없어짐.

100% 재연 가능하고, MS IME는 안 그런데 내 프로그램만 그렇고.. 현상 자체는 완벽하게 파악이 됐지만 이건 또 MS가 무슨 농간을 부린 건지 허무한 생각이 든다. 아마 둘 다 같은 원인 때문일 거라고 추측만 하는데.. 제일 골치 아픈 부류의 문제이며 해결이 쉽지 않을 수도 있다.

3. key의 인식 방법과 관련된 customization

이건 Windows 10과는 관계가 없는 다른 얘기이다.
<날개셋> 한글 입력기는 한글을 생성하기에 앞서서 key 입력을 인식하는 방식 자체를 사용자화 가능하다. 크게 다음과 같은 시나리오가 있다.

(1) 원래는 먹던 특정 key를 먹지 않게 할 수 있다: 표준 두벌식의 경우 오로지 A~Z 26개 key만 사용하기 때문에 나머지 숫자와 기호는 따로 IME가 가로채는 게 아니라 그냥 응용 프로그램으로 넘겨서 숫자나 기호를 입력하게 한다.

(2) 원래는 먹지 않던 특정 key를 IME 입력으로 바꿀 수 있다: space의 경우, 굳이 IME가 처리할 필요가 없는 key이다. 하지만 인디자인 버그 같은 걸 해결하기 위해서 IME가 굳이 가로채어 공백을 되돌리게 할 수 있다.

(3) 특정 key를 IME 입력 대신 다른 key로 바꿀 수 있다: 내 프로그램으로 드보락 글쇠배열을 사용하는 경우, 보통은 드보락 방식대로 IME가 알파벳을 보내게 한다. 하지만 글쇠 누름 날개셋문자를 사용하면 아예 해당 알파벳 key 입력을 응용 프로그램에다가 보내게 할 수도 있다.

쉽게 말해 비한글 알파벳이나 공백 같은 문자를 IME 방식으로 보내느냐, 그렇지 않고 더 원초적인 key 메시지 형식으로 보내느냐를 제어할 수 있다는 뜻이다.
단축키 같은 것은 key 입력 메시지 형태로 온 것만 인식되지 IME 방식으로 전달된 문자로는 인식되지 않는 경우가 많기 때문이다. MS Excel의 경우, 영문을 key 입력 형태로 입력했을 때에만 함수의 목록 자동 완성이 처리되지만 IME 방식으로 입력된 것에는 반응하지 않는다.

(1)과 (2)는 6.5 버전에서 기본 입력 스키마에 해당 기능이 추가되고 구현됐다. 한편, '글쇠 누름' 날개셋문자는 비교적 최근인 7.9 버전에서 추가되었다.
현재 개발 중인 8.2 버전은 (3)이 소개하는 '글쇠 누름' 날개셋문자의 사용을 홍보하기 위해, 제어판의 글쇠배열 편집 창에서 숫자/문자를 입력하는 '일반 문자' 날개셋문자를 그에 상응하는 '글쇠 누름' 날개셋문자로 자동으로 모두 바꾸는 기능을 추가했다.

그리고 더 간단히, 사용자가 누른 key에 해당하는 글쇠 누름 날개셋문자를 자동으로 입력시키는 모드도 추가했다. 예전에는 세벌식 한글, 두벌식 한글, 이동, 영문 알파벳 같은 모드가 있었는데 그런 것처럼 새로운 모드를 넣었다는 뜻이다. 아주 자연스럽게 기능 확장이 가능하다.

또한 (2)를 더 쉽게 설정할 수 있게 하기 위해, 단축글쇠를 입력받는 대화상자에다가는 지금 누른 가상 키코드의 문자값에 해당하는 '일반 문자' 날개셋문자를 자동으로 배당하는 기능도 추가했다.
알파벳이나 숫자를 key 입력으로 보내는 것과 IME 문자열로 보내는 것의 차이에 대해서는 도움말에다가도 더 자세한 설명을 넣을 예정이다.

4. 고기 먹고 싶음 -_-

아직 어쩔 수 없는 여름이긴 하지만 그래도 날씨가 예전보다 덜 더워져서 무척 좋다.
난 어릴 때부터 왜 태양이 긍정적인 심상이고 그늘이 부정적인 심상인지를 이해를 못 했을 정도로 몸에 열이 많고 더위를 싫어했다.

이제 좀 가을이 되고 나면 날씨 탓할 일 없이 더 집중해서 코딩을 진행하고 싶은데.. 프로그램 완성의 꿈은 요원하기만 하다.
도깨비불 현상 없는 입력 방식이 심리적으로 무척 도움이 된다. 세벌식은 없어질래야 없어질 수 없고 없어져서는 안 되는 한글 입력 방식이다. 뭐 그건 그렇고..

사용자 삽입 이미지
나만 저렇게 생각하는 게 아니었구나.
돼지는 훌륭한 단백질 공급원이고, 단백질은 훌륭한 스트레스 해소원이다.

사용자 삽입 이미지
그래서 위대한 령도자 세종대왕도 약을 빨거나 한 건 아니고 고기를 드시면서 한글을 창제하시였다. 한글이 없었으면 내 프로그램도 없었겠지.
(다만, 그 덕분에 저분은 세자 시절부터 굉장한 비만이었으며, 당뇨 같은 성인병도 평생 달고 살았다고 함. 본인도 키에 비해서는 좀 과체중인 상태..;;)

Posted by 사무엘

2015/08/28 08:31 2015/08/28 08:31
, , ,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/1132

Trackback URL : http://moogi.new21.org/tc/trackback/1132

Comments List

  1. 사무엘 2015/09/12 23:35 # M/D Reply Permalink

    다음 버전에서 Windows 10 관련 반영된 사항은..

    1. Metro UI에서는 제어판, 텍스트 필터 등 데스크톱 GUI를 사용하는 기능들을 모두 사용할 수 없게 메뉴 차원에서 막음. 어차피 동작하지 않으므로.

    2. Windows 10은 명령 프롬프트가 굉장히 많이 바뀐 듯함. Metro가 아님에도 불구하고 제어판을 띄우면 뜨지 않을 뿐만 아니라 에러가 났던 문제 해결. 예전에는 없어도 되던 안전 루틴이 필요해짐.

    3. 명령 프롬프트에서 한글 조합 진행이 더 되지 않던 문제 해결.
    A처럼 동작하면 이 프로그램에서 안 돌아가고, B처럼 동작하면 저 프로그램에서 안 돌아가는 정말 엿같은 상황이 있는데.. 지금까지는 명령 프롬프트만을 위한 전용 로직이 있었다.
    그런데 Win10은 명령 프롬프트에서도 자기가 명령 프롬프트라고 알려 주지를 않아서 문제가 발생하고 있었음. 다른 방법으로 문제를 피해 갔지만, 또 다른 프로그램에서 오동작이 발생할 가능성이 있음.;;

    단, Edge에서 페이스북의 댓글란에서 한글 입력이 씹히고 오동작이 발생하는 것은
    거의 1주일이 넘는 디버깅과 테스트, 문자 조합 루틴을 다시 짜 보는 생쑈에도 불구하고 원인 불명 해결 불가로 결론을 내렸습니다. 도대체 MS IME와 제 프로그램이 동작 방식이 뭐가 달라서 저렇게 되는지 알 수 없습니다. Edge의 버그라는 가능성을 더 높게 칩니다.

Leave a comment

다음 버전 개발 근황 약간

요즘 날씨는.. 최악의 불볕과 최악의 찜통은 별개 개념이라는 걸 온몸으로 입증해 보이는 듯하다. 미치겠다.;;
이렇게 이번 여름방학도 벌써 절반이 넘게 지났고 <날개셋> 한글 입력기 8.0이 나온 지도 역시 한 달이 좀 넘었다. 그 동안 서적 번역 등 다른 일에 관심이 쏠려 있어서 방학 전반부 동안은 사소한 이슈 말고 굵직한 기능을 설계하고 구현하는 코딩은 거의 못 하고 지냈다.

그래도 지금까지 지켜본 바로는 8.0은 별다른 새로운 버그 없이 높은 완성도로 잘 만들어졌다. 이 프로그램도 가까운 미래에는 꿈에도 그리던 전체 신규 기능 개발 완료와 고정· 정착 단계에 진입하는 게 아주 요원한 꿈은 아닐 것 같다.
국민 교육 헌장을 보면 "안으로 자주독립의 자세를 확립하고, 밖으로 인류 공영에 이바지할 때"라고 나와 있는데, 실상은 "안으로는 약 빨고 밖으로는 외계인 고문을 일삼으면서" 결과물을 내야 할 거 같다.

본인은 석사를 졸업한 지 이제 3년이 지났다.
석사 논문은 아시다시피 저 입력기의 이론적 배경과 구조, 주요 기능이 주제였다. 지금 동일 주제로 논문을 다시 쓰면 그때보다 수십까지는 아니어도 10수 페이지 정도는 더 써 넣을 분량이 있다.

가령, 다음 글자로 넘어갔을 때도 초성이 아니라 변함없이 종성 문맥으로 동작하는 '종성 지향 두벌식'은 6.7 버전에서 첫 도입되었으며 <날개셋> 한글 입력기의 역사에서 무척 중요한 위치를 차지하는 기능이지만, 논문이 다 완성되고 졸업하자마자 그 직후에야 추가된 기능이다. 그러니 논문엔 못 들어갔다.

7.9와 8.0대에서는 종성 지향 두벌식의 정반대 이념이며 두벌식 연구자의 떡밥이던 '초성 지향 두벌식'까지 추가되었다. '살 → 사라'가 아니라 반대로 '사ㄹ → 살ㅈ' 이런 식으로 되는 입력 방식 말이다.
전자는 별도의 날개셋문자 타입으로 구현된 반면, 후자는 '고급 입력기'가 제공하는 낱자 치환 옵션의 일환으로 구현되었다. 기술 계층이 서로 완전히 다른 것이다.

또한 그때 이후로 키보드 입력이라는 물리적인 프로세스 자체에 대한 기술적 이해도가 더 깊어진 덕분에, 키 입력을 흉내 내는 기능이 독립된 날개셋문자 타입으로 추가되었다. 최근에는 입력 패드 구현체가 그런 키보드 입력이 드디어 지원되기 시작한 쾌거도 이뤘다.
이런 것들이 논문에 더 들어갈 수가 있었다는 뜻이다. 박사 졸업 이수 요건에 속하는 학술지 소논문에 이런 걸 적절히 투고할 방법이 있으면 좋겠다. 엄연히 국어 정보학과 관련된 개인적인 연구 실적이니까.

  1. 한글의 고유한 특성과 활용 가능성: 한글은 IME가 필요한 복잡한 스케일의 문자이지만 중국· 일본어처럼 문장 단위가 아니라 1글자 단위로만 조합을 잡으면 된다. 이렇게 한글 같은 문자만이 처해 있는 특수한 상황에서 IME만이 제공할 수 있는 여러 편의 기능이 있을 것이다.
  2. 세벌식의 우수성: 두벌식은 자음 종류 구분과 음절 경계 구분을 위한 온갖 테크닉이 필요하다. 그러나 세벌식은 그게 기본적으로 되기 때문에 타자기나 두벌식에서는 불가능한 다른 응용 기능을 언어 의존적인 데이터 없이 바로 구현할 수 있다. PC에서 세벌식 입력 방식이 없다는 건 말이 안 된다.
  3. 이 시스템의 엔진의 독창성: 한글 입력 방식을 규정하는 모든 세부적인 동작을 customize할 수 있으며, 그 과정에서 두-세벌의 중간에 속하는 입력 방식도 구현 가능하다.
  4. 이 시스템의 구현체의 독창성: 이 엔진을 편집기, IME, 입력 패드라는 다양한 기술적인 구현체를 통해 제공한다.

지금 논문을 다시 쓴다면 내가 주장하고자 하는 바를 위와 같은 네 카테고리로 더 분명하게 구분해서 깔끔하게 결론이나 초록을 썼지 싶다. 뭐 그건 이미 다 지난 일이고...
난 다음 박사 논문을 위해서는 "한글의 고유한 특성과 활용 가능성"이라는 기본 명제는 동일하지만, 입력이 아닌 출력에 속하는 한글 글꼴과 관련된 연구를 할 생각이다. 그러니 입력기는 빨리 마무리를 좀 지어야 한다.

논문 얘기가 너무 길어졌는데, 어쨌든 <날개셋> 한글 입력기의 다음 버전에서 만날 수 있는 사소한 변화들을 늘어놓으면 다음과 같다.

1. 이제는 프로그램을 설치할 때, 원하는 구현체만 선택해서 설치할 수 있게 했다.

사용자 삽입 이미지

세 구현체들의 특징은 다음과 같이 표로 일목요연하게 정리된다.

항목 편집기 외부 모듈 입력 패드
형태 EXE (32/64비트 하나만) DLL (32/64비트 모두) EXE+DLL (각각 32/64비트 모두)
도스용 프로그램에 비유 자체한글 에디터 한글 바이오스 (입력 부분만) 램 상주 키보드 인터럽트 유틸리티
기능 지원 범위 오로지 자기 내부 자기를 사용하는 타 프로그램 내부 실행 중인 모든 프로그램들
TSF A급 O △ (동작 환경에 따라 다름) X
Alt 지원 O X O
특이사항 자체 옛한글 글꼴, 텍스트 필터, 키 입력으로 붙여넣기. 성능 오버헤드가 가장 작음 명령 프롬프트 및 Metro UI에서 유일하게 동작 가능 구현체들 중 크기가 가장 작고 가벼움. 키보드 모드는 옵션으로 제공


2. 웹 브라우저 같은 외부 프로그램의 텍스트를 <날개셋> 편집기의 빈 문서 창에다가 drag & drop을 하고 나면 가끔 편집기의 프레임이 고전 테마 형태의 이상한 모양으로 일시적으로 바뀌는 문제가 있었다. 개인적으로는 운영체제의 버그에 가깝다고 생각하는 현상이지만 Windows Vista부터 8.1까지 일관되게 발생하는 현상이고, 또 문제를 회피하는 방법도 있으므로 그걸 적용했다.

사용자 삽입 이미지

3. 도움말에서 "외부 모듈 → 알려진 버그" 부분에, 키보드 보안 프로그램으로 인한 오동작 가능성을 더 자세히 언급했다. 이런 문제가 있을 수 있는 프로그램은 크게 "IE 브라우저"뿐만 아니라 요즘은 "온라인 게임"이 더 중요하다. IME도 나름 키보드 입력을 가로채는 프로그램이다 보니, 디지털 서명이 없는 날개셋 같은 프로그램을 여타 보안 프로그램이 차단할 수도 있다.
5년 전에 스타크래프트 2가 출시 직후에 이와 관련된 대표적인 문제를 일으켰었는데, 앞으로 다른 게임에서 이런 부류의 문제가 계속 보고될 수도 있다.

4.
얼마 전, 인디자인 9에서 한글 입력과 관련된 귀찮은 문제가 출판 디자인 업계에서 거론된 적이 있었다. 한글 조합 중에 space, tab 등의 글쇠를 누르면 원래는 한글 조합도 중단되고 해당 글쇠 문자도 뒤에 입력이 돼야 한다. 그런데 인디자인은 이때 조합만 중단되고 해당 글쇠는 씹히기 시작했다. 그것도 예전엔 안 그러다가 최신 버전에서 갑자기 그러기 시작했다. space/tab이 아니라 IME가 인위적으로 처리를 하는 비한글 문자는 씹히는 문제가 없었다(세벌식 자판의 숫자처럼).

그런데 이와 비슷한 문제가 MS Word에서도 부분적으로 발생한다는 것이 최근 확인되었다. "고급 입력기"가 제공하는 사용자 정의 조합이나 한글 출력 치환 기능을 이용해서 평범한 알파벳이나 숫자를 조합하는 상태를 만들고 나면, space, tab을 눌렀을 때 조합만 종료되고 해당 글쇠는 씹힌다. 그 반면, 한글이나 전각, 특수문자, 2글자 이상의 긴 조합을 만들고 있을 때는 그런 현상이 없다! 간단히 "일본어 히라가나/가타카나" 예제 유형만 MS Word에서 사용해 봐도 확인 가능하다.

TSF를 지원하는 다른 모든 프로그램들은 안 그러는데 오로지 MS 워드만 왜 저러는지 나로서는 알 길이 없다. 아니, 애초에 왜 그 타가 씹힐 수가 있는지도 이해가 안 되지만.. 문제의 증상과 해결(회피) 방법이 인디자인과 Word가 동일하기 때문에 도움말에 동일한 항목으로 보충 설명을 넣었다.

5.
끝으로, 시대가 시대이다 보니 About 대화상자에 Windows 10을 인식하는 데이터도 추가했다.
그리고 외부 모듈에서 옛한글을 사용하는 것과 관련된 추가 설명을 UI나 도움말에 넣었다. (시스템 계층에서 한글 표현 방식도 제대로 설정했는지 확인하라, 옛한글 글쇠배열을 가져오기만 하는 것과 빠른설정으로 총체적으로 맞추는 건 다르다 등)
지금까지 두벌식으로 옛한글 글쇠배열을 설정하면 4단 아랫자리에 있는 한쪽이 길쭉한 반치음들은 종성까지 입력 가능한 형태로 배당되었는데, 이제는 그걸 없애고 초성으로만 배당되게 했다. 이들 자음은 어차피 초성 형태밖에 존재하지 않기 때문이다. 종성 표현은 <날개셋> 편집기 내부에서 사용자 정의 영역 글자를 이용해서 편의상으로나 존재한다.

현대 한글 두벌식을 사용할 때는 ㄸ, ㅃ, ㅉ이 받침이 존재하지 않기 때문에 언제나 초성으로만 입력된다.
옛한글 두벌식일 때는 이들은 종성으로도 입력 가능하고 그 대신 반치음들이 그런 형태를 이어받게 되는 것이다.

Posted by 사무엘

2015/08/01 08:38 2015/08/01 08:38
Response
No Trackback , 11 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1122

Trackback URL : http://moogi.new21.org/tc/trackback/1122

Comments List

  1. 김경록 2015/08/06 01:11 # M/D Reply Permalink

    엄청나군요.....

    1. 사무엘 2015/08/07 20:08 # M/D Permalink

      자꾸 만들 것, 개선할 것들이 떠오르는 게 축복인지 저주인지는 모르겠습니다. 도박 중독 같은 코딩 중독? 가을쯤에 8.2 정도 나와 줘야겠죠. ^^

      (그리고 홈페이지 이용에 잠시 불편을 끼쳐 죄송합니다.)

  2. 곽동영 2015/08/12 13:53 # M/D Reply Permalink

    늘 수고가 많으십니다.
    이제 안마태연구소 웹페이지도 사라져서 저처럼 안마태자판+드보락을 쓰는 사람에겐 날개셋이 유일한 희망이 되었습니다.
    안마태 자판은 말씀 주신대로 제가 .ist 파일 작성하여 잘 쓰고 있습니다.
    혹시나 해서 요청을 하나 드리자면 날개셋으로 드보락 자판을 쓰는 경우 엑셀의 함수 자동완성이 안 되는데요.
    평소 암호입력이나 단축키가 쿼티로 인식되는 건 오히려 너무 편한데 엑셀만 살짝... 아쉽습니다. 하하.
    혹시 다음 버전에 간단히 추가 가능하시면 부탁드립니다.

    더운데 건강 유의하세요~

    1. 사무엘 2015/08/12 21:36 # M/D Permalink

      안녕하세요! 제 프로그램을 늘 애용해 주셔서 고맙습니다. ^^

      엑셀은 보아하니 정식 키입력으로 알파벳이 입력됐을 때만 함수 자동 완성을 해주고, IME가 만들어 낸 알파벳 문자열에 대해서는 반응을 안 하네요.
      그럴 때는 지난 7.9에서 추가된 '키 입력' 날개셋문자를 배당해 보세요. A와 Shift+A 자리에 똑같이 KY|'A', 드보락의 V 자리에 해당하는 .와 > 자리엔 KY|'V'를 집어넣는 식입니다.
      그러면 드보락 입력이 되면서 함수 자동 완성도 될 겁니다. (전 되는 걸 확인했습니다.) 단, 알파벳과 숫자만 이렇게 KY|'' 형태로 배당이 가능하고, 다른 특수문자는 가상 키코드 값이 문자 코드 번호와 일치하지 않기 때문에 '직접 눌러보기'로 값을 확인해서 배당해야 합니다.

      다음 버전에는 일반 날개셋문자를 키 입력 타입으로 일관 변환해 주는 기능도 넣는 게 좋겠습니다. 좋은 제안에 감사드립니다.

      (그리고 안마태 연구소는 왜 홈페이지 운영을 중단했는지 모르겠네요. 안타까운 일입니다.)

  3. 곽동영 2015/08/13 09:07 # M/D Reply Permalink

    감사합니다!
    역시 늘 사무엘 님께는 방법이 있네요.
    사실 지금까지도 "응용 프로그램 간에 입력 항목 변경 내용을 자동동기화" 옵션을 통해 엑셀 쓸 때만 윈도에서 제공하는 드보락 입력기를 이용했었습니다.
    그전에는 드보락에서 돌아오면 날개셋은 쿼티로 돌아가 있어서 무척 불편했었는데 작은(?) 배려가 저에게는 엄청난 효율을 가져다주었습니다. 늘 감사드립니다. 하하.

  4. 곽동영 2015/08/25 10:01 # M/D Reply Permalink

    안녕하세요, 사무엘님!
    윈도우10으로 업데이트했더니 다행히도 무사 동작합니다만 엣지(웹브라우저)에서는 무조건 쿼티 영문으로만 입력되네요.
    혹시 저만의 현상일지요.

    1. 사무엘 2015/08/25 17:33 # M/D Permalink

      Windows 10 관련 이슈가 몇 가지 접수돼 있습니다. 저는 아직 Win10을 써 보지 못했습니다만, 올가을에 다음 버전이 나오기 전까지는 확인해서 조치하도록 하겠습니다. 알려 주셔서 고맙습니다. ^^

    2. 사무엘 2015/08/27 15:55 # M/D Permalink

      Windows 10으로 운영체제를 업데이트 하고 나니, 날개셋 한글 입력기가 편집기만 남아 있고 외부 모듈은 시스템 상에서 사라졌더군요. (엣지뿐만 아니라 모든 프로그램에서)
      그 이유는 모르겠습니다만, 날개셋을 그냥 삭제하고 재설치만 해도 외부 모듈의 사용은 모든 프로그램에서 가능한 걸 확인했습니다. 혹시 문제가 여전히 발생 중인지 확인 부탁드립니다.
      참고로 다음/네이버의 검색어 입력창으로 포커스를 옮기자마자 한영 모드가 무조건 영문으로 바뀌는 것은 원래 그러는 것이고 Windows 10 이전부터 그랬습니다.

  5. 곽동영 2015/09/06 23:28 # M/D Reply Permalink

    윈도우 옵션에서 제거했다가 재등록하는 꼼수를 썼었는데, 그게 원인이었군요.
    처방 감사드립니다. 간만에 집에서 쓰는 노트북에 접속해서 날개셋 삭제 후 재설치 한 후 지금 엣지에서 글 올리고 있습니다. 하하.
    다만 처음 엣지에서 입력시 날개셋 기본 설정인 두벌식-쿼티-옛한글... 순으로 적용되다가 잠시 후 저의 세팅 (안마태 2009년 - 드보락 - 두벌 - 쿼티)으로 돌아오는 있습니다.
    좀 더 자세히 살펴보고 리포트 드리겠습니다!
    감사합니다.

    1. 사무엘 2015/09/06 23:55 # M/D Permalink

      엣지는 Metro 앱입니다. 사용자 입력 설정 파일에 접근을 할 수 없어서 처음에는 기본 설정으로 동작하다가, 주변에 설정이 정상적으로 로딩된 데스크톱 앱으로 갔다가 돌아오면 그제서야 엣지 내부에서도 설정이 동기화되는 거랍니다.
      자세한 것은 도움말 "VI. 외부 모듈 → 알려진 문제 → Windows Vista 이상에서의 문제 → Win8 Metro" 관련 설명을 참고하세요~ ^^

  6. 곽동영 2015/09/07 09:46 # M/D Reply Permalink

    아! 이미 파악하고 계신 문제셨군요. 하하.
    글자 사라지는 것도 불편해서 엣지는 그냥 간단히 눈팅용으로만 사용해야 할 것 같습니다.
    오피스 2016도 정식 출시되면 사용해보고 호환성 리포트 드리겠습니다.

    감사합니다!

Leave a comment

날개셋 한글 입력기 8.0

1. 들어가는 말

이번 학기도 다 끝나고 여름방학이 시작됐다. 이젠 코스웍이 한 학기밖에 안 남았고, 슬슬 종합 시험과 학술지 논문 등 길고 긴 연구 모드로 들어갈 준비를 해야 한다.
그런데 아직 기말 과제가 다 안 끝났을 때, 방학이 되길 벼르고 벼르면서 타는 목마름으로 할것들을 적어 놓은 게 이미 한 트럭인지라, 방학이 된 뒤에도 별로 방학 같은 느낌이 안 든다.

이게 무슨 상황이냐 하면, 월급날이 돌아와 봤자 카드 명세서와 저축, 집 대출 이자 내지 자동차 구입 할부 등의 비소비 지출들이 한바탕 raid를 벌이고 나면, 여전히 가난한 것과 완전히 똑같다.

알람 안 맞추고 좀 원없이 자 보고 싶다.
하루에 최하 8시간 이상, "너무 자서 골병 들 거 같다. 이제 좀 그만 자야지" 생각이 들 때까지 자고 싶다.
코딩 노예 계약서를 화형에 처하고 싶다.
차 끌고 전국일주 여행 좀 가고 싶다. 그리고 여친도 좀 사귀고 싶다. -_-;;

내가 도대체 무슨 부귀영화를 바라고서 이 나이까지 이 짓을 하고 있나.. 그냥 빨리 돈 벌고 안정적으로 살려면 스펙 관리해서 코레일이나 철도 시설 공단에나 들어가면 되지 싶은 자괴감이 들긴 하지만,
뭐 어쨌듯 이런 와중에 <날개셋> 한글 입력기 8.0이 완성됐다. 그 다음 버전(8.x)까지 빨랑 다 만들어 버리고 완성된 모습을 좀 보고 싶다.

이번 8.0은 리팩터링 내지 내부 완성도 강화 작업이 많아서 readme에다가는 쓸 게 적은 편이었다. 하지만 내부적으로는 0.1을 능가하는 분량의 변화가 있었다.
지난 5월에 이미 언급했듯이 편집기에서 한글 정규화 규칙 강화, 수식의 상수에 원형 보존이라는 굵직한 변화가 있었으며, 또 '초성 지향 두벌식', 글쇠누름 날개셋문자 기능과 관련해서 조합 종료 처리가 불완전하던 것을 보강했다.

사소한 것으로는 한글 조합 중에 아무 자모 없이 H2, H3, H2J 이런 날개셋문자만 달랑 넘겨 준 경우 지금까지는 그냥 아무 일 없었다는 듯이 무시만 당했지만, 지금은 입력 중인 한글의 종류를 그걸로 변경되게 했다. 이것 말고도 아주 마이크로한 부분에서 프로그램의 완성도를 높이고 소스 코드 구조를 개선하는 작업들은 가시적인 작업 성과에 비해 난이도가 무척 높았다.

또한 도움말과 프로그램 소개 페이지에 있는 스크린샷들을 싹 다 최신 버전 기준으로, 특히 외형도 Windows 8 모양으로 교체했다. 알다시피 Windows 8이 비주얼이 더 단순하고 빈약한 덕분에 같은 화면이어도 스크린샷의 크기가 더 작아졌다. 이로 인해 도움말 크기가 몇만 바이트 감소하고, 프로그램 전체의 배포 패키지 크기도 아주 약간 더 작아졌다. 프로그램은 덩치가 조금 더 커졌는데도 말이다. 예기치 못한 긍정적인 효과이다.
이런 식으로 사소한 것들이 쌓이고 쌓였다는 뜻이다. <날개셋> 한글 입력기는 개발 15년째인 아직까지도 매 새 버전마다 새로운 역사를 쓰고 있다.

2. 입력 패드에 키보드 입력 모드 추가

이런 것 이후에 이번 <날개셋> 한글 입력기 8.0에서 추가된 큰 기능은..
편집기와 외부 모듈에 이어 제3의 구현체이던 입력 패드가 드디어 키보드 입력이 가능해졌다는 점이다.
Windows에서 정식 IME가 아닌 EXE 형태의 프로그램이 다른 프로그램에서 키보드 입력으로 한글을 입력해 넣는 게 가능해졌다.

입력 패드는 5.3버전에서 첫 도입된 이래로 약 6년 동안 마우스를 이용한 '입력 도구'의 구동만 가능한 반쪽짜리 구현체였다. 키보드까지 지원하는 것은 기술적인 난관 내지 구현 가성비 등을 감안했을 때 보류되어 있었고 연구 우선순위도 별로 높지 않은 상태였다. 당장 이번 8.0에서도 처음엔 딱히 고려 대상이 아니었는데...

그러나 화면 키보드에 '눌린 글쇠 표시'기능을 넣는 과정에서 입력 도구에도 키보드 입력을 연계하는 기능이 7.9와 8.0의 개발 과정에서 자연스럽게 구현되었다. 어떤 글쇠가 눌렸다는 통지를 받고, 원한다면 이 키 입력을 입력 도구가 가로채어 먹을 수도 있는 것이다.
그러니 아예 키보드 입력을 지원하는 것도 이 작업의 연장선 차원에서 지원 가능하겠다는 생각과 함께 불현듯이 개발이 진행되었다.

그냥 입력 패드를 실행하면 딱히 변화가 없다. 그러나 트레이를 우클릭해서 메뉴를 열면 "키보드 입력 사용"이라는 메뉴가 추가되어 있다. 이걸 선택해서 체크하면 키보드 입력이 가능해진다.

단, 입력 패드는 운영체제 IME가 동작하지 않는 틈을 타서 동작하며, 이미 제도권에서 돌아가고 있는 운영체제 IME를 대체하거나 그 동작을 바꾸지는 않는다. 운영체제 IME가 '영문 반자'로 켜져는 있으되 동작은 안 하는 상태여야 한다. 걔가 한글 모드일 때는 본 프로그램은 아무 동작도 하지 않는다. 또한 운영체제 IME가 자기 입력 모드를 바꿀 때 사용하는 한영 글쇠 같은 것도 가로채지 못하므로 Shift+Space나 우클릭 메뉴처럼 다른 전환 글쇠를 배당해야 한다.

또한 마우스만 지원하던 예전부터 마찬가지이긴 했지만, 입력 패드가 제공하는 입력 기능은 데스크톱 GUI 환경 전용이다. 명령 프롬프트나 Windows 8 이상의 메트로 UI에서는 동작하지 않는다. 거기서는 정식 외부 모듈만을 써야 한다.

입력 패드가 제공하는 입력 프로토콜의 수준은 TSF A급이 아니다. 조합을 만들고 완성된 문자열을 내보내는 것만 가능할 뿐, 조합이 끝난 인접 문자열을 알아 오거나 고칠 수는 없다.
입력 패드가 TSF를 지원하는 프로그램에서 TSF A급으로 동작하는 것은 이번 8.0의 개발 작업을 통해 기술적으로 '불가능한 건' 아님을 확인했다. 하지만 구현하는 오버헤드가 굉장히 크며, 편집기와 외부 모듈이 있는 상황에서 입력 패드가 굳이 그것까지 지원할 필요는 없다고 여겨져서 미지원 상태로 남겨 뒀다.
따라서 편집기는 전용 프로그램이다 보니 언제나 A급이 보장되고, 외부 모듈은 어느 프로그램에서 동작하느냐에 따라 A/B급이 유동적으로 바뀌는 한편, 입력 패드는 간편하게 동작한다는 특성상 언제나 B급이라는 차이가 존재한다.

끝으로, 편집기나 외부 모듈과는 달리 입력 패드는 한자 변환을 아직 지원하지 않고 있다. 키보드 입력이 지원되기 시작했기 때문에 앞으로는 이 한계가 이제 더욱 부각되어 보일 것이다.
이 역시 기술적으로 불가능한 건 아니고 단순히 해당 UI가 시간 부족-_-으로 인해 구현되지 않아서 지원되지 않은 것이다. 입력 패드에서 글자 조합 중에 한자/후보 변환을 시도하면 "해당 기능은 아직 지원되지 않습니다"라는 풍선 도움말이 뜬다.

3. 타자연습

타자연습은 프로그램에 변경 사항은 없으며 이번 입력기 8.0 버전도 예전의 7.9와 마찬가지로 타자연습 3.41하고 API가 호환된다. 그러므로 타자연습을 굳이 또 다시 받아서 설치하지는 않아도 된다. 다만, 이번에는 3.41을 다시 올리면서 연습글에다 "세스코 질문 답변 모음"을 추가했다.

"나는 바퀴벌레 제 1군단 장군이다. 우리는 너희 세스코를 적으로 간주하며 오는 12월 25일 크리스마스 선물로 너희 세스코 본사를 대대적으로 공격할 것이다." 뭐 이런 문장으로 연습을 할 수 있다.
'퀴'는 세벌식에서 치기 어려운 축에 드는 글자이니 연습 효과도 상대적으로 클 것으로 기대된다.;;
이 때문인지, 어지간한 연습글들은 분석해 보면 4단의 사용 빈도가 3~5%대인 반면, 세스코 글은 6%가량 된다. ^^

엔하위키(지금은 이름이 '나무'로 바뀌었지만)나 각종 인터넷 카페에서 <날개셋> 타자연습 프로그램에 대한 소개를 해 놓은 걸 보면 김 성모 유행어와 각종 인터넷 유행어가 연습글로 들어있는 게 역시나 반응이 아주 좋다. 이제는 시간이 너무 흘러서 그것조차도 유행이 다 지나려 하긴 한다만..
세스코도 비슷한 맥락으로 재미있는 연습글 역할을 할 수 있을 것이다.

4. 후속 과제

7.9에서 8.0은 지난번 7.7에서 7.9로 올라갈 때만치 양적 성장은 없지만 추가된 소수의 기능들이 제각각 매우 중요하고 여파가 크다. 버전에서 소수점이 아닌 1자리 숫자의 변화와 같이 일어나기에 적절한 것들이다.

사실은 이번 8.0에서는 최종 변환 규칙의 동작 방식을 변경하고, IME 관련 이벤트를 정형화해서 "변경된 글자판을 cursor 근처에다 잠시 표시해 주는 입력 패드"도 추가하려고 했다. 그러나 이것은 입력 패드의 키보드 입력 기능을 구현하느라 뒷전으로 밀려서 다음 버전의 과제로 남게 됐다.

사실, 입력 패드는 현재의 글쇠배열을 표시하는 UI가 어디에도 존재하지 않는다. 시스템 트레이의 아이콘을 가리키고 있어야만 툴팁으로 나온다. 그러니 입력 패드를 쓰고 있을 때는 저 UI가 더욱 필요할 텐데 시간 관계상 8.0에서 다 반영되지 못했다. 3개월 정도 시간이 지났고 이미 0.1 이상의 충분한 작업량이 쌓였으며, 7.9에 꽤 어이없는 버그가 있기도 하기 때문에 새 버전의 공개를 지금 시점보다 더 미룰 수는 없었다.

그러니 굳이 많은 기능들을 사용하는 헤비 유저가 아니더라도 이 글을 보시는 7.9 사용자라면 8.0으로 빠짐없이 업그레이드를 하고, 한번 입력 패드도 사용해 보시기 바란다.
생각 같으면 한 배포 패키지에서 32비트와 64비트별로 파일이 알아서 설치가 되고 편집기/외부 모듈/입력 패드 구현체들 중 사용자가 원하는 것만 선택해서 설치하는 옵션도 넣고 싶긴 하다.

과연 다음 버전 8.1이나 8.2는 신규 모아치기/동시치기 엔진까지 포함해 <날개셋> 한글 입력기의 종결자 버전이 될 수 있을까? 그건 나도 모른다. to be continued일 뿐..! 그래도 1년 전에 비해 task list가 눈에 띄게 가벼워진 것을 보면 감회가 새롭다. 느리긴 해도 노예 계약은 추가되는 것보다 이행되는 게 더 많으며, 꾸준히 청산하고 있는 중이다.

* 여담 1: 한중일 IME들의 제어판 UI의 구조

잘 알다시피 Windows에서 문자 입력을 위해 단순히 운영체제의 기성 코드 + 데이터 차원의 variant가 아니라 아예 제3자가 만든 IME라는 별도의 프로그램이 쓰이는 언어는 한국어(한글), 일본어, 중국어 간체, 그리고 중국어 번체 이렇게 4개이다.
그런데 Window에 내장돼 있는 중국어나 일본어 IME에서 환경설정 대화상자를 열면 그건 IME 프로그램 내부가 아니라 별도의 EXE 프로그램이 실행되는 형태로 열린다. 그 대화상자가 떠 있는 상태에서 예전에 글자를 입력하던 창으로 돌아가는 것도 가능하다.

환경설정뿐만 아니라 보조 입력 도구를 꺼내는 것도 IMEPADSV처럼 한중일 IME들이 한데 공유하는 별도의 프로그램을 써서 하며, 도움말도 통상적인 HtmlHelp API를 쓰는 게 아니라 HH 프로그램을 별도로 띄우는 방식으로 동작한다.
IME들은 자기가 돌아가는 프로세스에 끼치는 영향을 최소화하려고 의도적으로 그렇게 만들어진 것 같다. 뭔가 복잡한 GUI를 띄워야겠다 싶은 건 in-process로 구동하는 걸 기피한다.

내 프로그램의 경우 제어판은 규모가 상당히 크긴 하지만 그냥 in-process에서 modal 대화상자 형태로 돌아가며, 편집기나 입력 패드 같은 독립적인 구현체들 단위로 별도의 EXE가 만들어져 있지, 중간의 구성요소가 또 EXE이지는 않다. 쉽게 말해 <날개셋> 제어판이 그 자체가 독립적인 EXE로 존재하지는 않는다는 뜻이다.

MS 한글 IME는 운영체제의 제어판이 아닌 자기 자신만의 독자적인 UI에 환경설정을 꺼내는 명령이 아예 존재하지 않아서 두벌/세벌 전환조차도 하기가 불편하다. TSF가 도입되기 전, Windows 98~ME 시절에는 자기 도구모음줄을 우클릭해서 글자판을 아주 간편하게 바꿀 수 있었는데 그런 기능이 없어졌다.

* 여담 2: Windows 8.1의 MS 한글 IME

Windows 8때까지만 해도 이런 게 없었는데 난 이걸 비교적 늦게 발견했다.
8.1의 메트로 UI에서 MS 한글 IME로 한글을 입력하다가 글자를 지워 보면, 연달아 입력하던 단어까지는 계속해서 자모 단위로 지워지다가 그 뒤부터 글자 단위로 지워진다. 오, 신기한 기능이 추가됐다. 사실 이렇게 동작하는 게 일반적으로 훨씬 낫다. <날개셋> 한글 입력기의 경우 2년 전 버전 7.1에서 비슷한 옵션이 처음으로 추가되었다.

단어 전체를 조합으로 잡는지, 아니면 실시간으로 앞 글자를 얻어 오는지는 잘 모르겠지만, 세벌식에서 받침 ㄶ을 한 타로 바로 입력했는지 ㄴ+ㅎ로 입력했는지를 다 정확하게 기억하는 걸로 봐서는 아마 전자인 것 같다.

Posted by 사무엘

2015/06/28 19:37 2015/06/28 19:37
Response
No Trackback , 19 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1110

Trackback URL : http://moogi.new21.org/tc/trackback/1110

Comments List

  1. ㅇㅇㅇ 2015/06/29 07:47 # M/D Reply Permalink

    항상 감사드립니다
    정말로한글 입력기의 최고봉인 듯 합니다

    1. 사무엘 2015/06/29 12:51 # M/D Permalink

      저도 감사합니다. 변함없는 관심과 성원을 부탁드립니다~ ^^

  2. 허국현 2015/06/30 09:00 # M/D Reply Permalink

    win 8.1의 변화의 경우에는 Tablet이나 전화기 같은 데에서 오타칠 경우, 다시 글자를 처음부터 치는 것이 피곤하기 때문에 그렇게 만든 것이 아닌가 혼자 추측해 본 적이 있습니다.

    1. 사무엘 2015/06/30 11:41 # M/D Permalink

      글자를 처음부터 다시 치는 건 어느 매체로 입력을 하더라도 불편하고 귀찮고 번거롭죠. 메트로 모드의 입력란은 기존 데스크톱의 에디트 컨트롤과의 호환을 고려할 필요 없이 처음부터 TSF를 완벽하게 지원하게 설계되어서 한글 IME도 저런 기능을 구현한 것으로 보입니다.
      한글 IME의 입장에서는 지금이 메트로인지 아닌지 구분해서 동작하는 것도 얼마든지 가능하고요.

  3. 신세기 2015/07/03 00:12 # M/D Reply Permalink

    드디어 8.0 버전이 나왔군요. 날개셋 입력기의 새로운 버전업을 축하드립니다!

    1. 사무엘 2015/07/03 18:06 # M/D Permalink

      감사합니다. 굳이 고급 기능을 사용하는 헤비 유저가 아니더라도 꼭 새 버전으로 업글해서 사용해 보세요~!

  4. 사샤나즈 2015/07/12 22:26 # M/D Reply Permalink

    혹시 게임에서의 작동 문제에 대해서도 문의를 받으시나요? 이번에 나온 메이플스토리2에서 날개셋 입력기로 한글 입력을 하면 커서 아래에 별도의 작은 입력칸이 나오면서 실제 게임 내 입력창에는 물음표밖에 입력이 되지 않는 현상이 있습니다.

    |를 커서라고 하면

    |
    [ㅎ]

    |
    [하]

    |
    [한]

    ?|
    [ㄱ]

    이런 식이네요. 혹시 알아봐 주실 수 있을까요? TSF 확장 옵션은 켜도 꺼도 차이가 없어 보입니다.

    MS 일본어 IME의 경우엔 변환 기능까지 지원이 되지만 게임 내에 일본어 글꼴이 없어 표시만 되지 않는 듯하더군요. 이 경우엔 물음표가 아닌 네모로 표시가 됩니다.

    1. 사무엘 2015/07/12 23:54 # M/D Permalink

      안녕하세요? 음, 그 정도면 제 프로그램에서만 다르게 동작하는 게 가능하지 않은 수준의 문제 같습니다.
      멀쩡히 보내 준 한글을 ? 라고 깨진 채 인식하는 건 IME가 아니라 해당 응용 프로그램이거든요.
      혹시 시스템의 로케일이 일본어인가요? 그리고 그렇다고 하더라도 요즘 만들어지는 프로그램이 유니코드를 지원하지 않는다는 건 말이 안 되는데..
      그리고 MS '한글'(일본어 말고) IME로 한글 입력은 동작이 어떤지 확인을 부탁드립니다.
      온라인 게임은 클라이언트 용량이 방대하고 계정을 만들어야 하는 등 준비 작업이 필요해서 제가 즉각 확인이 가능하지는 않습니다.

    2. 사샤나즈 2015/07/13 02:28 # M/D Permalink

      이 문제로 입력기를 쓸 수가 없어서 MS 한글 입력기를 대신 쓰고 있는데 MS 입력기에서는 문제가 없습니다. 별도 입력칸도 나오지 않고 게임의 입력칸에 직접 정상적으로 입력이 됩니다. MS 옛한글 입력기는 무슨 이유인지 한영전환이 되질 않네요. 로케일은 US인데 한 번 한국어로 바꾸고 해 봐야겠네요.

      PS: 한 번 더 확인하고 문의를 했어야 했나 싶은데 일단 한국어 로케일에서는 물음표가 아닌 한글 입력이 제대로 되지만 여전히 별도 입력칸이 나타납니다. 따라서 입력이 아래와 같습니다.

      |
      [ㅎ]

      |
      [하]

      |
      [한]

      한|
      [ㄱ]

    3. 사무엘 2015/07/13 09:17 # M/D Permalink

      음, 그런데 MS 한글 IME는 시스템 로케일이 한국어가 아니어도 한영 키를 눌렀을 때 한영 전환이 안 되는 것만 빼면 한글 입력 자체는 동작한다는 거지요?

      말씀하신 사항들만 들어 보면, 굉장히 이상하고.. 일부러 그렇게 만들기도 참 힘들 것 같은 동작입니다. =_=;;;
      일단 알았습니다.
      5년 전에 스타크래프트 2도 거의 일부러 IME를 가려 가며 동작하는 것처럼 보이는 말도 안 되는 한글 입력 문제가 있었던 게 생각나네요. 그거도 결국은 해당 프로그램이 패치가 되어 이슈가 종료되었습니다.
      http://moogi.new21.org/tc/232

    4. 사샤나즈 2015/07/13 13:13 # M/D Permalink

      아, 한영전환 문제는 MS 옛한글 입력기만의 문제고 MS 한글 입력기는 한영전환도 문제가 없습니다. (윈도8 이후로 MS 한글 입력기 종류가 두 가지가 있습니다. 옛한글 입력기는 로케일이 US든 한국어든 게임 내에서 한글을 입력할 수가 없네요)

      말씀대로 로케일에 관계 없이 MS 한글 입력기는 제대로 작동합니다.

    5. 김재주 2015/07/23 15:39 # M/D Permalink

      스타 2의 경우... 재발했습니다(...) 이게 웃긴게 게임 중에는 날개셋으로 한글 채팅이 가능한데 클랜 및 그룹, 채널 대화방에서는 채팅이 안 됩니다. 그냥 포기하고 MS IME를 쓰고 있네요.

  5. 사무엘 2015/07/13 11:04 # M/D Reply Permalink

    문득 떠오른 생각: IME간 동작 차이를 만드는 주범은 아마 온라인 게임과 같이 돌아가는 "키보드 보안 프로그램일 거다"에 한 표 겁니다.
    물론 사용자 입장에서 할 수 있는 조치는 어차피 별로 없습니다. 해당 게임이 날개셋을 예외로 인식하게 해 주는 수밖에 없지요.
    제 프로그램은 디지털 서명도 없기 때문에 "이 DLL 뭥미?" 하면서 키보드 트랜잭션을 ban 할 수도 있을 듯합니다.

    1. 사샤나즈 2015/07/13 13:14 # M/D Permalink

      이 가설을 테스트하려면 같은 키보드 보안 프로그램을 쓰는 다른 게임에서도 문제가 생기는지 알아봐야 하겠군요.

  6. 사샤나즈 2015/07/29 22:08 # M/D Reply Permalink

    이건 오늘 윈10 정식 출시됐으니 하는 얘기인데... 윈도스토어앺에 포커스 두고 태스크바에서 날개셋 제어판을 열면 애플리케이션이 팅겨 버려요.

    1. 사무엘 2015/08/01 08:50 # M/D Permalink

      으음, 윈도 스토어라면 메트로 말씀하시는 거지요? 윈10은 그 모드에서 language bar (task bar의 내부에 있는)에 있는 날개셋 아이콘에 접근해서 날개셋 제어판을 여는 것 자체가 가능하다는 건가요?
      아직 상황과 재연 경로가 이해가 되지 않습니다만, 제 컴이 윈도10으로 자동 업데이트되는 날이 오면 확인해 보겠습니다. 금방 확인 가능하지는 않습니다.

    2. 사샤나즈 2015/08/04 06:38 # M/D Permalink

      네, 그 아이콘으로 접근하는 것이 맞습니다. 일부 시스템에서는 그 아이콘이 아예 사라져 있기도 한데 이렇게 복원할 수 있습니다.

      http://answers.microsoft.com/en-us/windows/forum/windows_10-start/language-bar-icon/afc8f406-0469-46c2-8d2c-adc9898d3a54?auth=1

      PS: 혹시 예전에 말씀드렸던 메트로 (그러니까 지금 명칭으론 Windows app)에서 입력기 데이터를 불러오는 문제도 나중에 해결이 될 수 있을까 싶네요. 일단은 이전에 동기화 기능을 추가해 주신 덕분에 새 윈도10 애플리케이션에서도 입력기를 잘 쓰고 있습니다. :)

  7. 사샤나즈 2015/08/04 07:09 # M/D Reply Permalink

    윈도10의 Edge 브라우저에서 페이스북에 접속해 댓글에 한글을 입력하면 입력 중에 글자들이 사라지는 문제도 제보합니다.

    https://twitter.com/SaschaNaz/status/628322355710951424 (영상 첨부)

    TSF 확장 기능은 켜져 있었으나 끄고 재부팅해도 문제가 사라지지 않았고 한글 표시 부분은 '유니코드 5.2 (윈도 8)' 을 선택했으나 기본 선택으로 돌아가도 별다른 변화는 없었습니다.

    기본 MS 한글 입력기로는 이 문제가 나타나지 않습니다.

    1. 사무엘 2015/08/27 15:56 # M/D Permalink

      드디어 저도 Windows 10을 입수했습니다.
      1. Edge를 포함한 ‘메트로’ 앱에서는 전통적인 데스크톱 GUI를 사용하는 제어판 대화상자를 in-process 형태로 띄우는 게 불가능해 보입니다.
      지금까지는 메트로 모드에서 language bar 버튼에 접근하는 게 가능하지 않아서 신경 쓸 필요가 없었는데, 10에서는 그게 가능해졌으니 메트로 모드에서는 제어판 메뉴를 흐리게 막아야 할 것 같습니다.
      일본/중국어 IME는 설정 대화상자가 아예 별도의 프로세스로 실행되니 이런 문제가 없지만, 날개셋은 그렇지 않으니까요.

      2. 페이스북에서 글자 지워짐 문제: 100% 재연하고 윈도 10+제 프로그램에서만 발생하는 현상인 것도 확인했습니다. 하지만 쟤만 왜 저러는지 문제를 해결하는 건 꽤 어려울 것 같습니다.

      따라서 “1. 문제를 회피하는 UI를 넣을 예정, 2. 의미 있는 버그 신고이고 확인까지 했지만, 만만찮은 작업이 될 듯함..” 입니다.

Leave a comment

다음 버전 개발 근황

바야흐로 2015년, <날개셋> 한글 입력기 개발 15주년과 더불어 7 다음 8.0으로 도약할 준비를 하고 있는 프로그램 개발실의 근황을 전하도록 하겠다.

1. 편집기의 한글 정규화 방식 수정

<날개셋> 한글 입력기는 첫 버전인 1은 차치하고라도 지금까지 보면, 피보나치 수열에 해당하는 버전에 첫 진입할 때 편집기의 에디팅 엔진에서 한글 처리와 관련된 중요한 변화가 생기곤 했다.
1.0은 2바이트 조합형 코드 기반이었는데 2.0은 한컴 2바이트 코드로 바뀌었다. 그러다 3.0은 유니코드 + 비표준 정규화 방식을 썼으며 5.0은 유니코드 5.2 체계로 바뀌고 비표준 관행이 완전히 없어졌다.

그러니 5.0의 이후부터는 한글 코드 같은 기본적인 부분은 더 바뀔 일이 없을 것 같았는데 사실은 그렇지 않았다. 이번 8.0은 KS X 1026-2가 규정하는 한글 정규화 규칙을 반영하는 알고리즘이 추가되었다. 현대 한글은 오로지 U+AC00 이후의 글자마디로만 표현 가능하고, U+1100대의 자모의 조합으로 표현하는 것은 허용하지 않게 했다. 자모 조합은 미완성 한글이나 옛한글일 때만 가능하다.

Windows Vista와 7은 이전 버전인 XP와는 달리 자모 조합으로 표현된 현대 한글을 글자로 묶어서 표현해 줬는데 이 기능이 8부터는 도로 없어졌다. 사실은 다 똑같이 묶어서 표현해 주는 게 컴퓨터의 입장에서도 처리하기가 더 편하지, 'all 현대 한글 case'만 또 따로 걸러내는 건 불편한 오버헤드가 추가되는 일이다.

하지만 한 한글은 오로지 한 가지 방식으로만 표현되게 하기 위해서 일부러 이런 정규화 규칙이 도입되었다. 그래서 똑같이 U+11??자모를 썼는데 '갬'은 한데 모이지 않지만, 개+ㅁㄱ 옛한글은 한데 모인다. '한'은 모이지 않지만 '아래아 한'은 모이게 되었다.
Windows도, 날개셋도 다 버전 8부터 이 표준을 반영하기 시작했다는 것이 흥미롭다.

사용자 삽입 이미지

2. 수식에서 상수의 원형 보존

<날개셋> 한글 입력기는 먼 옛날 3.0에서부터 64비트 정수의 수식이 도입되어 글쇠배열, 오토마타, 입력 항목(글자판) 전환 같은 여러 용도로 쓰이고 있다.
수식은 크게 상수, 변수, 연산자로 구성되며 상수는 10진수, 16진수, 작은따옴표로 둘러싸인 문자 하나, 그리고 명칭이라는 네 가지 형태 중 하나로 표현할 수 있다.
사용자가 입력한 수식은 내부 데이터 구조로 바뀌어 저장되며, 이 내부 데이터는 지금까지 사용자가 입력한 상수의 형태에 대한 정보를 갖고 있지 않았다. 즉, 모든 상수를 저 네 형태 중 하나로만 획일화하여 표현했다.

그러던 관행이 오는 8.0에서부터 드디어 개선된다. 글쇠배열 수식을 예로 들면, 어떤 글쇠는 0xAC00이라고 입력하고 다른 글쇠는 '가'라고 입력했다면 사용자가 입력했던 각각의 형태가 드디어 보존된다.
서로 형태가 다른 상수와 상수끼리 연산이 수행된다면, 연산 결과를 나타내는 상수의 타입은 대부분 왼쪽 먼저 등장한 상수의 형태를 따른다. 그래서 100 앞에다가 0x0+을 붙여 주면 아무 효과가 없는 0은 없어지고, 100을 16진수인 0x64로 바꿀 수 있다. 그리고 앞에 'a'-'a'+를 붙이면 아스키 번호 100에 해당하는 'd'로 100의 표현 형태를 바꿀 수 있다. 이런 표현 형태는 내부적인 수식의 값 계산 성능에는 전혀 영향을 주지 않는다.

글쇠배열에 e==10 ? 0xAC00: 0xAC11 같은 수식이 있다고 생각해 보자. 10은 유니코드 문자나 날개셋문자와는 관계가 없고 다른 의미를 갖는 상수이기 때문에 굳이 16진수로 표시되어야 할 필요가 없다.
지금까지는 이 10도 싹 다 16진수로 바뀌어서 0xA로 표현되었지만, 이제부터는 사용자가 처음에 10진수로 입력한 상수는 저장도 10진수로 된다.

이런 식으로 작지만 큰 변화가 버전이 7에서 8로 바뀔 때 실현되기 적절한 변화라고 여겨진다. 새로운 정보가 추가되었기 때문에 8.0의 제어판에서 만들어서 바이너리 방식으로 저장한 입력 설정 파일은 이제 이전 버전에서 거의 읽지 못하게 될 것이다.
음수는 16진수, 명칭, 문자 등 다른 모든 형태를 무시하고 언제나 10진법으로만 표현된다. 그리고 왼쪽 피연산자 상수의 형태를 따르지 않는 예외 연산자는 다음과 같다.

  • 콤마: 연산들을 좌에서 우로 순서대로 나열하는 역할만 하고 최종 계산값은 맨 뒤의 값이 되므로, 왼쪽이 아니라 오른쪽의 형태를 선택한다. 즉, (10, 'A', 0x10)+1은 0x11로 최적화된다는 뜻이다.
  • 조건 연산자: A ? B:C 연산은 B와 C중 값으로 채택된 놈의 형태를 따른다.
  • 참/거짓만을 되돌리는 논리 연산자들: 비교, 동등, 논리 AND/OR/NOT은 좌우 피연산자의 형태에 관계없이 언제나 지금 수식이 사용하는 기본 표현 형태를 따른다. 어차피 0 아니면 1밖에 안 돌아오며 (A==B)*100 이런 변태적인 활용을 하는 일은 없으니 별 의미도 없을 것이다.

이런 시스템을 하나씩 설계하는 게 프로그래머로서 참 재미있는 일이다.

3. 미흡했던 부분 개선

(1) 조합 도중에 출력하는 글자와 그 상태로 조합이 종료됐을 때 표시하는 글자가 다를 수 있는 상황에 대한 처리를 이제 거의 완벽하게 마쳤다. 이 작업이 특별히 중요한 이유는 지난 7.9에서 추가된 '글쇠 누름' 날개셋문자와, 고급 입력기의 '초성 지향 도깨비불'이라는 두 가지 기능 때문이다.
전자의 경우 한글 입력과 관계가 없는 글쇠가 눌러짐으로써 한글 조합이 종료되어야 하며, 후자는 중간에는 '하ㄴ'처럼 조합을 표시하다가 나중에는 '한'으로 바꾸면서 조합을 끝내야 하기 때문이다.
이 작업은 편집기, 외부 모듈, 입력 패드의 각 구현체별로 다 따로 해 줘야 했으며 굉장히 어려운 작업이었다.

프로그램이 처음에 설계될 때부터 이런 것까지 다 고려해서 만들어졌으면 얼마나 좋았겠느냐만, 그 시절에 이것저것 다 따져야 했으면 프로그램이 애초에 제대로 만들어질 수가 없었을 것이다. 그래서 <날개셋> 한글 입력기는 개발된 지 15년이 지난 지금까지도 소스 코드의 이곳저곳이 공사중이다. 예전에 대충 만들었던 코드를 엄밀하게 다시 작성하는 작업이 태반이다.

(2) 외부 모듈: 이번 7.9에서는 아시다시피 Windows 8 이상에서 동작할 때 [한0], [A1] 같은 상태 아이콘의 글자 주변에 검은 테두리가 쳐졌는데.. UI 디자인 가이드라인의 하나만 보고 둘은 몰랐다. 테두리는 검은색이기만 한 게 아니라 반투명 알파값이 적용되어야 하더라..;; 그래서 이것도 마저 적용했다.

(3) 텍스트 필터: '코드 번호로 변환' 필터는 문자를 접두사를 붙여서 해당 글자의 다양한 인코딩 번호 형태로 바꾸는 기능을 제공한다. 알파벳이나 숫자는 원래는 변환 대상이 아니지만 바로 앞의 문자가 인코딩 번호로 바뀌었다면, 또 숫자나 알파벳이 연이어 등장하는 것을 막기 위해서 예외적으로 바꾼다. 다시 말해 '0'은 변환하지 않지만 '가0'은 '\xAC00\x30'처럼 바꾼다는 뜻이다.
그런데 이런 유도리가 유니코드 코드포인트로 바꿀 때에만 적용되었고, 다른 인코딩의 바이트 번호로 바꿀 때에는 적용되지 않았었다. 이것을 모 사용자에게서 지적받고 고쳤다.

4. 버그 수정

(1) 외부 모듈 A: 이번 7.9는... 혹시 눈치 채신 분이 계신지 모르겠는데, 외부 모듈에서 제어판을 이용한 뒤 '미저장 확인'이 동작하지 않는 귀찮은 문제가 있었다. 으윽.. 곧바로 버그 잡음. 편집기나 입력 패드는 상관 없다.
<날개셋> 한글 입력기는 한번 만들고 더 고칠 일 없이 끝이다 싶은 부분도 심심하면 여기저기 파내면서 리팩터링 공사를 하고 있다. 그러면서 불행히도 예기치 못한 실수가 들어가곤 한다.

(2) 외부 모듈 B: 이것은 직전 버전뿐만이 아니라 상당히 오랫동안 존재하던 버그라면 버그이다.
편집기의 경우, 조합이 끝난 한글을 한 글자씩 한자로 바꾸거나 한자를 하나씩 한글로 바꾸면, 글자가 바뀜과 동시에 cursor도 뒤로 밀려났다. 그래서 다음 글자도 연달아 바꿀 수 있다. 그 반면, 두 글자 이상의 글자가 한꺼번에 바뀌면 cursor가 뒤로 밀려나지 않는다.

그런데, 외부 모듈은 편집기와 동일하게 동작이 가능한 TSF A급 환경에서는 한 글자 단위로 변경을 했을 때도 cursor가 뒤로 밀리지 않았다. 안 밀릴 이유가 없는데 구현체별로 동작이 다른 것을.. 꼼꼼한 전체 코드 검증 테스트 끝에 발견하여 수정했다.

또한, 워드패드 같은 일부 TSF A급 구현체에서 0xF 특수글쇠를 이용해 앞 글자를 조합하는 상태로 갔다가 바로 다음다음 글자로 갔을 때, 글자가 생기는 곳과 cursor가 생기는 위치가 어긋나던 문제도 같은 원인 때문이었다. '알려진 문제'라고 오랫동안 도움말에도 등재돼 있던 사항이었는데 드디어 해결되었다.

(3) 입력 패드: '문자표'나 '부수 한자 입력'처럼 콤보 박스가 있는 도구를 꺼낸 뒤, 콤보 박스에서 뭔가를 고르고 나면 프로그램이 바로 뻗었다..;; -_-;; 7.9에만 있는 문제이다. 7.91 패치를 만들기라도 해야 하나 싶은 자괴감이 들었다.

(4) 편집기: 프로그램 창을 최소화시킨 상태에서 시스템 테마 같은 게 바뀌었을 때, 혹은 창의 폭을 아주 작게 한 상태에서 가끔은 텍스트의 문단 정렬 알고리즘에 오동작이 발생해서 프로그램이 무한 루프에 빠지는 심각한 버그가 있었다. 그냥 뺑뺑이만 도는 게 아니라 줄을 나타내는 메모리를 한없이 할당하면서 뻗었다.
굉장히 드문 상황에서 발생하는 문제이고 7.9만의 문제가 아니라 아마 6~7 이전의 굉장히 오래 전 버전부터 존재했던 문제이긴 한데, 이번에 뒤늦게 발견되어 버그를 저격하는 데 성공했다.

Posted by 사무엘

2015/05/04 08:37 2015/05/04 08:37
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1090

Trackback URL : http://moogi.new21.org/tc/trackback/1090

Leave a comment

날개셋 한글 입력기 7.9 -- 下

(上에서 계속됨)
※ 중대한 버그 수정

기능 얘기는 상편에서 그럭저럭 다 했고, 이제는 안정성이나 문서 등 부수적인 변화 사항 얘기를 하겠다.
굳이 직전 버전인 7.7만 그랬던 건 아니지만, 알고 보니 단순한 오동작 수준이 아니라 프로그램이 뻑날 정도의 안정성 버그가 생각보다 여러 곳에 있었다.

  • 편집기에서 Alt+F1로 보조 입력 도구 대화상자를 꺼낸 뒤, '확인'이 아니라 '설정'을 누르고 취소를 눌렀을 때
  • 콤보 박스가 있는 문자표나 부수 한자 입력 같은 보조 입력 도구를 꺼내서 콤보 박스를 클릭한 뒤, 그 상태에서 리스트를 우클릭 했을 때
  • 제어판의 글쇠배열이나 한자 낱자 선택기처럼, 문자열이 아닌 문자 하나만 입력받지만 어쨌든 날개셋 에디트 컨텍스트를 사용하는 자체 컨트롤에서 특수글쇠를 사용했을 때

그리고 외부 모듈은 입력 항목 전환 수식의 값을 잘못 줬을 때 인덱스 오버플로우가 나서 역시 오동작과 crash가 발생할 수 있었다. 해당 문제를 해결했다.

※ 사소한 개선

버그이긴 하지만 프로그램의 안정성에 영향을 끼칠 정도는 아닌 것으로는,
(1) 글쇠배열 편집 윈도우에서 '두벌식 한글'을 입력받는 모드로 가는 단축키 F6이 실제로는 동작하지 않던 문제를 해결했다. 사용자의 제보로 문제를 발견했는데, 이런 것까지 어떻게 찾아 냈는지 신고해 주신 분이 정말 대단하고 고맙다.

(2) 글쇠 수식 편집 대화상자에서 상하 인접 글쇠 버튼을 통해 4단 숫자 자리로 갈 때, 정확하게 인접 글쇠로 가지 않던 문제를 해결했으며, 이 대화상자를 '확인'을 눌러서 종료하면 마지막으로 편집하던 글쇠 위치로 cursor도 자동으로 가 있게 동작을 고쳤다. 이렇게 하니까 역시 훨씬 더 낫다.

(3) 사용자에게 당장 심각하게 와 닿는 문제는 아니겠지만, DLL의 로딩 reference count가 꼬여서 DLL들이 FreeLibrary 때 바로 해제되는 게 아니라 해당 프로세스가 종료될 때에야 해제되던 문제를 해결했다. 직전 버전인 7.7을 포함하여 지금까지 역대 날개셋 프로그램들이 거의 다 갖고 있었던 문제이다.

※ 사소한 변경

(1) 현재 문자표(편집기에서 Ctrl+I)를 꺼내면 유니코드 문자에 대해 BMP 영역에 한해서 그 문자의 이름이 나옴과 동시에, KS X 1001로 변환 가능한 문자는 그 KS 코드 번호도 []로 둘러싸져서 같이 나온다. 그런데 변환 후에 다시 원래 문자로 역변환이 정확하게 되지 않는 문자는 * 로 추가로 표시가 되게 했다.
예를 들어 U+00A9 Copyright sign은 [A8CF]로 바뀌긴 하지만, 엄밀히 말하면 이것은 "동그라미+소문자 C"여서 모양만 비슷할 뿐 실제로 서로 다른 글자이다. 이런 것들이 [A8CF]* 로 표시된다.

(2) 이제 날개셋 설정의 내부에서 외부 파일을 참조하는 경우가 두 가지나 생겼는데(후보 데이터, 문자 집합 데이터), 설정을 저장하거나 불러오는 중에, 자기 자신이 들어가는 컨테이너 파일의 경로에 대한 정보를 감안할 수 있게 했다. 그래서 참조하는 외부 파일이 컨테이너 파일(ist, set, xml 따위)과 동일하거나 그 하부 디렉터리에 있다면, 절대 경로 대신 상대 경로로 저장된다. 그래서 ist/set 파일과 txt 데이터 파일을 같이 인터넷으로 배포한다거나 하는 작업이 원활히 처리 가능해졌다.

(3) Windows 8의 IME들은 [가], [A] 같은 한영 상태가 '검은 테두리'가 쳐진 흰 글자로 찍히는 것이 표준 디자인 가이드라인이다. 이와는 달리 내 프로그램은 잘 알다시피 지금까지 그냥 흰 글자만 찍히곤 했는데, 드디어 이제부터 글자 주위에 검은 테두리가 추가되었다. 직접 보면 차이를 느낄 수 있을 것이다.

※ 문서화

도움말에도 새로 추가된 기능 때문에 당연하게 내용이 추가된 것 외에도, 기존 내용도 10수 군데 이상이 바뀌었다.
아주 사소한 것부터 열거하자면, "답은 한글" 페이지에 재레드 다이아몬드 교수의 quote를 추가했다. 지금까지 당연히 수록돼 있을 거라고 생각했는데 그렇지 않은 걸 뒤늦게 알고는 경악했다.

"기본 자료구조"에서 "한글이 표현되는 방식"에 덧붙여 옛한글이 표현되는 방식을 별도의 지면을 할애하여 미리 설명했다. 한양 PUA는 다 걷어내기에는 이미 인프라가 굳어져 버렸다는 것, 그리고 유니코드 5.2가 가장 이상적이긴 하지만 아래아한글 2010 내지 Windows 8 이상에만 볼 수 있다는 것까지 언급했다.

이 외에도 인디자인 오동작에 대한 설명(명백히 인디자인 자체의 버그임), 단축글쇠 규칙과 관련된 여러 유의 사항들, 사용자로부터 지적된 오타 수정 등이 반영되었다.
다만, 문서 구조가 점점 "훈계 위에 훈계, 줄 위에 줄, 여기에 조금, 저기에 조금"(사 28:10)처럼 돼 가고 있다. 중구난방 산만하지고 있다는 뜻임. 언젠가 또 문서 내용을 싹 다 엎고 재정리를 해야 할 날이 올지도 모른다. =_=;;;

※ 영문 홈페이지

한편, 외국인들은 잘 알다시피 내 프로그램을 오로지 한글 로마자 입력 방식 때문에 사용한다. 도움말을 영작을 도저히 못 하고 있는 게 참 안타까운 현실이긴 한데..
지금까지 페이스북으로 자주 접수된 외국인의 피드백들은 크게 두 가지로, (1) "프로그램 UI가 언제부턴가 갑자기, 혹은 아예 처음부터 한국어로 튀어나온다. 영어로 바꾸는 법은?" (2) "잘 쓰고 있는데 프로그램 바이너리 파일이 삭제되고 제대로 동작을 안 한다."였다.

(1)에 대처하기 위해 영문 버전 홈페이지에 있는 서바이벌 가이드에다 언어를 변경하는 순서를 집어넣었다. (2)는 아마 안티바이러스 프로그램이 시스템을 감시하고 있다가 내 프로그램을 수상하다고 판단하고 무단으로 지워 버리기 때문인 거라고 설명을 넣었다. 내 프로그램은 msi, exe, dll 등등에 디지털 서명이 전혀 없기 때문이다.
아마 Windows 8부터는 다운로드 후에 탐색기에서 msi 파일의 속성을 꺼내서 Unsafe 마크를 수동으로 지워 준 뒤에야 설치가 가능했을 것이다.
쩝~ 서명도 받아야 할 텐데 이것도 한 최하 8.0 버전 이후대로 나중에 생각하기로 한다. 일단은 닥치고 프로그램 연구 개발만 해야 하기 때문에.

※ 다음 버전 계획

새 버전 자랑은 그럭저럭 다 늘어놓은 것 같고 지금부터는 후일담이다.
이번 7.9는 코딩 노예 계약서에 명시되어 있는 여러 아이템들을 이행하고 실현했지만, 그래도 미처 다 이루지 못하고 8.0으로 넘긴 아이템들 역시 많다. 입력 엔진 쪽은 제끼고, GUI 분야에서 작업이 확정되어 있는 것은 다음 두 가지 아이템이다.

(1) 수식에서 숫자는 무조건 한 형태로 획일화하는 게 아니라 10진수, 16진수, 상수 명칭이 적용된 놈 등 사용자가 입력한 원형을 보존하게 할 것이다.

(2) '보조 입력 도구'가 현재 한손 입력기, 화면 키보드, 부수 한자, 문자표 이렇게 4종류가 있다. 여기에 현재 사용자 변수(소문자)의 값과 지금 선택된 입력 항목의 번호를 원하는 형태로 보여주는 "사용자 편의형" 보조 입력 도구를 하나 추가할 것이다.

cursor 근처에 현재의 한영 상태를 표시하는 기능을 좀 추가해 달라는 기능 제안이 있었다. 물론 Windows 8 이상의 메트로 UI에는 이런 기능이 필요하고 날개셋 역시 그걸 지원한다. 하지만 데스크톱 UI에는 이미 멀쩡히 language bar가 운영체제 차원에서 제공되기 때문에 이것은 기능 중복인 관계로, 본인은 그런 제안을 일단 받아들이지 않았다.
굳이 그런 기능이 꼭 필요하다면 사용자가 그런 용도의 보조 입력 도구를 꺼냄으로써 그 기능을 사용 가능하게 할 것이다.

※ 다음 버전에서는 한글 정규화 방식이 변경될 예정

과거에 Windows Vista/7에서는 현대 한글이 자모 조합으로 풀어져서 표현된 것을 역시 한데 묶어서 출력해 주곤 했다. 가령, U+AC00뿐만 아니라 U+1100, U+1161도 똑같이 '가'로 찍어 줬다는 뜻이다. 이건 이전 버전인 XP까지는 없던 기능이었다.
그런데 지난 8부터는, 옛한글 쪽은 유니코드 5.2 자모가 추가되는 와중에 현대 한글을 모아서 출력해 주던 기능은 도로 없어졌다. 어찌 된 일일까?

답부터 말하자면 이것이 표준 규격을 더 준수하는 쪽으로 바뀐 것이기 때문이다.
유니코드 5.2와 함께 한글을 표현하는 규칙도 예전보다 더 엄격하게 바뀌었다. 현대 한글은 무조건 글자마디로, 옛한글이나 미완성 한글은 자모 조합인데 이것도 '초+중+(종)' 형태만 허용한다. 현대 한글을 자모 조합으로 표현하는 것은 이제 지원되지 않게 되었다.

<날개셋> 한글 입력기는 상징적인 의미를 감안하여 지금 7.9는 여전히 놔두고, 다음 버전인 8.0때부터 새로운 정규화 규칙을 적용할 것이다.
맥 OS는 계속해서 한글을 자모 조합으로 풀어서 표현하는데, 이것은 해당 소프트웨어의 잘못이다.

※ 갈수록 복잡해지는 프로그램

<날개셋> 한글 입력기의 전체 소스 코드는 7만 줄의 돌파를 앞두고 있고, 커널인 Ngs3.dll은 이제 15비트 단위를 넘어섰다(> 32768).
<날개셋> 편집기 같은 크기 고정 비트맵 글꼴 하나밖에 지원 안 하는 이 단순한 에디터도 사용자가 키를 하나 눌러서 cursor가 움직이고 A나 '가' 같은 글자가 하나 입력돼서 화면에 찍히기까지..
컴퓨터 내부에서 일어나는 변화와 실행되는 코드, 처리가 내가 보기에 너무 많은 것 같다.

동일한 일을 하더라도 지난 10여 년 동안 온갖 추상화 계층이 늘어나고 이것저것 체크할 게 늘어나다 보니 컴퓨터가 해야 하는 일은 더욱 많아진 것이다.
이 정도 규모의 프로그램이 벌써부터 이 지경이 됐는데 좀 더 최적화를 할 거리가 없는가 하는 자책감(?)이 들기도 하고, 한편으로는 서식이 존재하는 워드 프로세서는 얼마나 더 복잡할까 하는 생각이 든다.

단순 텍스트 에디터보다 복잡한 건 서식이 들어간 에디터이고, 그냥 화면용 서식을 처리하는 것보다 더욱 어렵고 복잡한 건 역시나 그 서식을 장치 독립적인 위지윅 형태로 레이아웃 가능한 워드 프로세서이다. 이미 아시는 분도 있겠지만 단적인 예로, 스프레드 시트인 엑셀은 서식은 지원하지만 위지윅을 지원하는 프로그램은 아니다!

※ 어떤 기능이 새로 추가되기까지의 과정

<날개셋> 한글 입력기에 새로운 기능은 대략 다음과 같은 사이클를 거쳐서 연구 개발되어 왔다. 참고 차원에서 소개한다.

  1. 수요 발생: "어.. 뭐가 불편하다, 이런 방식으로 입력이 가능했으면 좋겠다."
  2. 타당성 검증: "이게 있으면 타자를 더 편리하게 할 수 있거나 이론적으로 커버 가능한 한글 입력 동작의 영역을 더 확장할 수 있는 게 확실하다."
  3. 세부 작계 수립: 이론을 현재의 날개셋 소스에다가 접목한다. "이 기능은 입력 스키마에, 저 기능은 문자 생성기의 요 계층에 들어가면 되겠다. 요 가상 함수를 오버라이드 하면 된다. 이 때문에 부과되는 런타임 상의 메모리/성능 오버헤드는 이 정도이다."
  4. 구현: 기존 소스를 고쳐서 최소한의 기능만 동작하는 형태로 돌려 봄. 핵심 알고리즘을 실제로 구현함. 시제품을 하나 만든 것과 같음.
  5. storage: 이 새로운 기능으로 인해 새로 추가된 설정치 데이터가 있다면, 그걸 바이너리나 XML 형태로 저장되는 방식을 결정함
  6. GUI: 그 새로운 설정치들을 사용자가 고치는 대화상자 인터페이스들을 얹음
  7. 도움말: 새로운 개념, GUI들을 도움말에다 문서화함

5~7은 일종의 양산 단계와 같다. 4에 해당하는 코드가 전투 병력이라면 5~7은 보급 병력인 셈이다.

※ 맺는 말: 세벌식 진영의 파편화에 대한 생각

내 프로그램을 오래 사용하고 이곳 내 블로그에도 종종 들러 오신 분이라면 내 성향을 어렴풋이 알 것이다. (정치· 종교 성향 같은 거 말고=_=;; 한글 기계화 쪽 지론.)
난 골수 공 병우 세벌식주의자이고 세벌식을 그렇게도 깊이 연구했으며 한글 IME를 15년째 만들어 오고 있지만, 나만의 고유한 글쇠배열 하나 발표한 적이 없다.
글쇠배열 자체는 세벌식 최종을 예나 지금이나 별 불만 없이 잘 쓰고 있고, 단지 거기에다가 일부 특수글쇠만을 집어넣어서 "세벌식 무한낱자 수정"이라는 변종을 하나 만들었을 뿐이다. 영문 기호 같은 다른 '문자'를 집어넣은 게 아니다.

즉, 난 선박으로 치면 항해보다는 기관을 연구하는 사람이다. "Bksp를 눌렀을 때 무슨 단위로 지워지게 할 것인가"처럼 글쇠배열을 고치지 않고 그렇다고 NLP 기능도 동원하지 않고, 한글 입력기의 기계적인 메커니즘 자체를 더 정교하고 똑똑하게 만드는 것이 본인의 관심사이다. 문자 입력을 연구한다는 사람이 으레 관심을 갖기 쉽다고 여겨지는 저 두 분야는 정작 거의 다루지 않고 완전히 비껴 갔다는 점이 특징이다.

글쇠배열이야 어차피 이 장점을 살리면 저 단점이 있을 수밖에 없기 때문에, 초중종성이 모두 문맥 의존적이지 않은 독립된 자리에 배당돼 있고 "오른쪽에서 왼쪽 순이라는 큰 틀만 공 병우 스타일에 들면, 그 뒤부터는 뭐 어떻게 만들든지 도찐개찐"이라고 생각한다. 그리고 많은 사람들의 통념과는 달리, 본인은 4단 사용과 여러 겹받침 글쇠가 그렇게 큰 단점이라고 생각하지 않는다. 굳이 기계식 타자기와의 물리적인 호환성까지 고려하지 않더라도, 타자기와 컴퓨터가 사용자 경험이 근본적으로 완전히 다른 것도 아닌데.. 양손 균형과 리듬감을 위해서라도 그런 것들은 필요하다.

즉, 본인은 공 병우 세벌식 패러다임은 이미 타자기 시절 때 큰 그림이 그럭저럭 완성되었기 때문에 오늘날에도.. 무슨 스마트폰이나 아이패드로 논문을 쓰고 책을 저술하는 정도의 격변히 있지 않은 이상 기존 390과 최종의 사이를 절충하는 아주 사소한 변화 이상의 변화가 또 필요하다고 생각하지는 않는다. 모바일이나 터치 스크린을 배려해서 신세벌식 스타일로 중성과 종성을 문맥 의존적으로 중첩 배당하는 것은 불가피한 상황에서 optional한/부가적인 동작 방식으로 별도로 논의해야지, 그게 main이 돼서는 안 된다고 생각한다. 하긴, 최종이라는 명칭조차도 391이 더 정확하다는 말이 있는데.. 일단 7.9에서는 반영하지 않고 그냥 놔 뒀다.

요즘 민간에서는 이 둘의 통합을 목적으로 글쇠배열을 연구하고 날개셋 설정 파일을 배포하는 분이 계신다. 그런 걸 창의적으로 마음껏 연구하고 손쉽게 써 보라고 내 프로그램을 만든 것이니 이것은 일면 반가운 현상이다. 세벌식 자체가 듣보잡으로 걍 묻혀 가는 것보다 백 배 나은 모습이다. 컴퓨터의 속도가 아무리 빨라져도 거품 정렬이 퀵 정렬보다 더 빨라질 수는 없는 것처럼 양 손 열 손가락을 쓰는 환경에서 두벌식은 세벌식을 구조적으로 결코 따라잡을 수 없는 건 명백한 사실이다. 세벌식을 배제한다는 건 한글 입력의 진정한 활용 가능성을 반 이상 제 발로 포기하는 짓이다.

다만 세벌식 글쇠배열이 갈수록 파편화해 가는 것에 대해서는 본인 역시 본연의 임무인 프로그램의 연구 개발을 그럭저럭 마친 뒤엔 좀 더 적극적으로 의견을 내야 할 것 같다. 또한 공 병우 박사를 직접 뵌 적이 있는 후예 세대들과(390 위주), 그 후에 세벌식을 접한(최종 위주) 본인 같은 세대 사이에 좀 더 적극적인 의사소통과 의견 수렴이 필요할 것으로 보인다.

공 병우 박사는 저렴한 보급형 교육용 IBM PC 따위는 거들떠보지도 않고, 1980년대 초 그 옛날에 그 비싼 돈지랄이던 애플 매킨토시로 컴퓨터를 시작한 분이다. 80대 노인이 다 돼서는 그것도 21세기도 아닌 1980년대에 아들뻘인 5, 60대 중장년 후배들을 보고 "지금 시대가 무슨 시대인데 컴퓨터를 안 배우다니 무슨 추태냐! 아직도 펜으로 글을 쓰는 미개한 족속 같으니라고.. 서양에서는 초음속기와 우주선이 날아다니는 마당에 우리는 아직 소 끌고 달구지 끌고 다니는 거나 마찬가지다" 이렇게 갈궜던 넘사벽 얼리어답터임을 생각할 필요가 있다.

이거 뭐 우리 같은 사람은 사고방식이 뭔가 범접할 수 없는 분이다. 또한 본업인 안과학뿐만 아니라 공돌이 기질도 펄펄 넘쳐서 기계 발명도 엄청 많이 하셨던 분인데, 그런 분이 인터넷과 스마트폰을 접했으면 또 무슨 생각을 했을지(일단 스마트폰은 시간을 아껴 주는 좋은 물건이라고 기본적으로 +50점은 먹고 들어갈 듯).. 기계식 타자기와 직접적인 관계가 없으며 전통적인 두벌 세벌 논쟁과는 한 발짝 떨어져 있는 모바일 기기에서는 한글 입력에 대해 어떤 생각을 하셨을지 나로서는 100% 정확하게 시뮬레이션을 할 수 없다. 그래도 글쇠 수를 일부 줄일지언정 도깨비불 현상이 없는 한글 입력 방식은 반드시 필요하다고 주장하셨을지도 모르겠다.

사용자 삽입 이미지

* 지난 3월 6일, 한글 회관에서 열린 공 병우 정신 계승 강연회. 본인은 2005년의 10주기 때도 참석했고 20주기 때도 참석했다. 송 현 선생, 한 재준 교수, 안 대혁 박사가 각각 한글 글자판, 글꼴, 코드 분야에서 공 박사 정신이 끼친 영향력을 잘 강의해 주셨다. 내용도 쉬운 것부터 점차적으로 어려워졌다.

Posted by 사무엘

2015/04/02 08:31 2015/04/02 08:31
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1079

Trackback URL : http://moogi.new21.org/tc/trackback/1079

Comments List

  1. 김재주 2015/04/02 14:43 # M/D Reply Permalink

    저는 도깨비불 현상은 없으면 좋겠지만 있어도 별로 상관없다, 이걸 세벌식의 장점이라고 하기에는 너무 지엽적이고, 실질적으로 퍼포먼스와 관계가 없는 부분이기에 두벌식의 단점이라고 사람들에게 납득시킬 수도 없다.... 정도로 생각이 바뀌었습니다. 그보다는 장시간 타자 시의 손가락 피로도를 합리적인 방법으로 모델링하고, 발전 효과를 수치를 통해 직관적으로 볼 수 있도록 하는 것이 올바른 방법일 것입니다. 공병우 박사님 시절에는 아직 서구 쪽에서도 이러한 연구가 충분치 않았던 시절이고 컴퓨터의 성능이라던지 데이터셋 등도 미흡하던 때라서 복잡한 모델을 만들 수도 이를 최적화할 수도 없었죠. 이는 상당히 아쉬운 일이 아닐 수 없습니다.

  2. 김재주 2015/04/02 15:05 # M/D Reply Permalink

    일전에 말씀드린 적이 있지만 저는 머신 러닝이나 최적화 쪽에 관심이 많습니다. 그래서 언젠가 꼭 이런 방법론을 자판에 접목해보려는 생각이 있었는데, 요즘 보니 저보다 먼저 시작하신 분들이 계시더군요. 제가 처음이 아니라는 점은 아쉽지만 고마운 일이 아닐 수 없습니다.

    신세벌식 방식에 대해 말씀하셨는데, 약간 생각해볼 필요가 있습니다. 중국어나 일본어는 컴퓨터와 인터넷 기술의 힘을 빌어서 본래라면 불편했을 문자생활을 나름대로 편리하게 만들고 있는데, 기존 두벌식 자판이나 세벌식 최종 자판의 경우 사실상 한글의 우수성에 기대고 있다는 느낌도 있습니다.

    분명히 자판 외적으로 입력기의 지원을 통해 편리성과 효율성 두 가지 모두를 잡는 방법이 존재할 것이고, 확실한 효용성이 있다면 적극적으로 도입할 필요성이 있습니다.

    이것은 세벌식의 우수성으로 홍보할 수 있는 세일즈 포인트가 될 수도 있고요. 제가 보기에 지금까지 세벌식 체계에서 나온 방식 중 첫 번째는 용묵님이 구현하신 무한 낱자 입력 및 모아치기이고, 두 번째가 컨텍스트 기반 중종성 구현입니다. 전자는 기존 자판을 그대로 사용할 수 있다는 장점이 있고, 후자는 사실상 더 많은 수의 키를 사용할 수 있는 것과 같은 효과가 있습니다. 불행히도 이 두 가지가 양립할 수는 없으니 어느 쪽이 이점이 있는가는 면밀하게 따져봐야겠지요.

    아무튼 타자기 시대의 자판과 컴퓨터 시대의 자판이 꼭 같아야 하는가? 저는 약간 회의적입니다. 수동식 타자기를 보기 힘든 시대니까요. 하다못해 미국 정도만큼만이라도 타자기가 보급되어 있다면 그래야겠습니다만, 아시다시피 한국은 그렇지가 않지요. 저는 자판이라면, 그리고 먼 미래에라도 인정받고 복수표준의 위치를 노린다면, 지금은 응당 편리성을 우선시해야 할 때라고 생각합니다. 윈도우의 경우도 그렇지만, 쓰는 사람이 많으면 하위 호환성 때문에 오히려 고치기 어렵지요. 두벌식이 제자리걸음을 하는 동안 세벌식은 앞으로 나아가고, 뛰고, 날아야 살아남을 수 있다고 생각합니다.


    최근에 소인배님의 3-2015 자판을 익혀서 써보고 있는데, 이분 생각이 저랑 비슷한 점이 많더군요. 심지어 시뮬레이티드 어닐링을 자판에 적용하신 점까지도. 그래서인지 모르겠지만, 일단 제게는 잘 맞는 것 같습니다. 적어도 한글을 입력하는 도중에는 전혀 시프트를 누를 필요가 없어요. 저야 최종 자판을 쓰던 사람이니까 아랫글쇠는 시프트를 쓰게 됩니다만,

    아무튼 공세벌식의 기본적인 매커니즘과 배치를 거의 그대로 유지한 채로 이렇게나 할 수 있다는 것은 제법 신선합니다. 원판이 좋기 때문에 가능한 일이겠죠.


    한편으로는 표준 두벌식 자판 보면 한숨만 나오죠. 어차피 두벌식으로 할 거라면 배치라도 좀 잘 했더라면 훨씬 더 편안한 배열을 만들 수 있었을텐데 이건 뭐 일부러 힘들게 하려고 만든 qwerty도 아니고

  3. 사무엘 2015/04/03 02:20 # M/D Reply Permalink

    의견 잘 봤습니다. 재주 님뿐만 아니라 소인배 님 등 이공계 쪽으로 깊이 공부를 하신 분들은 세벌식에 대해서도 대체로 탈타자기(?) 등 더 개방적으로 생각을 하는 편이더군요.
    그에 비해 저는 전반적인 사상이 보수 근본주의 성향이어서 그런지 이쪽도 좀 그런 쪽입니다. ㅎㅎ

    1. 중국어· 일본어 입력이야 NLP가 없으면 안 되지요. 한국어에도 그런 쪽 연구가 필요하다고 생각은 하지만 이런 복잡 변화무쌍한 교착어와 맞춤법을 가진 언어에 적용이 쉽지는 않을 것 같으며, 그쪽은 일단 제 관심 분야는 아닙니다. 날개셋은 글자 단위 조합과 기계적인 조합/치환만이 개발 범위이구요.

    2. 도깨비불에 대해서는 저는 좀 더 단호하게 부정적인 입장입니다. 화면상으로 명백히 안 좋은 현상이며, 특히 아무 편견이 없는 어린애들이 컴퓨터를 처음 배울 때 입력 중에 왜 이렇게 글자 모양이 이상하게 바뀌느냐고 교사에게 실제로 묻기까지 할 정도인 현상입니다.
    두벌식에 익숙해져서 도깨비불에 대해서도 당연한 듯이 완전히 무감각한 사용자들의 심정을 이해하는 건 필요하지만, 저는 그게 제 개인적인 소신으로까지 닿을 것 같지는 않아요.
    그리고 그 현상 자체야 비주얼하고만 관계가 있는 것이지만, 그 배후에서 초성과 종성을 같은 손가락 같은 글쇠로 누르는 동작은 불편한 연타를 늘리기 때문에 결국은 퍼포먼스하고도 관계가 있는 거지요.

    3. 저 역시 무슨 2010년대에도 Windows 9x와의 호환성을 고려하며 프로그램을 개발해야 하는 것마냥 타자기와의 호환성이 중요하다.. 같은 말을 하는 건 아닙니다. 하지만 오로지 글쇠 수를 줄이는 것만이 편리한 글쇠배열을 만드는 길이다..라는 주장에는 전적으로 공감하지 않습니다.

    신세벌식 류도 결국은 한 글쇠에 context별 쓰임을 알아야 하기 때문에 결과적으로는 4단까지 쓰는 context 독립인 재래식 세벌식 배열과 학습 곡선이 크게 차이가 나지 않으리라고 봅니다.
    겹받침 글쇠를 암기하지 않아도 되고 shift를 안 눌러도 돼서 좋을까요? 겹받침을 왼손만으로 일일이 하나씩 치느라 불편한 손해도 만만찮습니다. 제가 15년 전에 390에서 최종으로 갈아탄 이유 중 하나이기도 했지요.

    손에 편한 글쇠배열과 타자기 호환이 가능한 글쇠배열이라는 두 이념은 흔히 오해하기 쉬운 것처럼 오로지 일방적인 동전의 양면 같은 모순되는 개념이 아니라는 것입니다.
    물론 애초에 두 손 열 가락을 총동원한 타자가 가능하지 않다거나, 4단까지 화면에다 늘어놓을 여력이 안 되는 모바일 터치스크린 같은 환경이라면 그건 별개의 상황이므로 얘기가 달라져야 할 겁니다.

    아무튼 제가 추구하는 컨텍스트 독립 배열이든, 부분적인 컨텍스트 의존 방식이든, 그래도 궁극적으로 사용자에게 더 편리한 타자 경험을 제공하는 입력 방식이 잘 연구되었으면 좋겠습니다.

    1. 김재주 2015/04/03 05:34 # M/D Permalink

      1. 도깨비불은... 사실 제가 초등학교 들어갈 즈음에만 해도 컴퓨터라는 것을 가지고 있는 사람이 많지는 않았습니다. 그래서 그 시절에서라면 충분히 있을 법한 사례라고 생각하긴 합니다.

      다만 요즘은 초등학생도 스마트폰 하나씩은(그게 아니더라도 폴더폰 하나 정도는) 가지고 있고 이걸로 문자도 하고 카톡도 하고 하면서 자라는 시대라는 것을 감안해야 합니다. 어차피 휴대기기에서 도깨비불 현상을 피할 수도 없겠지만, 아무튼 그런 현상이 다들 익숙하기 때문에 그걸 가지고 이상하게 생각할 사람 또한 점점 줄어들고 있다는 것이죠.

      현실적으로 생각해 보면 지금 이미 컴퓨터를 쓰고 있는 어른들은 두벌식 자판에 완전히 적응이 되어 있기에 세벌식으로 넘어오게끔 하기 어렵죠. (나이가 많을수록 전환하기도 어려울 것이고) 그렇게 전환해서 쓸 사람은 이미 배워서 쓰고 있다고 보는게 맞을 것 같습니다. 그러니 앞으로 세벌식으로 자판을 배울 사람들은 거의 99%는 어린 세대가 될 것입니다. 그런데 이들에게 도깨비불 현상이 문제다. 세벌식에서는 그런 현상이 발생하지 않는다. 이렇게 말해도 "아 그러네. 신기하다. 근데 이게 왜 문제죠?" 라고 하겠죠.

      그러니 어필 포인트는 용묵님께서도 말씀하신 바로 그 부분, 표준 두벌식에서는 받침글쇠와 첫글쇠를 모두 왼손으로 입력해야 하며 배치도 과학적인 방법으로 만들어진 것이 아니어서 피로도가 높다는 점이 되어야 할 겁니다. 철저하게 실용적인 면에서 홍보해야 한다고 보는 것이죠. 속도와 편리성 면에서 모두 앞선다는 점을 납득시킬 수 있다면 도깨비불 현상은 문제도 되지 않을 겁니다.


      2. 중종성 컨텍스트 전환은 당연히 그 자체로 학습곡선이 쉬워지지는 않습니다. 이 방식이 실질적으로 더 많은 키를 사용하는 방법이라고 말씀드렸습니다만, 두벌식과 세벌식의 관계에서 그렇듯 더 많은 키는 더 어려운 학습을 의미하지요. 그러나 이 방법의 궁극적인 장점은 더 많은 '외받침'을 쉬프트 입력 없이 칠 수 있게 된다는 점에 있습니다.

      최종 자판은 너무 많은 외받침이 윗줄에 있고, 겹받침은 무조건 쉬프트와 함께 입력하도록 고려가 되어 있기 때문에 외받침의 조합으로 겹받침을 입력하려고 하면 상당히 괴상한 타법이 되죠.

      소인배 님은 3-2015자판에서 이 점을 수정하여 겹받침을 쉬프트 없이 입력해도 편하다고 하시는데. 제 경험에도 상당히 그렇습니다. 새로 새벌식을 배우는 사람들은 굳이 겹받침 위치를 따로 외울 필요가 없을 것 같더군요. 이런 요소 때문에 최종 자판에 비해 더 쉽거나 비슷한 정도라고 말하는 것 같습니다.



      물론 3-2015가 매우 편리한 자판이라는 점도 분명하지만, 이것이 최적의 자판이라고는 아직 말할 수 없습니다. 소인배님도 그 나름대로 추가적인 개선을 꾀하시겠지만, 저도 나중에 대학원 졸업하고 여유가 되면 손을 대볼 생각입니다.

  4. 김경록 2015/04/03 10:31 # M/D Reply Permalink

    세벌식을 처음 쓸 때부터 세벌식 무한낱자수정을 잘 쓰고 있습니다. 가끔 pc방을 가서 그냥 세벌식만 쓰면 착착 붙는 느낌이 안들때가 많아요 ㅎㅎ

    1. 사무엘 2015/04/03 18:37 # M/D Permalink

      그게 지금 글자를 고칠 때는 좋은 반면, 가끔은 불편할 때도 있죠. 초성 이외의 낱자를 새 글자를 새로 입력하는 용도로도 예외적으로 쓰고 싶을 때. 그걸 타이밍으로 감지해서 다음 글자로 떼어내는 기능을 올해 중으로 추가할 생각입니다.

  5. 리만 2015/04/03 15:10 # M/D Reply Permalink

    이번 7.9에서 (제 생각으로) 제일 눈에 띄었던 한/영 상태의 검은 테두리! 그게 디자인 표준이었군요. 꾸준한 업데이트에 감사할 따름입니다.

    1. 사무엘 2015/04/03 18:37 # M/D Permalink

      네, 그래서 여타 IME들도 상태 표시를 그런 디자인으로 하고 있답니다. 유용하게 사용하시기 바랍니다.

  6. 근성인 2015/04/07 23:05 # M/D Reply Permalink

    한창 야근하고 있을 때 했네...

    1. 사무엘 2015/04/07 23:35 # M/D Permalink

      아니, 근성인님 아직까지도 집에 안 가고 있었나? 요즘 어째 지내시는지?? 우와아앙?

Leave a comment

날개셋 한글 입력기 7.9 -- 上

바야흐로 2015년 봄에 <날개셋> 한글 입력기 7.9를 내놓게 된 것을 기쁘게 생각한다. 번호가 9로 끝나는데 날짜가 마침 서울 지하철 9호선 2차 구간 개통일과 일치하는 것은 그냥 우연...;;치고는 절묘하다. ^^

이번 7.9는 이 프로그램의 개발 역사상 "한글 입력 체계" 카테고리에만 아이템이 제일 많이 추가된 버전이다. 지난 1월 이후로 중간 개발 근황글이 없다시피했는데, 근황글을 쓰는 것조차 시간이 아까울 정도로 지금까지 너무 바쁘게 지냈기 때문이다. 코딩, 글쓰기, 학교 과제, 회사일, 교회 서적 번역..
그래도 8.0까지 가는데 더는 지체할 수가 없어서 이번 7.9에서 한번 쉬었다 가고자 한다.

※ 새로운 날개셋문자: '글쇠 누름' 타입

IME란 기본적으로 특정 키보드 입력을 가로채어 그 대신 운영체제가 제시하는 다른 규격대로 조합/완성 문자열을 생성하여 보내는 프로그램이다. 그런데 발상을 전환하여, A라는 키보드 입력을 가로채어 그 대신 B라는 다른 키보드 입력을 생성하는 기능이 날개셋문자의 타입 차원에서 추가됐다. 여기에는 단타뿐만 아니라 간단히 Ctrl/Shift 조합도 포함될 수 있다.

<날개셋> 한글 입력기는 IME일 뿐 키매크로나 키보드 드라이버 훅킹 같은 걸 '지향'하지는 않는다. 하지만 새로운 날개셋문자 타입을 이용하면 A를 눌렀는데 화살표 키가 눌린다거나, 다른 뭘 눌렀는데 Ctrl+A가 눌린다거나 하는 간단한 치환 효과를 낼 수 있다. 프로그램의 활용 가능성이 더욱 높아지리라 기대한다.

GetMessageExtraInfo 함수가 이런 용도로 쓰인다는 걸 알 수 있었다. 즉, 사용자가 진짜로 누른 키 입력 메시지와, 프로그램이 인위로 생성한 키 입력 메시지를 구분하기 위해서다. 내가 인위로 생성한 키 메시지는 또 가로채지 않아야 하니까. 이는 The old new thing 블로그에도 언급되어 있다. 그리고 <날개셋> 한글 입력기가 개발 15년 만에 이 캐잉여 함수를 사용하는 프로그램의 반열에 올랐다. 경to_the축!

날개셋문자의 종류가 3.0 시절에는 5종류밖에 없던 것(일반, 세벌, 두벌, 특수글쇠, 상태 전이)이 이제는 10종류로, 정확히 두 배로 늘었다(중종-초, 종-초중, 다중 문자, 종성 두벌, 글쇠 누름). 그래서 이 참에 날개셋문자를 생성하는 대화상자도 이렇게 바뀌었다. 라디오 박스 목록 대신, 날개셋문자 기능들이 어떻게 분류되는지를 나무 계층 구조를 통해 알 수 있게 했다.

사용자 삽입 이미지

※ 글쇠 인식 관련 마이너 기능

앞서 언급한 '글쇠 누름' 날개셋문자를 추가하기 위해, 편집기, 외부 모듈, 입력 패드라는 모든 구현체에서 글쇠 인식 부분을 상당수 손질을 해야 했다. 그리고 이걸 수행하는 과정에서 뜻밖의 작업이 덤으로 행해졌는데..
화면 키보드에, 글쇠를 클릭해서 문자를 입력하는 통상적인 기능뿐만 아니라 역으로 사용자가 누른 키보드 글쇠를 화면에다 표시해 주는 기능을 드디어 추가했다. 화면 키보드를 우클릭하면 이걸 켜는 옵션을 볼 수 있다.

그리고 '글쇠 누름' 날개셋문자를 생성하는 UI를 구현하려다 보면 결국은 "입력하고자 하는 글쇠를 직접 눌러서 선택"하는 UI가 필요해진다.
이걸 구현하는 김에, 예전 고급 입력 스키마의 '고급 글쇠 인식 옵션' 대화상자에다가도 [...]버튼을 추가하여 대상 글쇠를 콤보 상자에서만 고르는 게 아니라 직접 눌러서 고르는 UI를 같이 추가했다.

※ 입력 스키마와 글쇠배열

(1) 글쇠 수식의 R 변수에다가 임의의 32비트 크기의 난수를 되돌리게 하는 옵션을 '고급 스키마'에 추가했다. 입력 동작을 non-deterministic하게 만드는 기능인데 굳이 '기본 스키마'가 갖춰야 할 기능이라 생각되지는 않아서 고급에다가만 넣었다. 'A'+R%26 이렇게 수식을 넣어 주면 A부터 Z까지 아무 알파벳이 임의로 입력되게 된다.
R 변수는 실제로 사용할 때만 값이 정해진다. 사용하지도 않는데 매번 무조건 난수값이 계산되고 사이클이 변하는 것은 아니다.

(2) 필요하다면 글쇠배열 수식의 전후에, 모든 글쇠에 대해 공통으로 실행할 수식을 지정할 수 있게 했다. 소문자로 된 사용자 정의 변수를 공통으로 초기화한다거나(전처리), 그리고 날개셋문자를 되돌릴 때 사용하는 변수값과 최종적으로 변경되어야 하는 변수값이 다를 때(후처리) 이 기능을 사용하면 된다.
물론 이런 전처리/수처리 수식을 사용할 정도이면 글쇠 수식이 정말 상황 의존적이고 복잡한 상황일 것이다. 한글 입력 순서를 자동으로 계산하는 기능은 그런 보조 수식은 고려하지 않고 동작한다.
지금까지 글쇠배열과 관련된 속성 숫자를 지정하는 입력란이 있었지만 사용하지는 않고 있었는데, 이제부터는 그 숫자를 이런 옵션을 저장하는 용도로 사용할 것이다.

(3) 글쇠배열 수식의 T 변수에는 기본 입력기가 만들어 내는 한글 조합의 오토마타 상태만 들어있었다. 그러나 옵션을 준 경우 고급 입력기가 만들어 내는 사용자 정의 조합의 상태 번호도 여기에 들어가고, 그 대신 이 조합의 타입 값이 C라는 변수에 들어가게 했다. 한글이면 1, 사용자 정의 조합이면 2이다. 하지만 고급 입력기의 사용자 정의 조합은 개념상 오토마타와 낱자 결합을 통합한 로직을 자체적으로 갖고 있기 때문에 글쇠배열이 조합 상태에 따라 조건부로 동작해야 할 일은 그리 많지 않을 것이다.

(4) 또한 옵션을 준 경우, 굳이 '상태 전이' 날개셋문자를 사용하지 않고 글쇠배열 수식에서 T 값을 변경하면 그걸로도 상태 전이 효과가 나게 했다. 이게 언제 유용한지는 좀 더 생각해서 입력 예제를 만들어 봐야 할 것 같다.

※ 입력 기능 추가

다음으로 문자 생성기 계층으로 넘어가면,
(1) '낱자 재결합' 텍스트 필터의 기능을 일부 수행하는 특수글쇠가 추가됐다. 기[ㅇ](종성 조합 중)을 [깅]으로 바꾼다거나, 저렇게 앞으로 가는 게 아니라 뒤로 결합을 하는 특수글쇠도 있다. 물론 이것은 조합이 끝난 옆의 글자를 변형하는 기능이기 때문에 TSF A급 구현체에서만 제대로 동작한다.

(2) 비록 이번 7.9에서 온전히 구현되지는 않았지만 곧 지원될 세벌식 지능형 동시치기 기능을 염두에 두고 음수 오토마타 지시자가 두 개가 새로 추가되었다.
지금 입력된 글쇠뿐만 아니라 직전의 글쇠까지 동시에 다음 글자로 옮기는 것, 그리고 지금 입력된 글쇠와 예전에 입력된 글쇠의 입력 순서를 바꾸는 것인데, 이와 비슷한 기능을 하는 특수글쇠도 같이 추가되었다.
앞으로 입력 스키마 차원에서 새로운 기능이 추가되면, 세벌식 글자판에서도 글쇠 입력 타이밍에 따라 도깨비불 비슷한 게 일어나면서 글자 재배치가 일어나는 동작을 볼 수 있을 것이다. 문자 생성기의 기존 기능을 이런 식으로 활용하는 것이다.

(3) 낱자 결합 규칙은 잘 알다시피 A + B = C의 형태인데 여기서 A, B, C는 모두 0이 아니어야 한다. 단지, A~C를 0인 것처럼 보이게 하는 가상 낱자 규칙만을 추가로 지정할 수 있을 뿐이다.
그런데 이번 버전에서는 그 금기를 깨고, 65530이라는 끄트머리의 reserved 낱자와 결합을 시도하는 경우 지금 낱자가 무조건 0으로 바뀌게 하는 예외를 추가했다.

이런 기능이 왜 필요한 것일까? 성분과 성분을 왔다갔다 하는 굉장히 기발한 입력 방식이 존재하기 때문이다. 그 예 중 하나는 김 민겸 님께서 고안한 입력 방식이다.
이걸 보면 "ㄱ → 그 → ㅋ", "ㄱ → 기 → 끼"라는 규칙이 있다. 모음 ㅡ가 한 번 입력되어 버렸는데 그때 또 ㅡ가 입력되면 그 뒤엔 모음은 0으로 깨끗이 초기화되고 초성만 ㅋ으로 바뀌어야 한다.

단순히 표시만 0으로 되는 가상 낱자여서는 곤란하다. ㅋ이나 ㄲ이 만들어진 뒤에 또 후속 모음이 입력되는 경우를 논리적으로 감당할 수 없기 때문이다.
이때 ㅡ 자리에는, 현재 초성으로 ㄱ이 입력되어 있는지를 점검한 후, ㄱ이 있다면 ㄱ을 ㅋ으로 바꾸는 초성을 입력함과 동시에 중성 자리에는 65530을 주면 된다. 이때는 오토마타도 초+중 상태이던 것을 초성 상태로 되돌리게 해야 한다.

<날개셋> 한글 입력기는 이런 것도 이제 이론적으로 수용 가능하게 되었다. 단, 이렇게 여러 낱자가 한꺼번에 변하는 변칙적인 입력 방식은 입력 순서 찾기 같은 자동화 기능의 혜택을 받을 수는 없다. ^^

※ 고급 입력기에 기능 추가 (특히 초성 지향 도깨비불)

온갖 복잡한 기능과 옵션을 동원해서 한글 한 글자를 조합하는 기능은 '기본 입력기'에 다 들어있다. '고급 입력기'가 하는 일은 비한글 문자도 조합을 잡는 걸 가능하게 해서 한글 조합과 혼용하는 것이다. 그리고 한글을 여러 한글로 풀거나 비한글 문자가 섞인 형태로 표현하는 것도 그런 기능에 포함된다.

(1) "한글 출력 치환"에서 "글자 치환" 기능은 지금까지 그냥 이 한글을 저 한글로 치환한다는 식의 테이블 기반 치환만 지원했다. 그러나 수천~수만 자의 한글을 치환해야 하고 치환 규칙이 뭔가 수식으로 표현이 가능하다면, 무엇을 무엇으로 치환할지를 A,B,C에 대한 수식으로도 깔끔하게 표현 가능하게 했다.
유니코드 PUA 영역에다가 여러 글자들을 배당해 놓고 그 글자를 마치 한글 입력하듯이 입력하고 싶다면, 이 출력 치환 기능을 이용하면 된다.

(2) 그리고 "낱자 치환"에서 특별히 종성을 치환하는 기능은 지금까지 가상 낱자와 연계해서 ㄴ+ㅇ 같은 임시 상태를 표현하는 데 쓰이곤 했다. 이번 버전에서는 그걸 더 확장해서 "초성으로 먼저 나갔다가 다시 앞 글자 받침으로 들어가는" 도깨비불 현상을 구현하는 옵션을 추가했다. 다시 말해 "울 -> 우리"가 아니라, "하ㄴ -> 한ㄱ" 이런 식으로 입력이 진행된다는 뜻이다.

지금도 이미 모든 종성에 대해서 종성 A를 "빈 종성 + 초성 A"로 치환하는 종성 치환 규칙을 수동으로 집어넣으면 이런 동작을 구현할 수 있다. 하지만 이 기능은 지금 도깨비불 현상 예상 결과를 토대로 자동으로 구현해 주기 때문에 낱자 치환 기능의 옵션으로 들어간 것이다.

이렇게 종성까지도 초성을 먼저 추구하는 두벌식은, 초성조차 종성 형태로 먼저 입력되는 '종성 지향 두벌식'과는 성향에 관한 한 완전히 딴판이다. 그에 반해 수식을 이용해 초성에서는 초성, 종성에서는 종성 문맥으로 동작하는 일반적인 두벌식은 중도(?) 성향이고 말이다. <날개셋> 한글 입력기는 이런 두벌식의 세밀한 패러다임을 모두 잡아 냈다.

받침이 없는 글자가 받침이 있는 글자보다 더 많기 때문에 두벌식 자판의 도깨비불 현상은 "초성부터 먼저 표시했다가 다음에 종성으로 가는 형태가 원칙상 옳다"라고 주장하는 분이 계신다. 이런 방식은 도깨비불 현상 이질감이 약간 덜할지는 모르지만 조합 중인 한글의 글자 수가 잠시 둘로 늘어나며, 조합이 완성되었을 때의 글자 형태(한)와 조합 중일 때의 글자 형태가(하ㄴ) 달라지는 문제가 있다. 그러니 '선종성 후초성' 방식이 대세가 된 건 다 아무 이유 없이 그리 되지는 않은 듯하다. 이번 7.9 버전도 그 조합 중단 처리가 원활하지 못하기 때문에 이는 8.0에서 풀어야 할 숙제로 남기게 되었다.

※ 새로운 '허용 한글 범위' 기능

지금까지 '허용 한글 범위'로 선택할 수 있던 기능으로는 커널이 기본 제공하는 "KS X 1001 완성형 2350자"에 덧붙여 플러그 인이 제공하는 "한양 PUA 완성형 옛한글 5299자", 그리고 "한컴 2바이트 완조형 옛한글" 정도가 고작이었다. 2350자 테이블이야 날개셋 커널이 완성형 한글 글꼴을 지원하기 위해 어쩔 수 없이 갖추고 있는 것이고 그래서 허용 한글 범위 기능까지 완전 덤으로 제공하는 것이다. 나머지 legacy 기능들도 그냥 명분상으로 제공될 뿐이지 이 유니코드 5.2 천하통일 시대에 딱히 의미가 있다고 보기는 어렵다. '설정'을 눌러도 딱히 설정할 것 역시 없다.

그러나 7.9부터는 이 기능을 예전보다는 좀 더 창의적으로 활용할 수 있게 되었다.
(1) 고급 입력기와 연동하여 "글자 치환"이 존재하는 한글만 입력이 허용되게 하는 기능이 있었는데, 여기에 덧붙여 "낱자 치환"이 된 낱자의 다음 낱자부터는 입력되지 않게 하는 기능도 추가되었다.

좀 변칙적인 입력 방식 중에는 같은 글쇠를 눌렀는데 한글과 비한글 문자가 순환되는 형태인 것이 있다. 비한글도 내부적으로는 가상의 한글 낱자인데 단지 그걸 비한글 문자로 치환해서 출력하는 것일 뿐이다. 그래서, 정말로 한글 초성을 입력하고 있었다면 중성이나 종성으로 더 진행이 가능한 반면, 지금이 비한글 문자로 치환된 초성을 조합하는 상태라면 중성 같은 다음 성분이 현 글자에 붙지 않고 다음 글자로 떨어져 나가게 한다. 이런 기능이 '허용 한글 범위'와 연동이 가능하다는 것이다.

요컨대 한글과 비한글 문자를 섞어서 입력한다면 '낱자 치환'에다 제약을 걸면 되며, 한글을 그 자체로는 전혀 사용하지 않고 다른 문자를 입력하는 수단으로만 사용한다면 '글자 치환'에다 제약을 걸면 된다. 후자는 한글로 일본 문자를 입력하는 것이 대표적인 예인 것이다.

(2) 그리고 사용자가 지정한 UTF-16 방식의 텍스트 파일에 있는 한글만을 조합 허용하고 그렇지 않은 것은 불허하는 기능이 추가되었다. 이거 하나만 있으면 앞으로 '허용 한글 범위'에 데이터 기반의 새로운 기능이 더 추가될 여지 자체가 없을 것이다. 외장형 후보 변환 데이터와 더불어 <날개셋> 한글 입력기가 외부 데이터 파일을 참조하여 동작하는 경우가 하나 더 추가되었다.

예제로는 KS X 1001 2350자에다가 오늘날 완전히 공기 잉여화한 문자 집합인 KS X 1002 1930자를 합한 데이터를 제공하므로 이것을 불러다가 사용하면 된다. 여러 입력 항목들이 동일한 데이터 파일을 읽더라도 한 파일은 메모리가 한 번만 할당되는 정도의 처리는 다 돼 있다.
(下에서 계속됨)

Posted by 사무엘

2015/03/30 08:33 2015/03/30 08:33
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1078

Trackback URL : http://moogi.new21.org/tc/trackback/1078

Comments List

  1. 박지호 2015/03/31 17:18 # M/D Reply Permalink

    세벌식 사용자입니다. 날개셋 잘 사용하고 있습니다. 감사합니다.^^

    1. 사무엘 2015/04/01 09:49 # M/D Permalink

      감사합니다. 유용하게 활용하시고 많이 알려 주세요~ ^^

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 12 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/06   »
            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:
1203342
Today:
54
Yesterday:
756