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