오랜만에 날개셋 한글 입력기와 타자연습의 새 버전이 나왔다.
한글 입력기의 32비트 배포 패키지가 드디어 날개셋 타자연습보다도 덩치가 더 커졌다.
타자연습이야 게임의 리소스와 MFC 라이브러리의 오버헤드 때문에 큰 편이었는데 입력기는 정말 순수하게 내가 작성한 코드와 내가 준비한 데이터만으로 덩치가 이렇게 커졌다.

날개셋 한글 입력기라는 걸 만들어 온 게 고3과 대학 시절 이래로 어언 20년이 됐다. 내 인생의 20대, 30대 나이와 함께했다.
한글 입력기뿐만 아니라 한글 글꼴도 새로운 걸 만들고 싶은 게 있는데 입력기만 너무 오래 끌었다. 그래도 덕분에 옛날에 도저히 상상하지 못했던 방향으로 입력기를 더 발전시키기도 했다. 10.0을 찍고 나니까 이제는 너무 터무니없이 거창한 것 말고는 프로그램을 만들 만치 충분히 다 만들었다는 생각이 든다.

1. 조합 안에 조합 생성 입력 도구에 문자열 자동 완성

지난번 개발 근황글에서 짤막하게 언급한 바와 같이, 이번 10.0 버전에서는 '조합 안에 조합 생성' 입력 도구에 후보 문자열의 뒷부분 자동 완성 기능이 추가되었다. 이 입력 도구가 수행하는 기능이 무엇인지를 감안한다면 진작에 들어갔어야 할 기능인데 다소 늦은 감이 있다. (이 입력 도구가 처음 도입된 건 2년 전의 9.3부터!!)

자동 완성 단축키는 tab/shift+tab 계열, 또는 ctrl+space 이렇게 두 종류이다. Windows와 유닉스 계열의 명령 프롬프트에서 경로/파일을 자동 완성해 주는 tab 키, 그리고 Visual Studio 개발툴에서 명칭을 자동 완성해 주는 ctrl+space 이들의 동작에서 모티브를 따서 다음과 같은 형태로 동작이 구현되었다.

후보 목록에 다음과 같은 문자열이 있고, 사용자가 a 또는 aa까지 입력했다고 치자.

aabbccccc
aabbdd
aabbddee

이 상태에서 ctrl+space를 누르면 후보 목록들의 공통 접두사인 aabb까지가 자동 완성된다. 이런 공통 접두사가 없는 상태에서 또 ctrl+space가 들어오면 그냥 맨 앞 또는 선택막대가 가 있는 문자열이 자동 완성된다.
물론 aabb 상태에서 d를 수동으로 입력한 뒤 ctrl+space를 누르면 dd와 ddee가 순서대로 완성된다. 즉, ctrl+space의 관점은 순차적인 진행, 전진이다.

그 반면, aa까지 친 상태에서 tab을 누르면 곧바로 맨 앞 항목인 aabbccccc가 자동 완성된다. 또 tab을 누르면 aabbdd, aabbddee의 순으로 순환하게 된다. shift+tab은 역순으로 순환한다.
tab/shift+tab의 결과로 인해 입력 중인 문자열이 달라지고 후보 목록의 내용이 달라질 수 있다. 그 상태에서 ctrl+space를 눌러서 추가적인 전진을 할 수도 있다.

그리고 후보 목록은 알파벳 순서뿐만 아니라 타자 길이가 짧은 것도 우선시해서 출력되는 반면, 이 tab 순환은 전전으로 사전 순으로만 진행된다.

사실, 날개셋 한글 입력기에서 기본으로 제공하는 영단어나 한자 새김 입력 정도만으로는 자동 완성 기능이 그렇게 막 유용하게 느껴지지는 않을 수도 있다. 자동 완성을 하느니 후보 목록에 n순위로 뜬 항목을 번호로 곧장 선택하는 게 더 빠르기 때문이다. 그래도 이 입력 도구에서도 명령 프롬프트(터미널)나 개발툴 에디터 같은 정도의 최소한의 편의 기능은 있어야겠다는 논리적 당위성 때문에 이 기능이 구현되었다.

참고로 자동 완성은 '새김으로 한자' 또는 '영단어' 입력일 때만 가능하다. '한글 단어를 한자로' 변환은 유일하게 자동 완성 기능이 전혀 지원되지 않는다. 입력한 한글보다 더 긴 길이의 한자어를 제시하는 동작이 없는 관계로, 자동 완성이라는 걸 제공할 여지가 없기 때문이다.

2. 한자 관련: 한글 독음 표시

UI에서 한자의 훈과 음을 표시할 때, 호환용 한자(독음의 바리에이션)에 대해서는 원래 한자의 음이 같이 병기되게 했다. '요'뿐만 아니라 '이, 인, 여, 노, 난, 열' 같은 글자에 대해서도 재미있는 결과를 볼 수 있다. 한국어의 두음법칙이 생각보다 까다롭다는 걸 느끼게 될 것이다.

사용자 삽입 이미지

그러므로 외국 사이트 같은 데서 한자를 입력할 때는... 이 글자보다는 가능한 한 {}로 둘러싸여 있는 음에서 동일 모양의 글자를 찾아 입력하는 것이 권장된다. 호환용 한자는 마치 UTF-8 텍스트의 BOM만큼이나 장기적으로는 사용이 권장되지 않는 deprecated 요소이기 때문이다.

물론 현실적으로는 이미 잔뜩 구축된 호환용 한자들과 기존 한글 IME들의 동작을 무시할 수 없을 것이고, 컴퓨터 소프트웨어들이 호환용 한자들을 알아서 정규화해서 처리해야 할 것이다.
먼 옛날 KS X 1001 상용 한자에서 서로 다른 독음에 대해서 똑같은 한자를 중복 배당한 것부터가 편법이고 원죄이긴 하지만... 그 시절에는 그렇게라도 해서 한자에 담긴 독음 정보를 보존해야 할 필요 또한 있었다.

그런데 金의 경우 도대체 왜 '성 김'이 본가이고 '쇠 금'이 호환용 한자로 연결되었는지, 不도 왜 '부'가 본가이고 '불'이 호환용인지는 나로서는 알 길이 없다. 날개셋은 별다른 이유 없이 그냥 마소의 데이터를 따르고 있을 뿐이다. 따지고 보면 '가'에 대해서 家부터 먼저 시작하는 마소 특유의 한자 빈도수 데이터부터가 출처가 무척 궁금해진다.

3. 부수로 한자 입력

(1) '부수로 한자 입력' 도구가 "한중일 통합 한자 확장 B, C, D"에 있는 U+20000 ~ U+2B81D 사이의 약 47000자에 달하는 한자들의 부수까지 추가로 조회해서 입력할 수 있게 했다. 단, 우클릭 메뉴에서 옵션을 선택해야 한다.

사용자 삽입 이미지

독음으로 한자를 입력하는 건 기본적으로 4888 상용 한자만 가능하고, 편집기 계층에 있는 '확장 한자 옵션'을 선택하면 BMP 영역 것까지 모두 가능해진다.
그 반면, 부수로 한자 입력은 기본적으로 BMP 영역이 가능하고, 별도의 옵션을 선택하면 확장 평면 것까지 사용 가능해진다.

날개셋 한글 입력기에서 확장 평면 한자는 짙은 초록색으로 표시된다. 지금까지는 이 색깔을 볼 일이 거의 없었지만 앞으로 "부수로 한자 입력 도구"에서 이 색깔을 적극적으로 볼 수 있을 것이다. 용 룡(龍) 자가 4개 붙은 그 극악의 64획짜리 한자(U+2A6A5)도 드디어 입력할 수 있다.

물론 확장 평면 한자들은 날개셋 한글 입력기 엔진이 공식 지원하는 한자는 아니다. 그렇기 때문에 이 한자들은 훈과 음 정보가 전혀 제공되지 않는다.
내가 보아하니 저 많은 확장 평면 한자들은 출처가 대체로 옛 문헌들인 것 같다. 기괴한 모양의 글자들이 많이 눈에 띄지만, 그렇다고 간체자 스타일의 획이 그려진 글자는 딱히 보이지 않기 때문이다.

내가 듣기로 CJK 확장 한자가 벌써 E, F, G에까지 도달했다고 하는데 도대체 아직까지 추가할 게 무엇이 있는지 궁금하다..;; 그래도 처음으로 확장 평면이란 걸 개척하면서 무려 4만 자가 넘게 한꺼번에 추가됐던 확장 B가 존재감이 압도적이다. C와 그 이후 영역들은 B보다는 규모가 훨씬 작으며, 수백~수천 자씩만 추가되고 있으니 말이다.

한중일 통합 한자 확장 E, F, G 따위도 데이터가 공개돼 있으니 지원할 수는 있다. 하지만 이들 영역은 당장 Windows 10에서도 글꼴이 기본 제공되지 않아서 글자가 제대로 표시되지 않으니, 내 프로그램에서도 지원할 필요를 아직 느끼지 않는다. 날개셋 한글 입력기는 한글 입력이 전문이지 굳이 이런 '부가적인 기능'을 운영체제보다 더 앞서 지원할 필요는 없을 것이다.

다만, 나중에 데이터 파일만 업데이트 하면 프로그램 코드를 수정하지 않아도 D 이후의 확장 영역을 추가로 지원할 수 있게 준비는 시켜 놓았다. 지원하는 확장 한자의 전체 개수를 하드코딩해 놓지 않고 파일로부터 값을 런타임으로 얻는 변수 형태로 처리했다는 뜻이다.

말이 나왔으니 말인데, 이모지 문자표도 이번 기회에 데이터 파일을 수정하면 동물, 자연, 음식, 활동 같은 카테고리까지 확장 가능하게 구조를 수정했다. 이모지도 마치 한자처럼 새로운 게 계속 추가되고 있는 영역이니 말이다.
이모지 문자표 내지 입력기를 제대로 만들려면.. 얼굴 이모지에서 피부색 바리에이션을 선택하는 UI도 들어가야 한다. 하지만 그건 현재 그냥 생략하고 있다.

(2) 확장 한자 지원 얘기가 좀 길어졌다만, 깨알 같은 변화가 하나 더 있다.
현재 얘는 부수를 클릭했을 때 보다시피 근처의 총획수가 동일한 부수들이 빨간색으로 표시되는 기능이 진작부터 존재했다. 그런데 현재 선택된 부수와 동일한 부수 소속인 글자들은 획수와 무관하게 하늘색으로 더 먼저 구분되어 표시되게 했다. 예를 들어 己를 선택했다면 巳와 已, 田을 선택했다면 由, 申, 甲, 그리고 4획의 王을 선택했다면 5획의 玉도 같이 말이다.

사용자 삽입 이미지

(왼쪽에 하늘색으로 흩어져서 표시된 그물 망 제부수자들을 볼 것)
적용해 보니 굉장히 편리하다. 이런 동작을 왜 지금까지 생각을 못 하고 있었나 모르겠다. 간체자까지 생각하면 획수가 다른 동일 부수 바리에이션이 더 많이 존재한다.
이 기회에 오리지널 제부수자보다 획수가 적은 제부수자들의 획수가 잘못 기재되어 있던 것들도 바로잡았다. 15년~20년 전 유니코드 DB에는 데이터가 잘못돼 있었던 것 같다.

