김 용묵의 절대공간 - 블로그

1. ARM64 지원 예정

지난 3월 말에 날개셋 한글 입력기 10.85가 나왔다.
그런데 앞으로 1~2개월 안으로 다음 버전이 매우 높은 확률로 나오게 됐고, 무엇보다도 10.x를 완전히 졸업할 수 있게 됐다.
다음 버전의 번호는 11.0으로 확정이다. 지난 2020년 5월 말에 10.0이 나왔으니 10.x를 6년 만에 넘어서는 것이다.

그 원동력은 바로.. ARM64 (AArch64)용 에디션의 개발이다.
지난 2007년, 버전 4.8에서 x64가 지원된 뒤, 거의 19년 만에 새로운 아키텍처의 지원이 추가되다니 참 감격스럽다.

이제 프로그램의 About 화면에는 프로그램 자신의 비트수뿐만(32 또는 64비트) 아니라 아키텍처 이름도 표시된다. x86 또는 ARM.
프로그램의 빌드 기준 아키텍처와, 운영체제의 아키텍처가 동일하다면 프로그램 이름에만 아키텍처가 표시된다. 그러나 둘이 다르면 운영체제의 버전에다가도 아키텍처가 따로 표시된다.

ARM64 기기에서는 기존 x86 프로그램을 모두 저렇게 실행할 수 있구나. ㄷㄷㄷㄷ 그래도 얘들은 실행 성능이 ARM64 native 앱에 비할 바는 못 될 것이다.
편집기뿐만 아니라, 다른 프로그램들과 연계해서 동작하는 외부 모듈(IME)와 입력 패드까지 ARM64용 Windows에서 잘 동작하는 걸 보니 감격스럽다.

그리고 이걸 작업하면서 기존 x86/x64의 빌드 시스템도 변경하고 뭐랄까 최신화 고도화를 했다.
믿어지지 않지만 날개셋 한글 입력기는 지난 10여 년 동안, 거의 7.x부터 10.x에 이르기까지 꽤 구형 컴파일러인 Visual C++ 2010으로 개발돼 왔다. (더 옛날 4.2, 6.0, 2003, 2008을 거쳐..)
내 프로그램은 구형 Windows를 지원하고 특정 Visual C++ 버전의 런타임 DLL에 의존하지 않기 위해서 좀 특수한 방법을 써서 빌드되는데(특히 구형 x86 32비트 에디션..), 이걸 새 개발툴로 옮기는 게 좀 부담스러웠기 때문이다.

하지만 ARM64를 지원하려면 개발툴을 강제로 업데이트 하지 않을 수 없고, 그 특수한 방법도 새 환경에 맞게 업데이트 해야만 했다.
약간의 삽질 끝에 그 방법을 ARM64 에디션에다 적용하는 데 성공했고, 동일한 방법을 x86/x64에다가도 업데이트 해서 적용시켰다. 이제 날개셋 한글 입력기는 구닥다리 Visual C++ 2010이 아니라 2022로 빌드하게 됐다.

Visual C++ 2010은 C++11을 지원한 첫 버전이었던 만큼, 요즘 기준으로 보면 최신 C++ 문법을 제대로 지원을 못 하는 게 여럿 있다.
표준 문법인 for (type a:b)를 못 쓰고 for each(type A in B)만 써야 한다거나..
클래스 멤버 함수 안에서 선언한 auto 람다 함수 안에서 바깥 멤버 변수/함수의 인식이 제대로 안 된다거나..
이런 식으로 아쉬운 게 적지 않았다. 그런 한계들이 드디어 해소됐다.

지난번에 타자연습은 4.0을 내면서 개발툴을 최신으로 바꿔 버렸는데, 뒤이어 입력기도 극악의 레거시 호환성을 그대로 유지하면서 개발 환경은 쇄신을 이뤄냈다. ARM64 지원과 함께 이 정도 변화가 생겼으니 10.85에서 11.0으로 버전업도 가능해진 것이다.

이렇게 ARM64 에디션이 나오게 된 것은..
거금을 들여 Microsoft 서피스 개발 장비를 후원해 주신 분이 계셨던 덕분이다. 프로그램 도움말의 '감사의 글'에 이분 성함이 들어갈 예정이다.

(요즘 메모리가 너무 비싸져서 컴퓨터 가격도 내가 수 년 전에 알던 그 가격이 아니던데..
AI 돌리거나 훈련시키느라 갈아넣는 컴퓨팅 자원이 늘어나는 바람에 사람이 쓰는 컴퓨터까지 부품이 비싸졌다고 한다.
이거 마치 바이오 디젤 수요 때문에 사람이 먹을 농작물 식재료 가격이 뛰는 것과 비슷한 현상 같다.)

2. 프로그래밍 이슈 I

같은 코드를 컴파일 했을 때, ARM64 네이티브 바이너리는 x64 바이너리와 크기가 의외로 그렇게 큰 차이가 나지 않았다. 사실, 마소에서는 기존 x64와 최대한 비슷하게, 이질감 없이 ARM64를 도입하려고 정말 애쓴 것 같다.
ARM64 컴에서도 x64 바이너리는 기계어 코드를 에뮬레이션 해서 돌아가기는 한다. 둘은 설계 방식이 서로 굉장히 이질적인 아키텍처일 텐데 말이다.

Windows Installer는 msi의 CPU 종류를 여전히 x86, x64, IA64 셋으로만 구분하지 여기에 ARM64를 추가하지는 않은 듯하다. (물론 IA64는 오늘날은 완전히 망하고 죽은 아키텍처이다만..)
ARM64에서는 x64와 x86 프로그램을 모두 실행할 수 있음에도 불구하고 Program Files나 System32 디렉터리에 또 무슨 Program Files (x64) 이런 변종이 추가되지는 않았더라. x64만을 위한 별도의 디렉터리 같은 건 없다. 개인적으로 무척 궁금했던 사항이었다.

물론 ARM도 처음에는 32비트 아키텍처로 시작했다가 2010년대 중후반부터 64비트로 넘어갔다. 그럼 Windows on ARM도 32비트 ARM 레거시에 대한 고려가 필요하지 않나 싶었는데.. 결론부터 말하자면 그렇지는 않은 듯하다.
모바일이나 임베디드가 아닌 PC용 Windows가 ARM으로 이식된 건 내력이 아주 짧다. ARM에서는 거의 곧장 64비트 시대가 시작됐기 때문에 ARM 32비트의 잔재는 거의 유니코드 1.0이라든가 조합형 한글 MS-DOS처럼 그냥 지원을 끊고 존재감을 없애고 짬처리 시킨 모양이다.

32비트 환경은 압도적인 레거시를 자랑하는 x86만 고려하면 된다. 하긴 Visual Studio고 Office고 카카오톡이고 다 64비트로 넘어갔으니 2020년대 중반쯤 되니 x86 32비트 프로그램을 접할 일이 생각보다 많이 줄어들었다.
구닥다리 VGA가 그래픽 카드들 간의 최소 공통분모였듯이 x86은 이제 여러 64비트 CPU들 간의 최소 공통분모가 된 것 같다. 뭐 그건 그렇고..

