« Previous : 1 : 2 : 3 : 4 : 5 : ... 11 : Next »

날개셋 한글 입력기 9.81

원래 이 글은 날개셋 한글 입력기 9.9의 개발 근황 소식이 될 예정이었으나, 중간 소규모 업데이트인 9.81을 소개하는 글로 용도가 바뀌게 되었다.
이번 버전에서는 외부 모듈의 다음 두 시급한 문제가 해결되었다. 이것 때문에 9.81이 먼저 나오게 됐다.

  • Chrome 브라우저에서 한글 조합 중에 마우스 클릭 등으로 조합을 종료했을 때 조합 문자열이 덧나는 문제 (주소 입력란, 웹페이지 내부 입력란 모두)
  • Outlook에서 한글이 뒷글자가 지워지면서 겹침 형태로 이상하게 입력되는 문제

하지만 이들 문제를 해결하는 방법은 동작하는 프로그램의 이름을 파악해서 해당 프로그램에 대해서만 인위적으로 보정을 하는 매우 단기적이고 지저분한 방식이 될 수밖에 없었다. 당장 9.8 버전에서 Outlook 오동작이 발생했던 이유도 크롬이 뻗는 더 심각한 버그에 적용되었던 해결책이 다른 프로그램에서는 부작용을 일으켰기 때문이었다.

크롬의 조합 문자열 덧나는 문제 보정은 다음과 같은 한계가 있다.

  • 내 입력기가 제공하는 기능 중의 하나인 초성 지향 두벌식은 조합이 종료됨과 동시에 조합 문자열이 딴 걸로 바뀌는 게 가능해야 제대로 구현할 수 있다. '날'에서 '나라'가 되는 게 아니라, '나ㄹ'에서 '날'이 나중에 만들어지는 기능 말이다. 하지만 이건 크롬에서 기술적으로 가능하지 않다. '나ㄹ날' 이렇게 글자가 덧나는 문제가 여전히 발생한다.
  • 크롬이 차기 버전에서 자기의 버그를 고치는 경우, 이 보정 동작은 반대로 조합 중인 문자열이 씹히고 날아가 버리게 하는 버그로 바뀌게 된다! 내 입력기는 크롬이 그 버그를 갖고 있는지, 아니면 고쳤는지를 기술적으로 판단할 수 없기 때문이다.

이 점을 염두에 두고 감안하시길 바란다.
이것 말고 이번 9.81에서는 UI 쪽에도 여러 자잘한 것들이 바뀌고 개선되었다.

  • 이모지로 쓰이는 U+1F9??대의 "기호 및 픽토그램 보충"도 영역명을 정식으로 추가하고 글꼴 본뜨기 스크립트에 반영했다.
  • 반대로 PUA 영역에 샘플 차원에서 오랫동안 남아 있던 옛날 아래아한글 사용자 영역 잉여 심벌 글꼴을 삭제했다. PUA에는 구결, 그리고 반각 한글 음성 부호 내지 풀어쓰기 부호만 남겨 놨다.
  • 도움말도 Firefox 브라우저를 TSF 기반 프로그램으로 언급했으며, 유니코드 1.1 / 2.0 / 5.2 내력 등 몇몇 내용을 고치고 더했다.

※ 자잘한 버그 수정

  • 지난 9.8에서 입력 도구의 리스트박스에서 마우스 휠 스크롤이 가능해지긴 했다. 그런데 스크롤할 것이 없는 화면에서 휠을 굴리면 위치 계산이 잘못되어 화면의 내용이 일시적으로 싹 사라지는 버그가 있었다. 이를 고쳤다.
  • '한글 표현 방식' 페이지를 여는 것만으로 날개셋 제어판의 '적용' 버튼이 잘못 켜지던 아주 사소한 버그를 발견하여 고쳤다. 외부 모듈에서 날개셋 제어판을 열면 적용 버튼 자체가 표시되지 않긴 하지만.. 외부 모듈 말고 '입력 패드'에서 제어판을 열면 이 현상을 확인할 수 있다.
  • 입력 설정을 팩토리리셋(?) 하거나, Edge 같은 메트로 앱에서 날개셋 한글 입력기를 구동했을 때.. 0번과 2번 글자판에 둘 다 두벌식이 잡히던 문제를 해결했다. 0번이 두벌식이면 2번은 세벌식으로 잡히는 게 본인이 의도한 동작이었다.

맨 앞의 휠 스크롤 버그를 제외하고 나머지 둘은 직전 9.8만의 문제가 아니며, 더 옛날부터 존재했던 버그이다.

※ 외부 모듈의 한자 변환 관련

(1) 외부 모듈의 한자 선택 UI에서, 1줄짜리 작은 화면과 n줄짜리 큼직하게 펼친 화면을 전환하는 자그마한 버튼을.. 오랫동안 Wingding 글꼴의 삼각형 그림문자로 표시하고 있었으나, 이번에 >>로 깔끔하게 수정했다.

사용자 삽입 이미지

(2) MS Word는 우클릭 메뉴를 통해 한글과 한자를 변환하는 기능을 제공하며, 날개셋 역시 이 인터페이스를 꽤 옛날 버전부터 지원해 왔다.
그런데 날개셋이 단어 단위로 한자 변환이 가능해진 건 6.x 후반대부터이며, MS IME와 완전히 동일하게 단어의 앞부분부터 한자어를 탐색하게 된 것은 무려 8.x의 후반대부터이다.

이런 기능이 구현된 뒤에도 MS Word의 우클릭을 통한 한자 변환은 먼 옛날 버전과 동일하게 1글자 단위로 머물러 있었다. Word에서밖에 볼 일이 없는 기능이며, 다른 기능이나 버그 수정에 비해 개발 우선순위가 낮았기 때문이다.
오랜 마음의 부담으로 남아 있던 부분을 드디어 손 봤다. 이제 Word의 우클릭 메뉴에서도 단어 단위로 한글에서 한자 또는 한자에서 한글 변환이 가능해졌다. 편집기 계층의 옵션에서 "단어 단위 한자 변환"을 켜기만 하면 된다.

사용자 삽입 이미지

※ MS Word black blank 문제

MS Word에서 기존 MS IME로 한글을 입력하다가 나중에 입력기를 날개셋으로 바꿔서 한글 입력을 시작했을 때..
이전에 MS IME로 입력했던 구간들의 공백이 다 시커멓게 바뀌던 일명 black blank 버그를 고쳤다. 아니, 정확히는 그냥 그 문제가 발생하지 않게 회피 조치를 취했다.

이건 Office 2007때부터 10년 넘게 존재했던 유명한 문제이다. (2003 이하에서는 그런 문제 없음)
심각한 문제는 아니다. 프로그램이 뻗는다거나 하는 문제는 아니며, 문서를 저장했다가 다시 불러오면 시커먼 공백은 사라진다. 그냥 그런 알려진 문제가 있다고 도움말에도 진작부터 실려 있었다.

이건 엄밀히 말하면 MS Word 내지 MS 한글 IME만 특이하게 동작하는 걔네들의 문제라고 봐야 한다.
그렇게 한글을 쓰다가 굳이 날개셋뿐만 아니라 타 중국어· 일본어 IME로 바꿔서 글자를 입력해도 동일한 문제가 발생하기 때문이다.

사용자 삽입 이미지

아 참고로.. 세벌식으로 쳤을 때만 저런다(MS IME에서). 두벌식으로 쳤을 때는 안 저런다.

한국어 IME에서는 별로 쓰일 일이 없지만 중국어· 일본어 IME에서는 밑줄처럼 조합 문자열의 속성 지정 기능이 쓰인다.
이걸 살짝 건드리는 것만으로 이미 입력된 텍스트가 저렇게 바뀌는 건 일부러 저런 버그를 구현하기가 더 힘들 것 같다만..
그냥 안 건드림으로써 문제가 생기지 않게 했다. 한컴 입력기에도 그런 문제가 없기도 하고 말이다.

※ 동작 방식 변경

(1) 편집기를 종료하거나 모든 창을 닫을 때, "앞으로 이 질문을 하지 않음" 옵션은 진짜로 앞으로 닫아야 할 창이 2개 이상 남아 있을 때에만 나오게 동작을 좀 더 똑똑하게 개선했다. "빈 문서는 저장 확인을 하지 않음" 옵션까지 감안해서 말이다.

(2) 편집기에서 한 화면의 페이지 수를 계산할 때, 맨 아래 마지막 줄은 자신의 줄 간격을 포함하지 않고 글자 자체의 높이만 고려하게끔 동작 방식을 바꿨다.
덕분에 마지막 줄이 글자가 뻔히 다 나타나 보이는데도 화면에 표시된 줄로 간주되지 않아 그 위치로 cursor가 이동하지 않고 화면이 스크롤되던 비효율을 해결했다.

사용자 삽입 이미지

(3) 입력 도구에서 각종 목록이 한 화면에 충분히 들어가서 스크롤을 할 필요가 없으면 실제 운영체제 GUI처럼 스크롤바 버튼이 disable되게 했다. 그리고 스크롤바가 너무 작아서 한 화면에 제대로 표시를 할 수 없으면 bar 영역이 아니라 버튼 영역만 보이게 했다.
이건 옛날에 대충(?) 만들고 오랫동안 미완성으로 남아 있던 부분을 보완한 것에 가깝다.

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

(4) 부수 한자 입력과 문자표에서.. 목록에 나타난 글자를 클릭하고 있으면 글자가 확대되어 보이는 기능을 드디어 구현했다.
이 두 도구가 제공된 지는 지난 5.x 버전 이래로 어언 10년이 돼 가지만.. 이 간단한 기능이 없어서 지금까지 뭔가 좀 허하게 느껴졌었다.

사용자 삽입 이미지

※ 이모지 문자표 추가

사용자 삽입 이미지

그리고 요놈을 추가했다. 이모지 문자표.
9.61에서 추가됐던 필기 인식에 이어, 그냥 운영체제가 제공하는 기능만 그대로 활용하는 입력 도구가 하나 더 추가됐다. 이로써 입력 도구는 총 12개가 되어서 제법 많아졌다.

사실 얘는 넣을까 말까 좀 고민되기도 했다. 한글 입력이랑 직접적인 관계가 있는 기능이 아니고 이모지 문자표는 Windows고 mac이고 다 운영체제 차원에서 기본 제공되는 게 요즘 추세이니 말이다. (Windows의 경우 Win+.)
하지만 이 기회에 컬러 폰트 API를 실습해 보고 싶기도 하고, 여느 문자와는 성격이 다른 이모지를 입력하는 별도의 UI도 있긴 해야겠다는 생각에 며칠 작업을 해서 해치웠다.

필기 인식이 Windows Vista 이상을 요구하는데, 이모지 문자표 도구는 그보다 더 높다. Segoe UI Emoji 폰트가 존재하는 Windows 10 이상(혹은 8.1??)에서만 제대로 사용할 수 있다. 이건 날개셋 한글 입력기에 구현된 기능들 중 요구하는 운영체제 버전이 가장 높은 기능이다.
운영체제가 기본 제공하는 이모지 문자표와 달리, 날개셋에서 제공하는 문자표는 크기 조절이 되며, 창을 계속 띄워 놓은 채로 딴 프로그램도 계속 사용하면서 이모지들을 입력할 수도 있다.

이 정도면 9.81 정도의 버전업 명분과 정당성은 충분할 것이다.

Posted by 사무엘

2019/08/27 08:36 2019/08/27 08:36
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1655

날개셋 한글 입력기 9.8, 그리고 타자연습 3.9가 4개월이 넘는 긴 공백기를 거친 뒤 드디어 완성되어 나왔다. 이번 버전은 버그를 엄청 많이 잡은 걸로는 역대 그 어떤 버전에도 뒤쳐지지 않지 싶다. 물론, 버그만 잡은 게 아니라 자잘하게 새로운 기능도 여럿 들어갔다.

한시름 놓긴 했지만 쉴 틈은 없다. 또 작업할 것들이 잔뜩 생기는 바람에 9.9는 무조건 나와야 하게 생겼다. 올가을쯤에 말이다. 박사 졸업하기 전까지 10.0은 없다는 게 내 당초 계획인데 계획이 간당간당해졌다. 당장 이번 9.8에도 새로운 작업 내역으로 인한 부작용과 결함이 발견되지 않길 바랄 뿐이다.

※ 외부 모듈

1. 악명 높던 크롬 버그

Chrome 브라우저의 버전 75 정도의 최신 버전에서부터 갑자기 한글 입력이 제대로 되지 않고 브라우저가 뻗기까지 하던 그 버그를 일단 해결했다.
처음엔 잘 동작하다가 나중 버전에서 문제가 발생했으면 그건 일차적으로 내 프로그램이 아니라 크롬의 문제이지, 왜 나만 갖고 그러는지-_-;; 본인으로서는 억울한 노릇이었다. 허나, 크롬은 워낙 널리 쓰이는 세계구급 프로그램이고, 마소 입력기나 심지어 아래아한글 2018과 함께 제공되는 한컴 입력기는 별 문제가 없는 듯하니 역시나 내 프로그램에 대해 유죄 추정의 원칙을 적용해야 했다.

이게 정말 난감한 문제이고 7월 중순이 다 돼서야 새 버전이 나올 수 있었던 이유는.. 크롬에게 맞게 내 프로그램을 수정하고 나면, 이미 맞게 동작하고 있는 다른 프로그램에서 교묘한 부작용과 문제가 발생했기 때문이다. 내 경험상 Windows에서 단일 로직만으로 모든 프로그램에서 잘 동작하는 외부 모듈을 만드는 건 거의 불가능하다. 답이 없다.

2. 암호 입력란 지원

크롬과 파이어폭스 브라우저에서 표시된 웹 페이지의 암호 입력란에서, 내 입력기가 영문 전용 모드로 바뀌지 않고 한글 입력이 된다는 것을 사용자 제보로 접수받아서 수정했다.
난 IE 말고 타 브라우저들은 크로스 플랫폼이고 에디트 컨트롤도 운영체제 보급이 아니라 자체 구현했을 정도이니.. 암호 입력란에서 IME가 동작하는 것 역시 일부러 그렇게 만든 것인 줄로 오랫동안 생각해 왔다. 그런데 얼마 전에 버그 신고가 들어온 걸 확인해 보니 내 입력기만 그렇게 동작하는 듯했다.;;

원인을 찾아보니, 영문 전용 모드로 동작하는 방법이 하나만 있는 게 아니었다. IE가 사용하고 날개셋도 인식하는 방법은 IME의 컨텍스트를 아예 지정하지 않는(null) 것이다. 그러나 크롬과 파이어폭스가 사용하는 방법은 컨텍스트를 주기는 하고, 거기서 disable이라는 속성을 추가로 주는 것이었다.

으음.. 이것도 표준 스펙이라고 명시는 돼 있지만, 이건 지난 10년이 넘는 세월 동안 날개셋 한글 입력기가 3.x 버전부터 외부 모듈이 개발된 이래로 단 한 번도, 전혀 지원한 적이 없던 프로토콜이었다. 지원 안 해도 어지간한 타 프로그램들에서 문제가 없었기 때문이다. 그랬는데 이 프로토콜을 사용하는 프로그램을 거의 처음으로 마주치게 됐다.

3. 조합 종료 처리

일부 TSF 기반 프로그램 내부에서 한글 조합 중에 여러 외부 요인에 의해 조합이 종료돼야 하는데 제대로 되지 않던 문제를 해결했다. 날개셋 편집기 내부에서 '빈 입력 스키마'를 골라서 날개셋 외부 모듈을 사용하는 상황을 가정한다.
한글을 조합하는 중에 (1) 마우스로 프로그램 바깥을 클릭하거나 Alt+tab을 눌러서 딴 프로그램으로 갔을 때, (2) 도구모음줄로 '새 파일', '찾기/바꾸기' 같은 걸 눌러서 포커스가 바뀌었을 때, (3) '찾기/바꾸기' 대화상자에서 '찾을 문자열'을 열심히 입력하고 있던 중에 Alt+N을 눌러서 그 입력란의 텍스트가 전부 블록 잡혔을 때에 대해서 개선 작업이 행해졌다.

(1)과 (2)의 경우.. 조합을 종료하는 것 자체는 기술적으로 가능했다. 하지만 저것만 되게 만들어 놓으면 엑셀 같은 프로그램에서 한글 첫 타가 씹히고 조합이 끊어지는 부작용도 같이 발생하는 게 문제였다. 그래서 두 조건을 모두 만족하면서 MS IME와 동일하게 동작하는 방법을 알지 못해서 조합 종료도 포기하고 그냥 놔 뒀었는데, 요 최근에 두 조건을 모두 만족시키는 깔끔한 방법을 다행히 발견해 냈다.

(3)은 외부 모듈이 아니라 날개셋 자체 에디트 컨트롤 쪽이 동작이 개선됐다. 그 상황에서는 날개셋이 생성한 조합뿐만 아니라 운영체제의 외부 모듈이 생성한 조합도 종료시키도록 조치를 취했다.

그리고..
2글자 이상 단어 단위 한자 변환이 가능한 TSF 기반 환경에서 한자 키를 누른 상태에서 다른 프로그램으로 갔다가 돌아왔을 때..
블록이 잡혀 있던 그 한글 단어가 지워져 버리던 버그도 발견하여 고쳤다. 처음부터 이렇지는 않았는데 Windows 후대 버전부터 발생하기 시작한 것 같다.

※ 나머지 기능 강화/개선

4. 입력 도구의 내부에서도 마우스 휠 지원

과거에 Windows에 마우스 휠이 처음 도입됐을 때는 휠이 굴렀다는 메시지가 키보드 포커스를 받고 있는 윈도우로만 전해졌다. 그런데 입력 도구들은 태생적으로 키보드 포커스를 받지 않는 윈도우이니, 마우스 휠과는 인연이 전혀 없을 것으로 여겨졌다.
하지만 Windows 8인가 10부터는 마우스 휠 메시지가 키보드 포커스 윈도우가 아니라 여느 마우스 메시지처럼 마우스 포인터가 놓여 있는 윈도우에 전해지도록 동작이 수정되었다. 그래서 입력 도구도 휠 메시지를 받을 수 있게 되었기 때문에 이에 대한 처리를 추가했다.

이제는 문자표, 부수로 한자 입력, 한자 변환 UI 등에서 휠을 굴려서 목록을 스크롤 할 수 있기 때문에 해당 기능들을 사용하기가 더 편리할 것이다. 단, 휠을 누르는 건 지원하지 않고 굴리는 것만 지원한다.

5. 편집기: 토씨 자동 교정 기능의 강화

한국어에서 '야'는 여러 품사를 넘나들면서 모양도 카멜레온처럼 변하는 형태소이다.

  • "이건 분명한 팩트야" (종결어미)
  • "논리야 놀자" (호격조사)
  • "바다야 평소에도 워낙 파도가 많이 치는 곳이니 논외로 하고.." (보조사)

그런데 얘는 '토씨(조사) 자동 교정' 옵션을 구현할 때 복병으로 작용한다. 호격조사일 때는 받침 있는 단어 뒤에서 '야'가 '아'로 바뀐다. 그러나 나머지 품사일 때는 '이야'가 되기 때문이다.
'을/를', '이/가', '와/과' 같은 것은 형태가 명백하고 규칙도 단순하지만, '야'는 '아'로 바꿀지 '이야'로 바꿀지를 자연어 처리 없이 텍스트 형태만 봐서는 판단할 수 없다.