그나저나 같은 한자의 획수 세는 방식도 절대 고정불변이 아니라 한국 중국이 서로 차이가 있다는 걸 알 수 있었다. 특히 1획으로 볼지 2획으로 볼지 굉장히 모호한 획 말이다.
중국이 대체로 획수를 더 적게 세는 쪽으로 바뀐 것 같다. 다시 말하지만 간체자로 형태가 완전히 바뀐 것 말고 동일한 한자가 말이다.

4. 허용 한글 범위 제약 기능 관련

(1) '현대 한글만 허용'이라는 간단한 기능이 추가됐다. 현대 한글 자모는 미완성 한글 형태라도 입력을 허용하지만, 초중종 중 어디라도 옛한글이 포함된 채로 두 성분 이상 결합하는 것은 허용하지 않는다. 옛한글 낱자는 단독으로만 입력과 결합을 허용한다. 언뜻 보기에 간단하지만 기존 오토마타나 다른 제약 기능을 이용해서 쉽게 구현 가능하지 않다고 여겨져서 이것만 직통으로 수행하는 기능을 추가했다.

(2) '지정된 파일에 들어있는 한글' 기능에 지금처럼 데이터를 파일 경로로 지정하는 외장형뿐만 아니라, 데이터 자체를 직접 갖고 있는 내장형으로도 동작하는 옵션을 추가했다. 그래서 이름도 '지정된 파일' 대신 더 범용적인 '지정된 데이터'로 바꿨다.
입력을 허용하는 한글의 수가 수십~수백 자 수준으로 아주 적거나 "현대한글 + 아주 소규모의 옛한글" 이런 식이어서 데이터가 작다면.. 번거롭게 외부 파일을 준비할 필요 없이 내장형이 더 나은 선택이 될 것이다.

사용자 삽입 이미지

5. 편집기의 색상 구성표

편집기에서 텍스트 편집창의 색상을 설정하는 UI에.. 다음과 같이 다양한 색상 구성표들이 추가되었다.

사용자 삽입 이미지

흑백, 호박색, 터미널 이렇게 어두운 그룹은 과거에 흑백 모니터를 사용하던 경험을 고스란히 재현해 줄 것이다. 날개셋 편집기는 그렇잖아도 옛날 추억의 한글 글꼴들을 한데 구경할 수 있는 프로그램인데, 색깔까지 복고풍 configuration을 제공하는 것은 나름 의미 있는 일이 될 것이다.

도스용 에디터, 칠판, 아래아한글 1.x 색상은 오래 전부터 제공되고 있었다. 외국에서는 아래아한글이 인지도가 없으니 영문 명칭은 무의미한 HWP 1.x 대신 그냥 시원한 바다색 Ocean이라고 바꿨다.

그리고 밝은 그룹인 레몬, 연보라, 베이지는 쌩 white보다 눈부심이 덜하고 편하기 때문에 역시 쓸모가 있을 것이다. 요 색깔들은 macOS의 터미널에서 제공되는 색상을 차용한 것이다.
이런 색상들을 간단히 가져와서 쓸 수 있는 것은 날개셋 편집기의 활용성에 긍정적인 기여를 할 것이다.

6. 외부 모듈에 보정 옵션 추가

바로 며칠 전에 어느 사용자께서 날개셋 한글 입력기가 Windows Terminal이라는 메트로 앱에서 조합 중인 글자가 자꾸 덧나면서(ㄱ가ㄴ나ㄷ다 같은..) 제대로 동작하지 않는다는 버그 신고를 하셨다.
이미 존재하는 보정 기능으로는 “ㄱ가나다”까지는 바로잡을 수 있지만 첫 글자가 덧나는 것은 막을 수 없었다.

엄밀히 따지자면 이 프로그램도 IME로부터의 문자 입력 접수에 제대로 대응하지 못하고 버그가 있다. 조합을 끊어서 전하든 기존 조합을 늘이고 옮겨서 전하든 겉으로 드러나는 결과는 아무 차이가 없는 게 맞는데.. 한편으로는 마소 IME는 괜찮은데 또 내 프로그램만 저러는 이유는 알 길이 없다.;;
이 때문에 프로그램과 통신하는 방식에 옵션이 하나 더 추가됐다.

예전부터 있었던 A 방식과 B 방식은 “연속 입력”에 대해서 기본 방식 또는 대체 방식을 지정하는 것이었다.
이번 10.0에서는 “최초 입력”에 대한 방식도 세분화됐다. Windows Terminal의 오동작을 해결하려면 두 입력에 대해 모두 “대체 방식”을 선택하면 된다.

사용자 삽입 이미지

7. 타자연습과 세벌식 파워업

입력기는 그야말로 0.1 이상으로 굉장히 많은 것이 바뀐 반면, 타자연습은 작년 여름에 나온 3.9 이후로 바뀐 것이 거의 없다. 입력기 10.0과 함께 타자연습도 4.0으로 같이 올라가면 참 좋았겠지만, 도저히 그럴 수 없어서 타자연습은 3.91이 됐다.

타자연습과 세벌식 파워업은 딱 한 가지... 무조건 주 모니터에서 창이 뜨는 게 아니라 자신을 실행시킨 GUI의 모니터를 기준으로 뜨도록 수정된 것이 전부이다.
지난 2017년~18년 사이엔 이들 프로그램이 고해상도 dpi를 제대로 지원하도록 수정되곤 했는데, 그 다음으로 multi-모니터를 제대로 지원하도록 수정이.. 참 굉장히 늦게=_=;; 행해졌다.

이상이다.
컴퓨터라는 기계가 있고 한글 같은 문자, 알파벳만치 마냥 단순하고 가볍지 않으면서 한자만치 무겁지도 않고 조합을 글자 단위로만 만들면 되는 단순한 문자가 있을 때.. 이런 문자의 입력을 위해 존재할 수 있는 모든 아이디어를 담을 수 있고 모든 형태로 실현 가능한 소프트웨어--이것이 지금까지 날개셋 한글 입력기의 개발 목표였다.

이제 앞으로는 날개셋 한글 입력기에 치명적인 버그 수정이나 자잘한 기능 추가 같은 유지보수 말고.. 기상천외한 기능이 새로 추가된다거나 프로그램 내부 구조가 바뀐다거나 하는 변화는 당분간 없지 싶다.
2020년대부터는 한국어/한글 정보 처리 쪽으로든, 철도 쪽으로든 내 인생이라는 연극의 다음 장, 다음 막이 진행됐으면 좋겠다.

지금까지 긴 세월 동안 날개셋 한글 입력기를 변함없이 사용하고 성원해 주신 분들께 감사드린다.
말을 이렇게 써 놓으니 내가 무슨 시한부 인생이라도 살고 있고 앞으로 날개셋 개발 다시는 안 할 것 같은 느낌도 든다만.. 이런 글 올려 놓고는 또 두어 달 뒤에 언제 그랬냐는 듯이 10.01 정도는 또 자잘한 버그 수정과 개선 명목으로 또 나올 수도 있다. ㅎㅎ

Posted by 사무엘

2020/05/28 08:35 2020/05/28 08:35
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1756

다음 버전 개발 근황

2020년은 2~40년 전쯤에 만들어졌던 각종 소설과 SF물에서나 다루던 까마득한 미래 시점이다. 그게 현실로 찾아왔다니 감회가 새롭다.
하지만 현실의 2020년은 코로나19라는 웬 신종 바이러스 때문에 교회 예배가 중단되고 학교 개학과 심지어 올림픽까지 연기되는 초유의 사태와 함께 시작되었다. 세상의 그 어떤 소설과 SF물도 이런 걸 예측하지는 못했을 것이다.

2020년은 날개셋 한글 입력기도 개발 20주년에 진입한 시점이다. 그리고 무려 10.0 버전이 현재 개발 중이며, 이게 9.x 시절부터 지금까지 수 년째 미뤄지고 또 미뤄졌던 파이널이다.
원래 9.5를 파이널로 삼으려고 했다. 9.5 이후로도 1년 반 동안 9.6, 9.7, 9.8x 등 새 버전이 도대체 몇 개가 더 나왔던가?? =_=;; 그러던 게 이제야 드디어 제동이 완전히 걸렸다.

이 글에서는 개발 중인 10.0에서 이미 작업이 완료된 것, 더해지고 고쳐지는 것들이 어떤 것이 있는지 잠시 소식을 전하도록 하겠다.

1. '기본 글자판 설정' 빠른설정에 no-shift 두벌식 세팅

10.0 버전에서 본인이 가장 먼저 알리고 싶은 소식은.. 날개셋 한글 입력기의 제어판에서 사용자가 가장 자주 접하게 될 UI인 '기본 글자판 설정' 빠른설정에 no-shift 두벌식을 간편하게 세팅하는 기능이 추가됐다는 것이다. 바로 여기에 말이다.

사용자 삽입 이미지

지금까지 사용자들로부터 받은 피드백을 종합해 보면.. 두벌식에서 shift 없이 쌍자음을 언제나 연타로 입력하는 것에 대한 수요가 제법 많다는 걸 알 수 있었다. 하지만 별 생각 없이 낱자 결합 규칙만 추가해 놓으면 '이끼, 바삐, 앗싸, 홀씨' 같은 단어에서 뒷글자에 등장하는 쌍자음을 연타로 입력할 수 없다. 음절 경계 모호성에 걸려서 '익기, 밥비, 았사, 홄시' 따위와 구분이 안 되기 때문이다.

이런 모호성을 해소하려면 그런 쌍자음은 어쩔 수 없이 shift를 동원해서 입력하거나.. 아니면 capslock 같은 글쇠를 눌러서 앞 글자의 조합을 수동으로 끊는 수밖에 없다. 옛한글 글쇠배열이야 모호성이 훨씬 더 많이 발생하기 때문에 대놓고 조합 중단 글쇠가 배당돼 있기도 하다.

하지만 그런 고전적인 방법 말고 타자 시간 간격을(타이머) 이용해서 음절 경계 구분을 할 수도 있다.
이건 구버전에서도 진작부터 지원돼 왔으니 기술적으로 새로운 기능은 전혀 아니다. 하지만 사용자가 일일이 설정을 하는 게 마냥 간단하고 쉽지 않다. 수요가 많은 상징적인 설정을 곧장 세팅해 주는 기능을 빠른설정에다가 도입한 것은 그 자체만으로도 버전업의 명분이 될 수 있다.

더구나 타이머를 적용하는 방식도 두 가지 중 하나를 선택할 수 있다.

  • 통상적인 방법(가-까 타이머): 뒷글자가 쌍자음이면 앞글자를 다 입력한 뒤 한 박자 쉰다(이-끼 → 이끼). 쉬지 않으면 예전처럼 ‘익기’가 된다.
  • 다른 방법(각-가 타이머): 위와 반대로, 쌍자음을 지연 없이 빠르게 치고, 자음이 앞뒤 글자에 분산돼 있을 때 한 박자 쉰다(익-기 → 익기). Google 단모음이 이런 방식을 사용한다.

각 방식이 어떻게 구현됐는지를 살펴보면.. 전자는 중성까지만 입력됐을 때도 타이머가 발동돼야 하며 오토마타도 상태가 두 개 더 필요하다.
후자는 오토마타 상태가 하나만 있으면 되지만 특수 도깨비불 규칙과 다단계 입력 분리(65531) 낱자 결합이 추가로 필요하다. ‘밝’까지 쳤다가 도로 ‘발ㄲ’을 만드는 것은 명백하게 더 과격한 동작이기 때문이다.