마소에서는 더 나아가 ARM64EC라고 한 바이너리에 x64와 ARM64의 기계어 코드가 같이 들어있는 일종의 fat binary라는 ABI도 내놓았다. 내 타자연습 프로그램은 이제 32비트와의 접점을 끊은 단독 프로그램이니 차라리 저런 형태로 빌드하는 게 도움이 될지도 모르겠는데.. 그건 앞으로 생각해 봐야겠다.
아무튼.. 마소는 x86과 ARM64는 번거롭게 서로 따로 놀게 만들지 않고 최대한 융합시키려고 하는 것 같다.

3. 프로그래밍 이슈 II

그리고 요즘 Windows API는 무슨 이유인지는 몰라도 실행 중인 프로세서 종류나 운영체제의 버전을 자꾸 샌드박스화하는 추세이다.
예전부터 있었던 구형 API로는 나중에 출시된 Windows 버전이나 새로운 CPU 아키텍처 값을 알 수 없게 하는 거. 이게 마소의 오랜 개발 방침이기라도 한 것 같다.

가령, GetSystemInfo는 현재 실행 중인 컴퓨터의 CPU 및 비트수를 알려주는 함수인데.. 32비트 프로그램이 64비트 Windows에서 실행될 때는 언제나 x86 32비트만 되돌렸다.
실제 CPU를 정확하게 알려면 굳이 Windows XP에서 새로 추가된 GetNativeSystemInfo를 써야 했다.

그랬던 것처럼, 지금 x64 프로그램은 자기가 ARM64 프로세서에서 돌아가는지 진짜 x64 전용 프로세서에서 돌아가는지를 기존 API만 써서는 알 수 없다. 그래서 IsWow64Process2 같은 새 API를 또 써야 한다. 이런 식이다.;

컴퓨터 환경뿐만 아니라 운영체제 버전도 말이다.
GetVersionEx 함수로는 운영체제 진짜 버전을 제대로 알 수 없게 된 지 10년쯤 넘었고 말이다. (Windows 8이 상한)
왜 이렇게 API를 쓸데없이 지저분하고 복잡하게 관리하는지 나로서는 도저히 모르겠다.
이런 것들이 지금 프로그램 개발하면서 개인적인 의문으로 남는다.

4. 맺는말

현재 날개셋 한글 입력기의 x86 계열 배포 패키지에는 외부 모듈이 Windows의 system 디렉터리에 설치되고 있다.
꼭 그럴 필요는 없지만 과거 Windows 9x와 XP 시절까지 존재했던 IME 프로토콜과의 호환성 때문에 그 관행이 유지되고 있다.
허나, ARM64에서는 Windows가 10/11이 원조이니 TSF 프로토콜만 지원하면 되고 IME는 전혀 고려하지 않아도 된다.

그러니 ARM64 에디션에서는 외부 모듈을 굳이 system이 아니라 내 프로그램 디렉터리에다 둘 예정이다.
생각 같아서는 system\IME 자리가 탐나기는 하는데.. 여기는 일단은 마소에서 기본 제공되는 IME들만 들어가는 곳이고 3rd party 프로그램에게 개방된 곳이 아니라고 한다.

이상이다.
ARM64 포팅 말고도 여러 자잘한 작업들을 할 게 더 있기 때문에 다음 버전이 곧장 바로 나오지는 못한다. 입력기의 경우, 한글 로마자 입력기에 자그마한 개선 사항이 들어갔다.

- 쿼티나 드보락이 아니라 그냥 현재 지정돼 있는 영문 글쇠배열에다가 한글 대응 규칙만 추가하는 옵션을 추가했다. 그래서 콜맥 같은 임의의 custom 글쇠배열도 한글 로마자 입력 용도로 바로 사용할 수 있게 했다. 이것도 진작에 필요했던 기능 같은데 이제야 실현됐다.

- '표준' 방식에서 H, U, L 글쇠의 특수 수식이 언제나 Qwerty 자리 기준으로만 배당되던 중대한 문제를 발견하여 수정했다.

그 밖에, '낱자 처리'의 보기 옵션 체크박스들을 건드리더라도 현재 낱자 목록들의 선택막대는 보존되고 남아 있게끔 UI를 개선하고자 한다. 보기 옵션은 뭔가 설정값을 실제로 변경하는 기능이 아니기 때문이다.

타자연습의 경우,
화면 DPI 150%에서 '좌우 대조' 방식으로 긴글 연습을 하면 화면 아래에 잔상이 남는 자잘한 문제를 해결할 예정이다.
그리고 영문 UI+코드 페이지를 사용하고 있을 때, 콤보박스 안의 한글 데이터가 깨지는 문제를 해결했다. 이건 원래는 존재하지 않던 현상인데 프로그램 빌드 방식이 크게 바뀌었던 4.0에서만 일시적으로 재발한 것이다.

끝으로.. 요즘 Windows에는 사용자 계정 컨트롤로도 모자라서 smart app control인지 뭔지이상한 보안 정책이 추가됐다. 디지털 서명이 없는 msi는 그냥 설치가 안 되게 막아 버리고 있어서 이것도 문제이더라.
내 홈페이지의 https 도입, 그리고 배포 패키지에 msi 도입도 더 진지하게 고민해 봐야겠다.

Posted by 사무엘

날개셋 한글 입력기가 작년 여름에 공개된 10.8 이후로 거의 7개월 만에 다음 버전이 나왔다. 2026년이 1/4가 훌쩍 지난 이 시국에 말이다.
지금까지 뭔가 건드린 것, 바꾼 것 자체는 적지 않다. 하지만 뭔가 결정타가 될 만한 큰 건 별로 없다.;;
오죽했으면 작년 말쯤에 '다음 버전 개발 근황' 소식이라도 올릴 법했지만 그런 것조차 없었다.

그래서 다음 버전의 번호가 11이나 10.9조차 되지 못했다. 하지만 그렇다고 겨우 10.81로 정하기에는 그건 또 아니니 결국 절충안인 10.85를 선택했다. 아 진짜 10.x는 언제 졸업하려나;;;

이 와중에도 각종 버그 신고나 사용법 문의는 꾸준히 들어온다. 잊을 법하면 후원금이 들어오고 최근에는 심지어 ARM64 서피스 기기를 통째로 후원해 주시겠다는 분이 등장했다! 너무너무 고마운 일이다.
기기를 받고 개발툴을 세팅하고 나면.. 오랜 숙원이었던 날개셋 한글 입력기의 ARM64 에디션도 나올 수 있을 것으로 기대된다. 이번 10.85부터 바로 포팅 들어가야지..

한번 이렇게 새 버전 릴리스를 하니 마음이 놓인다.
외부 모듈의 개발 상황부터 정리를 한 뒤, 본격적으로 이번 새 버전에서 달라진 점들을 분야별로 열거하도록 하겠다.

※ 외부 모듈 진행 상황

(1) 현재까지 외부 모듈과 관련하여 이슈가 들어온 것들은 다음과 같다.

• 일본어 IME와 함께 사용할 때 전각/한영 상태 전환 이슈: MS 한글 IME와 다르게 동작하는 것만이 접수 대상이다. 오래된 문의이긴 한데.. 현재는 정확한 재연 조건이 정리되지 않아서 보류 상태이다.
• 텔레그램, AppFlowy 앱에서 자잘하게 한글 입력이 덧나거나 씹히는 현상: 깔끔한 해결책이 아직 나오지 않아서 송구한 상태이다.
• 디아블로, League of Legend 게임: 이건 일개 IME의 평범한 오동작으로 발생할 수 있는 현상이 아닌지라.. 아마 보안 솔루션의 개입 때문이 아닌가 추정만 하는 상태이다.