날개셋 편집기의 바꾸기 기능은 전통적으로 '야'를 호격조사로만 취급해 왔는데, 이번 버전에서 다음과 같은 조치를 추가했다.

  • 호격 조사의 치환은 조사 다음에 한글이 이어지지 않고 그걸로 어절이 정확하게 끝날 때만 하도록 했다. 즉, '해야 솟아라'는 '태양아 솟아라'로 바뀌지만, '해야솟아라'는 '태양야솟아라'로 남아 있는다.
  • 그리고 '야' 다음에 윗첨자 1을 첨가한 '야¹'는 '이야¹'로 바뀌게 했다. '한글을 소리 나는 대로' 텍스트 필터에서는 발음 변환 방식에 변화를 주기 위해 힌트 부호를 사용하고 있는데, 비슷한 개념을 바꾸기 기능에도 도입한 것이다. 이건 굳이 어절의 끝이 아니어도 동작한다.

'야'뿐만 아니라 '요'도 비슷하게 중의적이다. '이요'와 '이오'는 윗첨자 ¹²를 덧붙여서 상호 교환되게 했다.

  • "1킬로그램요" (보조사) 형태 변함없음
  • "나는 길이요 진리요.." (연결어미) 이요/요
  • "주동자는 나요" (종결어미) 이오/요

'이요' 말고도 많은 조사와 어미들이 받침 여부에 따라서 중간에 '이'가 삽입되거나 생략되는데.. (-이여, -이야, -이나마, -이랑, -이란...) '예요/이에요'도 지금까지 처리되지 않다가 이번에 조건을 추가했다.

6. 편집기: 대화상자 외형

문서의 인코딩을 선택하는 대화상자의 외형과 동작을 살짝 고쳤다. UTF-8의 경우 BOM을 집어넣을지 여부를 지정하는 옵션이 오랫동안 아래에 별도의 체크 상자로 존재했지만.. 이번 버전부터는 그냥 목록에 별도로 뜨게 바꿨다.

사용자 삽입 이미지

오랜만에 이 바닥을 손대는 김에 UTF16-"BE"(빅 엔디언)라든가, UTF32 지원도 추가할까 생각했다가 그냥 관뒀다.
먼 옛날에 김 경석 교수 연구실에서 개발한 도스용 '나랏말씀' 에디터가 문자를 빅 엔디언 방식으로 저장했다. 그래서 그걸 읽을 때는 UTF16-BE를 지원하는 MS Word를 불가피하게 이용하긴 했었다. 하지만 요즘은.. 빅 엔디언 자체가 컴퓨터 메모리에서(파일 말고) 보기가 극도로 힘들어져 있다.

UTF32도.. 메모리가 아닌 파일로는 볼 일이 없다시피할 것이다. UTF7이 완전히 듣보잡이 된 것처럼 말이다.
하긴, 인코딩 말고 줄 바꿈 문자도 구형 매킨토시에서 쓰이던 \r only는 완전 듣보잡 방식이 되긴 했다. \r\n 아니면 \n만 살아남았다.

그리고 '기타 가져오기' 대화상자에서 있는 파일 내지 URL 입력란에.. auto complete 기능을 추가했다.
이제는 매번 별도의 버튼을 눌러서 파일 열기 대화상자를 꺼내지 않고도 파일의 전체 경로를 오타 없이 빠르고 편하게 입력할 수 있을 것이다.

사용자 삽입 이미지

7. 데이터: 이모지 본뜨기용 글꼴 변경

이건 프로그램의 기능 변화는 아니고 단순히 기본 제공 설정의 변화이다만..
지난 9.6 버전부터 글꼴 본뜨기 스크립트에서 이모지 영역을 본뜨는 지시가 추가되었다.
본뜨는 대상 글꼴이 처음엔 Segoe UI Symbol이었는데, 이번 버전부터 이모지 전용 글꼴인 Segoe UI Emoji로 변경했다.

이 글꼴이 16픽셀과 24픽셀 모두 훨씬 더 큼직하고 시원스럽고 보기 좋다.
제어판의 시스템 계층에서 글꼴 본뜨기를 강제로 다시 한 뒤, 문자표에서 U+1F300대 글자들 모양을 비교해 보시기 바란다.

※ 자잘한 버그

8. 날개셋문자를 받아들이는 수식에서 32비트 범위를 넘는 큰 임의의 수가 저장되지 않던 문제 해결

글쇠배열 수식에서 ? : 연산자를 사용해서 어떤 조건에서는 H3|_R을, 다른 조건에서는 H3|R_을 되돌리게 하는 상황을 생각해 보자. "조건 ? H3|_R: H3|R_" 같은 수식을 곧장 떠올릴 수 있을 것이다.
그런데 얘는 좌변과 우변에 공통으로 H3이 있으니 사람에 따라서는 "H3|(조건 ? _R:R_)" 이런 형태도 떠올릴 수 있다.

물론 수식을 그렇게 쓰는 건 별로 효율적이지 않다. 전자는 H3|_R이 합쳐져서 내부적으로 하나의 상수로 처리되지만 후자는 | 연산이 굳이 따로 행해지기 때문이다. 또한 _R과 R_ 부분에서 접두사 H3이 분리되면 프로그램이 이것들을 상수 명칭으로 가려서 보여주지 않고 내부 값을 노출해 버린다. 즉, 사람이 알아보기 어려워진다.

하지만 그와 별개로 사용자가 그런 수식을 지정했으면, 지정한 대로 저장하고 불러오는 건 똑바로 돼야 할 텐데 지금까지 그게 제대로 되지 않았다. 종성은 32비트 범위를 넘어서 32~48비트대에 저장되는데, 접두사가 없으면서 내부적으로 32비트 영역을 넘어가는 큰 수는 프로그램이 저장하지 않았기 때문이다. 그냥 날아갔다.

날개셋문자 수식에서 접두사가 없는 숫자는 그냥 일반 유니코드 문자 하나로 처리되는데, 잘 알다시피 현재 유니코드의 코드값 한계는 32비트는 고사하고 21비트 남짓밖에 안 되니.. 그건 그냥 짤라먹어도 상관없다고 판단했던 것이다. 하지만 그 숫자가 밖에서 다른 접두사와 결합해서 한글이 될 수도 있다는 것을 지금까지 고려하지 않았다. 이 문제를 발견하여 해결했다.

9. 타자연습

계정을 새로 생성하면서 사용할 글자판을 세벌식으로 지정했는데.. 그게 전혀 반영되지 않고 그냥 날개셋 편집기를 설치 직후 처음 실행했을 때와 같은 한영 글자판 두 쌍과 빈 입력 스키마가 지정되던 문제를 발견하여 해결했다. 꽤 오랫동안 존재했던 문제이나, 새 계정 등록이라는 게 일상적으로 자주 벌어지는 일이 아니니 버그가 생긴 줄 모르고 있었다.

이로써 타자연습은 게임 관련 개선, 이 버그 수정, 그리고 연습글 몇 편 추가로 새 버전의 명분이 충분히 갖춰지게 됐다. 장정 10여 년 만에 3.x 버전을 졸업할 때가 됐다.

※ 여담

(1) TSF 구현체

이번 버전에서는 개인적으로 임의로 만들어 사용해 온 'TSF A급'이라는 용어를 프로그램 도움말에서 모두 삭제했다. 그 대신, 그냥 'TSF 기반, TSF 지원'이라고 표현을 더 자연스럽게 바꿨다. 즉, 한글 입력만 가능한 게 아니라 단어 단위 한자 변환이 지원되고 이미 완성된 글자까지 자유자재로 고칠 수 있는 환경을 그냥 'TSF 기반'이라고 일컫기로 한 것이다.

과거에, 대략 Windows XP처럼 운영체제의 프로토콜이 IME에서 TSF로 바뀌던 과도기에는 TSF A급뿐만 아니라 B급이라는 개념도 있었다. 이건 TSF 방식으로 개발된 외부 모듈을 지원하긴 하지만 기술 수준이 여전히 IME 수준밖에 안 되는 환경으로, MS Office 중 워드 말고 엑셀, 파워포인트 같은 프로그램이 여기에 속했다.

그러나 Windows Vista부터는 IME 프로토콜이 사실상 폐지되고 모든 프로그램이, 심지어 재래식 WM_IME_* 메시지밖에 모르는 레거시 프로그램이라도 운영체제 차원에서 호환성 layer을 통해 반쪽짜리로나마 trivial하게 TSF 모듈을 구동한다. 그렇기 때문에 TSF B급이라는 프로그램을 따로 구분할 필요가 전혀 없어졌다. 이제는 TSF를 native하게, non-trivial하게 온전히 지원하는 프로그램만을 간편하게 'TSF 기반'이라고 부르면 충분하다고 여겨진다. 굳이 'A급'이라는 말을 붙일 필요가 없다는 것이다.

지난 10여 년이 넘는 기간 동안 이런 TSF 기반 입력 환경은 MS Word, 워드패드, 날개셋 편집기 같은 극소수 프로그램만의 전유물로 여겨져 왔다. 하지만 2010년대 중후반부터는 마소가 아닌 타 진영에서 만들었고 크로스 플랫폼 형태이기까지 한 프로그램에서도 TSF 기반의 텍스트 입력란을 종종 보게 되었다. 흥미롭고 고무적인 현상이다.

파이어폭스 브라우저는 놀랍게도 어느 샌가 온전한 TSF 기반으로 바뀌었다. 크롬도 cursor 이동이 제대로 처리되지 않고 여전히 공식적으로는 온전한 TSF 기반이 아닌 것으로 인식되지만, 언제부턴가 인접 글자가 무엇인지 얻어 오는 것은 되어서 한자 변환이 단어 단위로 된다. 이런 분야를 작업하는 사람들은 미국보다는 역시나 대부분 중국· 일본의 프로그래머라고 한다.

하지만 마소가 공식적으로 문서화하고 있는 TSF 스펙은 온갖 복잡한 상황에서 IME의 세밀한 동작을 규정하고 있지는 않다. 그렇기 때문에 또 온갖 파편화된 TSF 구현체들로 인해 자잘한 오동작과 버그, 무질서함은 IME 스펙만 있던 시절에 비해 더욱 올라갈 가능성이 높다. 앞으로 제2, 제3의 크롬 버그가 또 발생하지 말라는 법이 없어 보인다. -_-;;

(2) 페이스북 메신저의 회신 지연

본인은 날개셋 한글 입력기 관련 연락 통로를 이메일(비공개), 그리고 프로그램 다운로드 사이트에 같이 딸려 있는 페이스북 플러그인(공개) 이렇게 둘을 운영하고 있다.
페이스북 플러그인이 뜨는 곳에다가 "문의는 이곳(공개적으로) 또는 제 개인 메일(사적으로)로 해 주십시오. 페이스북 쪽지는 거의 확인하지 않기 때문에 대응이 늦어집니다"라고 써 놓았다.

하지만 최근에 우연히 쪽지를 확인하다가 거의 4개월, 6개월 전에 발송됐던 프로그램 문의 쪽지를 보고는 망연자실해서 해당 발신자 분에게 사과와 함께 답장을 보냈다.

페이스북은 모르는 사람에게서 온 쪽지는 왔다고 안내를 띄워 주지를 않더라. 그래서 쪽지가 온 줄도 모르는 채로 시간이 그렇게 가 버리는 것이다.
이 자리를 통해 다시 당부드리지만 프로그램 관련 문의는 메일이나 페이스북 플러그인, 아니면 하다 못해 이런 글의 댓글을 이용해 주시기 바란다. 방명록은 그런 용도로 있는 공간이 아니고, 페이스북 쪽지는 내가 언제 확인한다는 장담을 할 수 없기 때문이다.

Posted by 사무엘

2019/07/15 08:32 2019/07/15 08:32
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1640

다음 버전 개발 근황

올해가 벌써 절반이 끝나 가는구나.. ㅠㅠ 오늘은 오랜만에 프로그램 개발 소식을 전하도록 하겠다. 날개셋 한글 입력기 9.8과 타자연습 3.9가 일단은 다음 달, 즉 7월 초/중순 쯤에 나올 예정이다.
4~5월쯤에 9.71 형태로 나왔어야 할 물건이었으나.. 온갖 곳에서 고치고 개선할 점들이 잔뜩 튀어나오는 바람에 일정은 한없이 늘어나고 버전도 0.1 더 오르게 됐다.

새 버전이 지금 나왔다는 말이 아니니 오해 없으시기 바란다. 이 글은 내부적으로 작업이 완료된 것들만 늘어놓은 것이다. 새 버전이 완성되어 실제로 업로드될 즈음에는 다른 개발 아이템들이 더 추가되어 있을 것이다. 난 예나 지금이나 날개셋 한글 입력기 코딩을 할 때 내가 살아 있음을 느끼고 삶의 의미와 목적을 느낀다.

1. 오동작· 안정성과 관계 있는 버그

(1) 날개셋 제어판에서 빠른설정을 적용하는 등 입력 설정을 이것저것 바꾼 뒤 닫을 때 프로그램이 가끔 뻗던 버그는 이미 지난 4월에 문제의 원인을 파악해서 해결했다.
지난 9.5쯤부터인가, 화살표 키로 제어판의 카테고리를 이동할 때 페이지가 곧바로 표시되지 않고 약간 뜸을 들인 뒤에 표시되기 시작했는데(UI 반응성의 향상을 위해), 그 동작의 부작용 때문에 그런 문제가 발생했던 것이었다. 문제의 정확한 발생 조건을 찾기가 굉장히 어려웠다.

(2) 아울러, 편집기에서 다른 TSF 방식 외부 모듈을 구동해서 한글 조합을 만들었다가 끊기를 반복할 때 memory leak가 발생하던 것도 비슷한 시기에 해결됐다. 원인은 내가 짠 코드의 COM object 관리 잘못 때문이라고 허무하게 판명되었다.
옛날 버전까지 다 구해서 추적해 보니 8.2 또는 8.4 버전쯤부터 슬며시 생겼던 문제이다. (8.0 문제 없음, 8.4 있음.. 8.2는 구해 보지 못함) 그러니 대략 2016년쯤에 작성한 코드에 버그가 들어간 셈인데, 너무 옛날이어서 내가 그 시절의 코드 스냅샷까지는 갖고 있지 않았다. 결국 에디팅 엔진을 통째로 다 뜯어내고 전수조사를 벌여야 했다.

내 프로그램 코드에서 어지간한 포인터들은 RAII 이념에 충실하게 몽땅 smart pointer 역할을 하는 클래스로 감싸 놨다. 그렇기 때문에 소멸자에서 알아서 해제가 되며, 무식한 memory leak 같은 게 발생할 여지는 거의 없다.
하지만 포인터가 타 구조체의 멤버로 들어있거나, 포인터를 얻는 함수로 종료 조건으로 삼아서 뺑뺑이를 돌 때(while, for문)는 이런 자동화의 혜택을 받지 못한다. 이번 버그도 그런 사각지대에 존재하고 있었다.;;

(*) 최근엔 크롬 브라우저에서 날개셋 한글 입력기가 제대로 동작하지 않고 프로그램이 뻗는다는 버그 신고가 곳곳에서 들어와 있다. 크롬이 버전 74쯤부터 과거에 존재하던 버그가 고쳐져서 뭔가 좀 개선이 됐나 싶었는데.. 그 대신 다른 문제가 생긴 것 같다.
특히 신세기 님께서 제작하신 세벌식 모아치기 설정을 사용했을 때 크롬이 뻗는 것은 본인도 확인했다. 하지만 뻗은 지점이 내 코드가 아니라 크롬의 코드인지라.. 원인이 정확하게 무엇인지, 문제를 피해 갈 방법이 무엇인지는 아직 잘 모르겠다. 혹시 타이머 때문인가 추측만 할 뿐이다.

(*) 똑같은 영문인데 어떤 프로그램에서는 글쇠를 IME가 가로채지 않고 그대로 넘겨 줘야 정상 동작하고, 어떤 프로그램에서는 반드시 가로채 줘야 정상 동작하는 경우가 있다.
얼마 전엔 인디자인에서 한글 조합 중의 space/enter 키 인식 문제 때문에 본인에게 문의를 하신 분이 있었다. 인디자인은 여전히 몇 년째 그 버그가 고쳐지지 않고 있는가 보다.

사실, 글쇠를 IME가 가로채든 그렇지 않든.. 원래는 문자 입력 기능의 동작에 차이가 있어서는 안 된다. 그리고 사실 어찌 보면, 일부러 다르게 동작하게 만드는 게 더 어렵다.
하지만 한중일 언어나 문자 따위 모르는 외국인의 입장에서는 IME 인식하며 동작하는 프로그램에 대한 지식이 부족하고 정상적인 동작 모습을 상상하기 쉽지 않을 것이다. 그러니 이건 해당 프로그램이 고쳐지기를 바랄 수밖에 없는 노릇이다.

2. 안정성까지는 아니지만 그래도 사소하지 않은 버그

(1) 언제부턴가 문자 생성기가 기본이 아닌 고급인 상태에서 타이머 설정 대화상자를 들어가 보면 기존 타이머 설정들이 제대로 설정되지 않던 문제가 있었다. 곧바로 고쳤다.

(2) 날개셋 편집기에는 문자 영역 검색 기능이 있다. 굉장히 옛날부터 제공되었고 지금까지 큰 변화도 없는데, A<=0xFF, A==0처럼 아예 0문자가 조건에 걸릴 수 있게 수식을 주면 텍스트 블록이 이상하게 잡히면서 프로그램이 오동작한다. 이 버그를 이제야 발견해서 즉시 고쳤다.

3. UI

(1) 모든 대화상자들에서 명령 버튼의 기본 크기를 45*16 DLU 대신 47*15 DLU로 소폭 수정했다. 마소가 권장하는 50*14 dlu와 완전히 같지는 않지만 그에 좀 더 근접하게 바꾼 것이다. 버튼의 높이가 16 dlu이면 다른 한 줄짜리 에디트 박스와 비교해 봐도 솔직히 너무 크긴 했다.

(2) 고급 입력 스키마의 '고급 글쇠 인식' 페이지는 각 글쇠별로 down/up 상황에 대해 복잡한 수식을 설정하는 곳이다. 글쇠를 추가하거나 편집하는 UI를 별도의 대화상자로 만들어도 됐을 것 같으나.. 어쩌다 보니 동일 페이지에서 몽땅 설정한 뒤에 '추가'를 누르는 형태가 됐다.
한창 수식을 편집하고 있다가 왼쪽의 글쇠 리스트에서 다른 걸 찍는 순간 그 임시 데이터들은 몽땅 날아가 버린다. 이것이 직관적이지 못하다고 여겨진지라, "편집하던 내용을 반영/저장할까요?"라는 질문을 표시하게 했다.

(3) 외부 모듈(입력 패드도 포함)은 전용 환경인 편집기와 달리 한글 표현 방식을 따로 설정하는 곳이 있다.
이걸 옛한글이 아닌 현대 한글로 맞춰 놓은 상태에서 옛한글의 입력을 시도하면 지금까지는 간단한 주의· 경고문이 나타났다. 한 번 나타난 뒤엔 다시 나타나지 않지만, 현재 프로그램이 실행돼 있는 동안만으로 한정이고, 그 다음부터는 또 나타난다.

옛할글이 온전히 표시되지 못하고 첫 자음이나 모음만 나타나도 괜찮으니, 일부러 이런 설정을 일시적으로 사용하는 사람도 있다는 점을 감안하여.. 메시지 박스에다가 "다음부터 이 메시지를 표시하지 않음" 체크를 넣었다. 이걸 체크하면 최소한 다음에 제어판을 열어서 한글 표현 방식 옵션을 변경하기 전까지는 동일 메시지가 나타나지 않게 된다.
그리고 메시지를 '확인'이 아닌 '예/아니요' 형태로 바꿔서 그냥 즉석에서 설정을 옛한글을 사용하도록 변경할 수도 있게 했다.