그래도 사용자의 타자 행동 관점에서 두 방식에 절대적인 우열은 없으니 그냥 자기에게 편한 방식을 골라서 쓰면 된다.
기본으로 설정되는 시간 threshold는 0.5초(500밀리초)이다. 타이머 설정에서 이 값을 더 늘리거나 줄일 수 있다.

2. “조합 안에 조합 생성” 입력 도구

얘는 여러 글자로 이뤄진 단어 같은 덩어리를 다른 형태의 문자로 변환하는 핵심 인터페이스이다. 한글 단어나 훈으로 한자 입력하기, 그리고 T9 방식으로 영단어 입력하기 기능이 제공되고 있는데..

  • 변환에 쓰이지 않는 문자는 애초에 조합창에 들어가지 않고 바로 본문으로 삽입되게 인터페이스를 개선했다.
  • Ctrl 내지 Shift 클릭을 좀 다르게 인식하게 했다. T9 영단어 입력의 경우 마침표 and/or 공백을 뒤에 같이 삽입하게 했고, 한글-한자 변환의 경우 지금 외부 모듈이 지원하는 것처럼 "한자(漢字)" 내지 "漢字(한자)" 형태의 삽입이 되게 했다.
  • 여러 독음 후보들이 존재하는데 이들이 길이가 길고 앞부분이 상당수 일치한다면 명령 프롬프트나 개발툴 에디터에서 하는 것처럼 앞부분의 ‘자동 완성’이 되게 했다. 타이핑 수고를 상당 부분 덜 수 있을 것이다. 자동 완성 단축키는 tab 또는 Ctrl+space 중에서 선택 가능하다.

3. 편집기: 자잘한 개선

날개셋 편집기에서 파일을 읽고 쓰는 아주 기본적인 동작과 관련하여 다음과 같은 강화· 개선 작업이 이뤄졌다.

(1) 파일을 제대로 불러오지 못한 상태에서 저장을 시도하거나, 아까 전에 제대로 저장하지 못한 상태에서 창을 닫으려 하면 확인 질문을 하게 했다.
여기서 ‘제대로’ 열기나 저장을 못 한 상황이란.. 인코딩이 잘못 지정되어서 깨진 문자가 발생했고, 현재 메모리에 존재하는 문서와 파일 형태로 존재하는 문서 내용이 서로 일치하지 않는 것을 말한다. 그 상태로 저장을 하면 문서를 변경하지 않았더라도 원래 있던 정보는 소실될 것이고, 창을 닫으면 마찬가지로 깨진 문자가 원래 무엇이었는지 알 수 없게 될 것이다.

(2) 저장 옵션을 통해서 파일의 인코딩을 변경했다면 문서 내용을 대놓고 변경하지 않았더라도 창을 닫을 때 파일을 다시 저장할지 묻게 했다.

(3) 아울러, 문서창의 시스템 메뉴에 ‘파일 이름 변경’이라는 기능을 추가했다. 이걸 실행하면 ‘다른 이름으로 저장’과 비슷한 대화상자가 나타나며, 여기서 파일 이름을 새로 지정하면 문서창을 열어 놓은 상태에서 프로그램 상의 이름과 디스크 상의 이름을 그걸로 간단히 바꿀 수 있다. 탐색기에서 따로 이름을 바꾼 뒤에 다시 불러온다거나 하는 번거로운 수고를 하지 않아도 된다.

4. 외부 모듈: Chrome 브라우저에서 추가적인 보정

크롬 브라우저는 과거에 자신이 데스크톱 앱인데도 돌아가는 IME에다가는 자신이 메트로 앱이라고 잘못 알려주는 문제가 있었다. 그 버그는 얼마 안 가서 수정됐지만, 그 다음으로 또 약간 알쏭달쏭 아리까리하게 동작하는 게 있다(2020년 3월의 80 버전 기준).

마소 Edge와 Firefox는 TSF를 온전히 지원하는 브라우저이다. 그러나 IE와 Chrome은 그렇지 않다.
TSF를 지원하지 않는 프로그램에서는 앞뒤 글자를 요청한다거나 caret 이동 같은 지시를 내리면 어차피 실패한다. 내 프로그램은 실패에 대한 대비는 물론 돼 있다. 그리고 처음부터 앱을 가려가며 동작하는 게 아니라, 이런 실제 기능의 성공 여부를 토대로 동작한다.

그런데 크롬의 경우, 앱의 종류를 식별해 보면 "TSF 미지원"이라고 나오지만, 앞뒤 글자 요청이나 caret 이동 등의 지시를 내리면 마치 TSF 지원 프로그램처럼 수행되고 성공했다는 리턴값이 돌아온다. 하지만 그게 제대로 올바르게 correctly 수행되어 있지는 않다.

크롬에서 '대한민국' 같은 단어를 입력하고 단어 단위 한자 변환을 시도해 보면 마소 한글 IME는 안 되지만 날개셋은 된다. 하지만 변환을 해 봤자 '大韓民國'이 아니라 '대한민국大韓民國' 이런 식으로.. 정확하게 동작하지 않는다.
더구나 낱자 단위로 달라붙기 옵션을 사용하면서 bksp를 눌러 보면 caret이 앞 글자로 제대로 가지 않고 계속 자기 자리에서 머무른다.

여러 정황상 인접 글자의 fetch는 되지만 텍스트 selection을 변경하는 건 안 되는 것 같다.
결정적으로 크롬이 대외적으로 자신을 "TSF 미지원"이라고 보고를 하므로 날개셋 역시 크롬에 대해서 "오동작을 하느니 아예 동작을 안 하도록" 조치를 취하는 게 바람직해 보인다.

요 보정을.. "데스크톱 앱으로 인식"이라는 보정 옵션에다가 추가했다. 이 옵션이 켜져 있고 앱이 자신을 "TSF 미지원"이라고 표시한 경우, 내 프로그램은 텍스트 고급 조작 지시를 시도조차 하지 않고 방어적으로 동작하게 된다. "TSF 지원"이라는 명시적인 정보가 있을 때만 고급 조작을 하게 된다.

5. 도깨비 한글 글꼴

옛날 도스 시절의 한글 바이오스 유틸인 '한글 도깨비'의 최종 버전  5.1에서 제공되었던 고유한 둥글동글한 글꼴, 일명 '둥근도깨비'체가 날개셋 한글 입력기의 다음 버전에서 제공될 예정이다.
"둥근모, 한솔바탕, 도깨비고딕, 한메굵은본문"을 한데 섞은 듯한 인상이지만 어느 것에 딱 떨어지지 않는 변별성과 독창성이 있고, 모양이 상당히 예쁘기도 한 편이다.

사용자 삽입 이미지

내부 구조를 살펴보니 얘는 놀랍게도 일종의 완조형이었다.
'가'부터 '히'까지 받침이 없는 글자는 완성형으로 각각의 글자들이 일일이 그려져 있고, 받침이 붙었을 때의 '가'~'히'도 마찬가지이다. 그 뒤 받침은 ㅗㅛㅜㅠㅡ용 아니면 나머지.. 이렇게 두 벌만 있다. 이런 형태의 글꼴은 난생 처음 봤다.

이 글자들로부터 초성과 중성을 일일이 decompose한 뒤, 뭔가 반복· 규칙과 패턴을 찾아내어 3차원 조합 테이블을 복원하고 날개셋 편집기에서 읽을 수 있는 11172자 조합형 한글 글꼴로 얼추 재구성했다. 어렵지만 흥미진진한 작업이었다.

ㅏㅑㅓㅕ 같은 모음은 거의 판에 박은 듯이 똑같지만, ㅘㅙ 같은 복합 중성 및 이와 결합한 초성들은 자형이 의외로 제각각 임의로 그려져 있었다. 그래서 규칙을 찾기 어려웠다.
요런 모양의 글꼴을 이런 복잡한 완조형 말고 8*4*4벌로 간소화(?)된 형태로도 옛날에 봤던 것 같기도 한데 정확하게 기억은 안 난다.

도깨비 말고도 1990년대까지 도스 시절에 텍스트 모드에서 쓰였던 유명한 한글 바이오스 유틸로는 태백한글, 한메한글이 있다. 태백과 한메는 제품 이름 겸 개발사의 이름이기도 하지만, 도깨비의 경우 개발사가 '한도 컴퓨터'여서 제품명과 일치하지 않는다.

한글 도깨비의 개발자인 최 철룡 씨는 정말 대단한 분이었다. 1980년대에 IBM 호환 PC의 내부 구조를 모두 마스터하여 한글 바이오스를 만들었을 뿐만 아니라.. 사실은 안 철수와 거의 비슷하게 브레인 바이러스 백신까지 자작했었다. 처음에는 마이크로소프트웨어 잡지의 기자로 재직하다가 나중에는 성이 안 차서 자기 회사를 차리게 된다.
날개셋 한글 입력기는 아래아한글과 마소 도스/Windows뿐만 아니라 태백, 한메, 도깨비에서 제공하던 글꼴들도 한 종류 이상씩은 courtesy 차원에서 제공하고 있다.

6. 그 밖에

  • 프로그램 UI를 여러 군데 찔끔찔끔 수정했다. 기억에 남는 것으로는.. 이모지 문자표에다가도 우클릭 메뉴에 '복사'를 추가하고 전용 도움말을 넣었다.
  • 지난 8.8부터 9.0대 기간 동안 심혈을 기울여서 구현했던 '복합 낱자 입력 로직 생성기' 빠른설정이 언제부턴가 제대로 동작하지 않고 적용 후에 프로그램이 뻗던 문제를 뒤늦게 발견하여 고쳤다. 직전인 9.9보다 전부터 존재했던 문제로 보인다. 처음에 구현이 잘못된 건 아니고, 나중에 소스 코드를 리팩터링을 잘못 했기 때문이다.
  • 24픽셀(화면 확대 배율 150% 이상) 환경에서 날개셋 제어판을 꺼내서 ‘낱자 처리’ 탭에서 ‘낱자 코드 번호 병기’ 옵션을 켰는데.. 자그마한 낱자 번호가 초-중-종성별로 세로 위치가 차이가 나지 않고 언제나 같은 위치에 찍히던 문제를 뒤늦게 발견해서 고쳤다.
  • 이 외에도 그 밖에 24픽셀 비트맵 글꼴을 표시하는 목록에서 줄 간격을 1픽셀에서 2픽셀로 늘렸으며, U+200?대에 있는 특수한 공백과 줄표에 대한 글립도 16픽셀일 때와 마찬가지로 추가했다. 또한 외부 모듈에 24픽셀용 아이콘을 추가했다. 고해상도 24픽셀 환경에 대한 지원을 여러 방면에서 강화한 셈이다.
  • 외부 모듈의 ‘프로그램 호환성’ 탭에 현재 화면에 보이지 않는 몇몇 Metro 앱이 불필요하게 목록에 표시되어 있던 것을 감췄다. 그리고 ‘모두 원래대로’ 버튼의 원래 의도는 프로그램의 기본 보정 방식으로 되돌리는 것인데 그러지 않고 설정을 몽땅 삭제만 해 버리던 것을 고쳤다.
  • 정말 사소한 것이지만.. 立의 한자 훈이 '설 립'(stand 서다)이 아니라 '설사 립'(??!!!)으로 잘못 등록돼 있던 것을 고쳤다. 2020년 현재 마소 한글 IME의 한자 데이터에도 동일한 오류가 있으며, 그게 날개셋에도 그대로 전해진 것 같다.