(2) 지난 수 년 동안 '호환성 보정'이 필요했던 프로그램은 크로뮴 기반의 웹브라우저인 Chrome/Edge, 그리고 Windows Terminal이었다.
허나, 요즘 최신 버전에서는 해당 프로그램들이 둘 다 버그가 고쳐졌다. 이제는 저런 보정을 하지 않아도 예전 같은 오동작이 발생하지 않는다. 그래서 이번 10.85 버전에서는 기본적으로 저 보정들을 적용하지 않도록 설정값을 수정했다.

다만, 그래도 저 프로그램들의 동작이 100% 완벽하지는 않다.
Chrome/Edge에서는 한글 조합이 덧나는 현상이 없어진 대신, 조합이 끝날 때 기존 조합을 다시 업데이트하는 동작도 제대로 행해지지 않는다. 가령, 초성 지향 두벌식에서 '가ㄷ'라고 입력하던 걸 자동으로 '갇'으로 고치는 것이 안 된다. 보정을 하건 안 하건 동작 동일.. 이건 여전히 해당 프로그램의 동작이 고쳐져야 한다.

Windows Terminal은 혼자 오동작이 제일 극심하던 독특한 프로그램이었는데 예전에 비해 많이 좋아졌다.
하지만, 한글 조합 중에 화살표 키를 누르면 조합하던 글자를 놔 두고 caret만 움직이는 게 아니라 조합하던 글자까지 통째로 잘못 움직인다.
이건 MS IME는 괜찮고 내 프로그램에서만 발생하는 현상이기 때문에 추가적인 확인과 조치가 필요하다.

(3) 요즘 한글 글자판과 콜맥 영문 글자판을 같이 사용하려고 내 프로그램을 사용하는 분들이 굉장히 많은 것 같다.
하지만 내 프로그램은 키보드 드라이버 차원에서 기존 Qwerty 영문 배열을 다른 배열로 바꾸지는 못한다. 내 프로그램은 custom 영문 배열을 지원한다 해도 언제까지나 한글 입력기/IME일 뿐이니까.

그렇기 때문에 빈 입력 스키마를 없애지는 못한다, Qwerty 배열은 여전히 필요하다, 메뉴 단축키나 패스워드 입력을 콜맥 방식으로 변경하지는 못한다, 이건 영문 글쇠배열이 Qwerty인 모드가 아니라 IME가 동작하지 않는 모드를 의미한다...
이런 개념을 설명하는 질문 답장을 본인이 지난 15년 동안 아마 스무 번 정도는 쓴 것 같다.

메일을 보내실 정도이면 정말 답답하고 궁금했다는 뜻일 텐데. 이런 문의가 아직도 빗발치고 있다는 건, 내 프로그램이 사용자에게 이 개념을 여전히 충분히 알기 쉽게 설명을 제대로 못 한 것 같다.
날개셋 제어판 차원에서 이걸 더 상세히 친절하게 설명하는 UI를 고민해서 꼭 넣어야 할 것으로 보인다. ㅠㅠㅠㅠ
그리고 내 홈페이지의 영문 페이지에다가도 한글과 콜맥/드보락 자판을 같이 쓸 수 있다는 점을 더 어필하고 강조해야겠다.

※ 편집기: 전반적으로

그럼, 지금부터는 외부 모듈 다음으로 날개셋 편집기가 이번 10.85 버전에서 달라지고 점을 소개하겠다.
미주알고주알 모든 내역에 대해서는 Readme 문서를 참고하면 되니, 이 블로그에다가는 중요하고 스크린샷을 동원해서 설명할 만한 것만 수록했다.

(1) 프로그램 창의 폭을 줄이면 상태 표시줄의 '글자판 이름'과 '줄· 칸 정보' 두 구획의 폭도 적절히 좀 줄어들게 했다. 편집기에서 상태 표시줄 구획의 폭이 동적으로 바뀌도록 로직이 추가된 건 날개셋 한글 입력기의 개발 이래로 이번이 처음이다.

(2) 직전 버전에서는 문자표 대화상자에서 선택된 문자에 대해 운영체제의 폰트로 큼직하게 미리보기를 보여주는 기능이 추가됐다. 이거 글자 크기를 약간 더 키웠으며, & 요 글자가 preview가 찍히지 않던 문제가 있던 걸 덤으로 해결했다.

(3) 텍스트 통계 대화상자에다 가장 긴 줄의 분량을 표시하는 기능을 넣었다는 얘기는 작년에 이미 했었고..
그리고 현재 파일을 유니코드가 아닌 인코딩으로 저장하고 있고 깨질(=제대로 저장이 못 될) 문자가 있으면 이를 미리 표시하는 기능도 추가했다.
현재는 그렇게 깨진 문자가 있으면 저장을 한 뒤만 알려주고 있다.

※ 편집기: 파일 열기/저장 동작

(1) 현재 열려 있거나 예전에 열어서 최근 파일 목록에 등재돼 있는 확장자는 파일 열기/저장 대화상자에 이렇게 동적으로 추가돼 나오게 했다~! txt, htm/html, xml은 언제나 표시되는 고정 확장자이고, 나머지 확장자는 사용자가 연 적이 있을 때 추가된다는 뜻이다.

(2) 그리고 저장 옵션 및 인코딩 선택 대화상자가 다음과 같이 확 리모델링됐다.
이전의 대화상자는 유니코드도 여러 인코딩 중 하나일 뿐이라는 식으로 만들어져 있었지만 이제는 그런 느낌을 없앴다.
그리고 파일의 인코딩을 수동으로 선택받는 대화상자에다가는 이렇게 결과 preview 창을 넣었다.

이 대화상자를 볼 일이 많다면 대화상자를 크기 조절도 가능하게 하고 더 신경을 쓰겠지만.. 오늘날 같은 UTF-8 천하통일 세상에서는 별 의미가 없으니 이걸 필요 이상으로 너무 공들여서 초고퀄로 만들지는 않았다.

(3) 내용이 전혀 없는 빈 문서창 하나만 달랑 있는 상태에서 딴 파일을 열면.. 기존의 빈 문서창은 그냥 없애게 했다.
그리고 문서가 하나도 없고, 프로그램 창이 충분히 큰 상태에서 파일을 2~4개 정도 한꺼번에 열면 이 창들이 바둑판 모양으로 배열되게 했다. 지금처럼 무작정 최대화 상태로만 지정되지 않게 했다는 뜻이다.

(4) 백업 파일과 관련된 로직을 약간 개선했다. 확장자 자체가 이미 bak인 파일은 백업 파일을 또 만들지 않게 했다.
그리고.. 문서 창의 시스템 메뉴에는 편집 중인 이 파일을 삭제하거나 이름을 바꾸는 기능이 들어있는데, 이때 자신에 대한 백업 파일이 있다면 그건 같이 삭제하게 했다. 다시 말해, del/rename을 반복할 때 백업 파일이 지저분하게 남지 않게 했다.
아 그리고.. 읽기 전용으로 연 파일에서는 저런 del/rename이나 심지어 새 이름으로 저장(save as)도 동작하지 않게 했다.

※ 편집기: 에디팅 엔진

