Search Results for '2021/08/04'


1 POSTS

  1. 2021/08/04 다음 버전 개발 근황 by 사무엘

다음 버전 개발 근황

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

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


블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/08   »
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:
1667176
Today:
983
Yesterday:
1272