날개셋 한글 입력기 10.7

오랜만에 날개셋 한글 입력기가 10.7로 버전업됐다. 9.7 이후로 10.7이 나오기까지 무려 5년이나 걸렸다.
하~~ 이번에도 개발 작업은 너무 더디게 진행됐다. 10.8 정도로는 올리고 싶었지만 도저히 그러지 못했다. 다음 버전 개발 근황글이 올라왔던 지난번 이래로 더 바뀐 게 거의 없다.

이전 버전이 소수점이 65였기 때문에 다음을 70으로 정한 거지, x0이었으면 그냥 x1로 정했을지도 모르겠다.
나도 나이가 드니 개인적으로 프로그램 개발보다 더 중요한 일이 자꾸 생기는 것 같다. ㅠㅠㅠ

1. 해결: 뻗는 문제 등

(1) 이번 10.7의 가장 중요한 의의는 외부 모듈(IME)이 구동되자마자 케바케로 뻗던 문제를 확실하게 해결한 것이라 하겠다.
그러니 외부 모듈을 사용하시는 분이라면 번거롭더라도 어지간하면 새 버전으로 업데이트를 꼭 해 주시길 바란다.
안정성과 관련하여 심각한 문제가 수 년 동안 있었는데 그게 하필 요 근래에야 발견됐나 모르겠다. 이건 직전 버전만의 문제가 아니었는데 말이다.

이거랑 관련된 문의를 작년 말쯤부터 지금까지 메일로 여러 통 받았고, 개발 중인 임시 버전으로 다 해결됐다는 연락을 받았다. 이번 10.7은 그 수정 사항이 정식으로 적용돼 있다.

(2) 그 밖에 화면 키보드가 외형이 크게 개선된 것도 자신 있게 소개하고 싶다.
글쇠문자는 진하게 또는 적당히 확대되어 표시되게 했으며, 무엇보다도 아랫글쇠와 윗글쇠 중 지금 해당되는 것 하나만 표시되게 하는 옵션을 추가했다. 직접 써 보면 무엇이 개선되었는지 바로 알 수 있을 것이다.

(3) 편집기의 경우, 1.0 이래로 최초로 ctrl+ins와 shift+ins, shift+del이 지원되기 시작했다.

2. 미해결: 전각 및 한영 상태 오동작

지난 반 년 남짓한 기간 동안 저 뻗는 문제 말고 본인에게 제일 많이 접수된 문의는 바로..
일본어 IME와 날개셋을 같이 사용하는 분들로부터의 불편 사항이었다.
일본어 IME를 쓰다가 win+space나 alt+shift로 날개셋으로 돌아오면 한글이던 입력 모드가 매번 영문으로 바뀐다거나, 심지어 전각 모드가 지정된다거나..

하지만 이건 내가 정확한 재연 방법을 파악하지 못해서 별 조치를 취하지 못했다.
특히 특정 웹브라우저에서만 뭘 어떻게 하니 날개셋에서 전각 모드가 계속 이어진다..?? 이건 정말 어떻게 해야 재연 가능한지 모르겠다.

내가 확실하게 파악한 건,
Windows 11에서 기본 제공하는 마소 일본어 IME를 쓰다가 날개셋으로 전환하면 이전에 한글을 치고 있었는데도 도로 영문으로 돌아간다는 것이다. 마소 한글 IME는 그렇지 않더라.
요건 오동작이 맞고 나도 현상만 파악했다. 마소 한글 IME와 다르게 동작하는 것만 내 프로그램의 버그라고 접수한다.
전각으로 잘못 지정되는 현상까지는 도저히 모르겠으니 정확한 재연 스텝을 공개 수배하는 바이다.

임시방편으로는 날개셋 제어판을 열어서 "시스템 계층 - 고급 시스템 옵션 - 첫 실행 때 운영체제의 한영 상태를 무시하고 입력 항목 선택" 옵션을 켜 주면 영문으로 돌아가는 현상은 막을 수 있다.
원래는 이 옵션을 사용하지 않더라도 한영 상태가 마소 한글 IME와는 동일하게 유지돼야 한다.

3. 다음 버전에서: 비한글 글쇠 처리 방식을 보정 옵션으로 추가

날개셋 외부 모듈이 마소 한글 IME와 동작이 다르다고 이슈가 많이 발생하는 요인 중 하나로는 비한글 글쇠의 처리 방식이 있다. 가령, 한글 조합 중에 space를 눌렀는데 그 공백이 씹힌다거나, 심지어 조합 중이던 한글이 사라진다거나..

마소 한글 IME 기준으로 두벌식에서는 문제가 없는데 세벌식(390 및 최종 불문)에서만 문제가 발생하는 게 있다면? 100% 요 케이스이다. 반대로 세벌식에서는 괜찮고 두벌식에서 문제가 발생하는 것도 포함이다.
날개셋 한글 입력기의 도움말에서 “VI. 외부모듈 ? 알려진 문제 ? 비한글 문자 입력 관련”이 요 케이스에 대해서 다루고 있다.

그러고 보니 인디자인 문제는 한글 입력 중에 엔터를 누르는 게 한번 인식되지 않아서 정말 악명 높았었는데.. 요즘 최신 버전도 여전히 저런지 모르겠다.
요 근래엔 운영체제의 ‘메일’ 앱에서도 한글 입력 중에 space를 누르면 높은 확률로 씹히는 현상이 있다고 어떤 분이 문의를 하셨다. 이 역시 같은 현상이다.

이건 엄밀히 따지면 응용 프로그램이 IME가 보내 주는 입력을 제대로 처리하지 못해서 발생하는 문제이다.
그래도 당장 이 문제를 회피하는 방식을 날개셋 역시 여러 방법으로 제공하고 있다. Space를 응용 프로그램으로 보내는 게 아니라(마소 IME의 두벌식) IME가 가로채서 공백을 직접 보내게 한다거나(MS IME의 세벌식), 숫자나 기호도 응용 프로그램으로 직접 보내는 등..

그러나 이건 사용자가 입력 설정을 번거롭게 그때 그때 바꿔야 해서 번거롭다. 특정 프로그램에서만 조건부로 동작하게 만들 수 없다.
가만히 생각해 보니.. 이거야말로 “프로그램 호환성” 탭의 보정 아이템으로 넣어야 할 사항인 것 같다~!! 지금까지 왜 이 생각을 못 했을까..?

응용 프로그램별 보정이라는 사악한(?) 기능은 크롬 브라우저와 Windows Terminal 때문에 도입됐다고 해도 과언이 아니다. 허나, 저것들도 보정 옵션으로 추가된다면 사용 빈도와 유용성이 크게 높아질 것 같다. 이 비한글 글쇠의 처리 방식은 내가 보기에 진짜 지구가 멸망할 때까지 사라지지 않을 이슈일 것이기 때문이다. ㄲㄲㄲㄲㄲ

4. 나머지

(1) 가끔은 멀쩡한 msi 파일이 잘 열리지 않고 설치가 안 된다는 문의가(정확한 에러 메시지는 한번 봤다가 까먹었..) 들어오곤 했다.
이건 내 쪽이 아니라 운영체제 쪽의 일시적인 문제 때문으로 보인다. 딴 업데이트를 설치하다가 만 상태이다거나..
그냥 운영체제를 재부팅 하면 해결된다. 그것 말고 다른 해결책은 없는 걸로 보인다.
아 이건 도움말이나 프로그램 다운로드 페이지에다가도 언급을 해야 할 듯하다.

(2) 올해 연말, 아마 11월쯤에 10.9, 내년에 11.0으로 버전이 올라갔으면 좋겠다. 그리고 타자연습도 4.0으로 부디..
과연 목표가 이뤄질 수 있을지 모르겠다.
비록 버전을 조금밖에 못 올려서 안타깝지만.. 그래도 이번 10.7 버전도 누구든지 유용하게 사용해 주셨으면 좋겠다.
아울러, 이번 상반기에도 알음알음 후원해 주신 분들께 감사드린다. 후원자는 다음 버전 때 도움말의 '감사의 글'에 꾸준히 이름을 가나다 순으로 등재하고 있다.

Posted by 사무엘

2024/05/01 08:35 2024/05/01 08:35
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/2292

다음 버전 개발 근황

날개셋 한글 입력기의 다음 버전이 일단은 다음 달 4월 하순쯤에 나올 예정이다. 버전이 10.9가 되었으면 좋겠지만 현실적으로는 무리=_=;;이고, 아마 10.8이 될 가능성이 높다.
타자연습도 오랜만에 버전업 해서 4.0을 만들고 싶은데 얘는 또 언제 작업하려나.. ㅠㅠㅠ
아무튼, 현재 작업이 진행된 자랑거리들을 몇 가지 나열하자면 다음과 같다.

1. 외부 모듈: 안정성 개선

날개셋 한글 입력기는 사용자가 입력 설정을 바꿔서 imeconf.dat를 저장해 놓은 게 없는 경우, 마소 한글 IME의 설정 레지스트리 값을 참조하여 동일하게 두벌/세벌 설정을 세팅해서 동작한다.
그 레지스트리 주소는 운영체제의 버전에 따라 다를 수 있기 때문에 일종의 탐색 알고리즘을 거쳐서 결정된다.

그런데 그 로직에 심각한 버그가 있었다. 그것도 꽤 오랫동안 존재해 왔다.
한번 구한 주소값을 저장해 놓는다는 것이.. 지역변수 버퍼의 주소를 static 변수에다가 저장해 버리고는 계속 써먹는 병크가 벌어졌다.

이 때문에 날개셋 제어판에서 '프로그램 설치 직후 상태'로 팩토리 리셋 명령을 여러 번 내려 보면, 마소 한글 IME로 분명히 세벌식을 사용하고 있음에도 불구하고 제1글자판이(0번) 두벌식으로 지정되곤 했다.
이건 잘못된 메모리 주소를 넘겨준 것이기 때문에 원래는 실행 실패만으로 곱게 넘어가지 않는다. 일부 민감한 환경에서는 프로그램이 뻗을 수도 있다.

오랜 고질병이 있었구나.. 문제를 당장 개선했다.
더구나 외부 모듈은 imeconf.dat가 있더라도 매번 이렇게 디폴트 세팅부터 먼저 했다가 다시 파일 내용으로 세팅을 다시 하는 삽질을 지금까지 하고 있었다.
이를 개선했기 때문에 "메모리 문제 해결", "애초에 문제의 동작 자체를 하지 않게" 이렇게 2중으로 문제를 원천봉쇄 해결했다.

나무위키에 올라와 있던 "Windows 95에서 IE 4~5 + Active desktop을 켠 환경에서 날개셋을 기본 IME로 지정해 놓으면 부팅 과정에서 운영체제가 뻗어 버린다".....;;
이건 내가 직접 확인은 못 해 봤지만, 어쩌면 이 문제도 같이 해결되었을 가능성이 높다.

2. 편집기: ctrl+ins, shift+ins/del 단축키 지원

날개셋 편집기는 1.0 이래로 지난 20여 년 동안, 복사/잘라내기/붙여넣기 기능의 단축키로 Ctrl+C, X, V만을 지원했다. 이들 기능은 Ctrl+Ins, Shift+Del, Shift+Ins라는 단축키로도 통용되고 있지만, 내 프로그램에서는 지금까지 지원되지 않았다.
일단 내가 개인적으로 저런 제2군 단축키를 전혀 사용하지 않았고, 그리고 shift+ins는 한글 낱자 수정 - 글자 전체 수정을 전환하는 용도로 이미 사용 중이었기 때문이다.

그러나 정신을 차리고 보니.. 텍스트 입력 기능을 갖춘 주변의 각종 에디터나 워드 프로세서에서 제2군 단축키를 지원하지 않는 프로그램은 없다. 정말 내 프로그램밖에 없는 것 같다. -_-;; 이는 거스를 수 없는 대세라 여겨지고 또 사용자의 건의도 있으니 이걸 이제야 반영했다.

그럼 낱자/글자 모드를 전환하는 기존 shift+ins를 어디로 옮길지가 문제인데.. 의외로 간단하게 해결했다. 그냥 ctrl+ins로 옮겼다.
Ctrl+ins는 텍스트에 블록이 잡혀 있을 때는 복사 기능을 수행하고, 블록이 없을 때는 낱자/글자 모드를 전환하게 했다. 텍스트를 타이핑으로 수정하는데 블록을 잡을 일은 전혀 없을 테니 이렇게 해도 영역이 전혀 겹치지 않는다.

3. 편집기: 자잘한 UI 개선

(1) 도구 메뉴에 있는 텍스트 분량 계산 기능을 크게 강화했다.
텍스트 중의 확장 평면(surrogate) 글자 수, 대략의 공백(whitespace) 수와 단어 수를 추가로 표시해 준다.
일본어· 중국어는 띄어쓰기가 없으니 전각 구두점만으로도 단어 구분이 되게 했다.
그리고 블록을 잡았다면 블록이 텍스트 전체에서 몇 % 정도 차지하는지도 나오게 했다.

사용자 삽입 이미지

(2) 예전에 날개셋 편집기에서는 텍스트를 스크롤 하거나 인쇄할 때, 화면 내지 페이지의 맨 마지막 줄은 그 아래의 줄 간격을 계산에 또 반영하지 않도록 동작이 개선된 적이 있었다. 그럴 필요가 없기 때문이다.
이와 비슷한 최적화가 세로뿐만 아니라 가로 스크롤에 대해서도 행해졌다. cursor가 줄의 맨 끝에 있을 때는 굳이 반각 한 칸 공간을 확보하면서 스크롤되지 않는다. 홀쭉한 cursor를 표시할 공간만 있으면 스크롤을 더 하지 않게 했다.

사용자 삽입 이미지
(오른쪽 끝에 간신히 표시돼 있는 cursor를 주목할 것.)

(3) 계산기 대화상자에서 오류가 있는 수식을 입력하더라도 그저 씹히는 게 아니라..
텍스트 전체가 블록으로 잡히고, 히스토리를 보관하는 콤보 상자에도 제일 최근 아이템으로 "1회 임시 등록"되게 했다.
그러면 사용자가 수식에서 오류가 있는 부분만 고쳐서 다시 계산을 시도할 수 있다.
수식이 오류 없이 정상적으로 계산되면 오류 수식은 히스토리에서 제거되고 맞는 수식으로 대체된다.