사용자 삽입 이미지

(4) 제어판의 '시스템 계층'을 가 보면 다음에 편집기나 외부 모듈 같은 구현체 프로그램이 실행될 때 자동으로 띄워 놓을 입력 도구들을 선택하는 체크 상자가 있다.
이것은 지난 9.3 버전부터 추가된 옵션이다. 지금까지는 체크들을 모두 없애는 버튼만 있었는데.. 사실은 지금 사용자가 띄워 놓은 도구들을 그대로 다음에도 자동으로 띄우도록 하는 버튼도 있는 게 사용자의 입장에서 좋다.

사용자 삽입 이미지

그래서 그 버튼이 이번 9.8에서 추가되었다. 이걸 구현하기 위해서는 제어판 대화상자가 자신을 호출한 호스트와 통신하는 방식이 확장되고 고쳐져야 했다. 이 과정에서 코드가 더 깔끔하게 바뀌긴 했지만 타자연습도 API 호환이 깨졌다. 그래서 최신 버전을 쓰려면 입력기도 반드시 최신 버전을 써야 하게 됐다.

4. 입력 도구들의 깨알같은 개선점

(1) '휴대전화 입력기'의 숫자 모드에서 표시 형식을 전화기가 아닌 계산기를 선택했을 때.. 0과 그 주변의 숫자 배치를 실제 계산기에 더 가깝게 변경했다. 무성의한 , 0 . 대신 0 00 . 로 바꿨다.
글쎄, 콤마가 사라진 건 아쉽지만 계산기라면 0이 왼쪽에 가 있고 00이 있긴 해야 할 듯해서 말이다. 00이야 날개셋문자의 '다중 문자' 타입으로 간단히 구현 가능하다.

사용자 삽입 이미지

(2) '화면 키보드'에서 '눌린 글쇠 표시' 옵션을 켜면, Caps lock의 경우 램프가 켜진 것도 글쇠배열에 반영되어 보이게 했다. 이 간단하고 당연한 동작을 왜 지금까지 구현하지 않고 있었나 모르겠다.

(3) '조합 안에 조합 생성'의 '영문 T9 방식 입력'을 위한 DB가 지금까지 8~9글자짜리 짧은 단어밖에 없어서 불편했는데.. 이번에 최대 15자짜리 긴 단어도 대폭 추가했다. 그래서 DB의 내장 어휘 수와 파일 크기도 거의 2배 가까이 증가했다. international 같은 단어를 예전보다 더 편하게 입력할 수 있을 것이다.

(4) 예제로 제공되던 "천지인, SKY, Google 단모음 입력 방식"에 종성뿐만 아니라 초성도 시간차로 경계를 구분하는 로직을 추가했다. 이들 입력 설정에는 오토마타에 "B ? 2 : 0"라고 중성의 입력만 받아들이는 새로운 상태가 추가되었다. 초성만 입력된 상태에서 타이머가 경과하면 이 상태로 진입하게 된다. 임시 변수를 동원해서 글쇠배열 수식을 고치는 방식으로도 동일 기능을 구현할 수 있긴 하지만 그냥 오토마타를 고치는 게 더 단순하다.
그리고 '내부 입력 상태 표시' 도구에서.. 수식 계산만 하고 별도의 날개셋문자를 보내지 않는 타이머가 경과했을 때 변수 상태를 업데이트 해서 보여주지 않는 버그를 발견하여 이것도 고쳤다.

5. '한글 낱자 재결합'의 기능 개선과 강화

텍스트 필터 중에 '한글 낱자 재결합'이라고, 블록으로 잡은 한글을 낱자 단위로 분해한 뒤 다시 조합시키는 기능이 있다. 얘는 사용하면 동일한 타자 시퀀스인 한글을 모아쓰기/풀어쓰기, 복합 낱자/기본 낱자 등의 형태로 변환할 수 있다. '문자열을 글자판 입력으로 → 글자판 입력을 문자열로' 필터를 연달아 적용한 것과 비슷하지만, 얘는 한글이 아닌 문자를 제거한다거나 초중종 결합 여부와 순서를 더 세밀하게 지정할 수도 있다.

한글을 재결합하기 위해서는 먼저 분해부터 해야 하는데.. 지금까지는 그냥 평범하게 현재 입력 설정을 바탕으로 타자 순서를 구하는 식으로 분해했다.
그러니 세벌식의 경우, ㄻㅄㄲ처럼 글쇠가 별도로 존재하는 겹받침들은 더 분해되지 않았다. 그리고 지금 입력 설정에서 타자 순서를 구할 수 없는 낱자는 분해가 불가능하니 그 낱자를 그냥 통째로 취급했다. 가령, 현대 한글 입력 방식을 사용하면서 옛한글을 재결합 시켰을 때 말이다.

이번 버전에서는 '결합'은 현재 입력 설정을 따라서 하지만, '분해'는 입력 설정과 무관하게 그냥 그 한글 낱자의 기본 낱자 형태로 직관적으로 하는 옵션을 추가했다. 자음은 ㄱ~ㅎ과 ㅿㆆㆁ, 정치· 치두음, 모음은 ㅏ~ㅣ와 ㅐㅔㅒㅖ, 아래아 단위로 분해한다.

사용자 삽입 이미지

그래서 ㄻㅄㄲ은 초· 종성과 현재 입력 설정을 불문하고 언제나 ㄹㅁ, ㅂㅅ, ㄱㄱ의 형태로 분해된다. 낱자 결합 규칙과 오토마타가 전혀 없는 입력 설정에서 이 방식으로 한글 낱자를 분해하고 재결합하면 한글을 기본 낱자들로 늘어놓을 수 있다. 이건 회사 사람에게서 제안 받은 아이디어인데 꽤 의미 있고 유용한 기능인 것 같다.

그리고 다음으로, 예전과 같이 '타자 순서'대로 한글을 분해할 때, 종성 두벌식 방식의 한글이 제대로 처리되지 않던 문제를 해결했다. 예전에는 '한' 같은 글자를 재결합하면 ㅎ이 곧이곧대로 종성으로 인식되어서 중성 다음에 ㅏㅎㄴ 같은 식으로 결합됐는데.. 이 동작이 개선되었다.

6. 타자연습

(1) 다소 엽기적인 연습글인 이 상의 '오감도', 그리고 '영화 클레멘타인 감상평'을 연습글로 추가했다. "13인의아해가거리로질주하오"라든가.. "남친 집에서 클레멘타인 DVD를 발견했고, 결혼을 결심했습니다" 같은 문장으로 타자 연습을 할 수 있다.

(2) 예전엔 이런 현상이 없었던 것 같은데.. 게임을 창 모드에서 하다가 Alt+Enter를 눌러서 전체 화면으로 진입하면 첫 프레임은 화면이 전체적으로 몇 픽셀 offset되어 잘못 렌더링 되다가 그 다음부터 제대로 된다. 화면이 수시로 업데이트 되는 게임 중이면 별 상관 없지만, 첫 프레임이 "레벨 n 시작합니다" / "게임을 그만 할까요?" 같은 메시지 화면일 때는 다소 부자연스러운 glitch가 된다.
이 현상을 수정했다. 아마 Windows 8/10쯤에서 새로 발생한 부작용 같다.

(3) 그 외에 댓글로 올라온 의견과 제안을 반영하여 도움말의 일부 오타를 고쳤다. 그리고 게임에서 저장 가능한 상태 또는 이미 저장된 상태를 사용자에게 더 분명하게 알려주게 했다.
저장은 사용자가 게임에서 한 레벨 이상을 직접 깨서 다음 레벨로 진입한 다음부터 가능하다. 단, 레벨 2는 너무 낮고 쉬운 레벨이기 때문에 제외다. 저장되는 대상은 시작 레벨과 주인공 종류, 체력과 장갑, 점수이다. 게임 도중의 중간 상태는 저장되지 않으며, 저장 슬롯 자체도 단 하나만 만들 수 있다.

저장 기능 자체는 오랫동안 지원돼 왔으며 딱히 버그도 없었다. 단지 저장이 가능한 레벨이 시작되었을 때는 게임 시작 안내 화면의 우측 하단에 "F4: 저장"이라는 말을 작게나마 출력하게 했으며, 이때도 저장을 할 수 있게 했다. 그리고 게임 중에 사용자가 F4를 여러 번 누르면 "이 레벨의 시작 지점이 이미 저장돼 있습니다"라는 안내도 나오게 했다.

Posted by 사무엘

2019/06/16 08:32 2019/06/16 08:32
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1630

본인은 박사 과정에 진학해서 수업을 다 듣고 종합 시험도 통과한 뒤, 지난 2년이 넘는 기간 동안 휴학을 했다. 그리고 그 기간 동안 날개셋 한글 입력기는 8.6에서 9.7까지 올라갔다.
입력기 연구의 연장선에다가 글꼴 연구도 새로 접목하는 것을 목표로 진학했었는데, 입력기 연구가 당초 계획보다 다소 오래 걸렸다.

이제 입력기는 파일 포맷과 엔진 구조를 다 뜯어고칠 정도로 너무 비현실적인 추상화(재설계나 리팩터링), 아니면 너무 이상적인 수준의 기능을 제외하고 어지간히 규칙 기반 한글 입력과 관련된 것들은 다 통달했으며 잘 실현됐다. 9.7도 특별히 심각한 문제 없이 아주 잘 만들어졌다.

다만, 날개셋은 TSF 기반의 한글 IME일 뿐만 아니라 반대로 타 IME들을 구동해 주는 텍스트 에디터이기도 하니.. 요즘은 편집기에서 타 IME를 구동하는 동작과 관련된 이슈들을 좀 살펴보고 있다.

1. 내 프로그램에서 9.7 이후로 개선된 사항

(1) 외부 모듈의 옛한글 조합을 여느 블록(selection)과 달리 취급

날개셋 편집기에서 입력 항목을 '빈 입력 스키마'로 고르면 앞서 언급한 바와 같이 자체 입력기가 아니라 다른 외부 IME들을 사용할 수 있다.
그런데 한글 IME로 현대 한글을 조합할 때는 깜빡이는 네모 cursor가 나타나는 반면, 옛한글을 조합할 때는 조합이 그냥 블록 형태로 잡힌다. 그래서 자체 입력기로 옛한글을 입력할 때와는 달리 이질적이고 아마추어스러운 느낌이 난다.

이건 일차적으로는 운영체제에서 옛한글처럼 내부적으로 2개 이상의 코드값으로 표시되는 한글에 대한 배려를 안 해서 그렇다. 조합 문자열이 한글로만 이뤄져 있을 때 응용 프로그램이 강제로 보정을 해서 깜빡이는 네모 cursor를 구현하라면 할 수도 있다.

내 프로그램에서는 그렇게까지는 안 하는 대신, 비록 블록처럼 보이더라도 진짜 블록이 잡힌 것처럼 복사/잘라내기 버튼이 켜지지도 않게 프로그램의 동작을 깨알같이 개선했다. 그건 블록이 아니라 조합을 표시하는 용도일 뿐이기 때문이다..

사용자 삽입 이미지

(2) 붙여넣기를 할 때 외부 모듈의 조합이 덧나지 않게

또한, 자체 입력기가 아닌 외부 IME로 한글을 조합하고 있던 중에 도구모음줄의 '붙여넣기' 버튼을 마우스로 누르면..
자체 입력기를 사용할 때와 마찬가지로 조합이 종료된 뒤에 클립보드 내용이 삽입되는게 정상이다.

하지만 지금까지는 그렇지 않았다. 조합이 중단되고 그 문자열이 사라지고서 클립보드 내용이 삽입되었다. 이 버그를 발견하여 고쳤다.

사용자 삽입 이미지

이 두 가지 사항은 언제쯤 다음 버전에 반영되어 나올지 모르겠다.

2. 내 프로그램과 무관한 운영체제의 버그

(1) IME 도구모음줄이 두 종류 모두 표시됨

Windows 10 1803 버전 기준으로..
IME의 구형 재래식 도구모음줄과 Windows 8 스타일의 간소화 도구모음줄이 다같이 동시에 뜨는 경우가 있다. 정확한 재연 조건은 잘 모르겠지만 컴퓨터를 절전 상태로 껐다가 다시 켰을 때 가끔, 그러나 확실하게 이런 현상이 발생한다.

사용자 삽입 이미지

"고급 키보드 설정"에서 "사용 가능한 경우 바탕 화면 입력 도구 모음 사용" 옵션을 건드려 주면 다시 둘 중 하나만 나타나게 개선되긴 한다. 하지만 이건 운영체제의 버그이니 나중에 업데이트를 통해 해결되어야 할 것이다. Windows 8은 물론이고 10도 초창기에는 이런 현상이 발생한 적이 없었다.

(2) 일본어 IME의 조합 관리 버그

날개셋 편집기 또는 IE/Edge 브라우저의 텍스트 입력 폼에서 Microsoft 일본어 IME를 구동하고, 히라가나 모드에서 일본어를 몇 자 입력한다.
space를 눌러서 그 일본어 문자를 변환은 하지 말고, 좌우 화살표 키를 눌러서 조합 영역을 빠져나간다. 그러면 조합을 나타내는 밑줄이 일시적으로 사라진다.

그 뒤에 caret이 기존 조합 영역으로 돌아오면 기존 조합이 다시 생겨야 되는데 그리 되지 않는다.
그 상태에서 다른 곳에서 Shift+화살표를 눌러서 블록을 만들어 보면 아까 조합하던 일본어 문자가 덧나서 잘못 삽입된다.

사용자 삽입 이미지

이 버그는 Windows 10의 16xx대 이전 버전에서는 발생하지 않다가 후대 버전에서 나타났다. 1803의 후대 버전에서는 어찌 되었나 모르겠다. 날개셋 편집기뿐만 아니라 MS에서 만든 TSF A급 웹브라우저에서 모두 동일하게 발생하니 내 프로그램만의 문제도 아니다.

단, 워드패드에서는 동일 운영체제와 동일 IME에서 저런 오동작이 발생하지 않는다. 서식을 지원하기도 하니 에디팅 엔진 차원에서 무슨 차이가 있어서 그런 것 같다.

(3) 옛한글 IME의 조합 영역 처리 버그

이건 Windows 8 이래로 계속 동일한 것 같은데..
마소에서 제공하는 옛한글 입력기는 초성이나 중성에 옛한글이 들어간 상태에서 종성의 첫 타를 입력하면.. caret 위치가 좀 이상하게 찍힌다. 내부적으로 표현되는 글자 수가 3자가 되었으니 0~3까지 모두 조합 영역으로 설정해야 하는데 종성이 입력되기 전처럼 0~2까지만 설정한다.
그래서 날개셋 편집기에서는 화면이 일시적으로 이렇게 표시된다. 종성 둘째 타 이후부터는 다시 괜찮아진다.

사용자 삽입 이미지

시각적으로 좀 이상한 것 말고 다른 오동작은 없다. 하지만 날개셋, 한컴 입력기 등 옛한글 입력을 지원하는 다른 모든  IME에는 이런 현상이 없고 MS IME만 저러니.. 이건 저 프로그램만이 단독으로 해결해야 할 문제로 보인다.

3. 단순 차이점 -- 옛한글 filler 글쇠

두벌식 옛한글 글자판에는 중성이 빠진 미완성 한글 내지 종성 단독 낱자를 입력하기 위해서 일명 filler라는 글쇠가 있다. 위치는 관례적으로 Shift+J로, 날개셋, 아래아한글, MS 옛한글 입력기가 모두 동일하다.

날개셋과 아래아한글에서는 이 filler라는 게 언제나 '중성 filler'를 의미한다. 이것만 있어도 초성이나 종성이 없는 글자는 입력 가능하기 때문이다.
하지만 MS의 경우, filler도 뭔가 두벌식스럽게 글자를 완전 처음 입력할 때는 빈 자리에다가 '초성 filler'를 흉내 내어 주는 것 같다. 굳이 그럴 필요가 없지만 말이다.

그래서 초기 상태에서 종성을 단독으로 입력하려면 filler를 한 번이 아닌 두 번 눌러야 한다. 본인은 처음엔 이런 차이를 몰라서 마소 옛한글 입력기로는 종성 단독 입력이 불가능한 줄 알았다.
초성 filler도 지원해 주는 게 사람에 따라서는 더 직관적으로 보일 수도 있다. 하지만 한글을 연속으로 입력하기 시작하면 filler는 어차피 사실상 중성으로만 동작해야 하기 때문에 굳이 저럴 예외를 둘 필요가 있나 싶다.

중요한 건 이런 동작조차도 표준으로 딱 정해진 게 없어서 프로그램마다 차이가 있을 수 있다는 점이다. 날개셋에서는 글쇠배열의 수식을 바꿔 주면 지금 동작(중성 고정)뿐만 아니라 MS IME의 동작도 물론 구현할 수 있다.

4. 원인을 알 수 없는 문제

다음은 본인의 개발 환경에서 아주 드물게 발생하는 것을 확인하긴 했지만 재연 조건을 전혀 몰라서 좀 난감한 지경에 있는 버그 아이템들이다. 이것들이 문제의 원인이 전적으로 내 프로그램의 귀책사유로 판명되어 해결된다면.. 위의 1번의 개선 사항까지 포함해서 다음 버전인 9.71이 지금이라도 당장 나오게 된다.

(1) 여전히 발생하는 랙

이번 9.7에서는 안 그래도 편집기의 에디팅 엔진과 관련된 몇몇 버그들이 잡히고 내부 동작 방식이 최적화 됐다. 그런데 편집기를 한번 띄워 놓고 며칠 이상 오래--특히 중간에 컴의 절전 모드와 복귀를 수차례 반복할 정도로-- 쓰다 보면, 어느 샌가 글자가 화면에 나타나는 속도가 내 타자 속도를 못 따라갈 정도로 랙이 걸리는 경우가 여전히 발생한다.

게다가 이게 참 악랄한 게.. 랙의 발생하던 당시에 발생 조건이 다음과 같이 가변적이었다는 것이다.

  • 오로지 날개셋 외부 모듈로 한글을 입력할 때만 느려짐 (MS IME, 자체 입력기 등등은 괜찮음)
  • 외부 모듈로 한글을 입력할 때만 느려짐 (날개셋, MS IME에서 랙. 자체 입력기는 괜찮음)
  • 아무 방식으로나 글자를 입력할 때 몽땅 느려짐

마지막으로 이 문제가 발생했을 때엔.. 처음엔 외부 모듈에서만 발생하는 것 같더니 이내 상황이 최악으로 바뀌었다.
특정 문서의 맨 마지막 줄에서 글자를 입력할 때만 극심한 랙이 걸리고, 그렇지 않을 때는 괜찮았다(타 문서 or 다른 줄). 심지어 그 문서에서 편집하고 있던 텍스트를 몽땅 지우고 새로 입력을 시작해도 랙이 사라지지 않았다.

이 랙이 발생하는 동안 내 프로그램의 내부에서는 무슨 일이 벌어지고 있고 도대체 어느 계층에서 뺑뺑이를 도는 건지 도무지 알 길이 없다. 그냥 평범하게 프로그램을 띄워서는 절대로 발생하지 않는다. 그나마 유력한 단서가 될 만한 현상은.. 이때 날개셋 편집기가 다음과 같이 memory leak이 발생해 있었다는 것이다.

(2) MS IME를 사용할 때 발생하는 괴이한 memory leak