(1) Windows라는 운영체제는 alt와 함께 numlock 키패드 숫자를 누르고 alt를 떼면 그 숫자에 해당하는 코드 번호의 문자를 삽입해 주는 기능이 있다. 좀 뜬금없게도 16진법이 아니라 10진법이긴 하지만..
이게 원래는 numlock 램프가 켜졌을 때만 동작하는 게 정상이다. 그러나 날개셋 편집기처럼 운영체제 IME를 받아들이지 않는 상태라면(빈 입력 스키마 제외) 이게 numlock 램프가 꺼졌을 때도 동작한다.

그래서 날개셋 편집기로 alt+키패드 화살표로 화면 스크롤을 몇 번 하고 나면 엉뚱한 문자가 입력되는 경우가 있었다. 이건 뭐 20년 전 날개셋 3.x 초창기 버전부터 저랬는데.. 이번에 드디어 이 동작을 수정했다. 이제 alt+키패드 숫자는 어떤 경우든 numlock이 켜져 있을 때만 동작한다.

(2) 날개셋 편집기에서 입력 모드(글자판)를 '빈 입력 스키마'로 바꾸면 상태 표시줄의 글자판 이름이 '한국어 TSF' 이렇게 현재 지정된 키보드 내지 IME의 언어가 나타난다. 그리고 이 IME가 자국어 모드를 입력하는(한글?) 상태이면 그 뒤에 +도 표시된다.
심지어 상태 표시줄의 이 구획을 우클릭한 뒤에 '빈 입력 스키마'를 또 고르면 그 한영 상태가 toggle 되어서 + 가 나타나거나 없어지기를 반복한다.

원래는 이게 Windows 10/11까지도 잘 동착했는데.. Windows 11 언제부턴가 이 기능이 잘 동작하지 않고 있었다. 그래서 한영 상태 판단 기준과 변경 방식을 변경했다.

(3) 텍스트를 키보드로 타이핑하는 건 연속 입력으로 간주되어서 Ctrl+Z를 누르면 한꺼번에 다 없어진다. 보통은 화살표 key나 마우스 클릭으로 caret 위치가 강제로 바뀌어야 이 undo 단위가 분리된다.
이에 덧붙여, 텍스트 편집창의 포커스가 달라졌을 때(활성화/비활성화), 그리고 텍스트 전체 선택 이벤트가 발생했을 때도 undo 단위를 분리하도록 했다.
"123" → Ctrl+A → "abc"(기존 내용 덮어써짐)을 입력한 상태에서 Ctrl+Z를 눌렀다면 "123"이 선택된 상태로 돌아가야 할 텐데 지금까지는 그렇지 않았다.

※ 제어판 자잘한 외형

(1) 글쇠배열 편집 컨트롤에서 글쇠 자체를 나타내는 QWERTY 글자는 전통적으로 흰색으로 표시돼 왔다.
이게 Windows의 고전 테마에서는 아무 문제 없고 좋았고 심지어 Windows XP 시절에도 괜찮았다.
하지만 Windows 10/11은 대화상자 자체도 배경이 굉장히 밝아졌기 때문에 흰 글자가 잘 보이지 않는다. 대화상자의 배경이 과거 도스용 아래아한글 2.x의 흰 배경보다도 더 밝다.
고민 끝에 여기서는 글자색을 차라리 더 어두운 색으로 바꿨다.

그리고 '한글 표현 방식'의 preview 화면에서도.. 옛한글을 지원하지 않아서 옛한글이 길게 풀어진 폰트의 예문은 흐린 회색으로 표시되게 했다. 요런 자잘한 시각 피드백을 개선했다.

(2) 글쇠배열 편집 탭에서 Windows 유럽어 키보드 드라이버나 klc 파일을 열면.. 해당 파일이 내장하고 있는 악센트 문자 목록이 뜰 수 있다.
그런데 이 목록을 마우스로 드래그하다 보면 프로그램이 뻗고 해당 기능의 수행이 중단될 수 있었다. 꽤 오래 전부터 있었던 고질병인데 이제 발견해서 고쳤다.

※ 나머지..

(1) 프로그램이 전반적으로 인식하는 유니코드 영역에다 "한중일 통합 한자 EFGHI"를 추가했다.
글꼴 본뜨기를 다시 하고 나면 이제 문자표 대화상자에서 U+2xxxx뿐만 아니라 U+3xxxx대의 한자도 볼 수 있다.
그리고 '부수로 한자 입력' 도구를 열면 저 한자들도 부수-획수로 입력할 수 있다. 대략 23000여 자의 한자가 추가로 지원된다.

(2) '세벌식 순아래' 글쇠배열을 글쇠배열 편집 화면의 메뉴에서 곧장 선택할 수 있는 내장(stock) 배열에서 뺐다. 그 대신 이건 별도의 예제 파일(*.key)로 제공된다. 순아래는 세벌식 390이나 최종(391) 정도의 인지도가 있지는 않다고 여겨지기 때문에 이런 조치를 취했다.
개인적으로는 순아래를 내장 배열에서 뺄지 고민을 무려 15년 가까이 전에도 했었다. (이 블로그의 옛날 글을 검색해 보면..) 그걸 이제야 실행에 옮겼다.

(3) 빠른설정이나 글쇠배열 편집기에서 영문 글쇠를 생성할 때, caps lock 상태에 따른 대소문자 구분 수식은 'a'^(P&1)<<5 이렇게 비트 연산을 동원해서 부여되곤 했다. 그랬는데 이걸 없애고 그냥 단순한 ? : 연산자로 바꿨다.
사실, 수식이란 게 도입됐던 3.0 맨 처음에는 ? : 였는데 나중에 4~5.x 즈음에 조금 머리 쓴다고 비트 연산으로 바뀌었다.
그걸 원래 방식으로 되돌린 것이다. 원래 방식이 오히려 연산식이 하나밖에 없기 때문에 메모리를 약간이나마 덜 차지하고 속도도 더 빠르다. ㄲㄲㄲㄲ

(4) 끝으로, 아주 사소한 사항이다만 영문 글꼴 본뜨기 스크립트에 돋움체와 궁서체를 추가했다. 영문 궁서체 GungsuhChe는 생각보다 볼 만하다.

아무쪼록 유용하게 사용하시기 바란다.
날개셋 한글 입력기 11.0, ARM64 에디션, 타자연습의 다음 버전도 느리지만 차근차근 작업이 진행되어서 결과물이 나올 것이다.

Posted by 사무엘

지금 올리는 이 글은 원래는 이전의 새 버전 소개 글과 같이 올라갔어야 했다.
하지만 이 내용까지 같이 저 때에 맞춰 넣어서 글을 완성할 여유가 도저히 없어서 부득이하게 글을 둘로 나누게 됐다. ㄲㄲㄲㄲ
뭐, 글을 쓰고 보니 분량이 워낙 길어진지라, 별도의 글로 분리한 게 다행히 더 좋은 모양새가 되긴 했다.

1. 타자연습: 히스토리 기능의 부재가 아쉬워

연습글별로 예전에 마지막으로 연습하던 위치를 기억하기, 그리고 제일 최근에 열어서 연습했던 연습글을 기억하기.

이건 지금까지 여러 사용자들께서 건의했으며 본인도 지원의 필요를 느끼고 있었고, 이번에 어지간해서는 같이 구현하려 했다. 어떤 형태로 구현할지에 대해서도 얼추 구상을 마쳤다.
하지만 이건 아쉽게도, 죄송하게도 이번 4.0에서 실현되지 못했다. 또 다음 버전을 기약해야 하게 됐다.