(4) 찾기 명령을 내렸는데 텍스트가 더 없으면 "도로 역방향으로 찾으시겠습니까, 문서 처음부터 다시 찾으시겠습니까?" 물음이 뜬다. 이 두 번째 시도에서도 텍스트가 전혀 나오지 않으면 그때는 "찾는 문자열이 없습니다" 메시지가 뜨게 돼 있다. 이 로직 자체는 맞다.

그런데 내 프로그램에는 애초부터 '문서의 맨 처음부터 검색'하는 옵션이 있다. 이 옵션을 켰는데도 match가 발견되는 게 없다면 저렇게 "찾는 방향이나 위치를 변경해서 재시도 하시겠습니까?"라고 또 물을 필요가 없다. 그때는 바로 "찾는 문자열이 없습니다"를 출력하도록 로직을 개선했다.

(5) 내 프로그램에는 문자열을 찾는 게 아니라 특정 코드값을 만족하는 문자를 찾는 기능이 있다. 얘로 검색을 시도했는데 찾는 문자열이 없으면.. 대화상자가 종료되지 않고 다시 검색을 시도할 수 있게 UI 동작을 고쳤다.

4. 입력 패드: 미세하게나마 성능 개선

날개셋 한글 입력기의 구현체 중에 입력 패드는.. 아무래도 편집기나 외부 모듈에 비해 존재감이 없는 잉여에 가깝다. 한번 엔진을 만들고 나서는 고칠 게 거의 없는 물건이다만, 이번에 의외로 대대적인 '최적화/성능 개선' 작업이 행해졌다.

(1) 이 프로그램은 동작 원리의 특성상, 64비트 OS에서도 32비트 프로그램들을 지원하기 위해서는 64비트 버전과 32비트 버전을 모두 실행해서 메시지 훅킹을 제각기 구동해야 한다.
그러니 32비트 버전의 경우, 32비트 운영체제에서 단독 실행될 수도 있고, 64비트 버전을 보조하는 간편 모드로 실행될 수도 있다.

간편 모드로 실행됐을 때는 자체적으로 GUI를 표시하는 게 전혀 없고(전부 64비트 버전이 전담하니) 하는 일도 매우 단순하다. 그렇기 때문에 굳이 32비트용 날개셋 커널을 로딩할 필요가 없다.
32비트 버전이 간편 모드로 실행됐을 때는 날개셋 커널을 로딩하지 않도록 동작을 개선했다. 뭐 그래 봤자 메모리 1MB 남짓 절약한 것에 불과하지만.. 불필요한 군살을 이렇게 하나 뺐다. ㄲㄲㄲㄲ

(2) 그리고 32비트 호스트를 내부적으로 실행하는 것도 무조건이 아니라 입력 도구를 하나 끄집어냈을 때, 키 입력 모드를 켰을 때처럼.. 사용자가 진짜로 그런 기능을 수행할 때만 하도록 했다.
이런 최적화는 해 봤자 당장 성능에 큰 차이는 없겠지만.. 64비트 환경에서 32비트 의존을 최대한 줄이겠다는 상징적인 차원에서 행해졌다.

5. 보조 입력 도구: 화면 키보드

날개셋 한글 입력기에 '화면 키보드'는 정말 유구한 역사를 자랑하는 입력 도구이다. 다음 버전에서는 다음과 같이 외형이 바뀌고 자잘한 기능이 추가될 예정이다.

(1) Windows 글꼴을 사용하는 경우, 문자들이 진하게 표시되게 했다. 이렇게 하니 가독성이 훨씬 더 나아졌다.
지금은 문자 키의 우측 상단에 자그맣게 고정적으로 붙어 있는 123 QWERTY...가 쓸데없이 진하게 찍혀 있었는데 로직을 바꿨다. 또한, 구형 운영체제에서 그 123 QWERTY...의 크기가 잘못 계산되어 큼직하게 찍히던 문제를 같이 해결했다.

사용자 삽입 이미지

(2) 한 글쇠에 대해 글쇠배열은 원래 자리와 shift를 합쳐서 2줄로 출력된다. 그러나 평소에는 원래 자리의 것만 표시되게 하는 '1줄 모드' 옵션을 이번에 추가했다. 윗글쇠 자리는 shift를 누르고 있는 동안에만 표시된다.
이렇게 하면 글쇠배열이 더 깔끔하고 알아보기 편할 것이다.

사용자 삽입 이미지

(3) 자체 비트맵 글꼴은 Windows 글꼴과 달리 크기 조절이 되지 않는다. 그래서 글쇠배열을 크게 키워도 너무 작게 찍혀서 문제인데..
이제 창 크기를 '대형'으로 하면 글자를 2배로 확대해서 출력하게 했다. 1줄 모드일 때는 창 크기를 '중형'으로만 해도 2배로 확대된다.

사용자 삽입 이미지

Posted by 사무엘

2024/03/21 08:34 2024/03/21 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2278

날개셋 한글 입력기 10.65

0. 들어가는 말

날개셋 한글 입력기가 거의 7개월 만에 새 버전이 나왔다.
생각 같아서는 10.5 다음으로 꼭 10.7을 만들고 싶었지만, 변화량이 0.2를 올리기에는 충분하지 못해서 0.15만 올렸다. 그렇다고 0.1밖에 안 되는 건 또 아니기 때문에.. =_=;;
x.65라는 버전은 옛날에 3.65 (2006), 그리고 5.65 (2010) 이후로 세 번째이고 무려 14년 만의 일이다.

현재로서는 더 분발해서 오는 4월 말쯤에 10.9를 내놓고, 올해 말 11~12월쯤에 11.0으로 가는 게 목표이다. Windows나 맥이나 다 10 버전을 졸업하는 분위기인데. 내 입력기도 그렇게 될 듯하다. 2020년 이후로 10.x를 졸업하는 데는 4년 반이나 걸리게 됐다.
2020년대 들어서 슬럼프에 빠졌는지 프로그램 개발 속도가 너무 느려진 듯.. 슬럼프를 벗어야겠다.

개인적으로 이제 좀 오랜 마음의 짐을 벗은...은 개뿔, 또 다음 버전 만들어야지. 프로그램 큰 틀을 바꾸는 변화는 아니지만 이미 제공되고 있는 기능들의 완성도를 올리고 UI를 강화할 만한 작업들이 많이 남아 있다.

이번 새 버전에서 달라진 사항들에 대해서는 가장 먼저 지난 여름에 올렸던 개발 근황글부터 참고하시기 바란다. 그거 이후로 또 달라진 것은 다음과 같다.

1. 한글을 소리 나는 대로 필터의 기능 강화

날개셋 한글 입력기에는 '국밥 국력'을 '국빱 궁녁'으로 바꿔 주는 텍스트 필터가 있다. 이건 무려 20년 전 3.0 버전에서 처음으로 추가된 물건이다. 그리고 4.4 (2007)에서 "짙이 → 지티 - 지디, 지시, 진니, 지치"로 요약되는 4종류의 힌트가 도입되고는 큰 변화 없이 현재까지 15년 가까이 이어지고 있다.

먼저, 사용자에게는 아무 티가 안 나는 변화이겠지만.. 내부적으로 코드를 처음부터 다시 짜고 알고리즘을 재설계했다.
한글 낱자들이 난무하는 알고리즘들이 일체의 명칭 없이 숫자들이 하드코딩돼 있고, 음운 변화를 나타내는 테이블들도 중구난방이어서 보는 내가 화딱지가 날 것 같았다.
20년 전 대학 시절엔 내가 코딩 스타일이 이 정도로 개판이었나.. 그래도 명색이 컴공 전공이고 왕년에 올림피아드 입상도 했던 사람인데. =_=;;

본인은 장기적으로는 내 홈페이지에서 소스를 공개하고 있는 옛날 골동품 프로그램과 혼자 깨작거렸던 코드들을 github에다가 공개할 생각을 하고 있다.
하지만 공개하려고 옛날 코드를 다시 살펴보니.. 이건 뭐 대외 공개 가능한 퀄리티가 아니었다. 지금으로서는 상상도 못 하게 ugly한 코딩 컨벤션들을 어찌해야 하나 좀 고민된다.

아무튼, 저 필터 동작을 지금 내 눈높이를 만족하는 코딩으로 다시 구현했고, 이를 토대로 다음과 같은 동작도 더 추가했다.

(1) 4번 힌트에 비표준 자음 역행 동화를 추가했다. '신발'을 '심발'로, '벗기다'를 '벅기다'라고 발음하는 음운 변화 말이다. 한국어의 표준 발음으로 인정되지는 않지만 현실에서 많이 발생하고 있으며, 한국어 외의 타 언어에서도 많이 발생한다.
4번 힌트는 구개음화 등 기존 1~3번 힌트가 담당하지 않는 여러 자잘한 음운 변화를 담당하고 있는데, 여기에다가 저 동작을 넣어도 논리적으로 충돌이 나지 않는다.

기존 힌트들은 뒷글자가 초성이 없을 때(ㅇ)의 변화와 관련이 있다. 그러나 이 자음 역행 동화는 뒷글자에 nontrivial한 초성이 있어서 그거 영향을 받아서 앞글자의 종성 발음이 바뀌는 현상이다. 그렇기 때문에 그 자리에다가 새로운 동작을 넣어도 된다.
사실, 이 동작은 1~2번 힌트에다가 추가해도 된다. 하지만 이건 비표준 발음인 걸 감안해서 약간 보조, 잉여에 가까운 4번에다가 넣었다. 어쨌든, 굳이 새로운 힌트 부호를 추가하지 않고 새로운 음운 변화를 빈 공간에다 넣었다는 게 핵심이다.

(2) 지금까지 힌트는 하나만 선택 가능하다. 그러나 새 버전에서는 사이소리를 나타내는 3번 힌트는 예외적으로 타 힌트와 같이 사용할 수 있게 했다.
일례로 '싫증'. 아무 힌트가 없으면 '싫지'와 동급인 '실층'이 되어 버린다. 1번을 적용해서 '싫'을 '실'로 완전히 굳혀야 '실증'이 되고.. 여기에다 3번 힌트를 추가로 넣어야 '실쯩'으로 바뀐다.
'안기다'도 마찬가지다. 3번 힌트를 넣어야 '안끼다'가 되는데, 이 힌트는 이번에 추가된 4번 힌트와 동시 적용도 가능해야 한다. 그래야 '앙끼다'를 만들 수 있다.

2. 저장할 파일의 확장자 지정과 관련된 모호성을 해소

Windows에서 제공하는 파일명 지정 대화상자에는 기본 확장자라는 개념이 있다. 그래서 사용자가 일일이 확장자를 붙이지 않고 "내 문서"라고만 입력했다면 "내 문서.txt"라고 인식되게 되어 있다.

그런데 문제는 기본 확장자가 사용자가 의도하지 않는 방식으로 적용될 수도 있다는 것이다. "듣보잡확장자.xxq" 이런 이름을 주면 "듣보잡확장자.xxq.txt" 이렇게 인식되어 버린다. 지금은 도스 시절과 달리, 파일 이름에 점이 2개 이상 마음대로 들어갈 수 있기 때문이다.

그리고 기본 확장자를 무시하고 확장자가 아예 없는 파일을 만들고 싶을 때는 그냥 "확장자없음."이라고 파일 이름 뒤에 점만 찍는 게 도스 시절 이래로 여러 프로그램에서 관행이었다.
그런데 Windows에서는 이렇게 하면 "확장자없음..txt"라고 알아듣는다. -_-;; 그렇다고 기본 확장자 자체를 없애거나 옵션으로 처리하는 건 아닌 것 같고..

이 문제를 이번에 드디어 손 봤다. 해결한 방식은 간단하다.
접수된 파일명에 . 이 2개 이상 존재하는 경우, 마지막 확장자가 추가된 것이 진짜 맞는지를 묻게 했다. 이게 제일 깔끔한 해결책인 것 같다.

사용자 삽입 이미지

이제 날개셋 편집기에서는 운영체제에서 인식하지 못하는 임의의 듣보잡 확장자 파일도 번거로운 오동작 없이 바로 만들 수 있다. 운영체제 파일 대화상자의 동작이 고쳐질 수는 없으니, 그걸 사용하는 응용 프로그램에다가 보정 로직을 넣는 것밖에 선택의 여지가 없어 보인다.

3. 그 외

(1) 일상적으로 자주 겪을 일은 없겠지만.. 파일 저장이 100% 완전히 성공한 뒤에야 다음 작업이 진행되도록 했다.
창을 닫기 전에 저장 확인 질문이 떠서 '예'를 눌렀다면, 그 저장이 완전히 성공한 다음에 그 문서창이 닫히고 프로그램이 종료된다.
저장을 처음 하거나 '다른 이름으로 저장'을 눌렀다면, 그 저장이 완전히 성공한 다음에 그 파일 이름이 정식으로 반영된다.

지금까지는 중간에 오류가 발생해서 저장이 제대로 되지 않았더라도 일단 그 이름으로 파일이 생성되기만 했다면.. 무조건 성공으로 간주되었다. 저장 중에 딴 오류가 발생했더라도 다음 단계로 넘어갔기 때문에 사용자의 정보를 날려먹을 가능성이 있었다.

(2) 파일 전체 저장이 아니라 일부만 따로 저장하는 '블록 내용 저장'을 했는데 원래 편집 중인 파일의 날짜· 크기 스냅샷이 업데이트되던 버그를 수정했다. 이 때문에 지금까지는 원래 파일이 외부에 의해 건드려졌다고 오판 오동작이 발생했었다.

※ 과거 떡밥: 골동품 9x 계열에서의 안정성

요즘 세상에 가상 머신 만들어서 Windows 9x를 띄워 보는 레트로 레거시 덕후가 나만 있는 게 아니구나. ㄷㄷㄷㄷㄷ
지난달 말쯤엔 나무위키에 등재된 내 입력기의 소개에.. "Windows 95에서 IE 4~5 + Active desktop을 켠 환경에서 날개셋을 기본 IME로 지정해 놓으면 부팅 과정에서 운영체제가 뻗어 버린다" 이런 문구가 추가되었다. 무려 Word 97을 띄운 화면과 함께.