이상이다. 이 정도면 9.9에서 0.1이 더해진 10.0에 딱 어울리는 수준의 변화로 손색이 없다고 여겨진다.

대략 9.x 초기 시절에.. Windows 10의 특정 버전 내지 특정 게임에서 한글 입력이 안 될 때 내 프로그램을 쓰면 된다는 소문이 퍼졌으며, 날개셋 한글 입력기의 다운로드 트래픽이 폭증하여 내 홈페이지가 며칠 연속으로 셧다운 됐던 적이 있었다.
그래서 한동안 다운로드 링크를 내 홈페이지 서버가 아닌 Google Drive 링크로 제공했는데.. 요즘은 그런 시절도 지났는지 구글 드라이브를 안 써도 트래픽 초과가 뜨지는 않는다.

요즘은 프로그램 관련 문의를 메일로만 받고 있지만 그래도 여러 사용자에게서 문의와 버그 의심 신고 연락이 종종 오곤 한다. 정말 꿈에도 상상할 수 없던 곳에서 내 프로그램을 잘 쓰고 있다는 연락을 받은 적도 있었다. 덕분에 이번 버전도 자잘한 개선 중에는 메일을 통해 접수된 사용자 피드백이 반영된 게 무척 많았다.

내 프로그램을 사용하면서 개인 메일까지 보내서 질문이나 건의를 남겨 주는 분들이 계시니 고마운 일이 아닐 수 없다. 어서 새 버전이 완성되어서 새 기능들이 두벌식과 세벌식 사용자에게 모두 큰 도움이 되었으면 좋겠다.

Posted by 사무엘

2020/04/04 08:35 2020/04/04 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1736

1. 날개셋 한글 입력기 9.9

이미 확인한 분도 계시겠지만 날개셋 한글 입력기의 차기 버전인 9.9가 지난주, 지난 1월 말에 완성되고 공개되었다.

버전 9.9와 10.0 중에서 고민하던 끝에 아쉽지만 9.9를 선택했다. 비록 9.8x 이후로 많은 작업이 진행되고 많은 것이 개선되긴 했지만 외형은 지난달에 올렸던 개발 근황 이후로 크게 달라진 게 없기 때문이다. 그래서 새 버전 소식도 이렇게 소박하게(?) 전하고자 한다.
9.9라는 숫자에는 본인의 그런 아쉬운 심정이 담겨 있다. 그래도 얘는 9.x대의 마지막 버전이며, 진짜 10.0이 한 3월 말쯤으로 계획돼 있다.

(1) 9.82에서 프로그램별 수동 보정 기능이 추가됐는데, 몇몇 사용자 분들에게서 온 피드백을 들어 보면 그게 실제로 도움이 된 듯하다. 그거 설정을 바꾸는 것으로 새로운 프로그램에서의 오동작을 해결했기 때문이다. (예: Visual Studio Code 에디터)

(2) 한편, 크롬 브라우저가 버전 78에서는 자신이 데스크톱 앱인데도 IME에다가는 메트로 앱이라고 알려주는 버그가 있어서 9.82 당시에는 이를 임의로 보정하는 설정이 들어갔었다. 하지만 지금의 79에서는 그게 고쳐졌기 때문에 날개셋에서도 보정 설정이 제거되었다. 하지만 보정을 하더라도 딱히 다른 문제나 부작용은 없다.

그러므로 현재로서는 본인이 아는 한도에서는 “강제로 데스크톱 앱으로 동작” 보정이 필요한 프로그램이 없다는 것을 도움말에도 언급해 놓았다. 그냥 미래에 또 이런 일이 발생할 수 있다는 걸 염두에 두고 보정 설정을 남겨 뒀다.

공식적으로 문서화되지 않은 변화 사항으로는 남은 메모리 양을 표시할 때 내가 직접 단위 계산을 하는 게 아니라 운영체제의 깔끔한 API를 쓰게 한 것, 변환기 대화상자가 프로그램을 실행시킨 쪽의 모니터에서 표시되게 한 것, 인코딩 목록에서 UTF-7은 이제 거의 쓰이지 않으니 맨 뒤로 밀어낸 것 등.. 아주 사소한 것 위주이다.

그런 것 말고 좀 유의미한 작업이 진행된 것도 있는데, “조합과 후보 자동 완성”과 “조합 안에 조합 생성” 입력 도구에서 각종 후보 목록은 백그라운드 스레드에서 생성될 수 있게 내부 공사를 진행해 놓았다. 전자는 타이핑에 랙을 야기하지 않으면서 목록이 다 완성되면 한꺼번에 짠 표시하는 것만 담당하지만, 후자는 마치 웹 페이지 로딩하듯이 일단 자그마한 목록부터 띄운 뒤에 후보를 여기저기 incremental하게 실시간으로 추가하는 것까지 가능하다. 다만, 이것도 이를 실제로 활용하는 기능이 아직 없기 때문에 존재감이 없다.

입력기에 적용된 사소한 개선 사항이 타자연습에도 같이 반영된 것이 있긴 하지만.. 너무 사소하고 자잘한 것이기 때문에 타자연습은 아직 정식으로 버전업을 하지 않았다. 이번 9.9는 타자연습 3.9와도 API가 호환되니 그대로 같이 사용 가능하다.

새 버전을 유용히 사용하시기 바란다. 페이스북 플러그인은 고장난 지 한참 됐기 때문에 프로그램 다운로드 페이지에서도 완전히 제거했다. 그래서 본인의 이메일 주소만 기재해 놓았다.

2. 레거시 프로젝트 파일 정리