날개셋 편집기와 작업 관리자를 같이 실행한다. 다음으로, 편집기에서 TSF 지원 옵션을 켠 상태에서 '빈 입력 스키마'를 고른다.
Microsoft 기본 한글 IME로, "세벌식 390/최종"(두벌식 말고)으로 "ㅇ.ㅇ.ㅇ.ㅇ." 처럼.. 한글 + 비한글 문자를 수십 회 쭈룩쭈룩 교대로 입력해 보라.

그러면 초기에 2~3MB대 안팎이던 프로세스 메모리 사용량이 계속해서 증가하는 게 관찰된다. 명백하게 memory leak이다.
COM 오브젝트 간의 reference count 같은 게 꼬인 것 같은데.. 이건 도대체 누구 잘못이라고 봐야 할까?

당연히, 디버그 빌드에서 단순 memory leak detector로는 문제가 전혀 감지되지 않는다. 내 프로그램은 10수 년에 달하는 짬밥을 자랑하며 얼마나 오랫동안 안정화가 돼 왔는데.. 소스 코드 상으로 무식한 결함이 있지는 않다.

더구나 날개셋, 한컴 입력기 등 "타 IME에서는 이런 현상이 없다." MS IME도 세벌식을 쓰고 있을 때만 저렇고 두벌식일 때는 문제 없다.
그리고 Windows Vista, 7, 10에서 이 현상을 확인했다. 구닥다리 XP에서는 MS IME+세벌식에서도 문제가 없다.

그럼 내 과실 0, 마소 과실 100을 입증하려면 날개셋 편집기 말고 다른 프로그램에서도 MS IME + 세벌식으로 저렇게 쳤을 때 동일한 memory leak이 발생한다는 걸 입증해야 하는데 그건 또 그렇지 않아 보인다~! 워드패드, MS Word, IE, Edge 등 TSF를 지원하는 프로그램들은 또 희한하게도 저런 현상이 발생하지 않는다.

다음으로 지푸라기를 잡는 심정으로 날개셋 구버전까지도 구해서 써 봤다.
날개셋 8.0까지는 이 문제가 없고, 8.4부터 leak이 발생하더라. 8.2는 불명.. 그러니 이 버그는 대략 2016년부터 있어 왔다는 것이다.
이때 도대체 어떤 변화가 있었는지.. 본인은 프로그램 소스를 자주 백업하는 편이지만, 컴퓨터가 바뀌는 과정에서 지금으로부터 3년이 넘게 너무 오래된 소스는 갖고 있지 않아서 이 방법으로도 문제의 원인을 파악할 수 없었다. ㅠㅠ

난 Windows용 IME라는 물건을 개발하느라 지난 10여 년 동안 온갖 희한한 버그 신고들을 받고 기상천외한 지저분한 환경에서 디버깅을 했다. 그러면서 마치 교통사고 과실 비율 따지는 것 같은 현상들을 많이 경험했었다.
둘 다 스펙대로 100% 무결하게 구현된 건 아니었고(혹은 스펙 자체가 모호해서..) 둘 다 조금만 조심하면 됐는데 둘 다 무데뽀로 동작해서 운 나쁘게 문제가 발생하는 것.. 말이다. Windows용 IME라는 바닥은 무척 "구리다."

아무튼 현재로서는 저 memory leak의 원인과 해결 방법이 오리무중이다. 해결만 된다면 9.7 다음으로 9.71이 당장 나와야 할 것이다.

(3) 제어판 닫았을 때 프로그램 뻗나?

정말 민망하고 황당한 버그인데.. 올해 들어 두세 번인가 겪었다.
날개셋 편집기에서 제어판을 꺼내서 설정을 바꾼 뒤, 확인을 눌러서 닫았더니 편집기 프로그램이 그냥 대짜로 뻗어 버렸다.
한 번 발생했을 때는 그냥 재수없는 우연인가 싶었는데, 몇 주 전에 마지막으로 동일 문제를 겪었을 때는 '미저장 확인'을 누른 것만으로도 뻗었다.

물론 그 뒤로는 편집기에서 날개셋 외부 모듈을 또 얹고, 제어판에서 온갖 설정을 바꾸고 빠른설정을 띄우면서 지지고 볶아 봐도.. 동일 문제가 다시는 재발하지 않고 있다. 위의 랙도 몹시 드물게 발생하지만 이 crash는 그것보다 더 드물게 발생했다. 그래서 난감하다.

Posted by 사무엘

2019/03/31 08:30 2019/03/31 08:30
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1603

날개셋 한글 입력기가 올해 최초의 새 버전이 나왔다. 우연히도 3· 1 운동 100주년과 비슷한 타이밍에 말이다. 올해 초까지만 해도 이제 날개셋 한글 입력기는 당분간 더 만들 게 없을 거라고 예상했었지만 결국은 9.7까지 또 잘만 올라가게 됐다. 마치 석유가 이제는 고갈된 것 같아도 자꾸 더 채굴되는 것처럼 말이다.

물론 9.5 이후로 완전히 새로운 기능의 추가나 대규모 개편 같은 작업은 없다. 다만, 지금 체계 하에서 이미 있는 기능들의 완성도를 높이는 작업 아이템은 여전히 종종 발견되고 떠오르고 있고, 그게 버전 번호를 올려 주고 있다. 그래도 날개셋 10.0이 내 학위논문보다 먼저 나오는 일은 없었으면 좋겠다. ㅠㅠ

이번 9.7에서는 이전 글에서 언급했던 것처럼 마우스 휠의 인식 방식을 개선했으며, 글꼴 본뜨기 스크립트에 한중일 확장 한자 C/D도 추가했다. 그것 말고 프로그램의 완성도를 강화하는 변화로는 다음과 같은 것들이 있다.

1. 수정 가능한 공용 파일의 접근성 강화

날개셋 한글 입력기 프로그램이 사용하는 데이터 파일 중에는 모든 사용자가 공유하면서 사용자가 내용을 수정할 수도 있는 텍스트 형태의 파일이 있다.

  • 편집기가 사용하는 상용구 리스트(qidiom.txt)
  • 글꼴 본뜨기 절차 리스트(fontextr.txt) -- 16픽셀용과 24픽셀용이 서로 별개
  • 날개셋 제어판이 사용하는 custom 내정값 XML (scheme.xml) -- 각 언어별로 서로 별개

그런데 문제는.. 이 파일들은 여느 데이터 파일들과 마찬가지로, 관리자 권한이 없이는 내용을 변경할 수 없는 형태로 설치된다는 것이다.
본인은 이 파일들을 읽기/쓰기 겸용을 의도했지만 실제로 사용자들은 제대로 변경해 가며 활용을 할 수 없었다.

고민 끝에 이제 이렇게 조치를 취했다.
이 파일들은 처음에는 .txt.$라고 확장자 뒤에 $가 추가된 형태로 설치된다.
그리고 날개셋 프로그램에서 이 파일이 필요할 때 동일 명칭의 .txt와 .txt.$ 파일을 모두 살펴보고, .txt가 없거나 .txt.$보다 날짜가 과거이면 .txt.$를 .txt로 덮어쓰기 복사를 한다. 그래서 새로 생성된 .txt 파일을 사용한다.

ProgramData 디렉터리는 Program Files 같은 읽기 전용 디렉터리가 아니며, 응용 프로그램이 파일을 새로 생성하는 것은 가능하기 때문이다. 그리고 그렇게 일반 권한으로 동적으로 생성된 파일은 사용자가 얼마든지 고칠 수 있다.
이렇게 하면 사용자가 실수로 .txt 파일을 지워 버리더라도 .txt.$로부터 원래 파일이 자동으로 복원되는 효과도 얻을 수 있다. 그러니 더욱 좋으며, 이게 최선의 문제 해결 방식이라고 생각된다.

2. 입력 패드에 /S 옵션이 제대로 동작하지 않는 문제 해결

날개셋 입력 패드의 경우, 입력 도구를 띄웠다가 모두 닫아서 입력 도구가 하나도 없게 됐을 때 프로그램도 자동으로 종료하는 /S 옵션이 있다. 입력 패드를 특정 입력 도구만 띄우는 목적으로 간단히 활용할 수 있게 하기 위해서 이런 옵션을 제공한다.

그런데 이 옵션이 지금까지 다음과 같이 제대로 동작하지 않는 걸 뒤늦게 발견했다. 그래서 고쳤다.

  • 각 입력 도구의 자체 UI(X 버튼 또는 우클릭 메뉴) 명령을 통해서 닫아서 모두 없어진 것만을 감지했다. 입력 패드 프로그램의 트레이 우클릭 메뉴를 통해서 입력 도구를 모두 닫았을 때는 프로그램이 자동 종료되지 않았다.
  • 그리고 개수를 체크하는 코드 자체도 언제부턴가 프로그램의 소스 코드 구조가 바뀌었을 때 같이 바뀌었어야 하는 부분이 바뀌지 않았다. 그래서 1개에서 0으로 줄었는지를 확인하는 게 아니라 2개에서 1개가 됐을 때를 체크하게 잘못 동작하고 있었다.

3. 에디팅 엔진의 미묘한 버그 수정

날개셋 한글 입력기에서 완전 기초 기본 기능에 속하는 편집기의 에디팅 엔진 쪽에 아직까지도 버그가 발견되고 고칠 게 있다는 게 본인 역시 실감이 안 가지만.. 이번에 그런 게 있었다. 물론 평소에 대다수 사용자에게는 거의 티가 안 나기 때문에 10년이 넘는 세월 동안 본인에게도 발견되지 않을 수 있었다.

날개셋 편집기의 장점 중 하나는 운영체제의 TSF 인터페이스를 온전히 지원한다는 것이다. 그래서 IME들이 자기 조합 문자열뿐만 아니라 주변 텍스트 내용에 모두 접근해서 읽고 쓸 수 있다.
그러기 위해서 날개셋 편집기 역시 운영체제의 요청이 있으면 편집 중인 텍스트를 되돌리고 수정하고, 현재 블록이 잡힌 영역을 알려 준다. 또한, 텍스트가 자체적으로 수정되었다면 어디가 얼마만치 수정되었는지를 운영체제에다가 알려 주기도 한다.

문제가 발견된 곳은 내 프로그램에서 수정된 영역을 운영체제에다가 알려 주는 부분이다. 이걸 제때 해 주지 않으면 오동작이 발생한다는 건 오래 전부터 경험적으로 체득되어 있었다.
다만, 내 프로그램도 수정된 내역에 따라서 문단 정렬을 다시 하고 cursor의 좌표를 수정하고 그럭저럭 내부 정리를 완료한 뒤에 통지를 해야 하는데 그러지 못하고 착오가 있었다. 그래서 일부 특수한 조건이 만족되는 상황에서는 틀린 좌표를 알려 줬다.

운영체제가 수정 영역 정보를 어떤 용도로 참고하는지 알 길이 없으니 Windows XP 시절에는 저렇게 동작하고도 별 탈이 없었던 것 같다. 그런데.. 올해 초에 장만한 새 노트북에서는 곧장 문제가 발생했다.
운영체제는 틀린 정보를 토대로 역시나 내 프로그램을 상대로 잘못된 요청을 했다. 현재 텍스트에 존재하지 않는 행과 열에 접근하게 되었다. 담당 함수는 뻗지 않고 false를 되돌렸지만 내 프로그램은 그 상황에 대비가 되지 않았으며, 결국 초기화되지 않은 변수를 갖고 후속 처리를 하게 됐다.

이로 인해 확인된 이상 증세로는.. 길고 빽빽한 문서의 뒷부분을 작성할수록 속도가 느려지는 것, Ctrl+Z Undo의 수행 속도가 느려지거나 심지어 무한 루프에 빠지는 것이다. 논리적으로 꽤 치명적인 결함이고 crash가 발생해도 이상하지 않은데.. 이 버그는 의외로 많은 컴퓨터에서 외형적인 이상은 별로 일으키지 않았다. 괜히 늦게 발견된 게 아니었다.

어쨌든 문제를 발견하여 해결했으며, 이 참에 여러 군데의 텍스트가 동시에 수정되었을 때(찾기-모두 바꾸기, undo/redo, 여러 블록에 대한 지우기 및 텍스트 필터) 각 영역을 일일이 통지하는 게 아니라 영역을 모두 합성해서 한 번만 통지하도록 동작 방식을 수정하기도 했다.

4. -lock (caps, num, scroll) 글쇠에 램프 상태 유지 옵션 추가

날개셋 한글 입력기는 임의의 글쇠에다가 글자 입력이나 글자판 전환 같은 기능을 배당해서 쓸 수 있는데, 그 중에는 자체적인 켬/끔 램프가 존재하는 caps, num, scroll lock 글쇠도 포함된다.
이렇게 -lock 계열 글쇠를 customize해서 누를 경우, 날개셋에서 지정한 기능만 수행되고 램프 상태는 바뀌지 않게 하는 옵션이 추가되었다!

사용자 삽입 이미지

이 옵션은 편집기 계층의 단축글쇠, 또는 기본 입력 스키마가 제공하는 추가 인식 글쇠 배당 대화상자에서 볼 수 있다. 거기서는 각 글쇠별로 옵션을 지정할 수 있다.
그리고 추가적으로 고급 입력 스키마의 옵션에서도 지정할 수 있는데, 이건 한 곳에서만 지정하면 caps, num, scroll 글쇠를 customize할 때 모두 일률적으로 지정된다. 램프를 사용하는 글쇠가 딱 세 개밖에 없으며, 그렇게 자주 쓰일 만한 글쇠도 아니기 때문이다.

이들 램프가 켜지거나 꺼지는 건 키보드 하드웨어 차원에서 동작하는 강력한 기능이기 때문에 원래는 소프트웨어가 이래라저래라 제어할 수 없다. 램프 상태를 유지시키는 옵션은 날개셋 한글 입력기가 내부적으로 그 글쇠를 또 보내서 다시 꺼 버리는 식으로.. 좀 유치한 편법을 동원해서 동작한다. 하지만 그것 말고는 내가 알기로 IME 수준에서 할 수 있는 일이 없다. 키보드 드라이버 수준이라면 모르겠다만..

키보드에서 caps lock은 영문이 아닌 한글 입력 중엔 완전 잉여인 게 사실이다. 그러니 이걸 다른 용도로 사용할 수 없을지 고민하는 분들이 좀 계셔 왔는데.. 램프를 고정하는 옵션이 있으면 caps lock을 재활용하기 한결 수월해질 것이다.

5. 한글 표현 방식 탭.. 더 간소화

이건 실질적인 기능 추가나 버그 수정은 아니지만.. 지난 9.3 버전에서 크게 바뀌었던 한글 표현 방식 탭의 구조가 더 간소화됐다.
일반적인 환경에서는 진짜 씨크하게 현대 한글이냐 옛한글이냐 둘 중 하나만 고를 수 있게 했다.

사용자 삽입 이미지

여기서 '비표준 옵션도 표시'를 눌러야 한양 PUA니 유니코드 1.1이니 하는 레거시 옵션을 고를 수 있고, 거기서 또 '세부 옵션 표시'를 눌러야 종전의 세부 옵션들을 볼 수 있게 했다.

이번 새 버전도 많이 유익하게 사용되었으면 좋겠다. 올해 초까지 변함없이 후원도 해 주신 분이 계신 것에 감사드린다.
타자연습은 바뀐 것이 없지만, 이번에 한글 입력기의 소스 코드를 정리하는 과정에서 거의 쓰이지 않는 잉여 가상 함수를 하나 삭제하는 바람에.. 클래스 라이브러리의 바이너리 호환이 깨지게 됐다. 그래서 부득이하게 업데이트 됐다.

그럼 이제부터는 컴퓨터/프로그래밍 관련 여담을 좀 늘어놓고자 한다.

A. 키보드

뭐, PC 키보드에 존재하는 3대 lock 글쇠 중에서 존재감이 제일 없는 잉여는 두 말할 나위 없이 scroll lock일 것이다. 본인은 조금이라도 이걸 구분해서 동작하는 프로그램을 엑셀 말고는 지금까지 좀체 보지 못했다.
맥 계열 컴퓨터의 키보드에는 이게 존재하지도 않는다. 어지간한 노트북 키보드에서는 fn을 눌러야 접근 가능한 식으로 봉인됐다. pause 키처럼 말이다.

옛날 도스 시절에 하드웨어를 좀 특수하게 제어하는 게임은 caps/num/scroll lock을 눌러도 램프 상태가 변하지 않고, pause를 눌러도 컴퓨터 진행이 정지하지 않으며, ctrl+alt+del을 눌러도 시스템이 재부팅되지 않게 무슨 lock 같은 걸 걸어 놓고 돌아가긴 했었다. 그 옛날에 만들어진 황금도끼 도스용도 그런 프로그램 중 하나였었다. 그런 건 어떻게 구현했는지가 문득 궁금해진다.

GUI 환경에서 '복사'의 단축키로 워낙 잘 쓰고 지내긴 하지만 명령 프롬프트에서는 Ctrl+C가 프로그램의 실행을 중단하도록 인터럽트를 발생시키는 단축키였다. Ctrl+Pause(Break)는 Ctrl+C보다 수위가 더 강한 글쇠였고 말이다. 이건 소프트웨어적인 이벤트이기 때문에, 이 글쇠에 반응할지 말지를 지정하는 기능은 아마 도스 API 수준에서 있었지 싶다.

B. 명령 프롬프트에서의 문제

Windows용 한글 IME의 개발자로서 Windows의 명령 프롬프트는 참 기묘한 환경이다.
기본적으로야 운영체제가 기본 제공하는 TSF라는 인터페이스를 그대로 적용할 수 있지만 정확하게 들어맞지는 않는다. 다른 프로그램에서는 스펙에 명확하게 규정되지 않은 문제에 대해서 어떤 방법을 적용해도 동작하는데, 저기서만 미묘한 오동작이 발생해서 해결책을 찾느라 골머리를 썩인 적이 몇 번 있었다.

가령, 한글을 조합하고 있다가 다음 한글로 넘어갈 때 말이다. 지금 조합을 종료한 뒤 뒷글자 조합을 새로 시작할 수 있는가 하면, 지금 조합을 뒤에다 길이 0짜리 문자열로 유지한 뒤 그걸 재활용해서 뒷글자를 표현할 수도 있다. 마치 빈 문자열이냐 NULL이냐의 차이와 비슷한데, 어지간한 프로그램이라면 무슨 방법을 쓰든 동작이 동일해야 한다.

그런데 어떤 프로그램에서는 전자로만 해야 하고 후자 방법을 쓰면 조합이 씹히거나 끊긴다. 다른 프로그램에서는 후자로만 해야 하고 전자 방법을 쓰면 안 된다. 문제의 해결 방법이 프로그램별로 서로 다르기 때문에 IME의 소스를 더욱 지저분하게 만드는 주범 역할을 한다.
명령 프롬프트의 경우, 조합을 반드시 끊어야 하더라. 안 그러면 기존 글자가 지워지고 뒷글자로 덮어 써진다.

'새나루'는 본인이 개발한 날개셋과 더불어 오랫동안 3rd-party 한글 IME의 한 축을 담당해 왔지만 2010년대 이후로 버전업이 없이 개발이 사실상 중단됐다. 그 대신, 웬일로 한컴에서 Windows용 IME를 만들어서 아래아한글 2018에서부터 제공하기 시작했다. 한컴 IME도 명령 프롬프트에서 동일한 문제가 발생하던데, 난 이 문제를 겪어 봤기 때문에 원인을 안다.

C. 음절문자의 글쇠배열은?