글쎄, IE 4와 Active desktop을 기본 내장 중인 Windows 98에서는 Active desktop을 켠 채로 내 입력기를 기본 IME로 지정하더라도 부팅에 아무 지장이 없다. 본인이 보유 중인 가상 머신에서 테스트를 해 보니 그렇다.
그러니 나무위키에 등재된 저 이슈는 일단 재연이 안 되고 지원도 어려울 듯하다. ^^

사실, Windows 95와 98은 똑같이 불안정한 9x 계열 커널이고, 한때는 95 + IE4 = 98일 뿐이라는 비아냥까지 많이 나돌았다. 하지만 기술적으로 보면 98은 바뀌고 향상되고 안정화된 게 생각보다 많았으며, 특히 IME 쪽은 더욱 그러했다.
일례로, 95의 경우 16비트 프로그램에서 날개셋은 사실상 못 쓴다고 보면 된다. 그나마 98/ME는 제어판 여는 것만 불안정하고 입력 기능은 사용 가능하다.

Windows installer 2.0 runtime을 받을 수 있는 곳 링크도 올려 놓을까 싶다.. =_=;; ㅋㅋㅋㅋ
암튼, 개발자와 사용자 간에 메일보다 더 개방된 방법으로 피드백을 주고받는 통로가 있긴 해야 할 것 같다.

※ 미래 떡밥: Windows 11 UI 적용

Windows 진영에서는 10여 년 전, Windows 8 시절부터 IME들의 아이콘 디자인 표준이 바뀌었다. 검은 테두리의 흰 사각형 배경에 단색으로 일종의 글자나 기호 모양으로 자기 IME를 표현하라는 게 골자이다. 그래서 마소의 한글 IME는 '한' 모양이고 일본어 IME는 원 안의 J 모양이다. 내 입력기 역시 10여 년 전의 6.8 버전부터 그 디자인을 적용했다.

이게 Windows 10까지도 그대로 이어져 왔는데.. 11에서는 조금 난감한 변화가 생겼다.
win+space를 눌러 보시라. 예전에는 스펙대로 흰 사각형 배경의 아이콘들이 쭉 떴는데 11부터는 흰 배경과 검은 테두리가 사라졌다. 어찌 된 일일까?

사용자 삽입 이미지

이건 기존 아이콘을 가공하거나(배경 제거-_-) 변조해서 만들어 낸 이미지가 아니다.
Windows 10과 11의 한국어/일본어 IME 프로그램을 바이너리 차원에서 비교도 해 보고 스펙을 검색도 해 봤지만.. 어떡해야 이렇게 11 스타일로 배경을 제거한 아이콘을 만들 수 있는지에 대한 정보는 도무지 나오지 않았다.

내가 지금까지 알아낸 바로는 이건 IME 프로그램에서 조치를 취한 게 아니다. 그리고 저렇게 배경 없는 아이콘은 png나 ico가 아니라 폰트-_- 기반이다.
Windows 11에서는 간결한 fluent한 디자인을 표방하면서 각종 아이콘 내지 픽토그램들의 상당수가 폰트로 바뀌었다. 가령, 전원 버튼이라든가 앱/웹사이트의 종합 메뉴를 호출하는 햄버거 버튼, 배터리 용량 아이콘 따위 말이다. 오죽했으면 Segoe Fluent Icons라는 폰트도 생겨 있다.

그런데 정말 골때리는 건.. 저기서 '한', J 따위를 그리는 일명 '아이콘 폰트'는.. 해당 IME 프로그램에서 유래된 게 아니라는 것이다. IME가 아니라 운영체제 셸(QuickActions) 앱에 들어있다. 거기 내장된 폰트 하나에다 마소 한중일 IME들의 아이콘 글립이 모두 들어있다.

사용자 삽입 이미지

운영체제에서 무슨 근거로 마소 IME는 그런 폰트로 아이콘을 갈음하고, 타 3rd-party IME에 대해서는 원래대로 프로그램 리소스에 들어있는 아이콘을 출력하는지...?? 도저히 모르겠다. 최소한 IME가 사용하는 운영체제의 표준 API로 폰트 아이콘을 지정한 것 같지는 않다. 레지스트리? 설마 하드코딩으로 박았나? 3rd-party IME에서 저렇게 하는 방법은 내가 아는 한 전혀 공개돼 있지 않다.

아이콘뿐만 아니라 설정 페이지도 말이다. 데스크톱 UI 기반으로 원래부터 제공되던 기존 환경설정 기능 말고, '설정' 앱에서 UWP 기반으로 돌아가는 요 페이지...

사용자 삽입 이미지

이것도 내가 지금까지 열나게 검색하고 디버깅한 바로는.. 이걸 담당하는 부분이 IME 프로그램에 있지 않다~!! SettingsHandlers-nt라는 모듈에 있다.
IME의 UI와 관련된 코드 및 리소스가 IME 프로그램에 있지 않고 운영체제에 하드코딩으로 박혀 있다는 말인지..
현재로서는 마소 IME는 또 문서화되지 않은 API나 프로토콜을 사용해서 자기들만 외형이 새끈하게 바뀌고 있다고밖에 여겨지지 않는다. 이게 개인적인 고민거리이다.

※ 타자연습 계획

끝으로.. 타자연습도 지금은 아니지만.. 정말 오랜만에 일단 올해 중 업데이트 계획이 있다. 이제는 드디어 타자연습도 버전을 4.0으로 올릴 생각이다. =_=;;

  • 로그인 하지 않아도 기본적으로 편집기에서 지정된 글꼴을 바로 따라가기 (내장 글꼴은 너무 빈약하니.. -_-)
  • 최근에 사용했던 연습글과 타자 위치 등을 기억하기
  • 세벌식 최종 자판에만 존재하는 참고표나 가운뎃점을 편의상 딴 걸로 바꾸는 옵션..
  • 게임은 꼭 단계가 바뀌지 않아도 같은 단계의 후반부로 갈수록 글자 떨어지는 속도를 다음 레벨에 근접하게 서서히 올리기

요런 것들 전부나 일부를 생각 중이다. 다 반영된다면.. 4.0 충분히 되겠다. 지금이 3.93이니까.
이 참에 연습글로 추가해 넣을 만한 최신 인터넷 밈이나 개드립이 있는지 모르겠다. 오징어 게임 대사라든가.. ㄲㄲㄲㄲ 이것도 모집한다.
이런 거 연습글이 반응이 아주 좋은가 보다.. ^^ 한쪽에는 성경이나 우리나라 근현대사 얘기가 있는데 한쪽에서는 "어둠에다크에서.." 연습글이 있다니 분위기가 완전 깬다.

Posted by 사무엘

2024/01/13 08:35 2024/01/13 08:35
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/2252

다음 버전 개발 근황

날개셋 한글 입력기 10.5가 공개된 지 벌써 2개월이 훌쩍 지났고 3개월이 돼 간다.
다음 버전은 내년 초쯤으로 계획하고 있다. 현재까지 작업된 것 중에는 딱히 완전히 새로운 기능은 없다. 그보다는 이미 제공되고 있는 기능을 제대로 구현하고, 자잘한 버그를 잡고 완성도를 높인 것의 비중이 더 크다.

1. 편집기: 위치만 다르고 이름이 동일한 파일을 여러 개 열었을 때의 식별 방식 강화

날개셋 편집기는 문서창에 자기가 다루는 파일 경로에서 디렉터리를 생략한 실제 이름만을 제목으로 표시한다.
그런데 이렇게 하면, 디렉터리는 다르고 이름은 동일한 파일을 여럿 열 경우 문제가 생긴다. 여러 창들의 제목이 동일하게 겹쳐서 사용자가 원하는 문서창을 고르기가 어려워진다. 그렇다고 파일의 전체 경로를 언제나 표시하면 당연히 너무 길고 거추장스럽고 지저분해진다.

그래서 이번 버전에서는 이 로직에 대대적인 공사를 했다.
위치만 다르고 이름이 겹치는 파일이 한꺼번에 열린 경우, 변별이 되는 가장 가까운 상위 디렉터리의 이름을 같이 출력하게 했다.

일례로, C:\a\b\foo.txt라는 파일을 열면 처음엔 foo.txt라고만 제목이 붙는다.
그런데 이 상태로 C:\foo.txt를 추가로 열면.. 각각 b\foo.txt와 C:\foo.txt라고 제목이 바뀐다.
둘 중 한 문서를 닫으면 다른 문서창의 제목은 다시 foo.txt라는 간단한 형태로 돌아온다.

저 두 파일이 있는 상태에서 C:\c\b\foo.txt와 C:\c\x\foo.txt를 추가로 열면..
b\foo.txt만으로도 변별이 안 되는 쌍이 생긴다. 그렇기 때문에 이들은 각각 a\...\foo.txt와 c\...\foo.txt 라고 바뀐다.
그러나 C:\foo.txt는 변함없으며, b 말고 x라는 경로는 겹치지 않기 때문에 ... 없이 x\foo.txt 라는 제목이 부여된다.

사용자 삽입 이미지

왼쪽이 before, 오른쪽이 after이다.
자잘하지만 실용적인 가치가 높은 동작 개선 작업이 무려 2023년이 돼서야 진행됐다.
저런 창 제목뿐만 아니라, 파일 메뉴 아래에 뜨는 "최근에 열었던 파일 목록"(MRU)에서도 동일한 디렉터리 구분 알고리즘이 적용됐다.
이름이 동일한 파일들을 한꺼번에 열 때 이런 동작이 크게 도움이 될 것이다.

2. 제어판의 글쇠배열 UI

  • 글쇠에다 문자를 배당하는 모드일 때는 우리 자체 입력 엔진뿐만 아니라 운영체제 IME로부터도(빈 입력 스키마 지정) 문자를 배당할 수 있는데.. 이때 한자 변환을 선택하면 후보창이 선택막대가 있는 글쇠의 아래에 딱 맞춰 표시되게 했다. 무슨 말이냐 하면 이렇게 말이다.
    사용자 삽입 이미지
  • 반대로 이동 모드일 때는 운영체제 IME가 꺼진다. 이때는 운영체제 IME가 한글 모드였더라도, 글쇠를 누르면 한글이 입력되는 게 아니라 정확하게 그 글쇠로 선택막대가 이동하게 했다. '글쇠 누름'(KY) 날개셋문자를 입력받는 모드일 때도 마찬가지이다.

3. 세로쓰기 상태에서 외부 모듈의 한자 변환 UI의 개선

외부 모듈은 날개셋 편집기나 MS Word 같은 프로그램에서 세로쓰기를 하고 있으면 한자 선택 UI도 세로쓰기 형태로 표시된다. 이런 동작 자체는 오래 전부터 제공되었지만, 다음과 같이 버그가 수정되고 동작이 개선되었다.

사용자 삽입 이미지

  • 글자가 굴림이 아니라 맑은 고딕일 때는 왠지 딱 정중앙이 아니라 한데 삐딱하게 치우쳐서 표시되는 것 같았는데.. 이걸 드디어 수정했다. 위의 그림에서 위와 아래의 차이를 참고할 것.
  • 스크롤바를 클릭하거나 드래그 한 것이 언제부턴가 인식되지 않고 있었다. 이 문제를 해결했다.
  • 그리고 멀티모니터 환경에서 주 모니터보다 왼쪽.. 즉, x 좌표가 음수인 모니터에서는 한자 선택 UI가 글자의 왼쪽이 아니라 오른쪽에 잘못 표시되던 문제가 있었다. 이를 해결했다.

4. 휠 클릭 자동 스크롤 관련 glitch들

날개셋 한글 입력기에서 제공하는 자체 에디트 컨트롤이나 문자표 등, 스크롤 가능한 GUI 요소들은.. 다들 마우스 휠을 클릭했을 때(굴리는 게 아니라) 앵커가 나타나면서 자동 스크롤 모드로 진입하는 게 있다.
얘는 기능 자체는 아주 오래 전부터 제공되어 왔지만, 제공되는 환경에 따라 미묘하게 일관되게 동작하는 게 있어서 개인적으로 찝찝하게 느껴 왔다. 너무 자잘한 사항 같지만 드디어 이제야 개선했다.

  • 대화상자에 있는 컨트롤에서 자동 스크롤(예: 문자표 대화상자)을 진행하던 중에 엔터나 ESC를 누르면 자동 스크롤만 종료되어야 한다. 하지만 지금까지 그 키가 대화상자의 확인/취소 명령에 그대로 전달되어서 대화상자가 통째로 종료되곤 했다. 그렇게 되지 않게 조치를 취했다.
  • 휠을 눌렀다가 바로 떼는 게 아니라, 마우스 포인터를 움직여서 스크롤을 좀 시키고 나면.. 눌렀던 휠을 떼는 순간 자동 스크롤이 바로 종료되곤 한다. 이게 다른 컨트롤에 대해서는 동작하는데, 보조 입력 도구(부수로 한자 입력, 이모지 등)에서 자동 스크롤을 그렇게 하면 자동 스크롤 종료가 동작하지 않았다. 이때도 동일하게 동작하게 조치를 취했다.

5. Neo둥근모 폰트 추가

'달고나'(본명은 정 은빈 님?)라는 분이 만든 'Neo둥근모'의 영문 글꼴을 추가했다.
Neo둥근모는 날개셋 편집기에서 제공하고 있는 그 김 중태 원작 둥근모 폰트를 오늘날 운영체제에서 사용 가능한 트루타입 형태로 변환하고, 한글과 잘 어울리는 풍의 영문· 숫자 글립까지 추가한 작품이다.

사용자 삽입 이미지

다만, 곡선을 넣은 게 아니라 비트맵 픽셀을 기계적으로 변환했다는 점을 감안해야 한다. 크기를 키우면 계단 현상이 그대로 나타난다. 힌팅 같은 것도 없다. 이건 디자이너가 아니라 프로그래머가 만든 폰트인 티가 팍팍 난다.

그럼에도 불구하고 영문· 숫자 폰트는 뭔가 게임 UI 폰트 같으면서도 매끄럽고 코딩용 폰트로 어울리고, 무엇보다 기존 한글 둥근모 글꼴과도 아주 잘 어울리는 것 같다. 잘 만들었다. 날개셋 편집기 같은 프로그램에도 딱 맞는 용도이다.
그래서 이 폰트를 내 프로그램의 비트맵 폰트로도 넣어서 제공하고, 원 제작자와 출처를 프로그램 도움말에다가 집어넣었다.