새해 기념으로.. 날개셋 한글 입력기의 소스에서 구닥다리 구버전 Visual C++용 솔루션/프로젝트 파일들을 드디어 완전히 삭제했다. 이를테면 *.vcproj (200x용), 그리고 심지어 *.dsp/*.dsw (6!!) 말이다.

사실, 소스 코드에 C++11 문법을 도입하던 순간부터 내 프로젝트들은 VC++ 2010 이전 버전과 연을 완전히 끊은 거나 마찬가지였다.
그리고 VC++ 역시 딱 2010부터 지금과 같은 솔루션/프로젝트 파일과 버전 관리 체계가 정착했고, IDE와 컴파일러 툴킷, 플랫폼 SDK 계층이 깔끔하게 분리되기도 했다. 그러니 그 이전 버전은 이제 신경 쓸 필요가 없다.

본인의 개인적인 소신은 더 쓰이지 않는 파일이어도 요즘이 하드 공간이 부족한 시대도 아니고, "굳이 일부러 찾아서 지우는 수고까지 할 필요는 없다" 주의였다. 하지만, 그것들이 보는 사람을 괜히 헷갈리게 하고 무질서도를 높이는 부작용에 대해서는 지금까지 생각을 못 하고 있었다.

이건 물건 정리와도 비슷하다. 언젠가는 다시 쓸 일이 생길지도 모르는 물건이 분명 있겠지만.. 너님의 생활 습관상 그럴 일 없으니 좀 버려야 하는 물건도 있다.
비슷한 맥락에서.. 사용되지 않는 코드도 무작정 주석이나 #if 0 처리만 해서 누더기처럼 덕지덕지 남겨 두는 게 장땡이 아니다. 재사용할 가능성이 정말 희박하고 남 보기에 정신 사납게 하는 역효과가 더 큰 것들은 그냥 완전히 지워 없애 버리는 미덕을 발휘하는 것도 필요해 보인다. 그 '정도'와 경계는 개인 취향에 달린 문제이겠지만 말이다..

아울러, 소스 코드들이 DB 데이터라면, 이들을 빌드하는 방식을 명시하는(각종 컴파일러· 링커 옵션들) 프로젝트 및 복잡한 빌드 스크립트는 DB 스키마 또는 아주 복잡한 쿼리와 비슷한 물건일 것이다. 이것도 날렸다가 다시 구성하는 건 소스 코드 자체를 날리는 것 만만찮게 골치아픈 일이 될 것이다.

3. 3D 그래픽 시연 프로그램

끝으로.. 최근에 이걸 만들어 봤다.
3D 컴퓨터그래픽을 공부하는 사람이라면 모를 수가 없는 그 유명한 '유타 주전자'를 3차원 그래픽 시연 프로그램의 예제 데이터로 추가했다. 이게 지난 10여 년 동안 제공되지 않고 있었다니.. 송구스럽기가 이루 말할 수 없을 지경이다.

이 주전자를 구성하는 3D 좌표 데이터야 이미 대외적으로 널리 공개돼 있다. 하지만 이걸 3차원 그래픽 시연 프로그램이 곧장 읽을 수 있는 무식한 직선의 나열로 변환하려면 베지어 곡선을 넘어 베지어 곡면이라는 것을 적당히 근사해서 와이어프레임 형태로 표현할 수 있어야 한다.

3차 베지어 곡선이 4개의 점(시작점 + 끝점 + 제어점 2개)으로 구성되고 t=0..1 사이의 인자를 받는 매개변수 함수로 표현된다면..
3차 베지어 곡면은 그런 베지어 곡선을 4개나 모아서 평면을 이루며, 0..1 사이의 인자 매개변수도 하나가 아니라 2차원답게 둘을 받는다.

전자가 함수값을 구하기 위해 계수와 제어점 사이의 곱셈과 덧셈을 4회 수행한다면, 후자는 그 제곱인 16회나 수행한다. 아니, 각각의 항 자체도 계수*제어점이 아니라 계수x*계수y*제어점으로 곱셈의 횟수가 더 많다. 계산량이 정말 장난이 아니더라.

이 세상의 많고 많은 글꼴들이 모두 베지어 곡선으로 표현되듯, 자동차나 비행기처럼 인간이 디자인한 기계류의 그 '유체역학적인' 부드러운 곡면도 다 이 공식을 이용해서 기술된다. 옛날에 베지어 곡선이라는 걸 고안한 사람인 '피에르 베지어'가 직업이 무엇이었는지를 생각해 보면 답이 명확해진다.

암호 같은 베지어 곡면을 인터넷을 통해 알게 된 공식대로 직선들로 쫙 풀어서 표현해 주니.. 내 프로그램에서 '유타 주전자'의 와이어프레임이 거짓말처럼 짠 나타났다. 정말 신기했다.
이런 유형의 계산은 양만 많지 패턴이 워낙 규칙적이니, 캐시 적중률 높고 병렬화에도 유리하다. GPU가 괜히 진작부터 만들어져 쓰인 게 아닐 것이다.

일반적인 3D 그래픽 렌더러라면 내 프로그램처럼 가냘픈 선이 아니라 폴리곤을 기본 단위로 취급할 것이고, 와이어프레임조차도 폴리곤을 기반으로 렌더링 방식만 변경해서 표시하는 것일 테니 삼각형 단위로 선들이 더 조밀하게 나타날 것이다. 하지만 내 프로그램은 그냥 베지어 평면의 각 격자 단위로만 선을 그었기 때문에 기본 단위가 사각형 형태로 나타난다.

정말 신기하게도.. 이 유타 주전자 데이터를 구성하는 선의 개수와,
기존 예제 중에서 원형 튜브(Torus)의 선의 개수가 서로 정확하게 일치한다. 2304개이다.
둘은 내부 구조나 데이터 생성 방식이 서로 완전히 다르고 관련이 없는데도 말이다.

Posted by 사무엘

2020/02/02 19:33 2020/02/02 19:33
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1712

다음 버전 개발 근황

날개셋 한글 입력기 최신 버전이 나온 지가 또 벌써 두 달이 돼 가는데.. 현재는 9.9 내지 10.0이 개발 중이다.
현재의 최신 버전인 9.82에서는 이 버전만의 고유한 버그가 발견된 것은 현재까지 없다. 그럭저럭 잘 만들어진 것 같다. 그 대신 오래된 버그가 발견된 게 여럿 있어서 개발 중 버전에서 이들을 잡는 중이다.

1. 각종 UI에 표시되는 글자들의 크기 체계화

날개셋 한글 입력기에는 한자 후보 선택 UI라든가 각종 입력 도구들처럼(화면 키보드, 문자표 등) 글자를 일반 비트맵 글꼴이나 표준 UI 폰트(굴림/맑은 고딕 9)보다 약간 더 크게 찍는 곳이 여러 군데 있다.
내가 날개셋 버전 10이 임박한 시기에 이 부분을 건드리게 될 줄은 전혀 생각을 안 하고 있었으나.. 갑자기 필이 꽃히면서 다음과 같이 대대적으로 수술을 했다.

(1) 첫째, 그런 글자들을 대 아니면 소라는 두 그룹으로 나누고, 반드시 그 둘 중 하나에 소속된 통일된 크기로 표시되게 했다.
큰 글자는 버튼이나 정사각형 셀 하나에 글자 하나가 큼직하게 표시되는 상황으로, 문자표, 부수 한자 입력, 이모지 등이 해당된다.
작은 글자는 외부 모듈이나 입력 패드의 한자 선택 UI, 그리고 '조합 자동 완성', '조합 안에 조합 생성' 입력 도구가 해당된다.

(2) 날개셋 제어판의 시스템 계층에다가 이 두 그룹의 실제 크기를 사용자 정의할 수 있게 했다.
단위는 운영체제 표준 UI 폰트의 크기(100%)에 비례하는 백분율이며, 기본값은 '대'는 200%, '소'는 134%이다. 100%보다 더 작은 값을 줄 수는 없고, 최대 500%까지 줄 수 있다.

외부 모듈의 한자 후보 선택 목록에 글자가 너무 작으니 좀 키워 달라는 요청이 지금까지 몇 건 접수된 게 있다. 겨우 그 기능만을 위한 UI를 구현하는 것은 번거로워서 반영되지 못하고 있었는데 이 큰 작업을 하면서 저것도 이제 덩달아 가능해졌다. '작은 크기'를 150%~200%대로 키우면 된다.

그 반면, '큰 크기'를 200%보다 더 키우면 화면 키보드, 한손 입력기, 12키 입력기 등 비슷한 크기의 글자를 사용하는 입력 도구들의 덩치도 한꺼번에 키울 수 있다. 단, 이미 화면에 띄워진 도구는 말고, 다음에 새로 생성되는 도구부터 말이다.

(3) 맑은 고딕은 구닥다리 바탕· 굴림 같은 글꼴과 달리 글자의 종횡비가 정확한 1:1 정사각형이 아니며, 자체적으로 줄 간격 여백이 크게 잡혀 있기도 한 글꼴이다. 그래서 바탕· 굴림을 지정하던 곳에다가 맑은 고딕을 지정하면 글자가 너무 작게 찍히는 문제가 여러 곳에서 있었다.
이번에 그 문제도 완전히 해결했다. 크기가 동일한 값으로 주면 바탕· 굴림이건 맑은 고딕이건 상대적인 크기가 비슷하게 지정되며, 단지 맑은 고딕은 줄 간격만 더 길게 벌어지게 했다.

글자 크기를 지정하는 제어판 UI는 이렇게 구현되었다.
이전에 글꼴을 선택하는 옵션이 있었으니 거기에다가 크기를 지정하는 옵션도 한 그룹으로 엮어서 같이 넣는 것이 자연스럽다.

사용자 삽입 이미지

UI를 어떤 형태로 만들지 결정하기가 어려워서 고민을 많이 했다.
시스템 계층 탭은 안 그래도 공간이 비좁아져 있는데, 글꼴이니 키보드 드라이버니 입력 도구니 하는 것들은 서로 관련이 전혀 없고 따로 노는 아이템들이다.

더구나 글꼴의 종류에 이어 크기를 지정하는 옵션이 들어갔다면 이제는 미리보기(preview) 창도 슬슬 만들어야 할 때가 됐다. 하지만 지금 저 탭에 미리보기 창을 넣을 공간 따위는 전혀 없다.
상황이 답이 없는 지경으로 흘러가니, 이제 글꼴과 관련된 옵션들은 별도의 탭으로 분리라도 해야 하나 싶었다. 하지만 그건 너무 번거로우며 들인 노력 대비 결과가 좋지는 않아 보인다.

최종적으로는 보다시피 '미리보기'라는 링크를 넣고, 사용자가 이걸 클릭하면 아래에 "입력 도구 자동 구동 목록"이 있던 영역이 글꼴 미리보기 창으로 바뀌게 했다. 미리보기 창의 디폴트 크기도 저 정도가 딱 적당하고.. 이게 여러 모로 최선의 선택인 것 같다.

2. 후보 UI에 표시되는 글자의 폰트 체계화

날개셋 한글 입력기의 모든 구현체(편집기, 외부 모듈, 입력 패드)에는 한자 변환 후보를 표시하고 선택받는 UI가 있다. 별도의 옵션이 없으면 그냥 운영체제의 기본 글꼴로 글자를 표시하지만, 특정 글꼴을 써서 표시하라고 사용자가 지정도 할 수 있다.
다음 버전에서는 이 글자의 크기뿐만 아니라 글꼴과 관련해서도 다음과 같은 변화가 생길 예정이다.

(1) 정규 후보 변환 UI뿐만 아니라 “조합과 후보 자동 완성”, “조합 안에 조합 생성” 입력 도구도 후보 목록을 출력하는 부분에서는 저 글꼴 설정이 반영되게 했다.

(2) 그리고 저 글꼴 설정과는 완전히 별개로, 코드값이 특정 영역에 드는 문자는 무조건 이 글꼴로 출력하게 하는 일명 fallback 글꼴 조건을 추가로 지정 가능하게 했다. 그 조건은 별도의 텍스트 파일로부터 읽어들인다.

2번이 아주 참신한 기능이다.
지금 사용 중인 운영체제보다 시기적으로 유니코드에 더 늦게 찔끔 추가된 문자는 그 운영체제에서 글꼴을 제대로 잡아 주지 못한다. 가령, 일본의 새로운 레이와 연호 마크(U+32FF) 같은 것 말이다. 10여 년 전에는 ‘우편번호’ 마크, 20여 년 전에는 유로화 마크도 그런 부류에 속했다.

그리고 아예 대놓고 특정 custom 글꼴을 써야만 제대로 표시되는 사용자 정의 영역 문자도 있다.
그런 것들은 글꼴 설정과는 별개로 무조건 이런 전용 글꼴을 써서 출력하라고 수동으로 고정해 놓는 게 좋을 것이다.

이건 사용자가 막 자주 사용할 만한 옵션은 아니지만, 특수한 상황에서 굉장히 유용하게 쓰일 수도 있어 보인다.
새굴림 같은 옛날 글꼴이 있다면 한양 PUA에 있던 구결을 그 글꼴을 써서 출력하라는 지시를 예제 차원에서 남겨 두었다.

3. 휴대전화 입력기

휴대전화 입력기가 제공하는 4가지 모드 중, 영문과 기호 모드에서는 한 버튼에 3개의 문자가 배당돼 있다. 그리고 이들 중 하나를 버튼을 연타해서 골라서 입력하게 돼 있다.
그런데 이 방식은 동일한 글자를 연달아 입력하거나 같은 버튼 그룹에 속한 문자를 이어서 입력하기가 불편하다. 매번 SEP 버튼을 누르는 식으로 조합을 끊어야 하기 때문이다.

이 불편을 덜기 위해 이번 버전에서는 다음 두 방법이 추가되었다. 우클릭 메뉴를 통해 편한 것을 선택하면 된다.

  • 타이머: 버튼을 누르고 나서 0.5초 정도 반응이 없으면 조합이 자동으로 종료된다.
  • 길게 누름: 버튼 자체를 0.5초 정도 길게 누르면 이 글자는 다음 글자로 넘어간 상태로 삽입된다.

'길게 누름'은 한글· 영문 같은 모드에서 해당 버튼에 해당하는 숫자를 입력하는 용도로도 쓰이는 편인데, 기왕 '길게 누름'을 인식하는 김에 저렇게 동작하는 옵션도 같이 추가되었다.

4. cursor가 가리키는 글자를 표시하기

날개셋 한글 입력기가 제공하는 입력 도구들 중 "문자표, 부수로 한자 입력, 이모지 문자표" 이 셋은 고정된 테이블을 기반으로 문자를 입력하는 대표적인 도구이다.
그런데 새 버전에서는 이들에게 문자를 입력하는 기능뿐만 아니라, 역으로 cursor가 가리키는 문자를 자기 문자표에서 찾아서 표시해 주는 기능도 동시에 추가될 예정이다.

각 입력 도구들은 우측 상단에 ↔ 화살표가 그려진 자그마한 버튼이 추가되었으며, 이를 누르면 cursor 뒤에 있는 글자를 찾아서 표시하게 된다. 즉, "가|" 가 아니라 "|가"일 때 '가'에 대한 정보가 나타난다. 해당 입력 도구의 테이블에 존재하지 않는 문자이면 아무 일도 일어나지 않거나 짤막한 비프음이 난다.

이 기능을 '부수로 한자 입력'에서 사용하면 낯선 한자의 부수와 획수가 무엇인지를 곧장 확인할 수 있어서 좋다. 이모지 같은 다 문자표와도 연계하면 이 문자와 관련된 주변 다른 문자들을 곧장 조회할 수 있다.
물론 이 기능은 날개셋 편집기 내지, 외부 모듈의 경우 TSF를 지원하는 프로그램에서만 사용 가능하다. 실제로 글쇠 입력을 받는 문자 생성기 말고, 입력 도구가 문자를 밖에서 보내기만 하는 게 아니라 바깥 문자를 역으로 얻어 오는 동작이 구현된 것은 이번이 처음이다.

5. 기타 자잘한 개선

(1) 날개셋 한글 입력기의 GUI 중에는 편집기의 글꼴 목록이나, 제어판 시스템 계층의 외부 모듈 목록처럼 백그라운드 스레드를 사용해서 내용을 표시하는 것이 좀 있다. 그런데 스레드의 준비 작업이 다 끝나지 않았을 때 ESC를 눌러서 해당 대화상자를 잽싸게 닫으면 응답이 몇 초 내지 무기한 멎어 버리는 문제가 있었다. 이 오랜 지병을 이번에 완전히 해결했다.

(2) TSF를 지원하지 않는 프로그램에서 구현 가능하지 않은 특수글쇠(앞 글자 조합 상태, 특정 낱자를 앞으로 보내기 따위)를 눌렀을 때 프로그램이 얼어붙는 문제도 해결했다.
사실 이 문제 자체는 5년도 더 전 7.7 버전에서 해결되었지만, 훗날 9.8에서 크롬 브라우저 버그를 해결하기 위해 새로 만들어진 보정 로직에서 동일 문제가 재발하게 되었다.

(3) 최신 아래아한글의 글쇠배열 편집기에서 저장한 ukl 파일도 날개셋 제어판에서 읽을 수 있게 내 프로그램의 변환기 로직을 수정했다.
아래아한글에 지금과 같은 형태의 글쇠배열 편집기가 도입된 건 먼 옛날 2004부터인데, 그때는 파일 포맷 시그니처가 1.0이었다. 그게 어느 샌가 2.0으로 바뀌었기 때문에 내 프로그램에서 인식되지 않았다.
하지만 확인해 보니, 시그니처만 그렇게 살짝 바뀌었지 파일 내부 구조는 바뀐 게 사실상 없었다. 그래서 안심하고 시그니처를 인식하는 부분만 수정했다.

아래아한글의 글쇠배열 편집 기능은 customize 범위가 매우 제한적인 건 그렇다 치더라도.. UI도 왜 이렇게 만들었을까 고개를 갸우뚱하게 만드는 게 좀 있다. 글쇠배열의 이름을 지정하는 게 편집 화면이나 별도 UI로 있는 게 아니라 저장 대화상자에서 하게 돼 있고..;;
Shift 윗글쇠 부분을 편집하는 것도 마우스나 메뉴를 통해 가능하지 않고 키보드 space를 눌러야 한다고 도움말을 직접 참고하지 않으면 알 수 없다. 차라리 저 shift 그림을 클릭해서 전환이 가능하다면 훨씬 더 직관적일 텐데..

(4) 그리고 날개셋 제어판의 글쇠배열, 입력 유형(ist)을 열었는데.. 자체 고유 포맷 말고 내부적으로 변환을 거치는 파일을 가져왔을 때는.. 나중에 열기 대화상자를 눌렀을 때 이전 파일의 위치가 기억되지 않는 사소한 문제가 있었다.
여러 파일을 하나씩 연달아 살펴볼 때 불편할 수 있는 문제이기 때문에 수정했다.

(5) MS Word에서 문자표 계열 입력 도구와 '조합과 후보 자동 완성' 도구로 문자 입력이 가끔 제대로 되지 않던 문제를 해결했다. 얘만 좀 특이하게 동작하는 게 있어서 그랬다.

여기에다가 입력 도구와 관련, 그리고 세벌식 동시치기 관련 기능 강화 작업까지 마무리 되면 날개셋 한글 입력기는 9.9를 넘어서 10.0에 무난히 진입할 수 있을 것으로 보인다.

Posted by 사무엘

2019/12/15 08:34 2019/12/15 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1694

한글 IME 개발 관련 에피소드

1. 크롬 브라우저

Google 크롬 브라우저는 뭔 바람이 들어서 디자인이 갑자기 동글동글하게 바뀌었나 모르겠다. 탭과 각종 버튼들, 주소 입력란의 테두리가 말이다. 본인이 변화를 감지한 건 대략 버전 69(작년 9월쯤)부터이니 벌써 1년 남짓 됐다. 탭 모양이 저렇게 바뀌니까 크롬이 아니라 다른 브라우저를 쓰는 것 같다.

혹시 기억하는 분이 계시려나 모르겠는데, 크롬은 원래는 탭이 각진 사다리꼴 모양이었다.
Edge도 탭의 테두리가 그냥 직사각형 모양이다가 차기 베타 버전은 약간 둥글어져서 "edge"가 좀 무뎌졌다. 그에 반해 FireFox는 직사각형을 고수하고 있는 것 같다. 아무튼..

크롬은 그렇게 외형이나 HTML 파싱 및 렌더링 엔진, JavaScript 엔진이나 개선하면 될 것을.. 한중일 문자 입력을 받아들이는 IME 계층까지 지난 1년간 왜 이렇게 널뛰기 하듯이 바뀌는지 모르겠다. 나의 오랜 소감을 말하자면, 크롬은 IME 지원이 파이어폭스보다 더 열악하고 버그가 더 많으며 더 불안정하다. 현재 Firefox는 TSF도 완전히 지원하지만 크롬은 여전히 그렇지 않다.

(1) 크롬 버전 71(작년 12월 중반)쯤에는.. 주소창에서 바로 한글 검색어를 입력하기 위해서 네이버나 위키 등의 주소를 자동 완성한 뒤 바로 탭을 눌렀는데, 한글 첫 타는 조합이 끊기는 현상이 발생했던 적이 있다. 'ㅎㅏㄴ글' 이렇게 말이다.
MS, 날개셋 모두 동일하게 발생하기 때문에 외부 모듈 쪽 문제가 아니다. 단, 이건 버전 73쯤부터 해결된 듯하다.

(2) 저거보다 더 오래되고 심각한 문제로.. 크롬은 대략 2016~17년이니 굉장히 오래 전부터(50대 버전), 주소창에서 한글을 조합하는 중에('고') 마우스로 주소창 딴 곳을 클릭해서 조합을 끊으면.. 내부적으로 조합 종료가 제대로 처리되지 않아서 조합이 덧나는 버그가 있었다. 새로 cursor 위치가 바뀐 곳에서도 기존 한글 조합이 계속되었다. ('ㅏ' 대신에 '과'로..)

날개셋만 그런지 MS IME도 그런지는 기억이 안 난다만.. 오래 전부터 알려진 문제였기 때문에 내 프로그램의 도움말에다가도 이 현상을 언급해 놓았다.
고급 옵션에서 "하드웨어 가속 기능 사용"을 켰을 때만 발생하는 문제라는 것도 굉장히 괴이한 점이었다. 그래픽에서의 하드웨어 가속이랑 IME의 동작이 도대체 무슨 상관이 있단 말인가?

그랬는데 버전 74쯤에서는 다행히도 이 문제가 '사라졌다.' 역시 크롬에서 자체적으로 이 버그를 수정한 것이었다. 모든 일이 해피엔딩으로 끝나는 듯했다.

(3) 허나, 올해 상반기 크롬 75쯤부터는 상황이 최악으로 나빠졌다.
고쳐진 듯하던 '고과' 문제가 재발했으며, 한글을 입력하던 중에 비한글 문자를 입력하다 보면 프로그램이 그냥 뻗고 꺼져 버렸다. 도대체 뭘 건드렸길래.. >_<

크롬 카나리아 77의 경우, 한글을 조합하던 중에 마우스로 딴 델 찍으면 조합 상태는 초기화되지만 그 조합 문자열이 두 번 덧나곤 했다. '가가'가 되었다. 그러면서 프로그램을 쓰다 보면 뻗는 건 동일했다.
그래도 어쩌겠나. 크롬은 그야말로 세계구 급인 프로그램인데 내 입력기가 크롬의 동작에 맞춰야지.. >_<

덕분에 날개셋 한글 입력기 9.8은 크롬에서 최소한 프로그램이 뻗지는 않게 개선되었다. 그리고 사실은, 이걸 작업하면서 Firefox에서 자잘하게 오동작하던 문제, IE + 키보드 보안 ActiveX이 돌아가는 모 사이트에서 내 입력기가 뻗던 문제까지 덤으로 해결됐다. 그러니 내 프로그램도 일말의 개선의 여지가 있긴 했던 모양이다.

(4) 크롬이 같은 75.x 버전대에서 또 잠수함 패치된 뒤부터는.. '고과' 문제는 없어졌으나, 한글 조합 중에 Alt+D나 마우스 클릭 같은 행동을 하면 카나리아 77처럼 '가가'로 덧나는 문제가 발생하기 시작했다. 크롬 본버전과 크롬 카나리아의 동작이 동일해진 것이다.
날개셋 9.8은 뻗는 문제까지만 해결됐지 '가가' 문제는 여전히 갖고 있다. 이건 지난 9.81버전에서야 추가로 조치가 취해졌다.

세상에 같은 조작 요청을 했는데 굳이 저렇게 이상하게 동작하는 프로그램은 난 지금까지 크롬밖에 못 봤다. 크롬 최신 버전은 조합이 외부에 의해 종료됐을 때 그때 IME에서 조합 문자열을 딴 걸로 변경하면 정신을 못 차리는 것 같았다.

그게 지금의 78 버전에까지 이어지고 있고, 78은 바로 지난번에도 언급했듯이 갑자기 겉으로 메트로 앱인 것처럼 동작하는 것 같다. 내부는 딱히 달라지지 않았는데도 말이다. 뭐가 자꾸 많이 바뀌는 중이다.

2. MS Word에서의 겹침 모드 지원

운영체제의 GUI에서 제공하는 기본적인 텍스트 입력란(컨트롤? 위젯?)은 대개 삽입 모드만 존재한다. 그러나 본격적인 텍스트 에디터나 워드 프로세서들은 ins 키를 이용해서 겹침 모드라는 것도 같이 제공하곤 한다.

일반적인 영문 입력에서야 겹침 모드를 구현하는 건 일도 아니며, 한글 입력 정도만 돼도 반드시 1글자씩만 조합했다가 덮어써지는 것이 명확하기 때문에 일이 그리 어렵지 않다.
특히 Windows에 문자 입력 프로토콜이 재래식 IME밖에 없던 시절에는 텍스트 입력란을 제공하는 응용 프로그램이 겹침 모드를 그리 어렵지 않게 재량껏 구현할 수 있었다. IME는 확정된 형태의 문자열과 조합 형태 문자열을 알려 주기만 하지, 이걸 본문에 삽입하는 건 응용 프로그램의 재량이었기 때문이다.

물론 중국어· 일본어 IME는 임의의 길이의 문장을 조합으로 잡아서 한꺼번에 내보낼 수 있기 때문에 겹침 모드라는 게 사실상 별 의미가 없다. 그렇다면 그냥 1~2글자씩만 주고 받을 때나 한국어 IME일 때만 겹침 모드를 지원하는 식으로 프로그램이 동작하면 됐다.

그런데 TSF라는 새로운 프로토콜이 도입되면서 상황이 다소 복잡해졌다.
TSF는 cursor 위치를 옮기고 거기에 무슨 텍스트가 있는지 얻어 오고, 텍스트의 일부 구간을 블록을 잡고 거기를 새로운 내용으로 대체하는 등.. 삽입/겹침이라는 모드별로 행해지는 동작을 저수준으로 직접 기술을 할 수 있다. (비록 모든 프로그램에서 이 정도로 자유로운 조작이 가능한 건 아니지만)

그렇기 때문에 이 체계에서는 겹침 모드에 따른 동작을 응용 프로그램이 아니라 해당 외부 모듈이 달리 처리하는 게 바람직하다. 텍스트 에디터의 삽입/겹침 상태가 TSF compartment 값으로 주어지기 때문에 외부 모듈은 이 값을 참고할 수 있고 말이다. 하지만 마소에서 프로그램을 그런 식으로 개발하지는 않은 것 같다.

MS Word의 경우, 먼 옛날 97~2000까지는 내 기억이 맞다면 IME 기반으로 그냥 trivial한 방법으로 겹침 모드를 제공했었다. 한글 입력에 대해서도 겹침 모드가 없지는 않았다.
그러다가 TSF로 바뀐 XP부터는 한글에 대해 겹침 모드가 사라졌다. 2003에서는 "한글 입력에 대해서는 겹침 모드가 지원되지 않습니다"라고 에러 메시지도 나타났다.

사용자 삽입 이미지

그랬는데 2007인가 2010에서는 TSF 기반으로도 한글 겹침 모드가 잠시 구현되었다. 외부 모듈이 아닌 Word에서 자체적으로 말이다.
아마 외부 모듈이 요청하는 문자 삽입 요청을 재구성하여, 요런 패턴을 만족하는 것은 진짜 삽입이 아니라 뒷글자를 대체하는 식으로 동작하게 인위적인 보정을 했던 것 같다.

게다가 이건 특정 외부 모듈, 아니 특정 패턴을 대상으로만 불완전하게 동작했다. 똑같이 한글을 삽입하고 한글 다음에 비한글 문자를 집어넣는데, 같은 마소 IME에서만 겹침 모드가 동작하고, 날개셋이나 한컴 IME 같은 3rd-party IME에서는 동작하지 않았다.
겹침 모드로 인식되게 하는 패턴을 개인적으로는 찾아내어 파악했다. 하지만 당장 날개셋 외부 모듈의 동작을 그렇게 고칠 수는 없다. 수많은 다른 부작용에 대한 우려 때문이다.

그리고 결정적으로는..
최근에 MS Office의 기간제 구독형 에디션인 365를 설치해 봤는데.. Word에서 겹침 모드로 지정해도 이제는 마소 기본 IME도 겹침 모드가 전혀 인식되지 않고 언제나 삽입 형태로만 동작했다. 몇 번이나 확인해 봐도 그렇다. 설마 365랑 정규 에디션인 201x가 동작이 서로 다를 리는 없을 테고..

겹침 모드를 저렇게 무리수로 구현하는 건 영 아니다 싶어서 도로 뺀 것 같다. 본가인 마소에서 포기했으니 날개셋 역시 겹침 모드에 대해서는 전혀 신경 쓸 필요가 없어졌다.
이야기가 좀 찝찝하게 끝난 것 같은데.. 다시 말하지만 내 생각은 TSF 환경에서는 삽입/겹침을 각 외부 모듈이 알아서 처리하는 형태가 됐으면 좋겠다. 날개셋 한글 입력기의 엔진은 그걸 가정하고 개발되었기 때문이다. 지금 텍스트 입력 모드가 겹침 모드라는 것을 알 수 있다면 당장 그렇게 동작할 수 있다.

날개셋 외부 모듈은 처음에는 언제나 겹침 옵션이 꺼져 있고 삽입 모드로만 동작한다. 날개셋 편집기를 쓸 때처럼 ins 키가 지원되지는 않으니 날개셋 제어판을 열어서 '겹침 모드' 옵션을 수동으로 골라 줘야 한다. 그리고 이 옵션은 TSF를 지원하는 프로그램에서만 사용 가능하다.

Posted by 사무엘

2019/10/30 08:32 2019/10/30 08:32
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1678

날개셋 한글 입력기 9.82

날개셋 한글 입력기 9.82가 어제, 9.81 이후 딱 두 달 만에 완성되어 나왔다. 딱히 원조가카의 서거 40주년에 맞춘 것은 아니다. 24일이나 25일에 완성을 못 했기 때문에 26일에 완성하게 됐을 뿐이다.

원래 생각 같아서는 아예 이 달 초 한글날쯤에 공개하고 싶었다. 그러나 답이 없는 지독한 버그(알고 나면 별것 아니지만..)와 컨디션 조절 실패 때문에 일정이 늘어져서 그보다 훨씬 더 늦게 나오게 됐다.

이번 버전은 눈에 띄는 기능 추가가 아니라 개선과 버그 수정 위주이다. 그러니 버전 번호도 0.01만치만 증가했다. 그리고 타자연습은 변화가 없으며, API 호환성도 달라지지 않았다.
그럼에도 불구하고 이번 9.82는 유의미한 변화를 열거하라면 꽤 많다. 특히 외부 모듈 내지 입력 도구 UI와 관련된 것이 많다.

1. 한자 변환 UI 관련

(1) 바로 직전 버전인 9.81부터는 MS Word의 우클릭 메뉴를 통해서 단어 단위로 한자 변환을 할 수 있게 되었다. 그런데 한자를 고르지 않고 ESC를 눌렀을 때 블록으로 잡힌 단어가 사라지는 문제를 비롯해 몇몇 사소한 glitch들이 있던 것을 바로잡았다. 오랫동안 본인의 심기를 건드려 온 찝찝한 문제였는데 드디어 해결되어 기쁘다.
또한, 단어의 앞부분 일부만 한자로 바꾼 뒤에 cursor가 다시 원래 있던 뒷부분으로 되돌아오는 것도 날개셋 편집기 내지 MS IME와 동일하게 처리되게 했다.

(2) 한자 변환 UI의 선택막대를 더 큼직하게 키웠다. 특히 간격이 하드코딩된 픽셀수로 지정되어 있어서 화면 DPI가 올라갈수록 실질적인 간격이 말도 안 되게 좁아지던 문제를 해결했다. 이제 high DPI 환경에서도 한자 변환 기능을 사용하기가 더 수월할 것이다.
아래 그림은 각각 100%와 150%배율에서 before와 after 모습이다.

사용자 삽입 이미지

(3) 그리고 키 동작 방식을 MS IME의 UI와 더 일치하도록 바꿨다.
가령, space로도 항목을 이동할 수 있으며, 화살표 키로 선택막대가 페이지의 시작이나 끝에 도달한 뒤에는 다시 끝이나 시작 지점으로 순환되게 했다. 또한, page up/down을 눌렀을 때는 선택막대가 해당 페이지의 맨 처음 지점에 가게 했다.

(4) 끝으로, 아까 저 한자 변환 UI 그림에서 '기사'의 위치를 보면 유추할 수 있듯, cursor의 아래에 나타나는 모든 UI들이(입력 도구).. 창 테두리가 아니라 창 내부 글자가 cursor의 바로 아래에 나타나도록 표시 위치를 조정했다. 아래 그림에서 위는 before이고, 아래는 after이다.

사용자 삽입 이미지

또한, 목록에도 불필요하게 여백이나 스크롤 영역이 생기지 않도록 초기의 창의 크기가 더 정확하게 계산되게 했다. 그 차이도 위의 그림에서 이미 묘사되어 있다.
옛날에는 이런 게 왜 눈에 들어오지 않았던가 모르겠다.

2. 엑셀에서 입력 도구의 특이한 오동작

날개셋 한글 입력기가 제공하는 입력 도구 중에는 GUI 요소에 콤보 상자가 들어있는 것이 있다.
'부수로 한자 입력'에서 부수의 획수를 고르는 UI, 그리고 '문자표'의 위쪽에서 글꼴과 문자표 종류를 고르는 UI 말이다.

사용자 삽입 이미지

그런데 MS Excel에서 날개셋 외부 모듈을 구동한 뒤, 여기서 저런 입력 도구의 콤보 상자를 눌러서 열고 나면 몇 초 못 가, 혹은 심지어 마우스 포인터를 살짝 움직이기만 해도 열었던 콤보 목록이 저절로 닫혀 버리곤 한다. 그래서 글꼴이나 획수 같은 걸 제대로 선택할 수 없다.
이건 다른 프로그램들은 괜찮고 오로지 엑셀에서만 발생하는 문제이다. MS Word에 black blank 문제가 있는 것처럼 Excel도 특이한 동작 방식이 존재하는 셈이다.

이것 때문에 본인은 며칠을 끙끙대며 헤맸으며, 그 과정에서 입력 도구 UI 엔진의 여러 미세한 버그들, 불필요한 코드 따위를 제거하는 부수적인 효과를 내긴 했다. 그러나 이 문제는 근본적으로는 엑셀이 굉장히 특이하게 동작하면서 날개셋 한글 입력기의 동작까지도 교란하기 때문에 발생한다.

심지어 마우스 휠을 굴렸을 때의 반응도 다르더라.
요즘 Windows에서는 입력 도구에서 마우스 휠을 굴리면 그게 입력 도구로 가는 반면, 엑셀에서만은 여전히 이전 버전 Windows처럼 휠 이벤트가 엑셀 창으로 간다.
내 추측으로는 쟤들도 마우스 관련 훅킹이라도 해서 마우스 포커스를 가로채는 것 같다.

엑셀에서 콤보 목록이 닫히는 문제는 엑셀의 버전에 따라 양상이 둘로 나뉜다.
첫째, 2007 초창기 버전과 그 이하의 구버전에서는 그냥 콤보 상자를 누르고 가만히만 있어도 몇 초 후에 목록이 닫힌다. 이건 근본적인 해결이 불가능하며, 저 예외적인 상황만 감지해서 어거지로 보정하는 것도 가능하지 않다.

둘째, 2007 SP3쯤과 2010 등 이후 버전에서는 콤보 목록을 연 뒤 마우스 포인터를 살짝 움직이면 목록이 닫힌다. 이건 다행히 내 프로그램에서 동작을 변경함으로써 해결 가능한 것을 확인했으며, 이번 9.82 버전에서 반영됐다. 최신 버전에서 해결 가능한 문제이니 이 문제는 사실상 해결된 것이나 마찬가지이다.

그리고 정사각형 문자표가 있는 입력 도구들(부수, 문자표, 이모지..)을 마우스로 클릭하고 잠시 있으면 확대된 글자를 잘 보라고 마우스 포인터가 사라지는데..
이때도 엑셀에서는 알 수 없는 이유로 인해 포인터가 사라지지 않곤 했다. 사라졌다가도 마우스 포인터를 살짝 움직이면 다시 나타났다.
그 문제를 이번에 덤으로 해결했다. 마우스 포인터를 숨기는 방법을 바꿨다. 이건 콤보 목록이 닫히는 문제와는 별개의 문제였다.

참고로, 당연한 말이지만 외부 모듈이 아니라 입력 패드에서 입력 도구들을 꺼내면 Excel에서도 아무 차이 없이 입력 도구들을 사용할 수 있다. 얘는 아예 별도의 프로세스에서 입력 도구를 구동한 것이기 때문이다.

3. 아래아한글에서의 미세한 문제

아래아한글은 MS Word와 달리 전통적으로 TSF를 지원하지 않는 불모지였다. 그런데 2018을 뒤늦게 써 보니 여기에도 변화가 느껴졌다. 비록 문서 본문은 변함없지만 대화상자의 텍스트 입력란에서는 TSF가 지원되기 시작했기 때문이다. 마소나 날개셋 한글 IME에서 단어 단위로 한자 변환을 할 수 있으며, backspace 달라붙기 같은 기능들이 모두 제대로 동작한다.

2010년대 중반이 되니 유니코드 5.2 방식의 옛한글 글꼴이 운영체제 차원에서 완전히 정착했고, 2010년대 후반이 되니 날개셋 말고도 TSF 기반의 한글 IME가 만들어져 나오고 심지어 TSF를 지원하는 텍스트 에디팅 엔진도 나오는구나 하는 생각이 든다. 뭐, 아래아한글의 경우, 문서 본문에도 TSF를 지원하는 건 여전히 쉽지 않을 것이다.

다만, 이렇게 아래아한글에 TSF 기반 텍스트 입력란이 구현되면서 날개셋 한글 입력기와도 충돌을 일으키기 시작했다. 버그 내지 오동작 의심 증상이 무려 세 가지나 있었는데, 이것 때문에 개인적으로 굉장히 힘든 나날을 보냈다.

  • 첫째는 그냥 답이 없는 문제였다. 안 그래도 동작 방식이 A형 B형 둘로 나뉘어 있는데, 아래아한글은 이미 알려진 다른 유형인 B형으로 인위로 보정을 해 줘야 했다.
  • 둘째는 프로그램이 뻗을 수도 있는 제일 치명적인 문제인데, 엄~밀히 말하면 내 입력기의 버그가 맞았다. 조합 상태가 아니면 그냥 조합을 완전히 해제해야 하는데 빈 조합으로 남겨 놓고 있었다. 하지만, 그런 결함이 있다고 실제로 이상한 문제를 외형적으로 일으키는 프로그램은 아래아한글이 처음이었다.
  • 마지막 셋째는 도대체 왜 내 입력기를 쓸 때만 이상하게 동작하는지 알 길이 없었는데, 알고 보니 일반적인 상황에서는 발생할 일이 없는 문제라는 것을 최종 확인했다. 간단하게만 말하자면 날개셋이 제공하는 한자 변환 기능과, 아래아한글이 자체적으로 제공하는 한자 변환 기능이 충돌하는 문제이다.

세 문제가 원인과 해결책이 전부 저 정도로 제각각으로 달랐다. 그래도 어쨌든 다 해결되니 기쁘다.

4. 크롬과 에지

(1) 마소의 Edge 브라우저가 크로뮴 기반으로 재개발(?)되고 있으며, 현재 베타 버전이 공개돼 있다. 그런데 얘는 크롬과 동일한 엔진(크로뮴) 기반이어서 그런지 예전의 크롬과 동일하게 조합 중인 글자가 덧나는 버그가 있었다. 이에 대한 보정을 추가했다.

(2) 그리고 크롬도 최근에 버전 78로 업데이트가 됐는데.. 생뚱맞게도 자신이 Metro 앱이라고 IME에다가 알려주고 있었다.
Metro 앱 환경에서는 통상적인 데스크톱 GUI가 제공되지 않기 때문에 날개셋 제어판을 꺼낼 수 없다. 그렇기 때문에 이 환경에서는 내 프로그램 역시 제어판을 여는 버튼을 disable시켜 버린다.

그런데 본인이 확인해 본 결과, 크롬과 Edge 베타 모두 말은 그렇게 해도 데스크톱 GUI의 구동에는 문제가 없었다. 그렇기 때문에 이번 버전에서는 저 프로그램에서 제어판이나 각종 대화상자들을 변함없이 열 수 있게 보정을 추가했다.

5. 외부 모듈의 응용 프로그램별 수동 보정 옵션

이 기능은 오래 전부터 날개셋 한글 입력기에 도입할까 말까 망설였는데.. 크롬 버그 이후로 갈수록 증가하는 glitch 신고를 계기로, 더는 대세를 거스를 수 없겠다 싶어서 결국 구현하게 되었다.
무엇인고 하니, 날개셋 한글 입력기가 응용 프로그램마다 호환성 차원에서 일부러 다르게 보정해서 동작하는 세부 알고리즘을 외부에 노출하고, 사용자가 프로그램별로 이를 수동으로 customize 할 수 있게 하는 것이다. 내부에 하드코딩 되어 있던 보정 규칙 테이블이 이 기회에 개방되었다.

Windows용 한글 IME라는 건 단일 로직으로 모든 프로그램에서 정확하게 동작하는 것이 불가능하다는 것이 확실시되고 있다. 크롬 브라우저와 MS Word는 걔네들에게만 적용되는 고유한 보정이 존재하고, 그것 말고도 전반적이 통신 방식이 크게 A와 B라는 두 갈래로 양분되어 있다.
어느 방식으로 통신하나 잘 동작하는 프로그램도 물론 있고 그래야만 정상이지만.. >_< 현실에서는 둘 중 한 방식을 거부하는 프로그램도 있다.

특히.. 지난번 9.8 시절의 크롬 버그를 잡고 그 방법을 다른 프로그램에다가도 범용적으로 적용시켰더니.. 기껏 지금까지 잘 돌아가던 모 프로그램에서 부작용이 발생하더라는 연락을 개인적으로 받기도 해서 멘붕했다.
아, 여기서 버그나 오동작이라는 건 한글 입력 자체가 안 된다기보다는 IME의 문자 입력 이벤트에 응용 프로그램이 반응을 제대로 못 해서 글자가 덧난다거나, 조합 중인 문자열이 사라진다거나 하는 glitch들을 말한다.

이제 제어판의 '시스템 계층'을 보면 "한글 표현 방식"과 "고급 시스템 옵션"의 아래에 "프로그램 호환성"이라는 카테고리가 하나 더 추가되며, 지금 당장 실행돼 있는 프로그램을 대상으로 통신 방식과 몇몇 보정 방식을 변경할 수 있다.

사용자 삽입 이미지

'대상 프로그램'은 지금 날개셋 IME가 동작하고 있는 프로그램이 가장 먼저 제시된다. 하지만 콤보박스를 열어 보면 현재 실행돼 있는 프로그램 또는, 실행되지 않았더라도 보정 정보가 등록된 프로그램을 고를 수 있다. 프로그램은 그냥 실행 파일 이름으로 식별한다.

앞으로 미묘하게 뭔가 잘 동작하지 않는 프로그램을 발견한 경우, 어지간해서는 '프로그램과 통신하는 방식'을 A에서 B로 바꿔 보시기 바란다. 응용 프로그램별 세부 보정은 해당 프로그램 외에서는 크게 쓸 일이 없을 것이다.

이로써 날개셋 한글 입력기는 글쇠배열은 말할 것도 없고 한글 입력 오토마타, 낱자 입력 규칙, 한영 전환 글쇠를 포함해 옛한글의 표현 방식에다 이런 응용 프로그램별 보정 방식까지도 customize 가능한 흠좀무한 프로그램이 되었다.

6. 나머지, UI 차원에서 사소하게 개선된 것들

(1) 편집기의 계산기에서 입력된 수식에 오류가 있는 경우, 에러 메시지를 더 구체적으로 표시하게 했다. 그리고 계산 결과를 무조건 10진법, 16진법 또는 상수 명칭 형태로 출력하는 게 아니라, 입력된 상수의 형태를 따라서 유동적으로 출력하는 모드를 추가했다. 100+100은 200이지만 0x100+100은 0x164이고, 'a'+3은 'd'가 되는 식으로 말이다. 이게 기본 상태이다.

사용자 삽입 이미지

사실, 계산기 기능이 아니라 날개셋 제어판 같은 다른 곳에서는 수식을 이렇게 더 자상하게 취급하는 기능이 이미 제공되고 있었는데 계산기로 도입이 다소 늦었다.
그리고 변수에는 언제나 값만 저장되지 대입된 상수의 형태가 저장되지 않는다. 그래서 'a'+1은 'b'라고 출력되지만, A='a'는 출력 방식이 특별히 지정되지 않은 한 그냥 97이라고 출력된다.

(2) 문자표 도구에서 "글꼴이 지원하는 모든 BMP 문자"를 지정했을 때 바탕, 굴림 같은 글꼴에서 공백(U+20) 미만의 제어 문자들이 앞에 표시되지 않게 했다. 그리고 영역 구분을 A 이상 B '미만'으로 해야 하는데 B '이하'로 하는 바람에 쓸데없이 깨진 문자가 하나씩 포함되던 문제를 이제야 발견해서 뒤늦게 해결했다.

(3) 부수로 한자 입력 도구에서 부수 목록은 화면의 확대 배율과 무관하게 언제나 한 줄에 5개씩 표시되게 했다. 150% 배율에서는 폭 계산이 이상하게 돼서 줄당 4개씩 표시되고 여백이 남아서 보기가 무척 안 좋았는데 이를 개선했다.

(4) 제어판의 '시스템 계층'에서 한자 출력용 글꼴을 수동 지정하는 콤보 상자에는.. 사용자의 선택을 돕기 위해 CJK 언어를 지원하는 글꼴들만 목록에 등록돼 표시된다.
그런데 이 목록에는 몇몇 글꼴이 누락되곤 했다. 가령, 한자 출력용으로 손색이 없는 Noto Sans CJK 같은 글꼴은 설치돼 있어도 표시되지 않았다. 정확한 이유는 알 수 없지만 운영체제가 얘를 평범한 트루타입 글꼴로 분류해서 조회해 주지 않았던 것이다.

이 문제를 해결하여 저런 글꼴도 목록에 등재되도록 했다. 다만, 목록 등재 여부를 떠나서 사용자가 이 글꼴 이름을 딴 데서 복사해서 강제로 지정해 주면 지금도 그 글꼴을 지정 자체는 할 수 있다.

(5) 날개셋 한글 입력기는 각종 단축글쇠에서 shift, ctrl, alt, win의 조합을 modifier로 지원한다. 다만, 편집기와 입력 패드 같은 자체 환경 말고 외부 모듈(IME)에서는 운영체제의 동작 특성의 차이로 인해 alt가 사실상 지원되지 않는다. 그래서 외부 모듈에서 단축글쇠 편집 대화상자를 꺼내면 alt를 조절하는 슬라이더는 disabled 상태로 나타났는데...

사용자 삽입 이미지

이번 버전에서는 그에 덧붙여 사용자가 alt를 할당할 경우 이렇게 풍선 도움말로도 추가적인 안내를 하게 했다.
프로그램에 따라서는 alt는 안 되면서 ctrl+alt 조합은 인식되는 경우도 있는데, 이것도 모든 프로그램에서 다 되는 건 아니다. 그러니 일반적으로 alt는 사용할 수 없다고 생각하는 게 속 편하다.

7. 나빌 한글 입력기와 3-18Na 입력 방식

지난 2000년대에는 '새나루'라고 Windows용 오픈소스 한글 IME 프로젝트가 있었다. 얘는 Windows XP 시절을 풍미하면서 활발하게 개발돼 왔지만 개발이 중단되고 2010년대부터는 맥이 끊어졌다.
그런데 바로 올해엔 어느 용자 능력자께서 '나빌'이라는 한글 IME를 개발하여 오픈소스 진영에 기여했고, 두벌식 글쇠배열 기반으로 신세벌식 원리(중성· 종성 중첩)를 적용한 자기 나름의 새로운 한글 입력 방식까지 제안해 놓았다. 컴퓨터 아키텍처 쪽으로 책도 쓴 유명한 분이던데..

내가 저분의 개발 후기를 읽으면서 정말 놀라고 감탄한 것은.. 세벌식 자판부터 시작해서 Windows 프로그래밍과 새로운 TSF 스펙, 예제 코드까지.. 나라면 몇 주 몇 달 이상을 끙끙대며 삽질했을 새로운 지식과 정보들을 단순히 잉여질(?)만으로 그 짧은 시간 만에 몽땅 습득하고 응용해서 새로운 결과물을 뚝딱 내놓았다는 점이다.
난 정말 무식하게 오래 질질 끌고 한 우물만 오래 팠기 때문에 이 정도 경험과 기술이 축적된 거지, 밑바닥부터 시작하면 절대로 저렇게 못 했을 것이다.

인간의 창의성과 지적 능력의 끝이 어디인지를 다시 생각하게 된다. 이번 버전에서는 3-18Na 입력 방식을 내 프로그램의 설정 예제로 구현해서 추가했다.

아이고 글이 또 왜 이리 길어졌나..? 아무튼, 이번 버전도 유용하게 사용하시기 바란다.
홈페이지의 트래픽을 관리하기 위해 64비트 바이너리는 여전히 Google Drive 링크로 제공하고 있다. 하지만 내 홈페이지에도 파일 자체는 올라와 있다. *_x86.msi 대신 *_x64.msi로 말이다.
그나저나 페이스북 의견 페이지가 왜 또 안 뜨고 있나 모르겠다.

Posted by 사무엘

2019/10/27 08:37 2019/10/27 08:37
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1677

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

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

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/07   »
      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 31  

Site Stats

Total hits:
1407208
Today:
42
Yesterday:
497