한글이나 알파벳은 음소문자이다. 그렇기 때문에 글쇠배열을 적절히 만들면 양손이 각각 자음과 모음을 담당해서 최소한의 규칙성과 리듬감을 갖춘 형태로 타자를 할 수 있다.
그런데 자음· 모음 구분 없고 수십 종류의 음절이 제각기 서로 다른 글자로 배당돼 있는 일본어 히라/가타카나 또는 주음부호는 글쇠배열이 어떤 형태로 돼 있을까? 긴 글을 타자하는 경험은 어떠할까?

하긴 요즘은 대만에서도 주음부호 대신 한어병음을 더 가르치며 일본 역시 사람들이 어지간해서는 그냥 로마자로 발음을 입력하지, 골치 아픈 일본어 문자 전용 글쇠배열은 잘 쓰지 않는다고 듣긴 했다. 이거 뭐 삼성에서 훈민정음을 포기하고 Word로 갈아탔다는 것과 비슷한 얘기를 듣는 느낌이다.

Posted by 사무엘

2019/03/08 08:35 2019/03/08 08:35
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1594

1. 새 노트북과 새 폰

본인은 2010년대 초중반까지 노트북은 맥북을, 폰은 삼성 안드로이드 폰을 사용해 왔다. 그랬는데 노트북은 이제 성능이 너무 뒤쳐졌으며 배터리 용량도 너무 감소했다.

그리고 폰도 하필 약정이 끝날 무렵부터 배터리가 급격히 빨리 줄어들기 시작했으며, 그로부터 몇 달 되지 않아 걸핏하면 툭툭 꺼지기 시작했다. 폰이 꺼지지 않도록 잘 간수하는(?) 게 마치 옛날에 집안 불씨가 안 꺼지게 간수하는 것 같은 일이 됐다. 서비스센터를 방문해 보니 배터리나 전원 단자 문제가 아니라 순전히 메인보드의 문제라는 말을 들었다.

이런 이유로 인해 본인은 2019년 초의 비슷한 시기에 전화기와 노트북을 모두 교체하게 됐다. 폰은 고맙게도 남아도는 준중고 기기를 그냥 주신 분이 직장에 계셔서 본인은 신규 개통도, 번호 이동도 아닌 기기 변경이란 걸 했다. 그리고 졸지에 생각지도 않았던 아이폰 유저의 대열에 합류했다.
그 반면, 노트북은 맥OS를 굳이 더 쓸 필요를 느끼지 않아서 오랜만에 국산 일반 Windows 기계로 복귀했다. 예전과 반대로 전화기를 애플 것으로 쓰게 된 셈이다.

내가 원하는 노트북 컴터는..
굳이 그렇게 무리하게 얇거나 가볍지는 않아도 된다. 화면 해상도도 그냥 Full HD 1920*1080 급이면 넉넉하고 충분하다. 굳이 2000 안 넘어가도 된다.

또한, 요즘은 무선 인터넷 인프라가 워낙 널리 깔렸으니 광학 드라이브나 유선 랜 단자쯤은 본체에 안 달려도 크게 불편하지는 않은 지경이 된 거 같다.

다만, 램은 8기가가 뭐야 8기가.. 장난하나? 안 그래도 추후 확장하기도 어려운 주제에..
뭐, 저걸로도 Windows 10 깔고 작업 자체는 가능하다. 하지만 개발툴, 가상 머신, 5개 이상 탭을 열어 놓은 크롬 브라우저, 문서 작업을 위한 오피스 등등을 한꺼번에 너끈히 구동하면서 5년 정도 버티려면 요즘은 정말 못 해도 12기가 이상은 달아야 된다.

(메모리가 부족해서 프로그램을 그렇게 많이 한꺼번에 돌리지 못하면? 고성능 CPU라든가, 요즘 놋붉들이 그렇게도 강조하는 큼직한 화면이 별 의미가 없다. 그 넓은 화면에다가 여러 프로그램들을 도배하려 해도 메모리에서 결국 병목이 걸린다!)

Windows 7 이래로 10까지 Windows의 최소/권장 사양의 메모리 용량이 계속 똑같이 1GB/2GB(64비트 기준)인 건.. 개인적으로 좀 사기극이고 허위 과장 광고라고 생각한다. 전혀 현실적이지 않다.

그리고.. 본인은 아재 사고방식이어서 그런지, SSD를 영 미덥지 않게 생각해 왔다. 빠른 건 좋지만 용량이 너무 부족하기 때문이다. 하지만 세월이 흐르니 SSD의 가격도 놀라울 정도로 많이 떨어지고 512GB급 물건도 나오다니 기술의 발달에 경이로움을 느낀다.
기계식과 전자식의 차이는 확연히 드러난다. SSD가 아니면 이 정도 성능과 용량을 자랑하는 노트북 컴이 이렇게 조용하고 가볍고 빠르게 돌아갈 수가 없을 것이다.

2. 새 컴파일러

컴퓨터를 새로 세팅하면서 Visual C++도 드디어 최신 버전을 깔아 봤다. 전에도 얘기한 적이 있지만 IDE, 플랫폼 SDK, 그리고 컴파일러 툴킷이 서로 완전히 분리되고 제각기 따로 노는 게 가능해진 것은 매우 바람직한 변화이다. 그리고 IntelliSense DB를 저장하는 방식이 예전의 MS SQL Server Compact Edition (*.sdf)에서 SQLite (*.vc.db)로 바뀌어 있더라.

날개셋 한글 입력기의 소스를 빌드해 보니 다음 사항들만 '경고'로 걸리고 나머지는 문제 없이 컴파일 된다.

(1) GetVersionEx 함수를 사용하는 부분이 deprecated로 처리됐다. Windows 8.1 내지 10부터는 운영체제의 세부 버전을 체크하는 방식이 이 함수를 사용하지 않는 다른 쪽으로 바뀌었기 때문이다. 다만, 옛 함수가 strcpy 내지 gets처럼 보안 위험 때문에 deprecated 된 건 아니다.

(2) C++에서는 포인터를 정수형으로 typecast 하기 위해서 잘 알다시피 reinterpret_cast 연산자를 사용하는데, 포인터형보다 작은 크기인 char, short, UINT(64비트 환경 한정)로 바꾼다면 언제나 경고가 뜨게 됐다. 이건 static_cast로 형변환을 한 단계 더 거쳐야 된다.

(3) delay-load 콜백 함수의 포인터를 보관하는 전역변수가 보안 강화를 위해 const 형태로 바뀌었다. 이 변수는 이제 실행 도중에 값이 변경될 수 없으며, 우리 코드에서 이 변수를 정의하면서 단 한 번 주소를 지정해 줄 수만 있다.
const PfnDliHook __pfnDliNotifyHook2 = _DelayDLLNotifyHook; 이런 식으로 말이다.
이 변수는 실행 파일의 read-only 영역에 보관되기 때문에 const_cast 같은 연산자를 이용해서 값을 강제로 변경하려 하면.. 그냥 crash가 발생하게 된다.

1은 그냥 어쩔 수 없고, 2는 경고가 안 뜨도록 코드를 고치고, 3은 조치를 취했다.

3. 날개셋 한글 입력기의 개선 사항

이렇게 개인용 컴퓨터가 바뀌고 개발 환경이 바뀌자, 날개셋 한글 입력기에 고칠 점이 몇 가지 눈에 띄기 시작했다. 요런 것들을 반영하면 또 0.01 정도 버전 숫자를 올릴 수 있을 것 같다.

(1) 이제 Windows 10이 세상을 평정했으니.. About 대화상자에 표시되는 운영체제 버전 정보에서도 10일 때는 년/월 형태의 세부 버전 번호(1709, 1809 같은)가 나타나게 했다. 아래 그림의 위/아래가 before과 after이다.

사용자 삽입 이미지

(2) 입력 패드는 지금 떠 있는 도구들을 모두 닫으면 프로그램을 곧장 종료하게 하는 /S 옵션이란 게 있는데.. 이게 프로그램 내부 구조를 개편하는 과정에서 언제부턴가 제대로 동작하지 않게 된 것을 뒤늦게 발견했다. 다음 버전에서는 고쳐질 예정이다.

(3) 글꼴을 본뜰 때 CJK 확장 한자 B뿐만 아니라 그 뒤의 C, D도 추가로 본뜨게 했다. 지난번 emoji에 이어서 글꼴 본뜨기 스크립트가 또 바뀌었다.

이쪽 SIP(보충 한자 평면) 한자들은 글자 수가 너무 많은데 일상생활에서 별로 쓰이지 않는 것들이고, BMP(기본 다국어 평면)보다 지원 시기가 훨씬 더 늦은 점으로 인해.. 지원하는 글꼴들도 통상적인 BMP 영역 한자용 글꼴과는 달리 비트맵 글립이 들어있지 않은 편이다.
그래서 16픽셀 글꼴은 썩 보기 좋지 않으며, 24픽셀은 돼야 볼 만하다.

(4) Vista 이래로 줄곧 그랬는지 아니면 8/10에서 보안이 강화돼서 그런 건지는 모르겠지만.. UAC를 켜 놓은 상태에서 ProgramData 디렉터리에는 새로운 파일을 생성할 수는 있지만 프로그램이 설치해 놓은 파일을 사용자가 임의로 고치는 건 안 되는가 보다.

본인은 거기에 있는 파일은 사용자가 마음대로 수정할 수 있다고 가정하고 글꼴 본뜨기 스크립트 같은 일부 파일은 사용자가 곧장 열어서 사용할 수 있게 했었다. 그런데 그렇게 할 수 없다면... 데이터 파일을 운용하는 방식을 바꾸든가 해야 할 것 같다. 비슷한 문제를 날개셋 타자연습의 연습글 목록 xml에서 이미 한번 겪은 바 있다.

(5) 지금까지 사용자에게서 옛한글 관련 동작 때문에 예기치 않은 오동작 의심 증세 문의를 많이 받았다. 옛한글은 일상생활에서는 안 쓰이다시피하니.. 다음 버전에서는 프로그램을 기본 설치했을 때 '세벌식 옛한글'을 아예 빼 버릴까도 고민 중이다.
장기적으로는 한글 표현 옵션 탭에서도 한양 PUA 내지 유니코드 1.1 레거시는 더 꽁꽁 숨겨 놓고 접근하기 어렵게 할 계획이다. 이제 쓰일 일이 없어졌으니 말이다.

(6) 그리고 좀 더 유의미한 변화로.. 휠 내지 노트북 터치패드를 아주 미세하게 굴렸을 때의 스크롤 동작을 개선했다. 이에 대해서는 다음 항목에서 더 자세히 설명하도록 하겠다.

4. 세밀하게 움직이는 휠

마우스 휠이란 게 PC에 도입된 지 20년이 넘었다. 휠이 도는 단위는 기본적으로 칸 단위로 구획이 나뉘어 있으며, 한 칸 돌 때마다 WHEEL_DELTA (120)이라는 값이 전달된다. 120이라는 값은 약수가 많아서(2*2*2*3*5) 다양하게 쪼개기 편한 수라는 이유로 선택된 것이다.

마소에서는 지금은 마우스 휠이 칸이라는 덩어리 단위로 돌아가지만, 미래에 연속된 단위로 아주 부드럽고 세밀하게 돌아가는 휠도 등장할 수 있을 거라고 예상했다. 그래서 단순히 움직인 칸 수가 아니라 거기에 delta를 곱한 값을 되돌리게 여유를 두고 메시지를 설계했다.

저게 1990년대 중후반의 일이다. 하지만 본인은 부드럽게 세밀하게 돌아가는 마우스 휠은 아직까지 구경하지 못했다. 그 대신 그 동작은 노트북의 터치패드/트랙패드가 물려받았다. 처음에는 손가락의 궤적을 따라 마우스 포인터를 옮기는 기능밖에 없었지만 나중에는 패드의 오른쪽 끝을 수직으로 문지른다거나, 아무 곳이나 두 손가락으로 수직으로 문지르는 것을 스크롤로 따로 인식하게 된 것이다.

그 스크롤 요청을 하는 방식이 예전에는 그 윈도우에 대해서 SetScrollInfo/Pos 함수를 호출하고 WM_H/VSCROLL 메시지를 생성하는 것이었다. 화면 캡처 프로그램이 제공하는 스크롤 캡처 기능이 어떻게 구현됐겠는지를 생각하면 된다.

그랬는데 요즘은 WM_MOUSEWHEEL을 보내는 게 대세이다. 터치패드의 종류에 따라 동작이 케바케이긴 하지만, 이때 옛날 동작과의 호환을 유지하기 위해 WHEEL_DELTA의 배수 단위로 스크롤 요청을 하는 경우도 있고, 아니면 문지른 속도에 따라 그 이하의 값을 보내는 경우도 있다. 2010년대부터는.. 스크롤 하다가 손을 급격하게 확 떼면 스크롤도 마치 관성을 받은 듯이 한동안 지속되다가 멈추는 동작까지도 구현돼 있다.

스크롤 요청을 받은 윈도우가 그림이나 웹페이지처럼 원래 픽셀 수준의 부드러운 스크롤을 지원하고 있다면 WHEEL_DELTA로부터 산출한 비율만치 자연스럽게 스크롤을 하면 된다.
하지만 픽셀이 아닌 글자 줄 수 단위로 이산적이고 각진(?) 스크롤을 지원하는 윈도우는 사정이 다르다. 너무 작은 delta 값은 나눗셈 과정에서 아예 0으로 버려지고 없어져서 스크롤이 전혀 처리되지 않을 수 있다. 내부적으로 델타 값을 보관하고 있다가 그 합이 양수나 음수로 WHEEL_DELTA의 배수가 됐을 때 줄을 옮기도록 다소 번거로운 조치를 취해야 한다.

그런데 동일한 각속도로 굴렸어도 120 단위만 지원하는 휠을 굴렸을 때와, 그 이상 정밀한 휠을 굴렸을 때 들어오는 delta값의 규모가 서로 같지 않다. 휠의 종류를 얻을 수 있는 API는 내가 알기로 없다. 그렇기 때문에 그 종류는 WM_MOUSEWHEEL 메시지 때 날아오는 값들을 보며 얼추 짐작을 해야 한다. (120보다 작은 값이 들어오질 않는가?)

Windows의 리스트 박스에서 마우스 휠을 굴려 보면, 처음에는 목록이 한 줄 정도는 픽셀 단위로 답답하게 굼뜨면서 스크롤 되다가 그 뒤 나중에는 줄 단위로 비교적 빠르게 스크롤 되는 걸 볼 수 있다. 이게.. 휠의 종류와 동작 방식을 감지하는, 한번 "간보는" 동작이 아닌가 개인적으로 생각한다.

날개셋 한글 입력기에서 이런 정밀한 휠을 지원하도록 조치가 취해진 곳은 날개셋의 고유한 에디트 컨트롤, 문자표 리스트, 그리고 편집기의 화면 인쇄(300% 이상의 배율로 확대했을 때)창이다. 사실, 내 것이 아닌 어떤 노트북 PC에서 날개셋 편집기에서 휠 스크롤이 잘 안 된다는 걸 오래 전부터 어렴풋이 경험하긴 했는데 그 당시에는 그다지 문제 의식을 못 느끼고 넘어갔던 것 같다.

처음에는 휠을 굴렸을 때 키보드 포커스를 받고 있는 창이 스크롤 됐지만 Windows 8인가 10부터는 마우스 포인터가 놓여 있는 창이 스크롤 된다. 그리고 저렇게 정밀한 휠이 도입되고, 세로 스크롤뿐만 아니라 가로 휠 스크롤 메시지도 도입되니.. 휠도 마치 고해상도 dpi만큼이나 지금까지 은근히 많이 변했다.

Posted by 사무엘

2019/02/02 08:32 2019/02/02 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1582

날개셋 한글 입력기 9.6이 나온 지 한 달 정도가 지났다.
이 블로그에서 날개셋 카테고리에 속하는 예전 글들을 읽어 보니 수 년 전.. 7.x, 8.x 시절에만 해도 이 프로그램에 그런 기능조차 아직 갖춰지지 않았었고 별 희한한 버그가 있었다니 큰 격세지감이 느껴진다. 지금까지 참 먼 길을 갔고 그래도 소원의 대부분이 이제 이뤄졌다.

특히 9.6에서 새로 도입된 필기 인식 기능은 참 흥미롭다. 본인도 종종 꺼내서 이것저것 글자를 쓰면서 잘 갖고 놀고 있다. 물론 한글을 빠르게 입력하는 용도로는 고전적인 세벌식 자판만 한 물건이 없음이 틀림없다. 하지만 필기 인식은 아예 AI 기술이 접목된 기능이며, 운영체제의 기존 기능을 이런 식으로 날개셋 한글 입력기에다가 최초로 연결해 낸 것 역시 큰 의의가 있다.

그럼에도 불구하고 9.6 이후로도 한 달 만에 입력기를 또 소폭 업데이트 하게 됐다. 0.01 단위의 업데이트는 7.11 이래로 5년 만에 처음이다. 그리고 이 기회에 타자연습도 같이 버전업을 했다.
이제는 프로그램을 더 고칠 일이 정말 없으면 좋겠다.. 둘 모두 버전이 올라갔지만 타자연습은 API가 여전히 9.5 구버전과도 호환된다. 먼저 입력기의 변화 내역은 다음과 같다.

(1) 필기 인식 입력 도구에 마우스 포인터의 모양 및 동작과 관련하여 개선· 변경 사항이 좀 생긴 게 있다. 이 점에 대해서는 이 달 말쯤에 프로그래밍 관련 글에서 추가적으로 다뤄질 것이다.

(2) 날개셋 한글 입력기는 단어 단위로 한글을 한자로 변환할 수 있으며, 한자를 탐색하는 방향을 앞 글자부터 뒤로 설정하는 옵션이 지난 8.x 버전에서부터 추가됐다. 그런데 이건 앞에서부터 탐색한 결과 최소한 2글자 이상의 한자어가 존재할 때에만 동작했다.
이제는 맨 앞 1글자 단독으로도 한자 변환이 가능하다면 뒤에서부터 탐색하는 게 아니라 여전히 앞에서부터 찾게 동작을 수정했다. 기존 MS-IME나 아래아한글이 동작하는 것과 동일하게 맞췄다.

(3) 설치 프로그램에서 "날개셋 한글 입력기를 기본 IME로 지정할까요?"라고 묻는 부분을 삭제했다. 어차피 Windows 2000~7 사이에서만 유효한 옵션이고, 오늘날 널리 보급된 10에서는 아무 의미가 없기 때문이다. 그리고...

※ '외부 모듈 관리' 페이지의 리모델링

날개셋 제어판 시스템 계층의 '외부 모듈 관리' 페이지를 싹 뜯어고쳤다. 3.0 이래로 거의 15년째 변함없이 리스트박스 기반의 요런 모양이던 것을..

사용자 삽입 이미지

이렇게 리스트뷰 공용 컨트롤 기반으로 쌔끈하게 고쳤다!

사용자 삽입 이미지

아~ 고치고 나니 너무 좋다. 이렇게 고칠 생각을 왜 지금까지 못 하고 있었나 모르겠다.
리스트뷰 컨트롤을 쓰니 탐색기 쓰듯이 IME 목록을 저렇게 다양한 형태로 표시할 수 있다.
IME들을 언어별로 딱 그룹을 나누었으며, 활성화되지 않은 IME도 뒤에 격리되어 표시되게 했다.

그리고 '정보'를 눌렀을 때 나타나던 것들도.. 온갖 GUID와 이상한 상수들은 개발자의 입장에서도 별 영양가나 의미가 없다고 여겨져서 빼 버리고 크게 간소화했다.
그냥 해당 바이너리의 전체 경로와 버전, 그리고 혹시 파워유저가 관련 레지스트리를 건드릴 때나 참고하라고 HKL 코드값과 클래스 ID, 프로필 ID 정도나 나오게 했다.