6. 편집기: 자잘한 개선 사항

(1) 편집기에서 한글을 입력하던 중에 Ctrl+S를 눌러서 저장 명령을 내리면.. 조합을 종료하고 나서 해당 텍스트 파일이 저장되게 했다. 이게 정상인데 내 프로그램은 지금까지 그렇게 동작하지 않았다.
그러면 파일을 저장하고 나서 cursor 이동으로 인해 그 한글 조합이 종료될 때, 문서가 또 불필요하게 수정 상태로 바뀌기 때문에 사용자에게 심리적으로 깔끔한 느낌을 못 준다.

(2) 파일 메뉴의 하단에 예전에 열었던 파일이 표시되는 것처럼.
편집 메뉴의 하단에는 예전에 사용했던 텍스트 필터가,
보기 메뉴의 하단에는 예전에 골랐던 입력 도구가 표시되어 사용자가 바로 선택할 수 있게 했다.

사용자 삽입 이미지

(3) 날개셋 편집기에서 문서 저장과 관련해서 가장 자주 보게 되는 확인 질문은 아무래도 변경된 닫을 때 나오는 "저장할까요?" 질문일 것이다. 하지만 이 프로그램은 단순히 그럴 때 말고도 파일이 외부에 의해 수정됐을 때, 인코딩 변환 과정에서 깨진 문자가 있을 때처럼.. 저장하거나 저장하지 않음으로써 이 문서나 기존 파일의 정보가 날아갈 우려가 있는 모든 상황에서 다양한 확인 질문을 한다.

사용자 삽입 이미지

다음 버전에서는 파일이 외부에 의해 변경됐을 때의 확인 질문이 저렇게 더 세분화될 예정이다.
그리고 '모두 저장'이나 '끝내기, 모든 창 닫기'처럼 여러 파일들을 한꺼번에 처리할 때.. 같은 종류의 확인 질문은 별도의 체크 박스를 통해 모두 무시할 수 있게 했다. 현재는 "변경 내용을 저장할까요?" 질문만을 무시 가능하기 때문이다.

7. 나머지 자잘한 개선 사항

(1) 날개셋 제어판 창은 크기 조절이 된다. 그런데 창을 옆으로 쭉 키우다 보면, 일부 컨트롤은 테두리에 잔상이 남으면서 보기 흉해지는 경우가 있었다. 특히 '낱자 처리'나 '최종 변환'처럼 ( ) → ( ) 형태의 컨트롤이 있는 탭을 열고 크기 조절을 해 보면 문제를 더 분명하게 확인할 수 있다.

사용자 삽입 이미지

이건 10년 이상 이 프로그램의 역사와 함께했던 고질병인데.. 이번 버전에서야 드디어 원인이 파악되고 소스 코드 한 줄만 달랑 고침으로써 해결됐다.
각종 컨트롤들이 재배치됐을 때, 클라이언트 영역만 다시 그리는 게 아니라 말 그대로 테두리 같은 non-클라이언트 영역도 다시 그리게 했어야 했다. 이걸 몰라서 엉뚱한 부분만 의심하면서 오랫동안 삽질을 했었다. -_-;;
이 버그? glitch가 드디어 해결되니 속이 무척 후련하다.

(2) 현재 날개셋 한글 입력기는 외국인을 위해서 설치할 때 '한글 로마자' 입력 방식을 곧바로 맞추도록 하는 옵션이 제공된다.
그런데, 이 옵션을 선택하면 프로그램의 UI도 운영체제의 기본 언어나 이전 프로그램 설정과 무관하게 영어로 기본 제공되게 프로그램 동작을 보강했다. 이렇게 하는 게 논리적으로 타당할 것이다.

Posted by 사무엘

2023/08/27 08:35 2023/08/27 08:35
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/2200

날개셋 한글 입력기 10.5

날개셋 한글 입력기 10.5가 당초 예상보다 일찍 완성되고 공개됐다. 다음 버전 개발 근황을 올리고서 곧바로 다음 버전 완성 공지를 올리게 될 줄이야.. =_=;;
문서에다가는 6월 1일이라고 기재했지만 사실 그 전날 아침에 미리 올라왔다. 타자연습은 변함없으며 API 역시 호환된다.
오랜 작업의 결과물이 드디어 세상에 publish되니 개인적으로 몹시 홀가분하고 기쁘다.

UI 쪽의 변화 사항에 대해서는 이미 지난번 글에서 자세히 소개했다. 편집기를 사용하지 않고 외부 모듈만 라이트하게 사용하는 분이라면 변화 사항들이 그리 와 닿지 않을지 모르겠다. 하지만 이번 버전에서는 외부 모듈의 안정성도 향상된 게 있기 때문에 버전업이 누구에게나 의미가 있을 것이다.

이 글에서는 새로운 기능 소개 말고 외부 모듈 관련 이슈, 그리고 개발 관련 다른 잡다한 썰들을 늘어놓도록 하겠다.

1. Google Chrome + Google Docs 에서 한글 조합이 덧나는 문제: 해결

크롬 브라우저에서 주소 입력란이나 웹페이지 내부의 일반적인 텍스트 입력 폼에서는 괜찮은데.. 유독 Google Docs를 열어서 문서를 편집할 때 자잘한 문제가 또 있었다.
거기서 내 프로그램으로 한글을 입력하던 중에 마우스로 딴 데를 클릭하면.. 조합 중 글자가 덧나는 문제가 여전히 남아 있었다. 이 버그는 지금까지 거의 네댓 분으로부터 거듭 신고를 받았다.

수 년 전, 크롬 브라우저가 버전 70대이던 시절에도 비슷한 문제가 있었다. 그때는 내 쪽에서 동작을 수동 보정해서 회피했는데.. 또 크롬에서 자체적으로 버그를 고치기도 한 것 같아서 보정 동작을 삭제했다.

그런데 예전에 만들어 놨던 보정 로직을 되살려 보니까 Google Docs 문제는 해결되지만, 크롬의 다른 입력 창에서는 이제 글자가 덧나는 게 아니라 멀쩡한 글자까지 지워져 버리는 부작용이 발생했다. =_=;; 동일 프로세스에서 서로 다른 에디팅 엔진을 사용하다니.. 더 똑똑한 로직을 새로 개발하는 게 불가피해졌다.

다른 마소 IME, 한컴 입력기, 나빌 입력기는 괜찮은데 내 프로그램에만 이런 버그가 있는 이유는..
내 프로그램은 조합이 외부에 의해 종료될 때 조합 중 문자열을 다시 써 주는 동작이 있기 때문이다.
이걸 생략해 주니 크롬의 두 입력 환경에 모두 오류 없는 입력 동작을 구현할 수 있었다. 수동 보정으로 문제를 해결했다.

저 동작이 꼭 필요한 입력 방식은 초성 지향 두벌식이라고 '한'을 먼저 '하ㄴ'이라고 표시했다가 조합이 외부에 의해 종료됐을 때 '한'으로 바꿔서 확정짓는 소수의 특이한 방식 말고는 거의 없다.
바꿔 말하면 Chrome이나 Edge 브라우저에서는 한 메이저한 버그를 보정하기 위해서 다른 마이너한 부작용을 남겼다.

2. 자주 받은 문의: 비조합 문자를 입력할 때의 문제

저 버그 신고 말고 본인이 자주 받은 문의는 이것이었다. 내 프로그램으로 콜맥 같은 영문 글자판을 사용해서 한글이 아닌 일반 문자가 Visual Studio Code라든가 몇몇 외국산 프로그램에서 제대로 입력되지 않는다는 거.

이건 명백하게 내 프로그램이 아니라 해당 프로그램들이 IME 지원이 미흡해서 발생하는 현상이다. 기존 MS 한글 IME로도 두벌식이 아닌 세벌식으로 숫자나 기호를 입력해 보면 100% 똑같이 발생한다.
서구권에서 살다 보니 IME라는 게 뭔지 몰라서 IME로부터의 지시는 무조건 한글처럼 조합을 만드는 형태밖에 없다고 생각한 게 아닌가 싶다.

그러므로 원래는 그 프로그램이 고쳐져야 마땅하다. 그러나 내 프로그램 쪽에서 문자를 보내는 방식을 바꿔서 문제를 회피할 수는 있다.
그 글자를 IME 방식으로 보내는 게 아니라 일반적인 키보드 메시지 형태로 보내게 하는 거다. 걔들은 어차피 한글도 아니니까.

글쇠배열 편집기에서 "전체 간소화 - 문자를 글쇠 누름으로" 기능을 알려 드렸더니 문제가 잘 해결됐다고 회신이 왔다.

3. Visual Studio 검색란에서 한자 선택 UI: 해결 불가

이건 사용자로부터 문의를 받은 건 아니고 본인이 자체적으로 발견하고 파악한 현상이다.
개발툴 Visual Studio에서 일반적인 텍스트 에디터 말고 Ctrl+Q로 접근하는 짤막한 한 줄짜리 검색란은 뭔가 비범한 환경인 것 같다. 10년쯤 전 엄청 옛날에도 여기서만 한글 입력이 제대로 진행되지 않던 문제가 있어서 해결했던 기억이 나는데..

여기서 한자 선택 UI를 꺼내면 마우스를 클릭해도 UI가 전혀 동작하지 않고 그냥 사라져 버렸다.
이건 마소 IME 등 어떤 IME를 써도 마찬가지이기 때문에 내 프로그램의 문제는 아니다. 도대체 무슨 동작을 하는지는 모르겠지만 마우스 hook이라도 설치하는가 보다.
그런데 마소 IME는 그냥 곱게 꺼지기만 하는데, 내 프로그램은 몇 번 써 보면 프로그램이 뻗기까지 해서 문제..

디버깅을 해 보니 프로그램 상태가 외부에 의해 불가항적으로 통제 불가능한 상태로 바뀌는 것이어서 뭘 해 볼 수 있는 게 없다.
그래서 이건 불가피하게 해결 불가로 남기고, 도움말 "알려진 문제"에다가 언급만 해 놨다.

4. 잡설: 원고지 떡밥

문득 떠오르는 생각인데.. 날개셋 편집기에 원고지 형태 인쇄 기능은 넣기에 굉장히 적절한 기능인 것 같다. 얘는 서식을 전혀 지원하지 않는 쌩짜 plain 텍스트 편집기임에도 불구하고 프로그래머 코딩보다는 자연어 텍스트의 입력에 더 맞춰져 있으며, 취급하는 문자도 형태가 전각 아니면 반각밖에 없어서 문자 배치가 아주 간편하기 때문이다.

그러니 기능이 너무 많은 워드 프로세서보다는 이런 프로그램에다가 원고지 인쇄 기능을 넣는 게 원론적으로 훨씬 더 나을 것이다.
하지만 현실적으로는 이제 원고지라는 물건 자체가 거의 쓰이지 않으니 만들어도 쓸모가 별로 없다. 굳이 이런 기능을 구현하고 싶지는 않다.

텍스트 파일을 읽어서 원고지 형태로 인쇄하는 기능 구현은 Visual C++ / Windows API 프로그래밍 실습용으로도 적당할 듯하다. 그래픽, 인쇄, 각종 좌표 계산과 문자열 문단 정렬, 금칙 처리 같은 것들이 두루 동원되기 때문이다.

5. 나머지 남은 얘기들

(1) 이번 10.5 버전에서는 도움말 "감사의 글"에 공 병우 박사뿐만 아니라 송 현 선생도 최초로 언급하기 시작했다. 이분도 돌아가신 지 벌써 1년이 넘었으니 말이다. 정작 2022년에는 프로그램 버전업이 한 번도 없었기 때문에 지금까지 이 문구가 들어갈 기회가 없었다.

사용자 삽입 이미지

(2) 오랫동안 버전업이 없던 동안에도 꾸준히 후원을 해 주신 분들께 정말 감사드린다. 요 며칠 전에도 후원이 들어왔다.
하지만 10.5 작업을 해 보니 본인의 코딩 감각은 여전히 죽지 않았다는 걸 개인적으로 확인할 수 있었다. ^^

(3) 다음 버전은 올해 가을이나 겨울 연말쯤에 10.7 정도로 잡고 있다. 편집기, 제어판, 보조 입력 도구 곳곳에 이번에 다 완료하지 못한 UI 개선을 반영하고.. 여유가 되면 좀 더 어려운 성능 최적화도 할 예정이다. 작업 리스트는 다 마련되어 있다.

Posted by 사무엘

2023/06/01 08:35 2023/06/01 08:35
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/2167

다음 버전 개발 근황

날개셋 한글 입력기의 차기 버전 10.5가 현재 거의 완성 직전이다. 목표는 늦어도 다음달 6월 초-중쯤.. 10.4가 나온 지 벌써 1년 반이 돼 간다만.. 이 프로그램은 개발이나 유지 보수가 중단된 게 절대 아니다. ^^
엔진이 바뀐 건 없지만 각종 UI와 기능들이 아주 많이 바뀌고 개선되었다. 거기에다 외부 모듈의 버그 수정과 불편 사항 건의가 반영될 것이다. 특히 크롬+Google Docs에서 조합 중인 한글이 덧나는 문제는 여러 번 신고가 들어왔기 때문에 조치를 취하는 중이다.

10.5 이후의 그 다음 버전에서 더 진지하고 더 무거운 새 기능들이 구현돼 들어갈 것이다.
예나 지금이나 프로그램 개발은 즐겁다. 아무쪼록, 어서 새 버전이 완성돼서 지금 작업 완료된 기능들이 사용자에게 제공됐으면 좋겠다.

1. 편집기: 텍스트 import 기능에서 UTF-8 지원

편집기에는 콘솔 프로그램의 실행 결과를 가져오는 기능이 먼 옛날부터 제공되고 있었다. (2004년, 3.0부터.. ㄷㄷ)
실행할 프로그램 파일명과 실행 인자를 따로 줘도 되고, 아니면 파일명은 비워 놓고 실행 인자에다가 파일명과 인자를 한꺼번에 써 줘도 된다.