일단 지금 형태 있는 그대로라도 '64비트화'라는 거대한 0순위 과업이 생겼다 보니.. 신규 기능은 우선순위에서 밀렸다.
게다가 이건 아무래도 사용자의 계정에 새로운 데이터가 영구적으로 추가되는 '큰 기능'이다. 이걸 구현해 넣기에는 지금 프로그램의 로직, 계정 파일 포맷 등등이 마음에 안 들고 많이 구려서-_-;;;
이것부터 최적화하고 작업을 더 장기적인 안목을 보면서 하는 게 낫겠다는 결론을 내렸다.
지금 이 구조에서 저 기능만 간신히 넣는 건 너무 삽질스러워 보였다.;;

그래도 이번 4.0을 계기로 날개셋 타자연습도 오랜 겨울잠에서 깨어나고 먼지를 털어냈다.
이제 최신 개발 환경에서 신형 API나 최신 C++ 문법도 아무 제약 없이 쓰면서, 여건이 허락하는 한 프로그램을 계속해서 발전시켜 나갈 것이다.

2. 타자연습: 게임 음악 관련 불만

타자연습을 x64 환경으로 포팅하면서 알게 된 사실인데.. 마소는 64비트 Windows에서는 DirectMusic의 지원을 사실상 끊었다.
관련 인터페이스들을 다 싹 없앤 건 아니고 directmusic performance 계층만 없앴지만.. 이거 없앤 게 사실상 DMusic을 몽땅 없앤 거나 마찬가지이다.

도대체 왜??
아무리 waveform 음원이 대세이고 MIDI는 현업 게임들에서 도태됐다지만, 내 프로그램처럼 소규모 초저예산 게임에서는 미디 음악을 여전히 쓰기도 한다.

그럼 더 구닥다리인 MCI API로 돌아가리?
음악 음색도 안 좋고, 로딩 때 랙도 너무 심하고, 게다가 메모리에 로딩된 미디 데이터를 바로 재생하지 못하고 임시 파일을 써서 불러들였다가 도로 지우는 삽질.. 이건 도저히 쓸 게 못 되었다.

마소에서 미친 짓을 했으니, 나도 미친 짓을 하기로 했다.
음악만 별도의 32비트 호스트 exe로 따로 떼어내서 재생한 것.. 기능의 퀄리티 상으로 DirectMusic을 대체할 물건이 도저히 정말 전혀 없더라.
내가 프로그램을 이 따위로 비효율적으로 만들게 된 건 전적으로 마소 때문인 줄이나 알아라.

아울러, 내가 타자연습은 이 참에 ARM64용 빌드도 시험삼아 만들어 볼까 생각했으나.. 일단 보류했다.
사실상 x86 32비트에서밖에 못 쓰는 저 음악 문제도 있고, 그리고 Visual Studio의 설치 배포 프로젝트가 플랫폼을 여전히 x86, IA64, x64 셋 중 하나로밖에 지정을 못 하기 때문이다.

Windows on ARM 나온 지도 이미 수 년이 지나지 않았냐? 거기서는 msi를 도대체 어떻게 만드는지?
Visual Studio의 컴파일러 툴킷은 ARM64용이 있는데, 배포 프로젝트에는 저 플랫폼이 왜 없는 걸까?
이런 것도 마음에 안 든다. =_=;;

3. 입력기: 외부 모듈의 버그 신고

지금까지 마소 IME는 괜찮은데 내 프로그램만 한글 입력이 제대로 동작하지 않는다는 신고가 들어온 건 다음과 같다.

(1) LoL 게임=_=.. 신고 메일에 따르면 게임 중의 대화(?) 창에서는 한글 모드로 안 들어가고 영문만 입력되며.. 게임을 마치고 나온 대기 로비의 대화창에서는 한글 입력이 된다고 한다.
난 LoL을 전혀 하지 않고 프로그램 구조를 모르기 때문에 이에 대한 지원은 전혀 할 수 없다. 혹시 비슷한 현상을 겪는 분이 또 있으신지 제보를 기다린다. 스샷과 정확한 재연 방법도..

(2) 텔레그램 메신저, 그리고 AppFlowy라는 프로그램에서. 한글 입력이 덧난다거나, 한글 모드에서 입력하는 비한글 문자(세벌식 자판의 숫자, ※ 등)가 씹히고 제대로 입력되지 않는 현상이 있더라.
AppFlowy의 경우, 일반적인 입력란은 OK인데, 페이지를 하나 생성해서 제목 다음으로 본문을 입력하는 곳까지 갔을 때 오동작이 발생한다.

개인적으로는 응용 프로그램을 어떻게 만들어야 저런 오동작을 재연할 수 있는지 참 궁금하다만;;
아마 금방 쉽게 해결 가능한 문제는 아니어 보인다. 아마 해결된다면 저런 프로그램만을 위한 보정 동작이 추가될 가능성이 높다. 특히 (2) 같은 유형의 오동작 말이다.
(1)은 현재로서는 보안 프로그램으로 인한 통째로 차단이 의심된다.

아무쪼록 버그 신고를 한다면 날개셋 개발자는 그 프로그램에 대해 전~혀 모른다고 생각하고,
오동작이 일어나는 지점까지 모든 과정을 차근차근 알려주셔야 한다. 아무 입력란에서나 문제를 쉽게 재연할 수 있는 게 아니라면 말이다.
그 프로그램을 사용하기 위해서 무슨 가입, 계정 생성, 로그인 같은 게 필요한지도 안내가 필요하다.

4. Windows 최신 동향: IME 쪽

(1) 지난 몇 년 동안 Windows 동네에서는 한글 IME와 관련된 동작이 생각보다 많이 바뀌었다.
우와~~ composition의 모양이 검은 사각형이 아니라 밑줄로 바뀌었으며, capslock 같은 걸 눌러도 조합이 풀리지 않고 유지된다. 게다가 한글 조합 중에 ctrl+bksp를 눌러도 드디어 단어를 모두 지울 수 있다. (날개셋은 이전부터 이미 가능했음)

이런 건 긍정적인 변화인 것 같다. 여러 정황상 한글 IME의 동작을 중국· 일본어 IME의 동작에 맞춰 일치시킨 듯하다.

(2) Windows Terminal과 Google chrome 브라우저는 오랫동안, 지난 수 년 동안 내 프로그램 기준으로는 '보정'이 필요한 특이한 프로그램이었다.
그랬는데 지금 보니까 언제 고쳐졌는지 그 보정을 안 해도 별다른 오동작 없이 동작하도록 버그가 수정된 듯하다.
이제 그 보정 옵션은 특정 앱에 종속적인 다른 편의 기능을 제공하는 용도로 활용해도 될 것 같다.

(3) 전통적으로 한글 조합이 끝났을 때는 WM_IME_END_COMPOSITION이 오고 그 다음에 WM_IME_COMPOSITION이 뜬금없이 왔었다.
이거 30년 전 Windows 95 시절부터 변함없는 동작이었는데 이제는 후자 다음에 진짜 마지막으로 전자 END_COMPOSITION으로.. 논리적으로 맞게 바뀌었다.

이것도 긍정적인 변화이긴 하지만.. 일부 저 잘못된 동작에 딱 맞춰 동작하는 소수의 프로그램에서 오동작을 일으키는 건 어쩔 수 없다.
조합 모양과 저런 자잘한 동작들을.. 날개셋도 옵션 형태로 조만간 수용하고 업데이트 해야 할 것으로 보인다.