지금 선택된 입력기가 TSF 모듈인지 IME 모듈인지 같은 것은 '기술 정보' 내지 '자세히' 모드의 '비고'란에서나 간략하게 확인할 수 있다.
다만, 디폴트 입력기는 저렇게 '비고'란에다가만 '기본'이라고 달랑 써 놓는 게 아니라, 마치 프린터로 치면 '기본 프린터'처럼 기존 아이콘에다가 체크 무늬 오버레이 같은 걸 씌우는 방식으로 표시를 하고 싶긴 하다.

리스트뷰 컨트롤에 그룹을 지정하는 기능, 그리고 일명 tile view라고 불리는 제5의 보기 모드는 Windows XP 공용 컨트롤 6에서 도입된 가히 신의 한 수인 것 같다. 날개셋 한글 입력기에서 저 UI를 활용해 보는 건 이번이 처음이다.

※ 타자연습

입력기의 변화 사항은 이 정도이고, 다음으로 타자연습의 변화 사항을 소개하도록 하겠다.

1. 게임 배경 그림 개편

작년에는 날개셋 타자 게임에 체력과 실드 체계가 개편되었다. 그 뒤 이번에는 게임의 밸런스나 진행과는 무관하지만 중요도가 매우 높은 '시각적 요소'가 오랜만에 바뀌었다. 바로, 10수 년 동안 변함없이 유지되었던 전반부 레벨(3~6)들의 배경 그림이 바뀌고 제목도 바뀐 것이다.

레벨들의 예전 배경은 크게 그러데이션(전반부) 아니면 텍스처(후반부)로 구성되었는데, 전반부 그러데이션들은 하늘 컨셉을 너무 많이 우려먹은 게 사실이었다. 본인이 디자인을 알지 못하는 공돌이인 걸 감안하더라도 너무 촌스럽고 '성의가' 없어 보였다.

바꾼다고 해도 전용 텍스처를 사용하고 있는 후반부의 어려운 레벨들과 너무 위화감이 느껴져서도 안 되니, 여기 레벨들은 삼각형과 사각형이 동원된 간단한 기하학 무늬 위주로 배경을 바꿨다.
그래서 예전과 같은 단순 수평선 그러데이션을 사용하는 레벨은 맨 처음 1과 맨 마지막 12밖에 없게 했다. 이 정도면 단조로움이 많이 줄어들었을 것이다.

비주얼의 변화는 직접 확인해 보시라는 취지에서 스크린샷 첨부를 생략하겠다. 타자연습 페이지에는 레벨 3(새 제목: 에메랄드)이 어떻게 바뀌었는지가 나와 있다.
이 개편과 함께, 이번 버전부터는 256색 전체 화면 지원을 제외했다. 그리고 256색 지원을 위해 필요했던 번거로운 팔레트 처리 관련 루틴을 제거했다.

타자 게임을 처음으로 개발하던 2000년대 초에는 이 옵션이 필요했다. 속도가 1GHz가 채 안 되고 Windows 98/2000이나 그럭저럭 돌리던 컴은 비디오 카드도 덩달아 구닥다리인 경우가 많았다. 트루컬러 전체 화면에서는 게임 진행이 너무 느렸으며, 가상 머신에서 타자연습을 돌릴 때는 이게 지원되지 않기도 했다. 256색은 그런 성능 말고는 별다른 차이가 없다.

하지만 후대에 와서는 이건 전혀 필요하지 않은 옵션으로 전락했으며, 최신 컴퓨터에서는 아예 이 옵션을 일부러 숨기기까지 하는 지경이 됐다. 그래서 기왕 타자 게임의 배경 그래픽을 개편할 때 얘를 완전히 빼는 조치를 취했다.

2. 세벌식 글쇠배열 표시 유틸

아아.. 이건 지난 새 버전에서 같이 반영됐으면 좋았을 텐데 참 아쉽다만..
타자연습에 동봉돼 있는 세벌식 글쇠배열 표시 프로그램을 오랜만에 리마스터링(?)했다. '시작' 탭에서 '세벌식 글쇠배열' 버튼을 눌렀을 때 글쇠배열 창을 띄워 주는 그 프로그램 말이다.

타자연습의 주 개선 사항이 high DPI 지원 강화이었거늘, 타자연습과 함께 제공되는 이 유틸(3bfview)은 그거 대비가 전혀 돼 있지 않았다. 그래서 high DPI에서 실행하면 저해상도 픽셀이 강제로 확대되면서 얘는 내용이 뿌옇게 표시되곤 했다. 그걸 개선했다. 아래 그림에서 위와 아래의 차이를 주목하라.

사용자 삽입 이미지

사실은 '세벌식 파워업' 프로그램에도 동일 기능이 있다. 타자연습에 들어있는 유틸은 파워업의 소스 코드를 기반으로 일부 기능만 따로 떼어내서 만들어진 것이다.
그런데 지금까지 제공되었던 물건은 2012년경 파워업을 기준으로 한번 업데이트 한 뒤, 6년째 업데이트 없이 그대로 쓰여 왔다. 글쇠배열 하나 달랑 띄워 주는 기능이 크게 바뀔 여지가 없긴 하지만, 그나마 high DPI 지원만은 반드시 손 봐야 하게 됐다.

Posted by 사무엘

2018/12/01 08:29 2018/12/01 08:29
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1560

날개셋 한글 입력기 9.6

2018년도 벌써 끝이 얼마 남지 않았다.
그 사이에 날개셋 한글 입력기는 파이널 버전인 9.5가 나온 지 70일 남짓 지났고, 본인의 근황에도 여러 변화가 생겼다. 내 인생에 한글 입력기 TODO list가 비어 있는 나날도 이렇게 오는구나 싶다.

뭐, 정말로 TODO가 전혀 없는 것은 아니다.
생각 같아서는 이미 여러 번 얘기했듯이 입력 설정 파일 포맷을 뜯어고치고 싶고 엔진 구조를 다시 설계하고 싶고, 도움말을 몽땅 영작도 하고 싶다. 허나, 그런 것들은 지금 도저히 추진 가능하지 않을 정도로 너무 거창한 것들이고 비용 대비 효과가 미미하기 때문에, 굳이 지금 같은 학생 신분에서 졸업을 더 늦추면서까지 욕심을 내지는 않는 것이다. 9.5를 넘어 10.0이라는 대망의 버전 번호는 그 날을 위해 비워 두는 것일 수도 있다.

그래도 거창한 것 말고 GUI, 보조 기능, 데이터 쪽에 아주 자잘하게 바뀐 것은 있다. 이것들을 일단 9.6 정도로 정리하고자 한다.

1. 필기 인식!

날개셋 한글 입력기는 지난 9.3 버전 이래로 총 10개의 입력 도구를 제공하고 있다. 그런데 9.6에서는 기존 도구들과는 성격이 매우 다른 물건이 하나 더 추가되어 11개가 되었다.
바로 필기 인식이다. 현재의 글쇠배열이나 날개셋 입력 설정과는 아무 관계 없이, 글자의 모양을 사용자가 마우스로 그리고 프로그램이 이를 인식하여 문자를 입력시킨다. 기술적으로는 '온라인 필기 인식'이다.

사용자 삽입 이미지

필기 인식은 MS IME에서는 아주 오래 전부터 갖추고 있지만 날개셋 한글 입력기에는 없는 기능 중 하나였다. 뭐, 애초에 내 프로그램의 존재 목적과 전문 분야는 세벌식 관련 특수 기능, 키보드 인식 관련 customization, 옛한글과 복합 낱자 처리.. 따위이지, 그런 AI 분야가 아니니까 말이다.

하지만 내가 필기 인식 엔진을 직접 구현까지는 하지 않더라도, 기존 API를 통해서라도 날개셋에서 필기 인식 기능을 제공할 수는 없으려나 하는 아쉬움이 있었다. 그래서 본인은 방법을 찾아 봤는데.. 다행히도 방법을 어렵지 않게 발견할 수 있었다.

과거에는 Windows CE 내지 XP 태블릿 에디션 같은 일부 제품군에만 그런 API가 있었다고 한다. 하지만 이제는 데스크톱용 Windows에도 필기 인식 기능을 다 사용할 수 있더라.
그리고 API 형태가 XP 시절과 Vista 이후가 서로 좀 달라졌다. 이 시점에서 굳이 legacy API를 지원할 필요는 없으니, 내 프로그램의 필기 인식 기능은 후자만 지원하는 형태로 개발되었다.

필기 인식 덕분에 날개셋 한글 입력기의 다음 버전이 9.51이 아니라 당당하게 9.6으로 매겨질 수 있게 됐다. 자체 기능이 아니라 운영체제의 API를 빌려서 동작하는 기능이 한자 단어 사전과 더불어 하나 더 추가됐다. 필기 인식이야말로 키보드 대신 포인팅 장비만으로 문자를 입력하는 기능의 백미 진수가 아닌가 싶다.

위의 스크린샷에서 보듯이 필기 인식 도구는 (1) 글자를 그리는 공간인 정사각형 입력란, (2) 인식된 글자 후보 목록, 그리고 (3) 주요 도구 명령(획 지움 등)과 (4) 자주 쓰이는 키보드 글쇠 버튼들로 평범하게 구성되어 있다.

"부수로 한자 입력"이나 "문자표" 같은 입력 도구들은 키보드에 없고 평소에 자주 쓰이지 않는 특수문자 몇 자를 입력하는 게 목적인 반면, "필기 인식"은 일상적으로 자주 쓰이는 linguistic한 문자들을 연달아 많이 입력하는 용도로 쓰인다.
그렇기 때문에 전자 문자표들은 리스트의 항목을 더블 클릭해야 글자가 입력되지만, "필기 인식"은 한 번 클릭하는 것만으로도 글자가 곧장 입력되게 했다.

그리고 이 입력 도구는 중요한 옵션이 두 종류 있다. 첫째, UI 모드이다.
위의 스크린샷처럼 입력란이 하나만 있고 글자 후보 선택을 수동으로 할 때는 타이머도 옵션으로 지정할 수 있다. 마지막 획을 긋고 나서 별다른 조치 없이 2초 정도 있으면 1순위 글자가 자동으로 본문으로 삽입된다. 매번 '인식 완료'를 누르거나 목록에서 글자를 찍을 필요가 없다. 아니면..

사용자 삽입 이미지

이렇게 입력란을 2개를 꺼내서 쓸 수도 있다. 왼쪽의 입력란에다가 글자를 그린 뒤에 곧장 오른쪽 입력란에다 글자를 그리기 시작하면 왼쪽에서 인식된 글자가 곧장 본문에 삽입되는 것이다. 창이 세로로 길쭉한 크기이면 두 입력란도 좌우로 가로가 아닌 상하로 세로로 자동으로 배열된다.

입력란이 2개 있을 때는 space나 엔터를 누르는 것도 먼저 인식 결과를 본문으로 보내고 난 뒤에 수행한다. 글자를 그리고 있고 후보 목록이 뜬 상태가 일종의 composition 상태라고 생각하면 된다.

둘째로, 사용할 필기 인식 엔진의 언어이다.
필기 인식 엔진이란 건 범언어 세계 공통 형태로 존재하는 게 아니라 각 언어별로 제각기 나뉘어 있다.
그래서 한글은 오로지 한국어 엔진에서만 인식 가능하며, 히라가나· 가타카나는 일본어 엔진에서만 인식된다. 중국에서만 쓰이는 간체 한자를 인식하려면 중국어 엔진을 사용해야 한다.

어느 언어에서나 동일하게 인식 가능한 문자는 숫자, 알파벳, 아스키 기호와 한중일이 완전히 동일하게 사용하는 공통 한자들뿐이다. 한글을 알아보지 못하는 중국 및 일본어 엔진에서는 '튽'을 입력하면 다들 長이 1순위로 제시되는 걸 볼 수 있다.

이 입력 도구는 기본적으로 한국어 엔진을 사용하지만, 컴퓨터에 한중일에 속하는 언어가 2개 이상 설치되어 있다면 원하는 언어의 엔진을 우클릭 메뉴에서 선택할 수도 있다. 프로그램 제목 표시줄에도 현재 사용 중인 언어가 나타나 있다.
Windows 10 기준으로 설정 - 언어 옵션에 들어가면, 각 언어별로 언어 팩이나 IME와는 별개로 필기/음성 데이터를 받는 버튼이 있다. 거기서 한중일 언어의 필기 데이터를 받으면 그 기능을 내 프로그램에서 활용할 수 있게 된다.

그런데 정확하게는 모르겠지만 내 경험상, Microsoft의 한중일 기본 IME가 제공하는 필기 인식이랑, 저 official한 필기 인식은 따로 노는 별개의 기능인 것 같다. 마소의 일본어/중국어 IME는 '확장 입력기 애플릿'을 통해 자체적으로 필기 인식 기능을 제공하지만, 내 프로그램에서는 여전히 일본어/중국어 필기 인식 엔진이 존재하지 않는 것으로 인지하는 경우도 있다.

의외로 Windows Vista는 CD 대신 DVD로 출시되고 전세계 다국어가 기본 내장되기 시작한 첫 버전이어서 그런지..
중국어· 일본어 IME를 끄집어낸 적 없고 Office조차 설치하지 않은 한국어판에도 중국어와 일본어 필기 인식 엔진이 다 기본 내장돼 있는 듯했다. 그것도 Ultimate 말고 Home premium급이 말이다. 아무튼..

한중일 언어의 필기 인식은 이렇게 정사각형 격자에서 글자를 하나씩 인식하는 방식으로, 마치 학창 시절의 칸 공책처럼 동작한다. 하지만 라틴 알파벳은 길쭉한 4선지에다가 단어를 한붓그리기 하듯이 필기체로 날려 쓰는 형태로 동작한다. 즉, 프로그램의 UI 자체가 서로 다르다.
요즘 Windows 10급 컴퓨터에 영어 필기 인식 엔진은 기본으로 다 깔려 있고 이 기능을 활용할 수도 있지만.. 내 프로그램에서는 그건 보류하고 일단은 형태가 더 간단한 한중일 위주로만 구현을 했다.

이런 식으로 필기 인식뿐만 아니라 음성 인식(받아쓰기)도 보조 입력 도구로 구현됐으면 좋겠는데.. 기존 API를 공부하는 것만 해도 필기 인식보다는 훨씬 더 어려울 것 같다. 동아시아 언어는 지원이 아직까지 훨씬 미비하기도 하고 말이다.

2. 글꼴 본뜨기/본뜬 글꼴 삭제 기능

날개셋 한글 입력기는 내부적으로 전용 비트맵 글꼴을 사용하는 부분이 있다. 그렇다고 유니코드의 모든 문자의 글립을 직접 내장해서 제공하지는 않으며, 그럴 수 없고 그럴 필요도 없다.
한자 같은 글자는 그냥 사용자의 컴퓨터에 들어있는 운영체제 글꼴로부터 비트맵을 추출하라고 글꼴 본뜨기라는 기능이 있다. 유니코드 영역별로 여기는 무슨 글꼴을 이용해서 추출하라는 간단한 절차 스크립트 파일도 있다.

날개셋 제어판의 '시스템 계층'으로 가 보면 글꼴 본뜨기를 하고, 필요하다면 절차 스크립트를 편집하고, 본떴던 글꼴 파일을 삭제하는 기능이 있는데.. 이번 9.6에서는 이 글꼴 본뜨기 관련 기능들이 크게 개선되었다. 다음과 같은 변화가 생겼다.

(1) 예전에는 글꼴 본뜨기 버튼을 누르면 그냥 무조건 모든 본뜨기 작업을 처음부터 새로 했다. 하지만 이제는 이미 본뜨기가 돼 있는 파일은 또 건드리지 않고 넘어가며, 변화가 생긴 항목에 대해서만 본뜬다.
만약 모든 항목이 본뜨기가 돼 있어서 파일이 생성된 게 하나도 없으면 "모든 항목이 본뜨기가 돼 있습니다. 혹시 이것들을 무시하고 본뜨기를 처음부터 다시 하시겠습니까?"라고 확인 질문이 나오며, 여기서 사용자가 '예'를 누르면 이전처럼 본뜨기를 처음부터 새로 하게 된다.

사용자 삽입 이미지

(2) 글꼴 본뜨기를 한 뒤, 절차 스크립트에 명시된 영역과 겹치는 파일이 남아 있으면 그건 자동으로 제거하게 했다.
예를 들어 스크립트에 0~300, 500~800이 명시돼 있었고 이렇게 본뜨기를 했다고 치자. 나중에 500~800을 400~800이나 500~900으로 바꿔서 본뜨기를 하게 됐다면.. 이 영역과 충돌하는 이전의 05000800.16/8 같은 파일은 이 프로그램이 알아서 제거해 준다는 것이다. 충돌이 발생하지 않게 해 준다.

(3) 본뜬 글꼴 삭제 기능은 스크립트에 명시돼 있는 파일을 삭제하는 것과 스크립트에 명시되지 않은 잔상을 삭제하는 것을 취사 선택 가능하게 했다. 물론 둘 다 싹 다 없애는 것도 가능하다.

사용자 삽입 이미지

(4) 또한, 글꼴을 본뜨거나 삭제하기 전에, 이미 날개셋 한글 입력기 프로그램이 로딩해서 열어 버린 글꼴 파일들이라도 모두 닫게 했다. 그래서 정상적으로 덮어쓰거나 삭제할 수 있다.
이제는 본뜬 글꼴을 삭제해 버리면 한자 글꼴이 존재하다가도 다시 한자가 표시되지 않는 상태로 되돌아가는 게 가능해졌다. 이전 버전에서는 그게 가능하지 않았었다.

(5) 끝으로, 본뜨기 스크립트의 내부 구조도 개편했다.
SYMBOL, HANGUL, LATIN이라고 섹션을 구분하여 SYMBOL 영역에서는 예전과 동일하게 본뜰 문자 영역을 명시하면 된다.
HANGUL과 LATIN에서는 예전처럼 번거롭게 AC00~AC00, 00~FF을 써 줄 필요 없이, 이미 선언된 글꼴 ID만 써 주거나.. 아니면 새로운 글꼴을 선언만 하면 자동으로 완성형 한글이나 영문 글꼴을 본뜨도록 했다.

스크립트에서 글꼴 ID도 예전에는 고정된 배열을 기반으로 5~63 사이만 지정할 수 있었으나, 이제는 쿨하게 아무 숫자로나 지정 가능하게 했다(32767 이내). 그리고 완성형 한글이나 영문에서 재사용 없이 글꼴을 일회용으로만 선언할 때는 번호를 지정할 필요조차 없이 그냥 0만 줘도 된다.

한글 입력 엔진과는 무관한 그냥 UI 기능인데, 뭔가 프로그램의 완성도를 향상시키는 여러 작업들이 한데 행해졌다.

3. 이모지(emoji) 입력

2010년대부터 유니코드의 확장 평면에는 한자뿐만 아니라 이모지(Emoji)라고 불리는.. 이모티콘이 아니라고는 하지만 웹과 모바일에서 실질적으로 이모티콘처럼 쓰이는 온갖 그림문자들이 추가되고 있다.
유니코드 위원회는 출처와 근거가 명확하지 않은 임의의 문자를 제멋대로 넙죽 받아들이고 추가해 주는 곳이 절대 아니다. 그럼에도 불구하고, 일본에서 임의로 이런 그림문자들을 오랫동안 많이 사용해 온 덕분에 이들도 전세계에서 통용되는 유일한 코드 번호가 주어지게 되었다.