후자처럼 하면 프로그램을 실행하는 게 아니라 SET, PATH, DIR 같은 도스 명령을 실행해서 결과를 가져올 수도 있다. 얘는 프로그램을 실행하는 게 아니라 명령줄을 실행하기 때문이다. 그 명령줄에 프로그램을 실행하라는 명령이 들어갈 수도 있는 것이다.
그런데 이렇게 하면 경로와 인자에다가 시스템 기본 코드 페이지에 존재하지 않는 유니코드 문자를 넘겨줄 수 없다는 단점이 있었다. 지금까지는 말이다.

허나, Windows 10 이후로 운영체제의 추세가 잡다한 재래식 multibyte 코드 페이지들에 대한 인지도를 낮추고, multibyte 환경에서는 UTF-8을 기본으로 제공하는 쪽으로 가고 있다. 2017~19?? 그래서 내 프로그램에다가도 Windows 10 이상에서 동작할 때는 명령줄을 UTF-8 인코딩으로 전달하는 옵션을 추가해서 사용할 수 있게 했다.

이 옵션을 주면 DIR을 했을 때, 한글판 기준 cp949에 없는 문자가 들어간 파일/디렉터리 이름도 정상적으로 볼 수 있다. 또한, 그런 파일 이름을 찾도록 지정할 수도 있다. 단, 이 옵션을 주면 명령 프롬프트의 기본 UI가 한국어 같은 지역 언어가 아니라 그냥 영어로 통일된다.

사용자 삽입 이미지

아울러, 콘솔 프로그램이 아니라 URL 가져오기 모드에서 이 옵션을 켜면.. URL에서 알파벳· 숫자가 아닌 타 문자(한글 등)를 자동으로 UTF-8 기준으로 % encode 하게 했다. euc-kr 같은 타 인코딩으로 encode해야 하면 그건 사용자가 수동으로 해야 한다.

2. 편집기: 다른 대화상자들

(1) 편집 화면 설정의 화면색에 '어두운 회색, 어두운 자주색(우분투), 옅은 파랑'을 추가하고, 완전 백색보다 약간 어두운 '아래아한글 2.x' 색상도 추가했다.
아래아한글은 1.x 시절엔 파란 바탕 흰 글자였지만, 컬러를 지원하기 시작한 2.x부터 흰 바탕 검정 글자로 바뀌었다. 그런데 이게 완전 순백 화이트가 아니라 회색에 가깝게 어두운 화이트가 디폴트였다. 뭐, 이게 너무 눈부시지 않고 장시간 작업하기에 좋긴 하다. 옛날 생각도 나고.. ^^
Windows와 보조를 맞추기 시작한 아래아한글 3.0부터 배경이 순백 화이트로 바뀌었다.

(2) 아울러, 지난 10.4부터 블록의 색깔을 4종류 중 하나로 customize하는 기능이 추가됐는데.. 색상 설정을 바꾸면 블록의 실제 색깔이 어떻게 바뀌는지도 대화상자에서 직접 눈으로 확인할 수 있게 했다.

사용자 삽입 이미지

(3) 쪽 설정 대화상자의 컨트롤들을 "글자 - 문단 - 종이"의 순으로 스케일이 커지게 배치했다. 그리고 머리글과 바닥글의 입력란에서는 & 변수들의 종류가 풍선 도움말로 표시되게 했다.

사용자 삽입 이미지

(4) "도구 - 분량 계산 메뉴" 명령은 블록을 잡지 않았을 때도 사용 가능하고, 이 경우 텍스트 전체를 대상으로 시행하도록 했다. 워드 프로세서에서 제공되는 텍스트 분량 표시 기능을 생각하면 진작에 이렇게 동작 가능했어야 했다.;;

3. 편집기: 메뉴

(1) 단축키로만 존재하던 명령들.. Shift+F3(뒤로 탐색), Alt+K(상용구 치환), Alt+L(탐색기에서 복사한 파일의 이름 삽입)을 모두 메뉴에다 정식 등재했다.
사실, 파일 이름 삽입은 기존 Ctrl+V 붙이기 기능과 통합하는 게 가장 좋긴 한데.. 편집기에서 제공하는 붙이기 기능과, 날개셋 에디트 컨트롤이 자체 제공하는 붙이기 UI가 서로 연계하는 게 쉽지 않아서 그냥 이렇게 놔 뒀다.

(2) 파일 메뉴의 하단에 표시되는 '최근 사용 파일'이 겉으로는 8개까지 표시되지만, 내부적으로는 그게 전부가 아니라 2배에 가까운 14개까지 관리되게 했다. 그래서 지금 메뉴에서 파일 하나가 없어져서 삭제된다 하더라도, 뒤에 밀려나 있었던 9순위 파일이 마지막 8순위로 당겨져 올라가게 된다.

(3) 창 메뉴의 하단에 표시되는 창 목록들에서 현재 활성화된 창은 체크 √가 아니라 ⊙ 불릿 마크로 표시되게 했다. 체크는 복수 개의 on/off이지만 불릿은 n개 중 단 하나만 선택되는 UI 요소이기 때문이다. 저 상황에서는 불릿 마크가 더 적절하다.

4. 에디팅 엔진

(1) home 키를 눌렀을 때 무조건 첫 칸으로 가는 게 아니라, whitespace를 건너뛴 첫 칸으로 가도록 동작을 수정했다. 이미 그 칸에 있을 때 home을 누르면 진짜 첫 칸으로 간다.
이건 워드 프로세서보다는 프로그래머용 텍스트 에디터에 더 특화된 동작이다. 이렇게 하는 게 더 나은 것 같다.

(2) 저건 당연히 날개셋 편집기 같은 multi line일 때의 동작이다. 반대로 single line일 때는 불필요하게 ctrl+드래그를 해도 multi-selection이 되지 않게 하고, 일본어 문자나 한자에 대한 툴팁도 동작하지 않게 했다. 이건 기능 추가나 개선이 아니라 그냥 사소한 변경이다.

(3) 세로쓰기 모드일 때 일본어에서 길쭉한 전각 장음 부호가 가로줄이 아니라 세로줄로 나오게 폰트 모양을 수정했다. 역시 개발자가 외국어에 대한 식견이 넓어져서 필요를 느껴야 이런 걸 반영하게 된다. -_-
그리고 라틴 알파벳뿐만 아니라 키릴 문자와 그리스 문자도 단어 단위로 wrap이 되게 했다. 아래 그림에서 X이던 게 O로 바뀌었다는 뜻이다. ^^

사용자 삽입 이미지

5. 제어판: 최종 변환 규칙에서 여러 내정값을 한꺼번에 가져오기

제어판 - 편집기 계층 - 최종 변환 규칙을 보면 내정값으로 전각 문자, 호환용 한글 낱자 같은 몇몇 predefined set이 있다. 내정값을 가져오면 지금 있는 설정들은 모두 없어지고, 규칙 전체가 그 내정값으로 대체된다. 즉, A=B처럼 된다.

그러나 새 버전에서는 내정값을 Ctrl이나 Shift를 누른 채 마우스 클릭이나 화살표 키를 이용해서 지정하면.. 규칙을 그 내정값으로 통째로 대체하는 게 아니라, 지금 규칙에다 그 내정값을 추가할 수 있게 했다. 이 경우, A+=B와 비슷한 형태가 된다.

이제 "전각 문자 + 호환용 한글 낱자"처럼 여러 내정값 규칙을 동시에 사용할 수 있게 됐다. 이것도 진작부터 필요를 느끼고 있었는데 간단한 UI 조작만으로 드디어 가능해졌다.
기존 규칙과 새 내정값이 충돌할 수 있다. 현재 A라는 문자를 B로 치환하게 되어 있는데 새 내정값에는 A를 C로 바꾸라는 규칙이 있는 것 말이다. 이때 Ctrl은 새 내정값으로 대체하는 반면, Shift는 그건 대체하지 않고 놔 둔다.

날개셋 한글 입력기의 각종 대화상자에는 ctrl+클릭을 했을 때 동작이 미묘하게 달라지는 게 지금까지 은근히 많이 들어갔다. 하지만 ctrl을 눌렀을 때 뭔가 시각적인 피드백이 나오는 게 없는 게 좀 아쉽다. 이건 운영체제 차원에서 넣기가 쉽지 않아 보인다. 장기적으로 좀 생각을 해 봐야겠다.

6. 제어판: 나머지

(1) 글쇠배열 편집 화면에서.. 매번 대화상자를 꺼내지 않고 글쇠를 클릭만 해도 그 자리의 수식과 수식값을 아래에서 확인할 수 있게 했다.
앞으로 글쇠배열 편집기에도 아이템의 복수 선택, 아이템 이동 등 여러 편의 기능들이 더 구현되고 지원될 것이다.

사용자 삽입 이미지

(2) 입력 항목의 순서를 나타내는 이 입력란에서는 위가 아니라 아래 화살표를 눌러야 숫자가 커지고 목록에서 '아래'로 내려가도록.. 더 직관적으로 동작하도록 로직을 수정했다~!!
이거 진작부터 이렇게 하고 싶었는데 기술적으로 가능하다는 걸 아주 최근에야 확인했다.

(3) 날개셋문자를 입력받는 대화상자에서 왼쪽을 보면 날개셋문자의 종류(type)가 트리 계층 구조로 표현되어 있다. 이 중에서 그 자체가 독립된 타입이 아니고 하위 타입들을 분류만 하는 명칭인 '한글 조합'과 '비문자'는 진하게 표시되게 했다.

(4) 설명문을 작성하는 대화상자에 '글쇠배열에 대한 설명문, 입력 항목에 대한 설명문, 설정 전체에 대한 설명문'이라고 제목을 더 세분화했다. 그리고 한글 로마자 입력기도 표준 로마자 표기법을 제외한 나머지 방식에 대해서는 "한글 로마자 Qwerty (HWP, 북한, 공진청)" 등 세부 규칙이 이름에 추가되게 했다.

(5) 세벌식 390은 / 자리가 한글을 입력 중일 때만 ㅗ이고, 그 외의 상황에서는 /가 그대로 입력되는 형태이다. 그런데 이 상태로 복벌식 빠른설정을 적용하고 나면 그 수식이 사라져 버리고 문자가 /로 고정되곤 했다. 이 동작을 개선해서 / 자리는 390 + 세벌식 한글 입력 중일 때 ㅗ, 그 외의 상항에서는 / 로 제대로 처리되게 했다.

7. 보조 입력 도구

(1) '조합 안에 조합 생성' 입력 도구에서 빈 입력 스키마 경고가 쓸데없이 자꾸 출력되지 않게 조치를 취했다. 영문(빈 입력 스키마) 모드일 때는 한번 나타나긴 하지만 한글 모드로 전환하면 없어진다. 그리고 이걸 아예 표시하지 않게 하는 옵션도 추가했다.
이 입력 도구를 유용하게 쓰면서 한자어를 평소에 많이 입력하고 계신다는 분이 건의를 하셨다.

(2) '수식 계산 기록'에서 오토마타 수식에 대한 계산 기록이 찍힌 경우, 이때의 오토마타 상태와 설명문도 같이 표시되게 했다.

(3) '필기 인식'이 한중일뿐만 아니라 대만 번체 인식기도 인식하여 지원하게 했다.

(4) '부수로 한자 입력'에서 한자를 우클릭하면 이 글자의 간체자/번체자로 바로 이동하는 기능을 추가했다(그런 한자가 존재하는 경우). 호환용 한자를 찍으면 그 글자의 표준형 글자도 안내해 준다.
단, 이 간체/번체 변환은 운영체제에서 제공하는 기능을 사용해서 동작하며, BMP 영역 글자만 지원하고 오류도 제법 있다. 그냥 없는 것보다 나은 참고용으로만 사용 가능한 퀄리티이다.

사용자 삽입 이미지

(5) 현재 문자표나 한자 부수처럼 테이블 기반으로 문자를 입력하는 입력 도구들에는 우측 상단에 '↔' 버튼이 있다. 얘를 누르면 문자를 본문에다 삽입하는 게 아니라, 반대로 본문의 cursor가 가리키고 있는 문자 그 표에서 찾아서 표시해 준다. 그래서 처음 보는 한자에 대해서 ↔를 누르면 이 한자의 부수와 획수를 바로 알 수 있다.

그런데 이 기능은 cursor의 글자를 얻어 올 수 없는 환경에서는 사용할 수 없다. 지금까지는 이때 에러 메시지만 출력하고 끝이었지만, 이제는 그런 환경에서는 ↔ 버튼 자체가 없어지고 표시되지 않도록 동작을 수정했다.

8. 버그 수정

(1) 이전 10.4 버전은 '고급 입력 스키마'의 고급 글쇠 인식 기능을 사용하다 보면 keydown 이벤트에서 앱이 뻗는 경우가 있었다. 이걸 사용하는 분이 계신다면 이 긴 시간 동안 분명히 버그 신고를 하셨을 텐데... 본인에게 지금까지 신고가 들어온 건 없었다. 이건 내가 자체적으로 발견해서 고쳤다.

(2) 편집기에서 문서 줄 수가 32767 줄을 초과해서 32K~64K 사이에 있을 때, Ctrl+G 줄 번호 대화상자를 열면 번호가 음수로 잘못 표시되던 문제가 있었다. 이걸 고쳤다.

9. 도움말

(1) 'I. 일러두기'와 '부록 - 예제 데이터 소개'를 세분화했다.
전자의 경우 '개발 방향', '책임 범위', '사용자의 참여'로 아이템들을 나눴으며, 후자는 '세벌식 한글, 두벌식 한글, 나머지 외국어/특수문자'로 나눴다. 이렇게 해 주니 보기가 훨씬 더 좋다.

사용자 삽입 이미지

(2) 입력 도구들 중에 '문자표'와 '부수로 한자 입력'은 지금까지 자신만의 도움말이 없었는데 이번에 추가했다.
사용법이 너무 자명해서 특별히 쓸 게 없다고 여겨져서 생략했던 건데.. 정작 도움말 글을 써 보니 그렇지 않았다. 고유한 동작 방식을 설명하다 보니 한 페이지 정도는 너끈히 분량이 나왔다. =_=;;

10. 예제 데이터의 수정· 보강