5. Windows 최신 동향: 나머지

(1) 언제부턴가 날개셋 한글 입력기에서 제공되는 필기 인식 기능이 동작하지 않고 있다.
Windows 10/11의 어느 빌드에서부터 내 프로그램이 지원하는 방식인 필기 인식 라이브러리를 빼 버렸다. 그건 구버전 레거시로 치부하고 자기들은 또 다른 새로운 인터페이스로 갈아탄 것 같다. 나름 이것도 Windows Vista 때부터 있던 인터페이스인데..
어휴~ 이건 또 어찌 대응 가능할지 모르겠다. 금방 되기는 어려울 듯..

(2) 그리고 win 10/11 초창기에 비해 현재는 이모지의 렌더링 속도가 엄청나게 느려졌다. 내 프로그램에서 이모지 문자표를 꺼내 보면 창이 뜨고 목록이 스크롤되는 게 무진장 굼뜨는 걸 알 수 있다.
운영체제에서 제공하는 컬러 이모지 폰트가 더 정교해지고 복잡해져서 그런 것 같은데.. 내 프로그램에서 이모지를 실시간으로 점진적으로 표기하고, 한번 표시한 이모지의 비트맵을 캐싱하는 식으로 UI와 성능을 개선해야 할 듯하다.

(3) 지난 Windows 11 2022년쯤 버전부터 운영체제의 인쇄 대화상자가 새끈하게, 혹은 이상하게 바뀌었다. 이게 싫다면서 다시 익숙한 옛날 클래식 대화상자로 되돌려 달라는 청원도 많으나, 마소에서는 들을 생각이 없는 듯하다.
새 대화상자는 아시다시피 인쇄 미리보기가 한데 통합도 돼 있다. 이걸 지원하려면 응용 프로그램이 Windows 11의 새로운 인터페이스를 구현해 줘야 하는데..

문제는 본인은 저걸 지원하는 프로그램, 인쇄 미리보기가 나오는 프로그램을 지금까지 단 하나도 못 봤다. 심지어 메모장이나 그림판처럼 마소 자기들이 만든 프로그램조차도 저걸 지원하지 않으니 도대체 뭐 어쩌라는 건지 궁금해진다.;;;
아마 날개셋 편집기도 이 대화상자를 미리보기까지 정식 지원하는 건 하루아침에 금방 될 것 같지 않다. 개발 우선순위가 아주 낮다. ㄲㄲㄲㄲㄲ

(4) 영문 Qwerty 글쇠배열의 대안으로 드보락이 오랫동안 유명했다. 그러나 2010년대쯤부터는 콜맥이 드보락의 지위를 위협하는 지경에 도달한 것 같다. 본인은 날개셋에서 세벌식과 콜맥을 같이 사용 중이라는 사용자 피드백을 지금까지 굉장히 많이 받았다.
콜맥이 얼마나 유명해졌으면 Windows 11 언제부턴가 콜맥 키보드 드라이버도 내장되어서 정식으로 지원되기 시작했다.

콜맥은 숫자· 기호가 기존 쿼티와 일치하고 이질감도 덜하다는 게 장점인 것 같다. 쿼티와는 완전히 다른 드보락과 다른 점이다.

(5) 이 와중에 요즘 Windows에서는 워드패드가 퇴출돼 버렸다.
mac의 TextEdit나 리눅스의 gedit는 서식 있는 텍스트(간편 워드 프로세서)와 plain text를 동시에 취급할 수 있다. Windows 메모장은 그렇지 않은데 왜 워드패드를 없앴는지.. 이것도 참 이해할 수 없는 일이다. 마소 Word의 축소판 같은 대안이 있는 것도 아닌데 말이다.

RTF는 원래 규격이 그렇게 정의돼 있는지 모르겠다만, 그닥 유니코드 친화적이지 않다. 한중일 2바이트 문자는 몽땅 다 \' 라는 탈출문자와 함께 16진수 바이트 시퀀스 형태로 바꿔서 표시하게 돼 있다.;; 이 때문에 한글· 한자가 들어간 rtf는 실제 용량보다 덩치가 굉장히 커진다.

'코드 번호로 변환' 텍스트 필터에는 C언어 정수 및 문자 리터럴, URL 등 여러 known prefix를 제공하고 있는데, 다음 버전에서는 RTF의 저 prefix도 추가할 예정이다. Windows에서 워드패드가 사라진 와중에 RTF 파일을 읽는 데 도움이 되라고 말이다.

Posted by 사무엘

으아, 내가 프로그램 개발 작업 때문에 9월 한 달 동안 좀 바쁘긴 했지만.. 어째 9월 9일 이후로 블로그에 글을 한 편조차 올리지를 못했구나.. 시간과 체력이 부족한 게 늘 문제인 것 같다. =_=;;

어쨌든 오랜만에 날개셋 프로그램 개발 소식을 전한다.
사실, 한글 입력기는 지난 8월 말에 10.8이 먼저 공개됐었다. 그리고 바로 어제 타자연습도 4.0 버전이 완성되어 나왔다.
한글 입력기는 10.7 이후로 약 1년 4개월 만에 새 버전이 나왔다. 그러나 타자연습은 2021년 6월 이후로 무려 4년 3개월 만의 버전업이다. ㅠㅠㅠㅠㅠㅠ

오징어 게임이 나오기 전, Windows 11이 출시되기도 전의 시점에서 시간이 멈췄었구나..
타자연습은 입력기보다 개발 우선순위가 낮긴 하지만 이 정도면 해도 너무했다. 낡아 가던 프로그램이 이제야 정말 최소한의 유지보수를 받으면서 생존 신고를 했다.

먼저 입력기 얘기부터 하자면.. 개인적으로 여전히 불만족스럽다.
외부 모듈은 거의 건드리지 못하고 다른 원하는 기능들도 여전히 상당수 구현되지 못했다.
아주 자잘하게 개선된 게 없지는 않지만 결정적인 한 방 기능이 구현된 게 별로 없다. 그랬기 때문에 10.8을 올리고도 블로그에다 대대적으로 홍보를 안 했다.

(1) 10.8에서 가장 많이 변화되고 기능이 향상된 곳은 문자표 대화상자이다.
사용자가 선택한 문자가 큼직하게 따로 표시되며, BMP 외의 확장 평면 문자들도 드디어 문자 이름이 표시되게 했다.
'바로가기' 등록을 한 문자들은 레지스트리에 저장되어 프로그램을 다음에 실행할 때도 연계되며..
게다가 무엇보다도 문자표 대화상자를 열어 놓은 채로 본문으로 돌아갈 수도 있게 했다.
하지만 이건 편집기를 사용하지 않고 외부 모듈만 사용하는 분에게는 그다지 와 닿지 않는 변화일 것이다.

(2) 이번 10.8은 '한글 로마자 입력기 빠른설정 -> 로마자 표기법 표준' 방식의 동작도 개선되었다.
L과 X는 종성에서 각각 'ㄹ-ㄹ, ㄱ-ㅅ' 이렇게 독특하게 동작하는데, 초성에서는 각각 ㄹ과 ㅈ으로 단독 입력이 되게 했다.
그리고 QU는 QW와 동일하게(콰), SH는 SY와 동일하게(샤) 처리되게 했다. 그 이유는 조금만 생각해 보면 알 수 있다. 작은 변화이지만 예전보다 더욱 직관적으로 영문 입력하듯이 한글 입력이 가능할 것이다.