BMP를 벗어나 확장 평면이라는 제2군, 2루에 추가되는 문자들은 일상생활에서 쓸 일이 없는 듣보잡 벽자 한자나 고대 문자, 악보 기호 등이 고작이었는데.. 웬일로 채팅에서 활발히 쓰이는 그림문자가 이 영역에 대거 추가되었다.
그래서 유니코드의 버전이 10에 도달한 무려 2010년대까지도 모든 글자가 16비트 코드 포인트 하나로 감당 가능하다고 안일하게 생각하고 UTF-16의 대비가 제대로 돼 있지 않던... 구닥다리 글꼴 엔진이나 텍스트 에디터들이 이제야 부랴부랴 수정되어야 했다고 한다. 뭐, 출처를 알 수 없는 카더라 통신이다.

폰트는 근본적으로 흑백 벡터 이미지밖에 표현을 못 하니, 인쇄를 염두에 둔 워드 프로세서에서는 이런 이모지들이 그냥 U+26??대의 그림문자와 별 다를 바 없는 외형으로 찍힌다. 하지만 전문적인 채팅 앱이나 스마트폰의 텍스트 입력란에서는 이것들이 컬러 그림으로 표시된다. 이 정도면 마치 한자만큼이나 글자와 그림의 경계가 모호해지는 것이나 마찬가지로 보인다. 서식(글꼴, 글자색, 크기 변경 등) 없는 텍스트 입력란 하나만 만드는데도 온갖 유니코드 문자 처리뿐만 아니라 이제는 사실상 그림 출력까지 감당해야 할 듯하다.;;

2010년대에 나온 최신 중국어· 일본어 IME를 보면 이런 이모티콘을 입력하는 전용 문자표나 입력 모드가 꼭 존재하더라. 이런 거 입력도 뭔가 피할 수 없는 대세가 되어 가는 듯한 느낌이다.
하지만, 내 프로그램은 모든 유니코드 문자를 고르는 범용적인 문자표 외에, 분야별 전용 문자표 같은 것은 딱히 고려 대상이 아니다. 현재로서는 말이다.
또한 편집기도 일반 문자들조차 흑백 비트맵 나부랭이로 출력하는 주제에 이모지를 컬러 이미지로 출력해야 할 이유는 없다.

날개셋 한글 입력기가 이모지의 지원과 관련하여 할 만한 최소한의 조치는 글꼴 본뜨기 스크립트에다가 이 영역을 반영해 주는 것이다. Windows의 경우 Segoe UI Symbol이라는 글꼴이 이모지 출력용으로 쓰이고 있어서 이걸로 U+1F300부터 U+1F6FF 정도를 전각으로 본뜨면 된다. 문자표의 영역명에는 이 영역도 이미 등록돼 있다.

이건 아주 간단한 조치이니 지난 9.5에도 반영돼 들어갔으면 좋았겠지만..;; 인제 생각이 나 버렸으니 뭐 어쩔 수 없다. 이제 9.6을 설치한 뒤 글꼴 본뜨기를 다시 해 주면 편집기에서 이모지 글꼴들을 볼 수 있다.

4. '조합 안에 조합 생성' 입력 도구의 개선

'조합 안에 조합 생성' 입력 도구는 지난 9.3과 9.5 버전 시절에 도입되었던 핵심 기능들 중 하나이다. 이제 더 고칠 게 없을 거라 여겨졌지만 미세한 개선 사항과 버그들이 더 발견되어서 9.6에서 다들 고쳤다.

  • numlock 키패드로도 후보를 선택할 수 있게 했다. 안 그래도 세벌식 자판은 키보드의 1~0은 문자가 배당돼 있는데 Ctrl+숫자뿐만 아니라 numlock 키패드도 지원된다면 아무래도 더 도움이 될 것이다.
  • 한글을 조합하는 중에 capslock 또는 이에 준하는 조합 종료 글쇠를 누르면 원래는 아무 반응이 없어야 정상이다. 그런데 외부 모듈은 지금 조합이 덧나면서 조합이 종료되는 문제가 있었다. 편집기, 외부 모듈, 입력 패드에서 모두 아무 반응이 없게 일관되게 조치를 취했다.
  • 편집기와 입력 패드는 입력 도구를 꺼내는 과정에서 대화상자를 꺼내고 창 포커스가 바뀌기 때문에 이런 일이 원천적으로 발생할 수 없는데 외부 모듈은 현재 조합을 그대로 유지하면서 입력 도구를 열거나 닫을 수 있다. 이미 조합이 있는 상태에서 저 도구를 꺼내거나 닫으면 여러가지 문제가 발생할 수 있던 것을 다 해결했다.

Posted by 사무엘

2018/11/05 08:32 2018/11/05 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1551

날개셋 한글 입력기 9.5, 그리고 타자연습 3.81이 나왔다. 9.3 이후 반 년을 넘어 거의 200일 만이다.
지금으로부터 두 달쯤 전의 개발 근황글에서 예고한 바와 같이, 이번 9.5는 '파이널' 버전이다. 수 년치 분량의 TODO 리스트를 갖고 작정하고 새 아이디어, 새 기능을 구현하고 리모델링 리팩터링을 하던 것은 여기까지이다.

그 과업이 다 이뤄졌다! 내 인생에 이런 날이 오다니 감개무량하면서도 한편으로는 그저 담담하다. 9.5 이후부터는 장기 계획 없이 소규모 유지보수만 소규모로 진행될 것이다.

작년 여름에는 나라 사정 때문에 슬럼프에 빠졌던 게 많았던 반면, 올해 여름은 그런 외부 요인이 개발 컨디션에 심하게 영향을 끼친 건 없었다. 그래도 폭염이 너무 심하긴 했다..;;
또 이 정도면 정말 '완결 파이널'이라고 내 양심과 역사와 국가와 민족 앞에서 정말 단언할 수 있을지 확신이 서지 않아서 테스트만 하다가 긴 시간을 그냥 보내 버리기도 했다. 그래도 올여름은 넘기지 않고 끝을 보게 됐다.

1. 동시치기

이번 9.5 버전에서 제일 핵심적인 새 기능은 초보적인 수준의 동시치기이다.
지금까지 날개셋 한글 입력기가 세벌식 자판의 고급 응용 기능 명목으로 제공해 온 것은 오토마타를 통한 모아치기나 무한 낱자 수정 정도였다. 이건 일면 편리하지만 현재 글자를 최대한 붙이고 유지시켜 주는 것에만 최적화돼 있다. 다음 글자로 분리되어야 하는 상황의 대비가 미흡한 반쪽짜리이다.

그래서 새 버전에서는 한글 입력 중에 일정 간격을 두고 마지막 두 타가 이전 타보다 충분히 빠르게 입력됐다면, 이건 다음 글자에 대한 동시입력으로 간주하고 그 두 타를 뒤로 같이 보내는 로직을 구현했다.

마지막 두 타를 한꺼번에 다음 글자로 보내는 동작 자체는 이전 버전에서부터 구현돼 있었다. 그걸 후대 버전에서 드디어 본격적으로 활용하게 된 것이다.
이 기능을 사용하면 세벌식 자판에서도 명목상 도깨비불 현상 같은 동작이 발생할 수 있다. 물론 그래도 종성이 초성으로 바뀐다거나 하지는 않고 그냥 위치만 이동한다.

동시치기는 시간 주기부터 시작해서 세밀한 동작 옵션이 존재할 여지가 많은 기능이고 이것만 전담하는 빠른설정이 존재해도 이상할 게 없다. 본인도 그걸 의도하기도 했다. 동시치기는 특정 입력 방식이 아니라 안 마태건 공 병우건 세벌식 입력 방식에 적용 가능한 일종의 범용적인 패러다임이니까 말이다.

하지만 9.5 버전은 그 정도까지 구현하지는 못하고, 그냥 '동시치기 테스트.ist'라는 예제 파일만 넣어서 공 병우 세벌식 글자판을 기준으로 이런 기능도 구현 가능하다는 맛보기를 시연하는 선에서 그쳤다.

해당 파일을 열어 보면 설명문에 오토마타 로직이 세밀하게 설명돼 있는데, 핵심은 이렇다.
고급 입력 스키마의 옵션을 바꾸서 동시치기 타이밍 변수를 제공하게 한다(고급 스키마 옵션 - 한글 동시치기 타이밍을 오토마타 Q 변수에 전달).

그 뒤, 실제로 두 타를 옮기는 것은 두 타가 가리키는 (1) 한글의 성분이 서로 다르고(초성+중성, 중성+종성 등..), (2) 두 타를 떼어내더라도 앞 글자가 최소한 초성과 중성을 갖추고 있을 때에만 떼어낸다.
이 두 조건을 체크하기 위해서 오토마타에 s, r, u, v 같은 복잡한 변수와 수식들이 있는 것이다. 별로 어려울 것 없다.

이 입력 방식에서는 '아'를 친 뒤에 'ㅣ+ㄱ'을 빠르게 입력하자 글자가 처음에는 무한 낱자 수정 때문에 '이'가 됐다가 다시 '아'로 바뀌면서 '아기'가 입력되는 것을 볼 수 있다. 물론 그냥 단순히 순차적으로 빠르게 칠 때 예기치 않은 부작용도 발생하지 않게 타협점을 찾으려 했다.

이 정도는 돼야 두벌식이나 세벌식이나 컴퓨터에서는 성능과 편의성 차이가 별로 없다는 말을 완전히 반박할 수 있지 않을까? 세벌식은 타자기에서 이미 기본적인 온전한 입력이 되고 컴퓨터로 가면 오타 수정이 더 편하게 되고 타이밍 오차 보정까지 되는 입력 방식을 구현할 수 있으니 말이다. 그것도 언어 데이터 없이 그냥 원초적인 수준에서 말이다.

지난번 개발 근황에서 먼저 소개되었던 한글 조합 유지 기능은 한글과 비한글끼리의 순서를 보정하는 기능이고, 이번에 완결된 기능은 한글과 한글끼리의 순서 내지 음절 경계를 보정하는 기능이다. 이런 기능이 타자에 실질적으로 얼마나 도움이 되었는지를 입증하는 실험 데이터가 좀 있으면 좋겠다.

참고로 지금으로부터 10여 년 전, 4.x 버전 시절에 '고급 스키마'의 전신격인 동시입력 스키마라는 게 날개셋 한글 입력기에 이미 도입된 적이 있었다. 옛날 자료를 찾아보니 2개 이상의 한글 글쇠가 동시에 눌렸을 때 '중간 상태'로 진입하고, 모든 글쇠가 떼어지면 '종결 상태'로 넘어갔다. 종결 상태에서는 '고+ㅏ'나 '고+ㄴ'처럼 평소에 조합 가능한 입력이라도 더 결합을 거부하고 다음 글자로 가게 해서 음절을 구분했었다.

동시치기의 원론적인 동작에 정말 충실하게 로직을 구현하긴 했지만, 이 상태로 실제로 쳐 보면 생각보다 불편하다.
특히 기존의 이어치기 방식으로 타자를 빠르게 하면 오동작도 많이 겪게 된다. 동시치기 내지 동시치기에 준하는 빠른 타자가 행해지는 동안에는 음절 경계의 타이밍의 차이로 물리적인 음절 경계를 구분하는 게 더 낫다.

옛날 '동시입력 스키마' 시절에도 'ㅇ.ㅏ' 오타를 보정하고, keyup 타이밍 때 비한글 문자를 뱉는 옵션은 구현돼 있었다. 비록 한글 조합 중에 그 비한글 문자가 같이 보이지는 않지만 말이다.

2. 입력 도구들의 개선

9.3은 참신한 입력 도구들이 대거 추가된 버전이었다. 그리고 지난번에 다음 버전 개발 근황을 전한 뒤에도 입력 도구에 대한 개선 작업이 더 진행되었다. 구체적인 변화 내역은 다음과 같다.

'조합 안에 조합 생성' 입력 도구가 제공하는 변환 기능 중, '새김을 한자로'도 한번에 여러 한자의 훈을 한꺼번에 입력해서 여러 개의 한자로 순차적으로 변환할 수 있게 했다. 더구나 새김을 끝까지 다 입력하지 않아도 된다.
가령, "땅불바람물마음"이라고 한꺼번에 친 뒤에 한자를 하나씩 골라서 "地火風水心"을 곧장 입력할 수 있다. 이전 9.3에서는 이런 게 가능하지 않았으며, '땅'까지만 치고 나서 변환을 직접 한 뒤에 다음 글자를 입력해야 했다.

사용자 삽입 이미지

그리고 '조합과 후보 자동 완성' 입력 도구도 여러가지가 개선됐다.
(1) 먼저, 목록에서 오른쪽에 작게 표시되는 보조 문자열(조합 목록에서 글쇠 문자, 후보 목록에서 설명문)이 한 줄에 가지런히 맞춰서 출력되게 해서 미관을 개선했다.

사용자 삽입 이미지

(2) 조합이나 후보가 출력될 게 아무것도 없는 상황에서는 해당 목록이 작게만 공간을 차지하는 게 아니라 아예 화면에서 사라지게 했다. 좌측 상단에 있던 자그마한 기본 버튼들만 남아있다.

사용자 삽입 이미지

(3) 다른 프로그램에서는 별 문제가 없는데 MS Word에서는 이 입력 도구가 cursor 주변에 표시되지 않고 화면의 좌측 상단에 잘못 표시되는 문제가 있었다. 쟤만 유독 까탈스럽게 동작하는 게 있어서 문제를 꽤 번거로운 방법으로 우회해야 했지만.. 어쨌든 버그를 고치긴 했다.

(4) 이 도구를 띄워 놓은 상태에서 운영체제의 테마나 색깔 배색을 변경하고 나면 보조 문자열의 글꼴이 깨져서 굴림체로 바뀌어 버리던 문제를 해결했다. 그 이벤트가 발생했을 때의 처리 절차에 논리적으로 구멍이 있기 때문이었는데, 이를 총체적으로 싹 손 봤다. 공통으로 사용하는 글꼴 같은 리소스를 반드시 초기화부터 한 뒤에 입력 도구들이 이벤트를 받게 했으며, 이 순서가 꼬이는 일이 없게 했다. 심지어 날개셋 편집기와 외부 모듈을 동시에 구동했을 때에도 말이다.

(5) 이 외에도.. 프로그램을 이 정도로 변태같이 사용하는 경우는 현실적으로 극히 드물겠지만,
날개셋 편집기에서 또 외부 모듈을 구동하고, 두 구현체가 제각각 '조합과 후보 자동 완성' 도구를 구동했을 때.. 그리고 TSF가 아니라 이제는 사실상 사용되지 않는 9x~XP까지의 구형 IME 프로토콜로 동작할 때, 여러 오동작이 발생하던 문제들을 해결했다.
과거의 9.3을 개발하던 당시에 시간에 쫓기느라 이런 극한이나 레거시 환경에서까지 꼼꼼히 테스트를 하지 못해서 문제가 남아 있었다. 단지 그게 크게 부각되는 주요 문제가 아니었을 뿐이다.

3. 그 밖의 UI 개선

(1) 날개셋 제어판에서 '분야'를 선택하는 트리 컨트롤을 키보드로(주로 상하 화살표) 조종하면.. 그 분야에 해당하는 제어판 페이지가 곧장 뜨는 게 아니라, 중간에 0.2초 정도 지연을 넣었다.
키 입력이 일정 시간 이상 안 들어올 때에만 화면을 갱신하는 것이다. 화살표 키를 빠르게 연타하거나 꾹 누르고 있을 때, 일일이 제어판 페이지를 준비하느라 프로그램의 반응성을 떨어뜨리지 않기 위해서이다.

사실, Windows의 제어판은 오래 전부터 이미 이렇게 동작하고 있다.
디렉터리를 표시하는 트리는 마우스 클릭에는 즉각 반응하지만 키보드의 화살표 키에는 그렇게 하지 않는다. 잠시 뜸을 들이고 있다가 사용자가 키보드에서 손을 완전히 뗀 뒤에 그 디렉터리의 내용을 옆의 리스트 컨트롤에다가 표시해 준다. 매번 한 디렉터리의 파일 목록을 얻는 건 힘들고 시간이 많이 걸리기 때문이다.

트리 컨트롤이 이렇게 키보드에 대해서 지연 인식을 하는 건.. 정형화된 동작이고 여러 곳에서 쓰일 만한 기능인데, 어째 운영체제 공용 컨트롤 차원에서 제공되는 건 없는지 궁금하다(스타일, 플래그 형태로). 그런 게 있다는 소식을 들은 적이 없기 때문에 본인은 해당 동작을 수동으로 직접 구현했다.

(2) 그리고 또 사소한 것..
날개셋 한글 입력기의 대화상자 UI 중에는 파란색 밑줄이 쳐진 하이퍼링크가 있다. 가령, About 대화상자에 있는 홈페이지 주소라든가 '후원 안내' 말이다.
이전 버전까지는 마우스로 클릭한 것만 인식됐지만, 이제는 거기에 포커스를 옮기고 space를 누른 것도 인식되게 동작을 개선했다. 마우스 없이도 링크 클릭 명령을 내릴 수 있다. 원래 이렇게 되는 게 맞다.

4. 타자연습

끝으로, 타자연습은 딱히 새로운 기능이 추가되거나 동작이 바뀐 것은 없다. 하지만 API 호환이 깨졌기 때문에 입력기 9.5 엔진에 맞춰 다시 빌드되었으며, high DPI에서 실행되었을 때 발생하던 각종 glitch들을 잡았다. 이것 분량이 버전을 0.01 정도는 올릴 수준이 된다고 여겨지기 때문에 버전을 올리게 되었다.

  • 프로그램의 시작 화면에 나타나 있는 탭(시작, 글쇠 익힘, ... 통계)들이 지금보다 더 큼직하고 시원스럽게 배치되게 했으며, high DPI에서 한글의 아랫부분이 보기 흉하게 짤리던 문제를 해결했다.
  • DPI가 200%인가 225%를 넘어간 상태에서 샌드위치 내지 상하 대조 방식으로 긴글 연습을 하면 줄 전체에 꽉 차는 긴 문장이 제대로 찍히지 않고 뒷부분이 씹혔다. 새 버전에서는 이 문제를 해결했다. 물론 날개셋 한글 입력기의 비트맵 글꼴은 150% 배율까지만 크기가 보장되기 때문에 확대 배율을 너무 높게 잡으면 프로그램을 제대로 사용하기 곤란해지긴 한다..;;
  • '글쇠 익힘'과 '낱말 연습'에서 쓰이는 손가락 위치 선택 리스트 박스가 high DPI에서도 너무 작게 찍히던 문제를 해결했다.
  • '긴글 연습' 화면의 아래에 나타나 있는 도구모음줄(앞/뒤쪽..)도 high DPI에서 버튼들이 너무 비좁고 조밀하게 찍히던 것을 개선했다.

사용자 삽입 이미지

위의 그림에 묘사된 before/after에서 보다시피, 타자연습뿐만 아니라 편집기도 high DPI 환경에서 도구모음줄 아이콘들이 전반적으로 더 큼직하게 찍히게 했다. 편집기의 경우, 계산기 대화상자의 계산 결과 리스트가 high DPI의 글자 크기보다 너무 좁은 줄 간격으로 찍히던 문제도 있어서 이를 해결했다.