(1) 북한 표준 방식에 ㅓ+ㅣ=ㅔ, ㅏ+ㅣ=ㅐ 만 있지, ㅘ+ㅣ=ㅙ, ㅝ+ㅣ=ㅞ 는 빠져 있는 걸 확인해서 보충했다.

(2) 초성 ㄸㅃㅉ과 종성 ㄳㄶㄻ을 동일한 자음 글쇠로 모두 입력할 수 있는 변칙(?) 두벌식 예제를 추가했다. 몇 년 전에 이 블로그에서 다룬 적이 있었는데, 이걸 예제로도 정식으로 추가했다.

(3) 끝으로, Google 단모음은 초· 종성뿐만 아니라 중성도 일정 시간이 지나면 ㅏ+ㅏ=ㅑ, ㅓ+ㅓ=ㅕ처럼 동일한 낱자 연타는 되지 않게 하는 로직을 추가했다.
그러니 얘는 초중종 모든 입력 상태에 타이머가 필요해졌다. 중성의 동일 연타 차단은 오토마타 수식에서 B==E인 경우를 보면 되니 아주 간단히 할 수 있다.

Posted by 사무엘

2023/05/29 08:35 2023/05/29 08:35
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/2166

1. 잉카 제국과 한글

작년 한글날 무렵엔 무려 페루에서 사시는 외국인이 내 프로그램으로 한글 로마자 입력 방식을 잘 사용하고 있다고 감사 겸 문의 연락을 주신 적이 있었다. 먼 옛날에 중남미에 사시는 교민에게서 연락이 온 적은 있었지만 중남미 현지인으로부터의 연락은 처음이었다.
게다가 이분은 말로만 듣던 마추 픽추 유적지 근처에 사신다고..;; 잉카 제국이 만들어지고 마추 픽추 도시가 건립된 시기가 한글이 창제된 시기와 얼추 비슷하다는 얘기를 해서 나도 놀라움에 입을 쩍 벌렸다. (다들 1440~1460년 부근.. 오옷~!)

하지만 잉카 제국은 고유 문자가 없었다. 자기네 생활 노하우와 문화, 기술이 후세에 제대로 전수되지 못하고 그대로 소실됐다.
조선은 정반대로 기록 덕후여서 온갖 것들을 미주알고주알 실록으로 남기긴 했다. 단지, 한글을 적극적으로 사용하지 않고 여전히 한문으로 기록했을 뿐..

이런 얘기를 들으면서 한글 로마자 입력 방식은 국제적으로 굉장히 인지도와 수요가 높다는 것을 실감할 수 있었다.
페루 현지에서는 마추 픽추도 그냥 흔한 학교 수학여행 코스일 뿐이랜다. 우리나라로 치면 경주처럼 말이다.
그러고 보니 페루는 나스카 지상화 불가사의가 있는 나라이기도 하네~ 신비롭다. 나는 언제 저런 곳에 가 볼 일이 있을지 모르겠다.;;

2. 유아의 한글 타자

하루는 SNS에서 육아를 하고 있는 지인의 근황을 접했다.
아들이 한글을 배워서 폰으로 카톡도 하는데.. 도깨비불 현상을 이해하지 못하고 심리적으로 부담스러워해서 각 글자들을 일일이 띄어서 친다는 얘기가 개인적으로 아주 인상적으로 다가왔다.

사용자 삽입 이미지

그렇다니까~~ 두벌식은 근본적으로 직관적이지 못하다. 이런 영· 유아에게나, 한국어를 처음 배우는 외국인에게나, 아니면 기계치 어르신들한테 말이다.

타자기이든 컴퓨터이든 불문하고 한글 입력은 세벌식을 원칙으로 하고 두벌식을 보조로 삼는 쪽으로 갔어야 했다. 아무리 기계의 성능이 향상된다고 하더라도 이런 본질적인 차이가 변하지는 않는다.

3. 위험한 곳에서 사는 동포에게서

이 얘기는 오랫동안 마음속으로만 간직하고 있다가 시간이 한~~참 지난 뒤에야 꺼내 본다. 당사자의 신변의 안전을 위해서다.
하루는 한글을 조선글이라고, (글쇠)배열을 배렬이라고, 프로그램을 프로그람이라고 부르는 사람에게서 너님이 개발한 한글 입력기를 오랫동안 잘 쓰고 있다는 연락이 메일로 왔었다. 개인적으로 굉장히 놀랐다.

(1) 그 사람은 폐쇄적인 본토에서 인터넷에 직통으로 접속한 건 물론 아니고, 외화벌이를 하러 대륙으로 파견 나가 있었다. 메일 계정은 대륙의 모 포털 사이트 기반.

(2) 유 관순이 누군지, 삼일절이 뭔지 잘 모르더라. 그냥 어디서 집단 봉기를 일으켰다가 진압된 날.
쉽게 비유하자면.. 삼일 운동의 인지도가 그로부터 10년쯤 뒤인 1929년 11월 3일 광주 학생의 날의 인지도와 비슷한 수준이다. 여러분 중에 혹시 '박 준채'라는 학생 기억하시는 분 있나요? 유 관순이 그 수준이라는 거다.

(3) 무심코 내가 툭 던졌던 "주말 잘 보냈냐/쉬었냐"라는 인사를 완전 어색해했다. 그렇게 말하는 사람이 너님이 처음이었다나.
일요일에 탱자탱자 놀거나 종교 활동 하는 건 상상도 할 수 없는 사치이고.. 이때 군인이나 공무원들이나 하는 각종 환경미화와 마을 인프라 보수에 주민들이 동원된다. 주말이란 게 없다.

그 사람이 나에 대해서 느낀 점이라며 털어놓은 말은..

  • 국가관이 아주 투철하고 자기 나라를 사랑하는 분 같다. 나도 너님 앞에서 함부로 우리 공화국을 뒷담화 하지 않겠다. (ㅍㅎㅎㅎㅎㅎㅎ 내가 뭔 말을 했었길래..)
  • 종교 쪽으로 독실한 게 영화에서 본 가톨릭 신부 같다. (개인적으로 복음도 전해 봤음..)

이었다. 믿거나 말거나~~~
난 그 전까지 "국가보안법"만 있지 "남북교류 협력에 관한 법률"이란 게 있는 줄 몰랐는데, 이 일을 계기로 찾아보게 됐다.
그리고 '주 성하'라는 탈북 언론인이 있다는 걸 그쪽에서 알려 줘서 알게 됐다.

내가 한글 입력기를 개발하지 않았으면 세계 사람들로부터 이런 경험 할 일이 도무지 있겠는가..;;
후원금도 여전히 용돈 수준이나마 찔끔찔끔 들어오고 있고.. 액수보다도 빈도가 더 고마운 노릇이다. 내 프로그램이 여전히 잊혀지지 않았다는 뜻이니까.

Posted by 사무엘

2022/08/29 08:35 2022/08/29 08:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2060

날개셋 한글 입력기 10.4

2021년 하반기는.. 호박에 멧돼지에, 여친으로...
내 관심사가 너무 분산되는 바람에, 정작 직장은 그리 심하게 바쁘지 않았음에도 불구하고 한글 입력기의 개발 속도는 역대 최저를 찍었다.

그래서 반 년 만에.. 한 해의 끝을 앞두고서야 날개셋 한글 입력기 다음 버전이 나왔다. 타자연습은 변화 사항이 없으며, 바이너리 호환성도 동일하다.
지난 8월 이후로 새로 추가되거나 바뀌고 개선된 사항들을 나열하면 다음과 같다.

1. Windows 11 지원

가장 먼저.. 시대가 시대이니 새 버전은 Windows 11을 정식 지원한다. 이 버전에서만 날개셋 편집기에서 발생하는 자잘한 오동작/glitch를 좀 해결했다.
그런데 11도 API를 호출해서 얻는 내부 버전 번호는 여전히 10의 연장선일 뿐이다. 그렇기 때문에 레지스트리를 뒤지는 비공식 야메 방법을 동원하지 않으면 10과 11을 구분할 방법이 없다. 마소에서 버전 관리를 왜 이렇게 지저분하게 하는지 모르겠다.

(1) 편집기: 듀얼 모니터 환경에서 프로그램 창을 최대화 시켰다가 최소화 시키고, 이걸 taskbar의 제목을 클릭해서 다시 원상복구(= 최대화) 시켰을 때.. 가끔 최대화된 창이 모니터에 꽉 차지 않고 잘못 표시되는 문제가 있어서 해결했다.
엄밀히 따지면 내 프로그램이 특이하게 동작하는 버그가 맞긴 하지만.. 기존 로직도 Windows 10까지 한 번도 문제가 된 적이 없었다.;; 이상한 노릇이다.

(2) 편집기: 문서창의 테두리가 제대로 칠해지지 않고 지저분한 잔상이 남는 문제를 해결했다.
이 역시 XP 이래로 10까지 전혀 문제가 발생하지 않던 테두리 그리기 API가 11에서만 이상하게 오동작을 일으킨 것이었다. 어쩔 수 없이 이를 회피하는 로직을 넣어야 했다.

(3) 외부 모듈: 제어판 고급 옵션에는 자신과 연결되는 키보드 드라이버를 변경하는 기능이 있는데.. 어찌된 일인지 운영체제에 설치된 키보드 드라이버 목록이 뜨지 않고 있어서 조치를 취했다. 지금까지 아무 문제가 없던 부분이 11에서만 동작이 좀 달라져 있었다.

2. 편집기: 블록 색깔 지정

텍스트와 배경의 색깔이 각각 (x, y)일 때 블록의 색깔을 (1) 시스템 색상(그 특유의 파란 바탕), (2) RGB 반전(~x, ~y), (3) 역할 반전(y, x) (4) 열은 시스템 색상 중 하나로 사용자가 customize할 수 있게 했다.
이전까지는 원래 배경이 시스템 색상(운영체제 표준)일 때는 블록 역시 ‘시스템 색상’이 강제 지정됐고, custom 색일 때는 언제나 RGB 반전이 강제 지정되곤 했다. 이를 수동 지정 가능하게 했으며, 그러면서 ‘역할 반전’도 같이 추가한 것이다.

사용자 삽입 이미지

한 방식으로 계산된 블록 색깔이 모종의 이유로 인해 원래의 배경색과 너무 비슷할 수 있다. 특히 회색 배경은 RGB 반전을 시켜도 여전히 원래 배경과 비슷해서 구분이 안 간다. 이럴 때 ‘시스템 색상’이나 ‘역할 반전’을 선택하면 도움이 될 것이다.

운영체제의 표준 에디트 컨트롤은 전통적으로 ‘시스템 색상’을 사용 중이며, 리치 에디트 컨트롤은 한동안 ‘RGB 반전’을 사용해 왔다. 한편으로 요즘은 시스템 색상을 약간 옅게 적용한 옅은 파랑이 블록 색깔로 유행이다. 이것들을 모두 선택할 수 있게 했다. 간단한 작업만으로 프로그램의 첫인상과 사용 경험이 크게 달라질 수 있게 됐다.

3. 편집기: 나머지 자잘한 UI 변화

(1) 날개셋 편집기는 1.0 시절부터 지난 20여 년 동안 상태 표시줄에 "삽입/겹침"과 "글자/낱자"라는 구획이 있었다. 두 구획을 "삽입/겹침/[겹침]"이라고 하나로 통합했다.
ins 키와 마찬가지로 이 구획을 Shift+클릭하면 낱자 겹침 모드로 진입할 수 있다. 우클릭하면 아예 메뉴가 뜬다.
지난 10.x 버전부터 삽입/겹침 모드 전환 방식이 조금씩 바뀌기 시작했는데, 드디어 편집기와 외부 모듈이 모두 키보드/마우스까지 일치하게 됐다.

사용자 삽입 이미지

(2) 텍스트에서 블록을 잡으면 아시다시피 잡힌 영역의 색깔이 반전된다. 그런데 블록이 다음 줄에까지 계속 이어지는 경우, 앞줄은 텍스트의 실제 길이보다 한 칸 더 길게 반전된다. 텍스트가 없이 빈 줄이라도 블록에 속해 있음을 알 수 있게 하기 위해서이다.
그런데 줄이 바뀌는 게 진짜로 줄 바꿈 문자가 있기 때문이 아니라 단순히 화면으로 보기에만 wrap이 돼서 바뀐 것이라면 블록 영역이 한 칸 더 추가되지 않게 했다.

사용자 삽입 이미지

(위의 그림을 보면.. "초기화할", "선택하" 다음에는 블록도 더 잡혀 있지 않은 반면, "다." 다음에는 줄이 진짜로 바뀌기 때문에 블록도 한 칸 더 길게 잡혀 있다. 참고로 "관련", "알" 다음에는 진짜로 공백이 있기 때문에 블록도 이를 반영한 것이다.)

알고 보니.. 15년도 더 전, 2.x 버전의 편집기는 원래 '한 칸 추가'가 이렇게 조건부로 동작하고 있었다. 그런데 3.x부터는 웬일인지 '무조건 한 칸 추가'되기 시작해서 현재에 이른 것이었다. 참 신기한 노릇이다.

4. 한글 로마자 입력 빠른설정의 버그

(1) 현필 방식은 글쇠배열에 ㅡ가 없음에도 불구하고 E+U로 ㅡ를 만드는 규칙이 지금까지 지정되지 않았다. 즉, 얘로는 중성 ㅡ와 ㅢ를 입력할 수 없었다. 이 문제를 개선했다.

(2) 코리언 라이터(KW)는 한글 로마자 입력법으로서는 꽤 특이하게도.. ㄲㄸㅆㅃㅉ 쌍자음들이 모두 단독 글쇠가 할당되어 있다. 단자음의 연타나 shift가 아니니 매우 수월하게 입력할 수 있다. 음절 경계 구분 같은 입력 로직을 간소화하기 위해 이런 설계를 했나 보다.
이 특성을 살려, KW 방식에서는 초성 쌍자음에 대한 연타 결합이 들어가지 않게 했다. ㄱ+ㄱ을 하지 말고 그냥 ㄲ을 바로 누르라는 뜻에서다. 단, 초성만 그렇고 종성 ㄲㅆ은 여전히 연타로도 입력 가능하다.