(3) 그리고 날개셋 에디트 컨트롤에서 텍스트의 가로 스크롤 방식을 변경했다.
편집기에서 찾기/바꾸기 대화상자에 있는 그 문자열 입력란을 생각해 보시라. 입력란은 10글자밖에 표시를 못 하는데 ABCD...XYZ라는 긴 문자열이 입력되면 화면에는 ABCD...[QRSTUVWXYZ] 이렇게 표시가 될 것이다.

이때 사용자가 Q~Z 사이에 있는 문자열을 일부 삭제하면 예전에는 별다른 스크롤 없이 화면에 [Q*Z] 이런 식으로만 보였다.
그러나 이제는 화면 폭을 다시 계산해서 ABCD...[JKLMNOPQ*Z] 이렇게.. 언제나 오른쪽에 불필요한 여백이 생기지 않는 게 보장된다. 왼쪽으로 더 스크롤할 게 없을 때만 오른쪽에 여백이 생긴다.
single line 모드일 때뿐만 아니라.. multi line 모드이더라도 현재 줄 수가 하나밖에 없다면 동일하게 동작한다.

입력기는 뭐 이런 것들이 바뀌었고, 다음으로 타자연습은...

(1) 4년 만에 새단장을 한 만큼.. 드디어 64비트 전용으로 싹 다시 빌드되었다!!
지금까지 타자연습의 소스는 'task dialog가 없는 곳에서는? 맑은 고딕 폰트가 없는 곳에서는?' 등.. 지금으로서는 상상도 하기 어려울 정도로 낡은 로직들이 가득했다. 이것들 몽땅 다 제거했다.
이제 날개셋 타자연습은 최소한 Windows Vista 64비트 이상을 요구하며, XP 내지 32비트 전용 OS에서는 실행되지 않을 것이다.

(2) 그리고 시대가 시대이니만큼 프로그램의 모든 UI에서 굴림체를 맑은 고딕으로 싹 다 바꿨다.
본 프로그램뿐만 아니라 세벌식 글쇠배열 표시 유틸리티도 맑은 고딕 기반으로 비주얼이 깔끔하게 바뀌었다. 아유 그냥 속이 다 후련하다.
안 그래도 예전 버전이 정말 찔끔찔끔 바뀌어서 3.93까지 가 있었는데 이 기회에 4.0으로 바꾸는 게 아주 적절하다.

(3) 긴글 연습을 끝까지 하고 나서 다시 시작할 때.. 메모리 문제로 인해 한글 입력이 맛이 가거나 프로그램이 뻗던 중대한 문제를 해결했다.
정확하게는 '연습글의 단락 끝에 언제나 공백 추가' 옵션을 켠 채로 긴글 연습 → “연습을 처음부터 다시 시작할까요?” 질문에서 ‘아니요’를 골라서 종료.. 이후에 발생하는 문제이다.
프로그램 구조상 아마 아주 오랫동안 존재했을 걸로 추정되는 문제이다만.. 4.0에서는 이런 문제가 더 발생하지 않을 것이다.

(4) 예전에 예고했던 것처럼.. 한글 입력 설정을 변경하는 '날개셋 제어판' 버튼을 환경설정 대화상자 내부가 아니라 그냥 프로그램의 '글 연습' 탭 내부로 옮겼다.
날개셋 제어판은 딴 대화상자에서 또 호출되기에는 자체적으로도 구조가 너무 방대하고 기능이 많은 UI이기 때문이다.

(5) 그리고 끝으로..
프로그램이 4년 만에 업데이트된 만큼, 도움말 내용도 재검토해서 최신 내용을 반영했다.
가령, "세벌식과 드보락의 관계는?"은 "세벌식과 영문 글쇠배열의 관계는?"이라고 고치고, 드보락뿐만 아니라 요즘 각광받고 있는 콜맥에 대한 언급도 살짝 추가했다.

한글 문화원에 대한 얘기에다가는 공 병우 박사뿐만 아니라 송 현 선생 소개도 추가했으며.. 세벌식 사용자 모임 다음 카페 링크를 넣었다.
최신 유행어 밈 연습글도 눈꼽만치나마 업데이트 했으며, 200여 개에 달하는 수능 시험 '필적 확인 문구'라는 단문 연습글을 추가했다.

2025년 하반기, 오랜만에 나온 새 버전을 유용하게 사용하셨으면 한다..!!

Posted by 사무엘

아이고~ 3월 초 이후로 무려 3주 가까이 블로그에 새 글이 또 끊겼다.
그 사이에 나라엔 괴물 산불 때문에 정말 궤멸적인 피해가 발생했다. 이 와중에 대통령 탄핵은 인용되건 기각되건 이것도 엄청난 후폭풍 파장을 불러일으킬 것이다.

경제 성장이 멈춰서 기업들이 채용을 안 한다네, 자영업자 소상공인들이 지금이 IMF/코로나 시절보다도 장사가 안 된다며 울상인 거는 더 말하면 입만 아프고..
기름값이 좀 내려간 건 좋다만, 그거 말고는 전반적인 나라 상황이 별로 좋지 않다. ㅠㅠㅠ

그래도 이 와중에 본인은 정말 찔끔찔끔 느릿느릿이나마 날개셋 브랜드 프로그램들의 다음 버전 개발을 진행하고 있다.
마지막 버전이 나온 지 벌써 1년이 돼 가는데.. 어지간해서는 올해 상반기는 안 넘기고 죽이 되건 밥이 되건 업데이트를 좀 하고 싶다. 구체적인 시기나 정확한 다음 버전 번호는 아직 미정이다.

현재까지 작업된 것 중에 대외적으로 자랑할 만한 아이템들은 다음과 같다.
막 거창한 작업은 못했고, 그냥 이미 제공되는 기능과 UI들의 완성도를 더 높인 것들 위주이다.

1. 편집기 프로그램의 문자표 대화상자가 다음과 같이 많이 개선되었다.

(1) 오랜 숙원이었는데.. 드디어 U+10000 이후의 확장 평면 글자들에 대해서도 명칭이 나오게 했다.
문자표 대화상자뿐만 아니라 입력 도구 문자표와 이모지 문자표도 모두 동일한 혜택을 입었다.

각각의 이모지들에 대해서도 정확한 설명이 나오는 게 참 좋다.

이건 정확히는 Windows 10 2017년도 언젠가부터 도입된 유니코드 라이브러리를 활용해서 동작한다. 기존 BMP (기본 다국어 평면) 문자의 명칭을 얻는 API와는 다른 새로운 API를 사용한다.
단어들이 몽땅 대문자로 찍혀서 기존 BMP 영역의 명칭과는 이질감이 느껴진다만, 이건 어쩔 수 없는 듯.
마소에서는 왜 이미 만들어 놓은 기존 API를 확장하지 않았는지 그게 개인적으로 의문이다.

(2) '종류'를 'KS X 1001'이나 '모든 한글 자모'처럼 '글꼴이 지원하는 모든 문자'보다 작은 문자 집합을 사용할 경우, 그 문자 집합에 존재하는 유니코드 영역만 '바로가기'에 남게 했다.
이것도 개인적으로는 꽤 오랜 숙원이었는데 드디어 이뤘다.