한편, 다시 타자연습으로 돌아오면.. 고대비 검정 모드에서 긴글 연습을 하면 disable된 도구모음줄 버튼들이 자기 고유한 형체가 없이 이렇게 사각형으로 뭉개져서 찍히곤 했다. 이를 정상적인 형태로 개선했다(위 vs 아래). 도구모음줄이 상시 표시되어 있는 날개셋 편집기에서는 진작부터 이런 처리를 하고 있었는데 타자연습에서는 지금까지 그 생각을 못 했었다.

사용자 삽입 이미지

이 정도..
이번 새 버전은 이제 정말로 더 고칠 것 없이 오랫동안 잘 쓰였으면 좋겠다.

Posted by 사무엘

2018/08/30 08:36 2018/08/30 08:36
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1527

다음 버전 개발 근황 2

2018년 여름 현재 날개셋 한글 입력기의 차기 버전인 9.5가 개발 중이다. 지금까지 수 차례 연기와 번복을 거듭해 왔지만, 9.5는 정말로 완전체 파이널 버전이 될 것이 명확해지고 있다. 작업해 놓은 것을 정리해 보니 분량이 이렇게 길어질 줄은 몰랐다.

9.5 이후로는 버전업을 하더라도 그 주기가 지금보다 더 길어질 것이며, 지금 같은 장기적인 개발 계획 없이 그때 그때 생긴 아이디어 반영이나 문제점 개선 위주로만 가볍게 새 버전이 나올 것이다. 2000년에 나왔던 1.0 이래로 18년이 지나서야 이제 좀 한글 입력기가 물건다운 물건이 완성된 것 같다.

1. '조합 안에 조합 생성' 입력 도구의 변화

날개셋 한글 입력기의 차기 버전에서는 9.3에서 첫 도입되었던 입력 도구의 모습이 이렇게 미묘하게 바뀌었다.

  • 후보 목록이 언제나 입력란의 왼쪽 끝에 표시되는 게 아니라("한국어"), 실제로 삽입되는 위치("처리") 근처에 표시되게 했다.
  • '한글 단어를 한자로' 변환 기능의 경우, 낱글자에 대해서는 한자의 훈도 표시되게 했다. (곳, 아내, 슬퍼할.. 등)
  • 지금 변환 가능한 영역("처리")과 그렇지 않은 영역(그 이후 "학술대회")을 검정 vs 회색으로 구분해서 표시하게 했다.

눈에 띄지 않는 개선 사항은 다음과 같다. 한글 조합 상태와 관련해서 여러 미묘한 버그들을 발견해서 잡았다.

  • 이미 한자로 변환되어 있는 곳으로 cursor를 옮기면 무조건 모든 한자들이 도로 한글로 돌아가는 게 아니라, 예전에 변환했던 단위로만 역순으로 복귀되게 했다. 예를 들어, 위의 그림과 같은 상태에서 마지막 한자인 '보(報)'를 건드리면 '정보'만 한글로 돌아가고 '한국어'는 아직 한자로 유지되어 있다.
  • 평범한 왼쪽 화살표나 backspace 말고 특수글쇠(앞 글자 달라붙기 같은)의 기능으로 cursor를 움직여서 앞의 한자를 건드렸을 때는 한글 복귀가 제대로 되지 않던 버그를 잡았다.
  • 저런 특수글쇠로 비한글 문자 사이를 왕래할 때 cursor가 일시적으로 사라지고 보이지 않던 버그를 잡았다.
  • 한글을 조합하던 중에 글자판을 변경했을 때 조합이 종료되지 않던 버그, 맨 마지막 글자가 아니라 중간에서 한글을 조합하고 있다가 한자를 선택했을 때(예: '훈(민)정' 조합 중에 訓民) 변환이 제대로 되지 않던 버그를 잡았다.

2. '고급 입력 스키마 - 고급 글쇠 인식' 기능의 변화

지난 7.4에서 첫 도입되고 나서 별다른 변화가 없었던 '고급 입력 스키마'에 간단한 modifier key 필터링 기능이 추가됐다.
지금까지는 얘를 이용해서 D 같은 문자 글쇠에다가 입력 기능을 배당하고 나면, Shift+D는 말할 것도 없고, 심지어 Alt+D 같은 걸 눌러도 글쇠가 아무 구분 없이 인식하고 동작해 왔다. (Alt 인식이 불가능한 외부 모듈 구현체는 제외)

얘는 말 그대로 저수준 고급 글쇠 인식 기능이기 때문에, modifier의 인식 여부는 modifier 글쇠 자체가 눌렸을 때 변수와 수식을 이용해서 사용자가 알아서 처리하라는 게 취지이긴 하다. 하지만 저건 너무 고지식하다고 여겨져서 Shift, Ctrl, Alt에 대해서 인식 여부를 사용자가 지정할 수 있게 했다.

물론 이건 단축글쇠 규칙만치 세밀하지는 않기 때문에 modifier 글쇠의 좌우까지 구분하는 기능은 없다. 고급 입력 스키마는 A, S, D 같은 인접한 글쇠가 동시에 눌린 것, B를 길게 누른 것, C를 눌렀다가 뗀 것 같은 이벤트를 감지하는 것이 목적이지, 단축글쇠처럼 왼쪽 Shift+L, Ctrl+Win+X 이런 combination을 세밀하게 감지하는 게 일차적인 목표가 아니기 때문이다.

사용자 삽입 이미지

modifier key 필터링 여부를 지정하는 체크 박스는 on/off뿐만 아니라 indeterminate라는 제3의 상태도 있는데(위의 그림에서 Ctrl), 이게 바로 예전처럼 modifier가 눌렸든 안 눌렸든 따지지 않는다는 뜻이다. D와 Shift+D에 대해서 동작을 구분하고 싶다면 Shift는 indeterminate로 맞춰 놓고 별도의 변수로 상황을 구분하면 된다.

Shift는 몰라도 Ctrl과 Alt는 단축글쇠와 충돌하지 않으려면 사실상 언제나 off로 지정해 놓는 게 좋을 것이다. 단축글쇠 옵션에는 좌우 중 무엇을 눌렀는지 구분하지 않는다는 옵션이 있을 뿐, 아예 on/off 여부를 구분하지 않는 옵션이 있지는 않다. 이 역시 대조적이다.

modifier key 필터링은 key down에 대해서만 동작한다. key up은 key down 이벤트에 걸렸던 글쇠가 떼졌다면 그 당시의 modifier와 관계 없이 언제나 동작한다. 키보드가 무슨 마우스 버튼도 아닌데.. A키를 그냥 뗐을 때는 이렇게 동작하고, Shift가 눌러진 상태에서 뗐을 때는 이렇게 동작하는.. 그런 상황은 고려하지 않기로 한 것이다. 그런 기능을 굳이 구현해야겠다면 역시 변수와 수식을 이용해서 사용자가 직접 구현하면 된다.

3. '고급 입력 스키마' 기능의 변화

오랫동안 빈 공간이 많아 황량하고, 별로 자주 쓰이지도 않는 옵션밖에 없던 '고급 스키마 옵션' 탭에 유의미한 옵션이 하나 추가되었다. 바로 '비한글 문자가 입력되어도 기존 한글 조합을 일시적으로 보존'해 주는 기능이다.

사용자 삽입 이미지

타자를 빠르게 하다 보면, 한글을 조합하고 있고 한글 입력과 관련된 글쇠들이 미처 다 떼어지기 전에 space나 쉼표 마침표 같은 문자 글쇠가 먼저 눌러질 수 있다. 이 경우 "ㄷ.ㅏ", "르 ㄹ" 같은 오타가 생기기 쉽다.

허나, 이 옵션이 지정되면 입력 스키마가 이런 비한글 문자를 문자 생성기(한글 입력 오토마타)로 곧장 보내지 않고, 한글의 옆에다가 임시로 붙여 준다. 즉, "다."처럼 된 상태에서 "당. "으로 한글 조합을 계속할 수 있다.
그렇게 있다가 모든 글쇠에서 손이 떼어지고 나면 조합이 종료된다.

이거 간단한 발상이지만 생각보다 꽤 유용하다. 오동작 부작용도 거의 없고 말이다. (물론 공백까지 저렇게 보정이 되게 하려면 '글쇠 및 변수 옵션'의 '추가로 인식할 글쇠'에다가 space도 0x20으로 추가해 줘야 한다.)
스크린샷에서 보다시피, 여는 괄호 계열에 속하는 (<[{ 이런 것은 같이 눌러졌을 때 한글의 뒤가 아니라 '앞'에 붙도록 별도의 옵션을 줄 수도 있다.

이미 옆에 붙은 글자가 있는 상태에서 또 비한글 문자가 입력되면, 이 기능은 그것까지 추가로 붙여 주지는 않는다.
단지, 이미 붙었던 글자를 없애고 새로 들어온 문자로 대체하도록 할 수는 있다. '중복 입력 허용' 옵션은 그렇게 동작 방식을 바꾸는 역할을 한다.

이 기능은 여러 글쇠의 keydown과 keyup을 감지해서 동작하기 때문에 고급 스키마에서 담당하고 있으며, 한편으로 한글과 비한글이 섞인 가변 길이의 조합을 표시하기 때문에 문자 생성기도 '고급 입력기'와 연계해서 동작한다. 정말 말 그대로 고급스러운 기능인 셈이다. 기본 입력기만 사용하고 있을 때는 이 옵션이 사용 불가 상태로 표시된다.

4. 한글 입력 엔진 쪽의 변화

(1) 오토마타 중에서 'xxx 처리 후 조합 중단'을 의미하는 -6, -9 같은 마이너한 기능들이.. 조합이 완료된 한글 뒤에 쓰레기 문자를 삽입하기도 하던 버그를 고쳤다.
그리고 마지막 두 타의 입력 순서를 교환하는 꽤 어려운 -11도 복잡한 상황에서 제대로 동작하지 않던 버그를 고쳤으며, 이 기능은 더 전문적인 특수글쇠에다가도 구현해 넣었다.

(2) 오토마타의 O 변수는 지금까지 입력 글쇠 또는 현재 조합 중인 한글의 종류가 두벌식인지 여부를 비트 1|2 플래그 형태로 갖고 있는데, 이 뿐만이 아니라 지금 한글 조합이 처음부터 사용자의 타자로 입력된 건지 아니면 프로그램에 의해 자동 재현되었는지(4)에 대한 정보도 추가했다.

달라붙었거나 특수글쇠 같은 걸로 재구성된 조합에는 O 변수에 4라는 비트값도 추가되어서 나온다. 그래서 사용자가 처음 한글을 입력할 때는 모아치기 오토마타를 사용하는데, 달라붙은 한글에 대해서는 더 세밀하게 무한 낱자 수정을 사용한다거나 식으로 오토마타를 구성할 수 있다.

(3) C0|0x23이라고 직전 두 글쇠의 입력 순서를 교환하는 특수글쇠를 추가했다.
이건 더 말이 필요하지 않다. 'ㄷ.ㅏ'를 '다.'로, 특히 두벌식 자판에서는 '뭥미'를 '뭐임'으로, '생리'를 '새일'로, 'ㅇ버'를 '업'으로 바꿔 준다. 물론 앞 글자의 조합 상태를 마음대로 넘나들고 바꾸기 위해서는 날개셋 편집기나 MS Word 같은 환경이 필요하다.

두벌식 자판은 구조적으로 동시치기를 구현하기 힘들다 보니, 순서가 뒤바뀐 오타는 이런 식으로 강제 보정하는 것밖에 방법이 없다. 내가 테스트를 해 보니.. 순서가 뒤바뀌는 오타가 날 정도이면 그 오타 이후에도 타자가 여러 타가 진행되어 버리는 편이기 때문에 이런 보정 특수글쇠를 적절한 타이밍에 누르는 것도 그리 쉽지 않을 것 같다. 하지만 이 기능이 없는 것보다는 있는 것이 나으리라고 본다.

이전에 추가되었던 C0|0x22도 원래는 이걸 의도했었으나, 기술적인 난이도 때문에 기능을 온전히 구현하지 못했다. 그래서 글쇠의 교환이 아니라 글자 전체의 위치 교환 수준에 그쳤었다.

5. 편집기의 미세한 버그 수정

이제 더 고칠 게 없을 거라 여겨지는 편집기에서 의외로 버그가 몇 개 발견되어 고쳐졌다. 그것도 직전 버전에만 있던 게 아니라 꽤 오래된 버그들이다.

  • 이전 글에서 언급한 대로, 24픽셀 글꼴을 사용하고 있는데 일본어· 중국어 IME의 조합을 나타내는 밑줄(점선이나 실선..)이 여전히 16픽셀 기준 높이로 취소선처럼 잘못 표시되던 문제를 해결했다.
  • 아주 미묘하고 발견하기 어려운 버그이긴 한데, 도구모음줄의 세로 폭이 실제보다 더 크게 잘못 계산되어서 아랫부분이 제대로 갱신되지 않고 가로줄 모양의 잔상이 생기는 걸 보신 분이 있으려나 모르겠다. 그런 현상이 절대로 발생하지 않게 조치를 취했다.
  • 이건 사용자의 데이터를 파괴할 수 있는 치명적인 버그이다. UTF-16LE가 아닌 다른 인코딩으로 파일을 저장할 때 크기가 수MB(대략 2MB) 정도를 넘어가면 그 2MB 정도의 경계에 속하는 줄이 낮은 확률로 사라질 수 있는 문제가 있었다. 언제나 발생하는 건 아니고 좀 복잡한 조건이 우연히 충족됐을 때만 발생하기 때문에 문제가 이제야 발견되었다.

6. 사소한 UI 개선 사항

(1) 날개셋 제어판에서 어떤 글자판(입력 항목)에 어떤 입력 스키마와 어떤 문자 생성기를 배당할지--빈/기본/고급-- 지정하는 부분의 명칭은 지금까지 아주 오랫동안 "이 입력 항목의 기반 루틴"이었다.

허나, '루틴'이라는 말이 엔지니어가 아닌 일반 사용자 입장에서는 굉장히 어색하고 생뚱맞아 보여서 이걸 '기능 수준'이라고 바꿨다. '빈/기본/고급'이 기능의 수준을 결정하는 것이기 때문이다.
이것 말고 '기술 기반', '기술 수준' 등의 용어도 고려하다가 최종적으로는 "기능 수준"이라고 말을 정했다.

또한 날개셋 한글 입력기가 제공하는 날개셋문자의 종류로는 일반 문자, 세벌식/두벌식 한글 등이 있는데.. 특수글쇠의 명칭이 '특수 코드'라고도 혼용되고 있어서 이를 없앴다. 그냥 '특수글쇠'로 통일했다.

(2) 굉장히 사소한 변화이다만.. 날개셋 편집기에서 다수의 블록을 잡은 뒤 날개셋 외부 모듈로 텍스트 필터를 사용할 때, 블록이 4개까지만 인식되고 5개째 이상부터는 필터 변형이 되지 않던 문제를 해결했다.
이것도 거의 10년 가까이 전부터 변함없이 존재하던 문제였지만, 여파가 워낙 미미하기 때문에 지금까지 방치돼 있었다. 애초에 외부 모듈에서 텍스트 필터는 TSF A급 프로그램이 아닌 곳에서는 사용조차 할 수 없기 때문에 더욱 존재감이 없다..

이 문제를 해결하기 위해 날개셋 편집기가 바뀌어야 할지, 아니면 외부 모듈이 바뀌어야 할지는 난 정확하게 잘 모르겠다. Windows의 TSF 스펙이란 게 한 치의 모호성 없이 명확하게 정의돼 있지 않기 때문이다. 하지만 외부 모듈이 문제를 피해 가는 것이 당장 더 간단하기 때문에 그것부터 조치를 취했다.

일단 내가 주변에서 보는 텍스트 에디터나 워드 프로세서 중에서 불연속적인 다수의 블록을 잡을 수 있는 프로그램 자체가 날개셋 편집기와 MS Word밖에 없다. 하지만 Word는 여전히 외부 모듈에다가 자기가 갖고 있는 모든 블록의 내용을 넘겨주지 않기 때문에 이 기능이 직통으로 동작하는 프로그램은 같은 계열의 날개셋 편집기밖에 없다. 레퍼런스로 삼을 프로그램이 이것밖에 없으니 편집기와 외부 모듈 중 무엇을 고쳐야 할지를 판단하기가 더욱 어려웠다.

(3) 이것도 아주 사소한 변화이긴 하다만, 프로그램이 제공하는 모든 대화상자들을 꼼꼼히 검토했다. 그래서 버튼들만 쭉 나열돼 있는 곳에서 좌우 화살표를 누르면 성격이 같은 것들끼리 포커스가 순환되게 했다. 여기서 버튼이라는 건 '확인/취소' 같은 누르는 버튼뿐만 아니라 라디오· 체크 버튼까지 포함이다.
옛날에 이걸 한번 정비한 적이 있었지만 세월이 흐르면서 그 규칙이 깨진 부분이 다시 많이 생겨 있었다.

(4) 편집기의 '삽입-기타 가져오기' 대화상자도 해당 기능이 처음으로 도입됐던 3.0 이래로 변화가 없다시피했을 텐데..
콘솔 프로그램을 골랐을 때는 파일 경로와 인자, URL일 때는 주소.. 이렇게 각 방식에 필요한 추가 정보만 그때 그때 화면에 표시되게 외형을 바꿨다. 그 결과 대화상자의 크기도 약간 더 작아졌다.

사용자 삽입 이미지

7. 날개셋문자의 0문자 처리

끝으로.. 말이 나온 김에 이번 기회에 규약을 확실하게 정했다.
한글, 일반 문자, 특수글쇠 등.. 각 종류별로.. 종류만 그렇게 정하고 내부 코드값은 아무것도 없는 0인 날개셋문자를 줬을 때 어떤 일이 일어나느냐 하는 것이다.

물론 뭔가 크게 대단한 일이 발생하는 건 아니다. 다만, 한글을 조합 중인 상태에서 0번 일반 문자가 입력되면 조합만 종료된다. 그도 그럴 것이 일반 문자는 그 정의상 한글 조합을 무조건 종료시키고, 0번 문자는 '문자 없음'을 의미하기 때문에 조합만 종료되는 효과가 나는 것이 자연스럽다.

한글 기반이면서 초중종 세 성분이 모두 0인 날개셋문자는 한글 조합을 전혀 건드리지 않고 그 상태를 유지시킨다. 다만, 조합 중이던 한글의 타입은 바뀔 수 있다. 가령, 두벌식으로 '각'을 입력하고 나서 세벌식 기반의 0문자를 입력하면 조합 중이던 문자의 외형은 동일하지만 내부적인 속성이 두벌이 아닌 세벌로 바뀐다. 그렇기 때문에 다음에 두벌식 모음 'ㅏ' 같은 걸 입력하더라도 도깨비불 현상이 일어나서 '가가'가 되지 않고 그냥 '각ㅏ'가 된다.

이런 경우와 달리, 특수글쇠 0문자는 그 어떤 side effect 없이 언제나 현행 조합 유지인 것이 반드시 보장되게 했다.
글쇠 수식에서 조건부로만 무언가가 입력되고 조건이 충족되지 않을 때는 지금 입력을 그대로 놔두고 싶으면 특수글쇠 0문자를 의미하는 C0|0을 배당하면 된다. 단, 텍스트 에디터의 입장에서는 아무 동작도 안 하는 게 아니라 조합 문자열을 덮어쓰는 동작이 발생하기 때문에.. 외형상 텍스트가 바뀐 게 없더라도 텍스트가 변경됐다는(modified) 판정을 받을 수 있다.

Posted by 사무엘

2018/06/25 08:31 2018/06/25 08:31
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1504

« Previous : 1 : 2 : 3 : 4 : 5 : ... 11 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/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:
1252682
Today:
345
Yesterday:
441