(3) 지난 9.5 버전에서는 공진청 방식이라는 템플릿이 추가됐는데, 얘는 shift를 쌍자음 입력 용도로 사용하는 방식이다. 그럼에도 불구하고 이 템플릿을 골랐을 때 shift 처리가 제대로 되지 않는 경우가 있는 걸 뒤늦게 발견하여 문제를 해결했다.
shift를 쌍자음 입력 용도로 사용하는 템플릿은 공진청 방식과 북한 방식 이렇게 둘이 있다.

(4) 북한 방식은 ㅒ와 ㅖ를 Shift 자리가 아니라 ㅣ+ㅐ, ㅣ+ㅔ로 입력하도록 규칙을 수정했다.
북한은 일반 국규 글쇠배열도 쌍자음은 Shift로 입력하는 반면, ㅒ와 ㅖ는 Shift 자리가 아니라 ㅑ+ㅣ, ㅕ+ㅣ 조합으로 입력하게 돼 있다. 자음은 초성 종성 구분 때문에 어쩔 수 없이 Shift를 쓰지만, 모음은 일반 현대어와 로마자 방식 모두 의도적으로 no-shift를 추구한 것 같다. 그런데 현대어는 ㅣ가 말단에 등장하는데 로마자는 y를 의식해서인지 ㅣ가 앞에 등장한다는 차이가 있다.

한글 입력 방식은 용도랄까 성향, 이념에 따라 현대어 일반, 로마자, 옛한글.. 이렇게 크게 나뉘긴 하는 것 같다.
대부분의 경우는 현대어 일반만으로 충분하겠지만, 한글 글쇠배열을 잘 모르는 외국인에게는 로마자가 유용할 것이고, 고전을 다루는 일부 계층에서는 옛한글도 필요할 것이다.

5. 복합 낱자 입력 로직 생성기

(1) 글쇠배열 정보가 업데이트되지 않는 버그
현대 한글밖에 지원하지 않는 입력 설정에다가 옛한글까지 포함된 대결합을 지정하고 로직을 생성해 보면.. 옛한글 대결합은 지금 입력 설정으로는 접근 가능하지 않아서 쓰이지 않았다는 안내문이 쭉 나타난다.

그런데 그 상태로 대화상자를 '취소'로 닫은 뒤, 글쇠배열을 옛한글 방식으로 바꾸고 나서 로직을 생성하면 이전에 발생했던 안내문이 사라지지 않고 또 나타난다.
이건 이 입력 설정으로부터 입력 가능한 낱자들 정보를 cache 형태로 저장해 둔 것이 갱신되지 않아서 발생하는 문제였다. 이 버그를 고쳤다.

(2) 오토마타 연계 방식의 개선
이 빠른설정이 세팅해 주는 기능 중에는 허용 한글 범위 제약과 관련하여 오토마타 수식을 수정하는 것이 있다. 그냥 A, B, C 변수가 모두 0인 실패 상황일 때 단순히 0을 되돌리는 게 아니라 T==xx ? -3 어쩌구 하는 조건이 추가된다.

한글 입력 오토마타를 ‘이어치기’ 같은 단순한 걸 사용하고 있을 때는 고쳐야 할 지점이 명백하기 때문에 자동 수정이 가능하다. 하지만 그것 말고 더 복잡한 custom 오토마타를 사용할 때는 저런 수정이 정확하게 되지 않을 수 있다.

그렇기 때문에 이 빠른설정은 custom 오토마타에 대해서는 수식을 직접 건드리지 않는다. “T==xx 등등 요런 조건을 현재 오토마타의 0번 상태 수식의 끝에다가 사용자가 수동으로 추가해 주세요”라고 안내만 하는 식으로 동작해 왔다.
하지만 이번 버전에서는 반쪽짜리 동작이 다음과 같이 바뀌었다. 사용자에게 귀차니즘을 유발하지 않도록 말이다.

  • 오토마타의 0번 상태 수식이 A, B, C 변수를 모두 사용하고 있고 마지막이 ? : 0 으로 끝나면 그 0 부분에다가 새로운 조건이 언제나 자동으로 추가된다. 이미 T 변수를 참조하는 부분이 있다면 그 구간이 통째로 바뀐다.
  • 단지, known/stock 오토마타가 아니라 custom 오토마타라면 수식이 이렇게 바뀌었으니까 맞는지 확인하라는 말만 표시해 준다.
  • 0번 상태 수식이 저런 최소한의 조건을 만족하는 상태가 아니라면 오토마타를 통째로 제일 기본적인 이어치기 모드로 바꿔 버린다. 그러고 나서 새로운 조건을 추가해 준다.

사실, 허용 한글 제약이 걸려 있는데 이어치기가 아닌 다른 복잡한 custom 오토마타를 사용할 일은 거의 없다. 그러니 빠른설정 차원에서 오토마타 자동 수정을 시도해 보고, 안 되겠다 싶으면 이어치기로 강제 지정을 하는 게 더 합리적인 선택으로 보인다.

6. 수식 계산 기록

'수식 계산 기록' 도구에서 수식을 찍으면.. 이 수식의 문맥에서 쓰이는 대문자 변수의 의미가 화면 우측 하단에 같이 나타나게 했다.
날개셋 제어판에서 이 수식을 지정하는 입력란에 들어갔을 때 풍선 도움말로 표시되는 바로 그 문구이다. 그 도움말을 저 입력 도구에서도 상시 볼 수 있게 한 것이다.

사용자 삽입 이미지

저 로그에서 제일 많이 보게 될 수식은 글쇠배열, 한글 입력 오토마타, 자판 전환 세 종류를 크게 벗어나지 않겠지만.. 그래도 수식을 분석하고 변수값의 의미를 파악하는 데 큰 도움이 될 것이다.

* 알려진 문제: PowerPoint 2013(과 그 이후)에서는 입력 패드가 동작하지 않음

MS Office 제품 중에 TSF를 가장 먼저 지원한 프로그램은 아무래도 텍스트 입력에 제일 특화된 Word이었고, 그 다음으로 Outlook (Word 엔진 기반), Publisher, OneNote 같은 프로그램이 뒤를 이었다.
그랬는데 2013 버전부터는 PowerPoint도 내부의 텍스트 입력 엔진이 다시 만들어졌는지 TSF를 완벽히 지원하고 심지어 Word처럼 Ctrl+드래그로 블록을 여러 개 잡을 수도 있게 됐다.

덕분에 이제 파워포인트에서도 단어 단위 한글-한자 변환이 되고 bksp 달라붙기 같은 기능도 사용할 수 있게 됐는데..
그 대신 외부 모듈 말고 입력 패드는 동작하지 않는다는 것을 최근에야 뒤늦게 발견했다. 문자표 같은 걸 꺼내서 문자 입력을 시도해도 아무 반응이 없다.

입력 패드는 TSF보다 훨씬 더 단순한 IME 방식으로 프로그램에다가 문자 입력을 전달한다.
파워포인트는 2010년대가 돼서야 TSF 인터페이스를 구현하다 보니, 구형 IME 인터페이스를 받아들이는 부분을 과감하게 다 삭제해 버렸나 하는 생각이 든다.

입력 패드는 근본적으로 편법으로 동작하는 프로그램이다 보니 이렇게 잘 동작하지 않는 프로그램 환경이 앞으로 더 늘어날 수 있다.
문제를 해결할 방법이 없는지, 혹은 여기는 동작하지 않는 환경이라는 걸 미리 감지라도 할 수 없는지.. 이런 것들을 차차 연구해 봐야겠다.

Posted by 사무엘

2021/12/25 08:35 2021/12/25 08:35
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1968

다음 버전 개발 근황

날개셋 한글 입력기의 다음 버전은 올해 연말 정도 공개를 목표로 개발 중이다. 늘 그렇듯이 여러 기능들이 추가되고 자잘한 버그들이 잡혔다.

1. 복합 낱자 입력 로직 생성기에 허용 한글 데이터를 '내장형'으로 연계하기

지난 9.0 버전(4년 전~!)에 사실상 완성되어서 더 변화가 없었던 '복합 낱자 입력 로직 생성기'가 오랜만에 외형이 살짝 바뀌고 자잘한 옵션이 추가되었다. 얘가 뭘 하는 물건인지부터 먼저 복습을 좀 하자면 다음과 같다.

이 빠른설정은 2016년경 8.x 버전 시절부터 슬슬 개발과 구현의 필요성을 느껴서 2017년 초, 8.8 버전에서 드디어 첫 버전이 도입됐었다.
다음 버전인 8.9에서는 허용 한글 범위 제약 기능과 연계해서 로직을 생성하는 기능이 추가되었으며, 그 다음 9.0 버전에서 지금과 같은 세부 기능들이 모두 완성되었다.

다른 빠른설정들은 두벌식, 세벌식, 한글 로마자처럼 특정 문자 입력 방식을 새로 세팅해 주는 물건인 반면..
얘는 기본 자모만 입력 가능한 한글 입력 설정을 받아서 겹받침이나 이중모음 같은 복합 낱자들을 입력 가능한 설정을 세팅하며, 그 과정에서 발생할 수 있는 모호성이나 논리 오류를 찾아내고 바로잡아 준다.
대화상자를 네 단계나 거칠 정도로 설정할 것이 많으며 빠른설정들 중에서 덩치가 압도적으로 제일 크다.

얘는 이미 있는 입력 설정의 동작을 더욱 심화시키는 역할을 한다는 점에서 다른 빠른설정과는 성격이 근본적으로 다르다.
이건 개인적으로 날개셋 한글 입력기의 개발 내력에서 차지하는 의의가 매우 큰 중요한 기능 중 하나라고 생각한다. 현실에서는 한글 입력 엔진 하나만 갖고 이 정도로 미친 수준의 추상화나 잉여질을 생각하는 기업이나 연구소는 딱히 없기 때문이다.;;; 어쨌든 날개셋 한글 입력기에는 이런 기능이 있다.

이 빠른설정은 필요한 경우, 로직 생성 결과를 '지정된 데이터에 들어있는 한글'이라는 허용 한글 범위 제약 기능에서 인식하는 데이터의 형태로 생성해 준다.
가령, KS X 1001 2350자를 기준으로 동작한다면 '썅'은 있는데 중간 입력 과정인 '쌰'가 누락됐다는 것을 찾아내며, '쌰'가 포함된 허용 한글 데이터를 별도로 생성한다는 것이다.

'지정된 데이터에 들어있는 한글'은 별도의 파일에 저장된 데이터를 읽어들여서 동작하곤 했는데.. 지난 10.0 버전부터는 작은 데이터는 그냥 입력 설정에 포함된 내장형으로 동작할 수도 있게 됐다.
하지만 '복합 낱자 입력 로직 생성기'는 이런 변화가 반영되지 못하고 저 허용 한글 범위 제약 기능을 언제나 예전처럼 외장형으로만 운용해 왔다.

그러던 것이 이번 버전에서 드디어 개선될 예정이다. 이 빠른설정도 사용자가 옵션을 지정한다면 내장형을 적극 활용하게 된다.
기존 외장형은 큰 데이터를 부담 없이 취급할 수 있으며 한 파일을 여러 입력 항목이 공유할 때 메모리 공간이 절약된다는 것이 장점이다. 그 반면, 내장형은 덕지덕지 데이터 파일을 들고 다닐 필요가 없으니 관리가 편하다는 장점이 있다.

사용자 삽입 이미지

가장 먼저 대화상자의 외형이 미묘하게 개선되었다는 것부터 언급하도록 하겠다.
세로 길이가 예전보다 아주 약간 작아졌으며, '중간 과정 글자의 표현 방식'과 '낱자 결합 최적화' 콤보 상자의 배치가 삐딱삐딱 제멋대로이던 것을 저렇게 가지런하게 맞췄다.

그리고.. (1) '생성된 데이터가 n KB 이내로 작으면 내장시킴'이라는 옵션이 추가된 걸 볼 수 있다. UTF-16 기준이므로 한글 약 500여 자가 1KB라고 생각하면 된다. KS X 1001 2350자 테이블은 5K 이상은 돼야 내장형으로 들어갈 수 있다.
내장형을 전혀 사용하지 않으려면 숫자를 그냥 0으로 지정하면 된다.

(2) 아울러, 빠른설정을 적용하는 원본 입력 설정에 이미 '지정된 데이터에 들어있는 한글' 제약이 적용되어 있는 경우, 여기 '기본 허용 범위'에도 '현재 지정된 범위 그대로'라는 옵션이 생긴다.

얘를 지정하면 그 입력 항목에 현재 적용되어 있는 한글 데이터가 분석 대상으로 곧장 연계된다. 내장형이건 외장형이건 가리지 않고 자동으로 처리된다.

사용자 삽입 이미지

분석을 통해 새로 생성된 허용 한글 데이터가 내장형과 외장형 중 어떤 형태로 처리되었는지는 이렇게 결과 페이지에서 확인할 수 있다.

2. 화면 키보드 '실제 입력 문자 표시' 옵션의 동작 개선

'화면 키보드'에는 사용자가 누르거나 뗀 글쇠를 별도의 색깔로 알려 주는 '눌린 글쇠 표시' 옵션이 있고, 이 글쇠를 눌렀을 때 실제로 입력되는 문자를 매번 동적으로 다시 계산해서 알려 주는 '실제 입력 문자 표시' 옵션이 있다.
후자는 복벌식/신세벌식처럼 글쇠의 의미가 오토마타 상태에 따라서 달라지는 입력 방식을 사용할 때 매우 유용하다.

그런데 실제 입력 문자는 글쇠에 따라서는 capslock이나 numlock 같은 램프의 점등 여부에 따라서 달라질 수도 있다. 대소문자가 바뀌는 영문 글쇠배열이 대표적인 예이다.
하지만 이건 입력기 오토마타에 직접 들어가는 글쇠가 아니기 때문에 '실제 입력 문자 표시' 옵션만 켰을 때는 바로 바로 업데이트가 되지 않았다. '눌린 글쇠 표시' 옵션까지 같이 켜야 업데이트가 됐다.

이건 이 두 옵션이 구현된 이래로 굉장히 오랫동안 존재해 왔던 한계이다. 그러다가 이제는 '실제 입력 문자 표시' 하나만 켰더라도 키보드 램프 상태가 바뀌어서 달라지는 입력 문자도 맞게 반영되게 했다.

3. 낱자 단위 검색 기능의 버그 수정

