날개셋 한글 입력기가 10.0 이후로 10.2 버전 정도가 올해 연말 완성을 목표로 개발 중이다.
1. 자잘한 UI 개선
(1) 날개셋 에디트 컨트롤의 내부 가장자리에 좌우상하로 1픽셀씩 여백을 추가했다. 그래서 텍스트가 좌측 상단에 너무 답답하게 딱 붙은 게 아니라 약간이나마 더 여유로워 보이게 했다. (왼쪽: before, 오른쪽 after)
운영체제의 에디트 컨트롤은 진작부터 여백이 적용되어 있다. 그렇기 때문에 내 컨트롤에다가도 여백을 넣고 싶다는 생각을 아주 오래 전부터 하고는 있었다.
하지만 이런 여백이 있으면 좌표 계산과 스크롤/클리핑 등 내부 처리가 꽤 복잡해지기 때문에 지금까지 이를 반영하지 못했었다.
(2) 지금까지는 운영체제의 화면 확대 배율이 정확하게 150% (144 dpi) 이상일 때만 24픽셀 글꼴이 쓰였는데, 그보다 낮은 125% (120 dpi)일 때도 시스템 글꼴이 '맑은 고딕'처럼 자체 높이가 충분히 있을 때는 24픽셀 글꼴이 쓰이도록 로직을 수정했다.
이미 경험적으로 보셨겠지만 125%이더라도 대화상자는 에디트 컨트롤이 24픽셀 글꼴이 들어가고도 남을 정도로 커져 있으며, 16픽셀 글꼴은 보기에 너무 작게 느껴진다.
(3) 그리고.. 날개셋 1.0 이래로 20년째 좀 엉성한 모양이던 상하 스핀 컨트롤의 모양을 이제야 왼쪽의 에디트 컨트롤과 제대로 융합된 형태로 바로잡았다..;; 이걸 내가 왜 지금까지 그냥 놔 두고 있었나 모르겠다.
편집기의 화면 설정과 쪽 설정 대화상자, 줄 번호 찾아가기, 날개셋 제어판의 입력 항목 순서 같은 UI에서 스핀 컨트롤을 확인할 수 있다. (위: before, 아래: after)
(4) 편집 화면 설정 대화상자에서 사용자 정의 색상 4가지를 지정한 것과는 별개로, 색깔 선택 대화상자에다가 사용자 색상(최대 16개)을 지정한 것이 다음에 색깔 대화상자를 열 때에도 계속 보관되고 유지되게 했다. 다만, 이 색상은 이 프로그램 인스턴스가 살아 있는 동안에만 보관된다. (레지스트리에는 콤보 목록에 나타나는 배경-글자색 pair 4쌍의 값만 저장)
지금까지 별로 티가 나지는 않았겠지만 custom 색상이 제대로 저장되지 않았을 뿐만 아니라 미세한 메모리 범위 초과 오류까지 굉장히 오랫동안 존재했는데.. 그걸 이제야 발견해서 고쳤다.
2. 수식 관련
(1) 상수의 범위 초과 감지
날개셋 한글 입력기의 수식 처리기는 부호 있는 64비트 정수를 기반으로 동작한다. 그러니 2^63 - 1에 해당하는 9223372036854775807까지만이 인식되고, 1 더 큰 …5808은 부호 여부와 관계없이 음수로만 인식된다. 마치 0은 부호와 관계없이 동일한 0인 것처럼 말이다.
그리고 …5809 이상부터는 수식 파싱 차원에서 constant too big 에러로 처리되고 접수가 거부되게 했다. 16진수 상수도 마찬가지이다.
이제 11111111111111111111 같은 수를 입력하면 숫자가 제멋대로 짤리고 엉뚱하게 접수되는 게 아니라 처음부터 접수가 거부된다. 날개셋 한글 입력기가 거의 완결 단계에 들어서니 이런 정말 사소한 부분까지 완성도를 신경 쓸 여력이 생긴 듯하다.
물론, 이런 상수 자체 말고 계산 과정에서 발생하는 overflow나 underflow는(예: 곱셈 내지 bit shift) 여전히 프로그램이 감지해 주지 않는다.
(2) 계산기 필터 숫자 음수 부호 인식
수식은 글쇠나 오토마타처럼 날개셋 한글 입력기의 엔진 내부뿐만 아니라 사용자의 편의 기능으로도 쓰인다. 특히 입력된 텍스트의 내부에 있는 숫자나 수식을 일괄 계산해 주는 “계산기”라는 텍스트 필터가 오래 전부터 추가돼 있었다.
얘는 계산 대상을 인식할 단위로 텍스트 전체, 각각의 줄 전체, 중괄호나 따옴표로 둘러싸인 부분 등을 지정할 수 있다. 그리고 그냥 단독으로 등장한 숫자들을 모두 개별적인 계산 단위로 인식하게 할 수도 있다. 이렇게 하면 “2 3 5 7” 이런 숫자 리스트에 대해 일괄적으로 5를 더한다거나 2을 곱한다거나 하는 변형을 가할 수 있다.
그런데 이런 “개별 숫자 인식” 옵션이 지금까지 숫자 앞의 부호를 같이 인식하지 않는다는 점을 뒤늦게 발견하여 개선했다.
3. 문자 표현 방식 단일화 필터
지난 1~2년 남짓한 시간 동안 날개셋 한글 입력기는 보조 입력 도구에만 기능이 잔뜩 추가되었고 텍스트 필터 쪽은 거의 변화가 없었는데.. 이번에 또 자그마한 변화가 생겼다.
“한자 표현 방식 단일화”라고 텍스트 중의 호환용 한자를 표준 영역 한자로 변환해 주는 필터가 있는데.. 이건 무려 2011년, 6.3 버전부터 존재했던 기능이다.
이게 “문자 표현 방식 단일화”라고 더 범용적인 명칭으로 바뀌고, 변환 기능이 3종류가 더 추가됐다.
컴퓨터에는 기술적· 역사적인 우여곡절로 인해 동일한 문자를 표현하는 방식이 둘 이상 존재하는 경우가 많다. 특히 그 문자가 여러 부분문자들이 합쳐져서 구성되는 합자라면 더욱 그러하다. 특이한 액센트 부호가 붙은 알파벳 변형 문자가 대표적인 예이고, 한글도 낱자라는 부분문자들이 합쳐지는 형태이기 때문에 이런 범주에 든다.
합쳐진 전체 문자를 단독으로 취급하여 코드값을 부여하느냐, 아니면 부분문자들만 등록하고 이것들을 한데 묶어서 표현하느냐의 문제인데.. 이게 서로 장단점이 있기 때문에 딱 부러지게 정해진 답이 없다. 과거에 컴퓨터가 성능이 부족하고 소프트웨어의 국제화와 글꼴 출력 기술이 발달하지 못했던 시절에는 문자를 최대한 전자처럼 취급해야 했지만 오늘날은 후자 지향적인 처리도 얼마든지 가능해져 있다.
하지만 중요한 것은 정보 교환을 위해서는 동일한 문자는 합자 지향이든 부분문자 지향이든 한 방식으로만 표현되어 있어야 한다는 것이다. 동일한 문자가 일관된 방식으로 표현되어 있지 않으면 사람이 같다고 인식하는 문자가 컴퓨터에서는 같다고 인식되지 않고 검색이나 비교, 심지어 보안 같은 데서 큰 혼란이 생긴다.
한자는 글자의 생성 원리와 조합 가능성이 너무 판타스틱(..)하기 때문에 애초부터 분해를 포기하고 몽땅 무식하게 완성형으로 처리되고 있다. 그러니 합자냐 부분글자냐 하는 원론적인 문제를 겪지는 않고 있지만.. 한중일 국가별로 여러 지저분하고 구린 사정으로 인해 동일한 글자가 둘 이상의 코드값에 중복 배당되어 있다. 한국의 경우 독음 바리에이션 때문에 그렇다. (부/불, 악/낙/락 따위)
호환용 한자를 표준 영역의 대표 한자로 모두 바꾸는 것은 동일 문자를 동일한 코드값으로만 표현되게 하는 단일화, 정규화 작업 중의 하나이다. 이와 같은 맥락으로, 합자 지향 또는 부분문자 지향으로 변환하는 기능(각각 NFC 정규화, NFD 정규화)을 자체 구현이 아니라 운영체제 API 호출을 통해 수행하는 옵션을 여기에다 추가했다.
그러니 이 기능은 기존의 “한글 형태 정규화” 필터가 하는 일도 같이 하는 셈이다. 한글뿐만 아니라 유럽의 액센트 문자들도 같이 다루니 기능이 더 많다.
하지만 날개셋 한글 입력기는 한글을 전문으로 취급하는 프로그램이므로 한글의 형태만 바꿔 주는 전용 필터는 여전히 별도로 남아 있을 것이다. 더구나 얘는 자체 구현이다.
(1) 호환용 한자 제거, (2) NFC, (3) NFD 이렇게 세 가지는 설명이 됐고, 마지막 남은 변환은 (4) ‘리가처’ 문자를 부분문자로 분해해 주는 기능이다. æ를 실제 알파벳 ae로 바꾸는 식이다.
유니코드에는 도대체 무슨 용도인지는 모르겠지만 Nj, Lj 같은 글자가 한데 뭉친 리가처가 있으며, U+FB0?대에도 fi, ffl 같은 글자가 합쳐진 리가처가 있다. 리가처는 분해하는 기능만 있고, 일반 알파벳으로부터 다시 합성해 주는 기능은 없다.
4. 편집기: 파일 열기 관련
(1) 날개셋 편집기는 파일을 원형 그대로 제대로 열지 못해서 이대로 다시 저장하면 파일의 원형이 손실될 우려가 있을 때, 이를 에러 메시지로 표시해 준다. 원형 그대로 열지 못하는 조건으로 현재 문자 인코딩이 잘못 지정된 것, 줄 바꿈 문자가 일관성 없게 지정된 것 두 가지가 존재하는데 이 뿐만 아니라 null 문자가 존재하는 것도 추가되었다. null 문자 이후 부분은 인코딩과 무관하게 아예 잘리기 때문이다.
물론 null 문자는 텍스트 파일에는 존재할 이유가 전혀 없는 문자이며, 이게 존재한다는 것은 날개셋 편집기에다가 실행 파일처럼 편집 대상이 아닌 파일을 잘못 지정했기 때문일 가능성이 높다.
(2) 파일 메뉴 끄트머리에 있는 최근 사용 파일 목록에서 현재 접근 가능하지 않은 파일은 뒤에 (?)가 붙어 표시되게 했다. 단, 경로가 하드디스크에 있어서 존재 여부를 빠르게 확인 가능한 파일만으로 한정이다. 네트워크/USB 메모리/광학 디스크 따위는 포함되지 않는다.
(3) 최근 사용 파일을 열었는데 그 파일이 현재 존재하지 않는 경우, 그냥 파일이 없다는 에러만 표시하는 게 아니라 이 경로가 지정된 빈 문서를 새로 생성할 것인지를 묻게 했다. 일부 텍스트 에디터들이 행하는 관행을 날개셋 편집기도 따르기 시작했다.
다만, 파일 이름만 없을 때로 한정이다. 드라이브나 디렉터리 자체가 존재하지 않는 경우에는 여전히 예전과 같은 에러 메시지가 표시된다.
5. 편집기: 인쇄
날개셋 편집기에 인쇄 기능은 잉여에 가깝긴 하지만... 다음과 같은 작업이 행해졌다. 용지의 가로/세로 배치와 텍스트의 가로쓰기/세로쓰기 배치를 자유롭게 할 수 있게 했다.
- 텍스트를 다단(!!) 형태로 배치하는 기능을 추가했다. 너무 많이는 아니고 최대 4단까지 가능하게 했다. 그리고 용지 크기와 글자 크기, 단 간격을 감안해서 한 단의 폭이 전각 12자보다 작아지지는 않는 한도 내에서만 단을 나눌 수 있다.
- 용지의 인쇄 방향(세로 portrait, 가로 landscape) 같은 설정이 인쇄 대화상자를 닫은 뒤에도 저장되고 미리보기 같은 것에 반영되게 했다.
- 세로쓰기일 때는 화면 인쇄의 양쪽 보기 기능도 좌-우가 아니라 우-좌로 페이지를 표시하며, 다음 페이지로 스크롤도 오른쪽이 아닌 왼쪽 화살표로 되게 했다! 이렇게 고칠 생각을 지금까지 왜 못 했나 모르겠다.
- 페이지의 마지막 줄은 굳이 줄 간격까지 고려할 필요 없이 글자가 들어갈 공간만 있으면 인쇄되어 표시되게 했다.
- 머리글과 바닥글은 굴림 대신 맑은 고딕으로 출력되게 했다. (정확히는 현재 대화상자 GUI용 글꼴)
그 밖에,
- 확대 배율을 급격히 축소하고 나서(500%에서 150% 같은) 마우스 드래그로 스크롤을 할 때 화면 잔상이 남음
- 미리보기 때는 이상이 없는데 실제로 인쇄를 하면 머리글과 바닥글이 가끔 엉뚱한 각도로 기울어져 출력됨 (always는 아니고 컴퓨터에 따라 케바케로 발생하는 듯..;; )
- 약간의 resource leak
요런 버그도 고쳤다~!
위의 인쇄 미리보기 스크린샷은 이번 버전에서 바뀐 사항들을 모두 보여준다. (다단, 세로쓰기에서 2페이지 우-좌 배치)
*. 희망 사항: ARM64 지원
마소에서는 잘 아시다시피 Windows Phone/Mobile 같은 모바일 제품군은 안드로이드와 iOS 대비 승산이 전혀 없다고 판단되어 그냥 접고 포기를 선언한 바 있다. 하지만 그 대신, 요 몇 년 전에는 데스크톱용 Windows 10을 그대로 모바일 CPU인 ARM64용으로 포팅하는 굉장히 참신한 시도를 했다. Visual C++ 2017/2019를 통해 ARM64용 컴파일러와 라이브러리도 무료로 제공하면서 이 플랫폼을 적극 지원하는 중이다.
그래서 Windows 10 on ARM의 사용자로부터 날개셋 한글 입력기도 ARM64 에디션이 좀 나왔으면 한다는 요청이 있었다. 반디집은 진작에 ARM64용이 나왔으며, 본인은 저런 플랫폼이 있다는 것 자체를 반디집을 통해서 들었다.
얘는 x64 이후로 거의 15년 만에 접하는 새로운 아키텍처이다. 과연 ARM64가 x86 계열로 천하통일이 돼 있는 데스크톱 시장에도 잘 안착할 수 있을까? 만약 그게 성공한다면 데스크톱과 모바일의 경계가 한층 모호해지는 계기가 되겠지만.. 성공 여부는 성능과 가격 같은 기술적인 요인보다는 그냥 마케팅과 호환성, 사용자들의 경로의존성 관성 같은 social한 요인에 더 크게 좌우될 것 같다.
쟤도 ARM64뿐만 아니라 32비트 기반의 레거시 ARM이 있긴 하다. 하지만 Windows 10 운영체제 자체는 처음부터 64비트로 개발됐으니, x86 환경에서처럼 프로그램을 번거롭게 32비트와 64비트를 지저분하게 다 고려하지 않아도 될 것으로 보인다.
보아하니 ARM64는 x86 코드를 에뮬레이션으로 실행하는 기능이 있지만 물론 속도가 느린 건 감수해야 한다. 그리고 x64는 지원하지 않는다.
ARM64라는 새로운 환경이 어떨지 기대되긴 하지만.. 날개셋 한글 입력기를 여기에 맞게 빌드해서 테스트 해 보려면 나도 기기가 필요하다.;; -_-
직장을 포함해 주변에서 Windows 10 on ARM 기기를 한 번도 구경을 못 해 있다.
Posted by 사무엘