(3) '모든 한글 자모'에는 지금까지 오로지 표준 한글 자모만이 표시되곤 했는데..
여기 뒷부분에다가는 호환용 한글 자모도 추가했다. 현실에서는 한글 낱자를 표현할 때 이게 워낙 많이 쓰이기 때문이다. 코드 순이 아니라 사전 순으로 표시된다는 점에서 의미가 있다.

(4) 이 대화상자에서 '바로가기'를 등록한 것과, 문자표 입력 도구에서 '사용자 정의 문자표'를 지정한 것이 서로 연계되게 했다.
한쪽에서 문자를 등록하거나 제거한 뒤 대화상자/창을 닫으면, 다른 쪽을 열 때 그게 반영되어 나온다.

(5) 그리고 끝으로.. 이렇게 바로가기/사용자 정의 문자표를 등록한 것은 레지스트리에 저장도 되게 했다.

2. 편집기의 다른 UI와 동작들도 자잘하게 개선됐다.

(1) '기타 가져오기' 대화상자의 '실행 위치'에 현재의 커런트 디렉터리가 cue text로 표시돼 보이게 했다. 사용자는 이 프로그램이 어느 디렉터리를 기반으로 실행되는지를 바로 알 수 있다.

(2) 그리고 저 '/' 버튼을 눌렀을 때 표시되는 디렉터리 선택 대화상자를.. 재래식 스타일 말고 최신 스타일로 표시되게 했다. 에 그 뭐냐.. 기존 파일 선택 대화상자를 변형해서 디렉터리 선택 모드로 표시하는 거 말이다.
재래식 스타일(browse for folder)은 한눈에 봐도 좀 낡고 구려 보인다. 아래 스샷을 참고하시라.

(3) 이 프로그램에는 지금 편집 중인 문서 파일이 있는 위치(디렉터리)에서 '명령 프롬프트'를 여는 기능이 있다.
이게 지금까지는 cmd.exe / command.com이라는 실행 파일 이름을 하드코딩 하는 무식한 방식으로 구현되어 있었다.
그러나 이제는 COMSPEC이라는 환경변수를 통해 저 프로그램 이름과 위치를 얻어 오는 걸로 바뀌었다. 이건 뭐 아주 자잘하고 사소한 변화이다.

(4) 이 프로그램에는 '모두 저장'이라는 명령이 있다.
이건 내용이 변경된 문서 창들에 대해서 일괄적으로 저장 명령을 내리는 기능인데..
우리 쪽에서 내용을 변경하지 않았더라도 외부에서 파일 내용이 바뀐 것도 감지해서 어떻게 할지 사용자에게 묻게 했다. (그걸 불러오거나, 아니면 우리가 저장을 다시 해서 덮어쓰거나)

어쨌든 save all 명령이 한번 성공적으로 수행되고 나면 그 어떤 경우든 메모리로 읽혀져 있는 텍스트 내용과, 파일로 저장된 텍스트 내용이 서로 동기화가 되게 했다.

3. 그 밖에

(1) 텍스트 필터, 입력 도구 등~~ 분야별 각종 기능 목록에서 말이다.
별도의 추가적인 설정 사항이 없는 기능을 선택했을 때는 설정 버튼이 처음부터 흐려지고 눌러지지 않게 했다!!

햐~ 이것도 진작에 조치를 취했어야 했는데 왜 이제야 아이디어가 떠올랐나 모르겠다. ㄲㄲㄲㄲㄲㄲ

(2) 날개셋 제어판의 '낱자 처리' 탭에서 한글 낱자들을 선택하는 컨트롤 말이다.
회색으로 표시되는 초성 ㄱㄴ, 종성 ㄱㄷ처럼.. 내 프로그램에서만 편의상 사용하는 비표준 낱자들은 기본적으로 표시되지 않게 했다.
이전까지는 표시하는 게 디폴트, 숨기는 게 옵션이었던 반면, 이제부터는 숨기는 게 디폴트, 표시하는 게 옵션으로 정책을 바꿨다.

(3) '화면 키보드'에서 글쇠들의 배경색을 미묘하게 바꿨다. 문자 글쇠는 흰색으로, ctrl/shift 같은 비문자 글쇠는 회색으로 나오게 했다. (저 스샷 상으로는 회색이 너무 연하긴 하다만..)
흠, 옛날 쌍팔년도 시절 XT니 286이니 하던 시절엔 컴터 키보드가 다들 이런 색깔이었던 것 같은데.. 거기에서 착안했다. 요즘은 그런 고전적인 배색을 찾기 어려운 듯..

이 흰색과 회색 구분은 단순히 붙박이로 고정되어 있지 않다.
현재 입력 스키마가 가로채어 사용하는 글쇠는 흰색, 그렇지 않은 글쇠는 회색이다.
그렇기 때문에 '빈 입력 스키마'일 때는 모든 글쇠가 예전처럼 회색으로 나온다.
아직도 화면 키보드에 이렇게 자잘하게 개선할 게 있었다니 참 신기하다. ^^

(4) '한글 로마자 입력기'의 '공진청' 방식에서 ㅝ가 입력되지 않던 것을 바로잡았다.
이건 내 기억으로 거의 작년 8월에 외국인 사용자에게서 메일을 통해 오류를 제보받았던 건데.. ㅠㅠㅠ
프로그램이 그때 이후로 아직까지 버전업이 되지 않아서 개선 사항이 반영되지 못했다.

이상이다.
생각 같아서는 외부 모듈에서 '일본어 IME와 같이 사용할 때 전각/한영 상태 이슈', 'space 가로채기 여부를 보정 옵션으로' 이슈를 꼭~~ 처리하고 싶은데.. 이게 다음 버전에 들어갈 수 있을지 모르겠다.

4. 타자연습도..

(1) 타자연습은 딱 하나.. "로그인 하지 않은 익명 상태일 때 날개셋 편집기의 글꼴 설정을 가져오게 하기"만이 작업되어 있다.

(2) 타자연습 내부에서 날개셋 제어판을 꺼내는 곳은 지금처럼 설정 대화상자 내부가 아니라 주 프로그램 창으로 옮길 예정이다.

(3) 이것 말고, 긴글 연습을 끝까지 마치고 나서 다시 들어갔을 때 한글 입력 설정이 깨지고 프로그램이 뻗는 매우 중대하고 심각한 문제가 사용자의 신고로 접수됐고 내 자리에서 재연까지 확실하게 됐다.
이건 0순위로 해결돼야 하고 무조건 다음 버전이 나와야 할 안정성 문제인데, 정말 답답하게도 아직 정확한 원인 파악과 해결이 안 됐다. =_=;;; 어쨌든 이거 해결 없이는 다음 버전 없다.

내일 지구가 멸망한다 해도 코딩 할 거리는 왜 이리 많나 모르겠다.
내 프로그램 관련 소통 창구로 구글 포럼을 개설할까... 이것도 일단 생각할 거리이다.
10여 년 전엔 페이스북 플러그 인을 개설한 적이 있었는데, 뭐가 잘 안 돼서 얼마 못 가 닫았었다.

Posted by 사무엘

오랜만에 날개셋 한글 입력기가 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 사무엘

날개셋 한글 입력기의 다음 버전이 일단은 다음 달 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를 표시할 공간만 있으면 스크롤을 더 하지 않게 했다.

(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 사무엘

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 사무엘

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

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