날개셋 편집기의 찾기 기능에는 한글을 낱자 단위로 검색하는 옵션이 있다. 그런데 특정 낱자 또는 아무 낱자 말고, 낱자가 없는 것(없는 낱자) 자체를 조건으로 명시하기 위해서 내 프로그램은 초중종성별로 U+F800~F802라는 특수 낱자를 사용하고 있다.

그래서 U+F802 하나만 입력했다면 현대 한글과 옛한글을 막론하고 종성이 없는 한글을 아무거나 찾아내야 하는데.. 지금까지 그 기능이 옛한글 및 미완성 한글에 대해서는 정확하게 동작하지 못했다. 'ㅎㆍㄴ' 같은 글자도 받침이 없는 글자로 잘못 판정했다. 그 이유는.. 글자를 탐색하는 단위가 잘못 지정됐기 때문이었다.

'ㅎㆍㄴ' 자체는 받침이 없는 글자가 아니기 때문에 조건을 만족하지 않아 걸러진다.
그런데 그 다음 지점으로 이동할 때 코드포인트 3개를 이동하는 게 아니라 여느 문자를 검색할 때와 마찬가지로 2개씩만 이동했다.

그러니 다음 글자는 ㅎ만 건너뛰어서 'ㆍㄴ'이 되는데.. 이게 초성 filler가 없고 정규화 규칙을 만족하지 않기 때문에 얘는 실제로는 ㆍ와 ㄴ으로 찢어져서 인식된다.
ㆍ는 종성이 없는 단독 낱자이므로 얘 때문에 'ㅎㆍㄴ'이 통째로 걸려드는.. 뭔가 아햏햏한 결과가 연출되었다.

이게 역방향으로 검색할 때는 더 골치 아픈 문제가 되는데, 어쨌든 문제를 해결은 했다. 다음 버전에서 고쳐질 예정이다. 이 버그는 정 재민 님께서 찾아내서 알려 주셨다.
그렇잖아도 한글에 종성은 별도의 filler가 존재하지 않기 때문에 '받침이 없는 옛한글' 이런 것만 찾기가 약간 난감한데, 날개셋 편집기로는 이걸 그럭저럭 수월하게 할 수 있을 것이다.

4. 블록 잡은 상태에서의 한자 변환 지원

날개셋 한글 입력기는 단어 단위로 한글을 한자로 변환하는 동작이 MS IME와 거의 동일하게 맞춰져 있다.
한자어는 무조건 한글로만 바꿔 버리지, 한글을 거치지 않고 다른 한자어로 바꾸는 기능 정도만이 미구현이다. 이건 뭐 그렇게 크게 이질적이거나 불편한 사항이 아닐 것이다.

내 프로그램이 오랫동안 지원하지 않았던 건 블록을 잡은 상태에서의 한자 변환이었다. 이 상태에서는 무조건 단어의 맨 앞까지 한글을 탐색하는 게 아니라 블록으로 잡힌 영역만 탐색해서 한자나 한글로 변환하면 된다.
하지만 내 프로그램은 텍스트에 블록이 잡혀 있을 때는 한자/한글 변환 기능이 어떤 형태로든 전혀 동작하지 않았다. 그런 상황에 대한 고려가 되어 있지 않았으며 고려할 필요성도 느끼지 못했다.

한글 입력기가 내부적으로 사용하는 텍스트 입출력 프로토콜 자체가 애초에 블록의 존재 가능성에 대한 고려가 전혀 없었다. 날개셋 한글 입력기가 이런 기본적인 동작에 대해 이토록 오랫동안 out of 안중이었다는 게 스스로 생각해 봐도 믿어지지 않을 지경이었다. 뭔가 발상의 전환 같은 걸 경험해서 블록 안 텍스트에 대한 한자/한글 변환 동작을 추가 구현했다.

* 그 밖에

(1) 한글 낱자 하나를 입력받는 자체 콤보박스에.. 내 프로그램에서만 PUA 영역을 사용해서 표현하는 비표준 낱자를 나타나지 않게 하는 옵션을 추가했다.
검색할 때 '없음'을 나타내는 용도로 사용하는 특수 낱자라든가, 원래 초성과 종성 중 한쪽에만 존재하는 낱자의 맞은편 성분 버전 같은 것이 이 범주에 속한다. (초성 ㄱㄴ, 종성 ㄱㄷ 따위)

(2) 편집기의 영문 UI에서 용지 여백이 Margine이라고 잘못 적혀 있던 것-_-, 기본 글자판 빠른설정에서 두벌식 옛한글의 글쇠배열 미리보기에 shift+J(채움 문자)와 shift+M(음절 분리) 자리가 잘못 표시되어 있던 사소한 오류도 뒤늦게 발견해서 고쳤다.

(3) 날개셋 한글 입력기의 제어판에는 글쇠배열 편집기가 있고 한글 낱자 선택 전용 콤보박스가 있다. 글자를 한 칸에 달랑 한 글자밖에 입력받지 않는 자그마한 물건이어서 존재감이 별로 없지만.. 그래도 이들 컨트롤에서도 자체 에디트 컨트롤과 완전히 같은 방식으로 날개셋 자체 입력 엔진 또는 외부 모듈(운영체제 IME, 빈 입력 스키마)을 통해 문자를 입력할 수 있다.
그런데 이들 컨트롤에서 운영체제 IME를 통한 문자 입력이 오랫동안 제대로 되지 않고 있던 것을 뒤늦게 확인하여 고쳤다.

(4) 편집기에서 단어 단위 한자 변환 대화상자를 꺼냈을 때, 변환 영역이 블록으로 지정되었다면 그 영역이 블록 색깔로 표시되어 시각적으로 변별이 되게 했다.

(5) 편집기의 찾기 대화상자에 '한글 방점 무시' 옵션을 추가했다.
방점 없이 한글만 입력해도 방점이 덕지덕지 섞인 텍스트를 검색할 수 있으니 아주 편리하다. 이런 기능을 지금까지 왜 생각하지 못했나 모르겠다.
'공백 무시', '한글 낱자 단위로', '음이 같은 한자도 검색' 같은 옵션과 함께 사용하면 검색 기능이 더욱 강력해질 것이다.

Posted by 사무엘

2021/08/04 08:34 2021/08/04 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1917

날개셋 한글 입력기 10.2 이후로 약 3개월 만에 다음 버전인 10.21을 공개하고자 한다. 그리고 타자연습도 오랜만에 버전업을 해서 3.93이 나왔다. 하지만 둘 다 0.01밖에 증가하지 못했다.

개인적으로는 한글 입력기는 (1) 보조 입력 도구(화면 키보드, 문자표 등)들을 구동하는 엔진 개선, 그리고 (2) 세벌식 동시치기 기능 강화.. 이 둘을 10.x 중반에서 마무리 짓고 나서 내부적인 자체 기능 개발은 이제 진짜 끝을 내려 한다. 이것 말고 ARM64 지원이나 크롬 브라우저 이슈(미래에 또 발생한다면) 같은 건 외부 이슈들이다.

이번 버전은 지난번 개발 근황 글에서 언급했던 것처럼 크롬 브라우저 보정 내역 업데이트, 보정 UI의 보강, 여러 UI 개선과 버그 수정이 있었다. 그때 이후로 추가로 발생한 변화 내역은 다음과 같다.

1. 설치 UI에서 간략한 입력 설정 초기화 기능 제공

프로그램을 설치할 때 다음과 같은 선택 단계를 추가했다.

물론 이것들은 설치를 마친 뒤에 날개셋 제어판을 꺼내서도 얼마든지 할 수 있는 작업이다.
하지만 사용자가 원한다면 프로그램을 제거/재설치하면서 입력 설정도 같이 싹 리셋 가능하게 했다.

그리고 한글 로마자 입력 방식은 사용자가 원한다면 특별히 이렇게 바로 지정 가능하다. 제어판을 꺼내서 로마자 입력기 빠른설정을 번거롭게 불러올 필요조차 없다. 안 그래도 내 프로그램은 아직 영문 도움말도 없는데(UI만..) 외국인이 Windows 환경에서 한글 로마자 입력 방식을 더 간편하게 쓸 수 있게 했다.

2. 한글 출력 치환 관련

한글 출력 치환은 문자 생성기를 ‘고급’으로 지정했을 때 사용 가능한 기능으로, 내부적으로는 한글 입력 상태이지만 겉으로 비한글 문자가 섞여서 표시되는 처리를 담당한다.
여기서 비한글 문자라는 건 한글 자모를 여러 자로 풀어서 표현하는 것도 포함된다. 간단하게는 히라가나/가타카나 같은 일본어 문자를 한글로 입력하는 것(글자 단위 치환)부터 시작해 한글 한 글자의 범위를 넘어서는 온갖 복잡한 한글 입력 동작을 이 기능으로 구현할 수 있다.

한글 한 글자라는 경계를 기본 입력과 고급 입력으로 구분한 것은 개인적으로 오랜 연구와 고민의 결과였다. 그렇잖아도 고급 입력기는 통상적인 한글 조합과 무관한 사용자 정의 조합을 자체적으로 제공하기도 하니, 한글을 조합하고 있을 때는 이런 customization을 제공하는 것이 논리적으로 이치에 맞기도 하다.

아무튼.. 이 기능이 지금까지는 아무 낱자도 입력되지 않은 상태인 0낱자에 대해서는 치환이 지원되지 않았는데, 이번 버전에서는 이것도 가능하게 했다. 즉, 글쇠가 아직 눌러지지 않은 성분에 대해서 기본적인 치환 문자열이 미리 표시될 수 있게 한 것이다.

그리고 이 출력 치환 기능은 ‘기본’ 입력기에서 이미 제공하고 있는 가상 낱자와 같이 맞물려서 동작한다. 출력 치환이 걸리고 있는 낱자는 대부분의 경우, 자기가 원래 있던 자리에서는 0으로 치환되어서 아무것도 표시되지 않아야 한다.

그래서 제어판 UI에서 물리적인 낱자가 존재하지 않는 300, 500 같은 영역에서 문자열 치환을 지정했다면, 그 낱자 자신은 0으로 치환되도록 가상 낱자 규칙도 자동으로 추가되게 UI 동작을 개선했다.
이제 낱자 단위 출력 치환 설정을 한 뒤에, 가상 낱자에다가도 0치환을 추가하는 번거로운 두벌일을 하지 않아도 된다.

그리고 타자연습은..

  • 기본 연습글에 UN 세계 인권 선언문을 추가했다. 수백 개의 언어로 번역되어 인간의 존엄성과 기본권이라는 개념을 세계 각국의 법률에다 각인시킨 역사적인 텍스트이기 때문이다. 하지만 우리말 번역이 심하게 길고 어색하고 장황한 번역투인 것은 좀 아쉽다.

  • 내 프로그램은 인터넷 유행어와 개드립이 연습글로 수록되어 있는=_=;;; 게 조금씩 입소문을 타면서 주목받고 있다. "안녕히 계세요 여러분"..;; 과 "독일의 과학력은 세계 제이이이일!!"을 추가했다. 김 성모 어록, 세스코 질답 모음, 부산 운전 후기, 클레멘타인 영화 감상평, 어둠에다크에서 따위는 한참 전부터 이미 있었던 것들이고..

  • 사소한 사항이지만.. 긴글 연습 입력란을 감싸는 두꺼운 테두리도 고전 기본 스타일이 아니라 다른 창들과 마찬가지로 테마가 적용된 새끈한 형태로 변경했다.

사용자 삽입 이미지

요 근래에 타자연습 프로그램이 바뀌어 온 건 멀티모니터 지원, 1픽셀 여백 반영, 그리고 테두리 모양.. 이렇게 정말 소소한 것들밖에 없는 듯하다.;; 그런데 아무 의미가 없는 건 아니기 때문에 언젠가는 반영하고 버전업을 해야 한다.

이상이다.
2021년 현재까지도 공 병우 박사의 정신을 이어받아 세벌식 자판을 사용하고 10년 이상 날개셋 브랜드 프로그램들을 애용해 주시는 분들께 감사드린다. 정말 느리고 몇 번이나 양치기 소년 같은 불발탄 선언으로 그치긴 했지만, 이 프로그램의 주된 기능 개발도 정말 끝이 보이고 있다.

한글처럼 알파벳이나 한자와는 완전히 다른 독특한 문자가 애초부터 아예 없었다면 모를까, 기왕 있다면 그 한글의 구조적인 장점을 잘 활용하기 위해서 세벌식 자판을 사용해야 한다는 것은 결코 변하지 않을 것이다.

인터넷 검색을 하다가 우연히.. 윤디자인에서도 한글 IME를 만들었다는 걸 알게 됐다. 오.. 2019년이면 한컴에서 IME를 만든 때와도 얼추 비슷해 보이는데?
내가 대학교 말년, 날개셋 버전 3.x 시절에 TSF라는 규격을 만지면서 낑낑거리고 나서 한 13~15년쯤 뒤에야 다른 싸제 TSF 기반의 한글 IME도 조금씩 만들어져 나오기 시작했다. 작년에는 잘 알다시피 ‘나빌’이라는 입력기도 나왔고..

유튜브에다가 새마을호 Looking for you 동영상을 올리던 시절에만 해도 이런 마이너한 곳에 한국어 댓글이 달릴 일이라고는 없을 것 같았는데 지금은 댓글 천지가 됐듯이..
중국? 일본이 아니라 한국에서 TSF 쪽 API를 파는 사람은 전국에서 나밖에 없을 줄 알았는데 그래도 이런 IME도 개발되어 나온다니 일면 반갑다.

IME들 간에 평범한 기능들은 결국 다 비슷비슷하게 제공되고 격차가 없어져서 상향평준화 수렴진화할 것이다.
하지만 타 IME들이 결국은 이미 있는 글자판이나 옵션들 몇 가지만 지원하는 반면, 날개셋 한글 입력기는 세벌식에 특화돼 있고 입력 동작의 모든 면모를 프로그래머 수준으로 customize 가능하다는 점에서 다른 제품들과는 근본적인 차별화 요소를 지니고 있을 것이다.;;

Posted by 사무엘

2021/06/13 08:35 2021/06/13 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1898

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

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
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:
3040980
Today:
607
Yesterday:
1700