다음 버전 개발 근황

2014년에 처음으로 나올 <날개셋> 한글 입력기의 다음 버전은 7.4로 정해졌으며 한창 개발 중이다. 지금까지 작업이 완료된 변화 내역은 다음과 같다.

1. 현재 MS 한글 IME의 사전을 이용하여 단어 단위로 한자를 변환하는 기능이 제공되고 있는데, 원래 있는 사전뿐만 아니라 MS IME에다 사용자가 등록해 놓은 custom 사전의 내용도 목록에 같이 뜨게 했다.

2. 제어판의 '편집기 계층'에서 옵션을 바꾼 뒤 '확인' 종료를 하면, 제4후보 설정들이 날아가 버리는 약간 중대한 버그가 있었다. 이것을 고쳤다. 사용자 정의 후보가 첫 추가된 7.0 이래로 존재했던 버그이며, 7.11에 존재하던 사실상 유일한 버그였다. 게다가 이것은 7.11만의 버그도 아니니 이번 7.11은 딱히 고쳐져야 할 게 없이 정말 완성도 높게 잘 만들어지긴 했다.

3. 낱자 수정 모드로 진입했을 때 전체 반전이 아니라 사각형 테두리 모양의 cursor가 거의 10년 만에 부활했다. 물론 이건 외부 모듈 말고 <날개셋> 편집기만으로 한정이다.

사용자 삽입 이미지

아마 아시는 분이 많지 않겠지만... <날개셋> 한글 입력기에는 낱자 수정 모드라는 게 있다. 삽입/겹침이 '겹침'에 맞춰져 있고(Ins 키), 낱자/글자가 '낱자'로 맞춰져 있는 경우(Shift+Ins), '가'를 '개'나 '나'로 곧바로 고친다거나 '강'으로 한 타 만에 고칠 수 있다. 글자를 처음부터 다시 입력해야 할 필요가 없다. 이것은 무려 1.0 첫 버전부터 긴 역사를 자랑하며 지원되어 온 기능이다.

낱자 수정 모드도 엄밀히 말하면 한글 조합 상태이긴 하지만 여느 상태와는 다르다. <날개셋> 편집기는 삽입/겹침이나 한글/영문이 아니라 낱자 수정 상태만을 별도의 cursor 모양으로 표시해 주고 있었는데.. 이건 까마득한 옛 버전인 1.x와 2.x까지만으로 한정되었다.

에디팅 엔진이 완전히 교체되고 운영체제의 표준 cursor를 사용하기 시작한 3.0부터는 낱자 수정 모드 자체는 존재하지만 다른 시각 피드백 구분이 없어졌으며, 그 관행이 2004년 이래로 10년째 지속되어 왔었다. 테두리 cursor는 10년 가까이 봉인되었다가 드디어 이번 버전에서 부활할 예정이다.

4. 외부 모듈에서 '빈 입력 스키마' 내지 '빈 입력 스키마 호환 옵션이 지정된 영문 쿼티'를 없앤 상태로 '확인'을 누르면 아예 경고문이 나타나게 했다. 링크를 클릭하면 더 자세한 도움말 설명도 나타난다.
쿼티를 없애고 드보락만 지정했는데 '빈 입력 스키마'가 자꾸 자동으로 추가돼서 이상하다는 문의가 지금까지 하도 많이 들어와서 말이다.

그렇게 IME가 인위로 글쇠를 생성하는 글자판은 비록 영문을 입력하는 방식이라 할지라도 기술적으로는 한글 모드일 뿐이다. IME가 아무 글쇠도 처리하지 않고 한국어 키보드 드라이버에 배당되어 있는 쿼티 방식 그대로 글쇠를 보내는 모드가 아예 없을 수는 없다.

5. 또한 이와 비슷한 매락에서, 단축글쇠 배당 대화상자에서는 Ctrl/Alt의 경우 오른쪽 방향은 인식되지 않을 수 있다는 경고문도 간단히 추가했다. 한국어 키보드 드라이버는 이들 글쇠를 한영/한자 키로 인식하기 때문이다.
<날개셋> 편집기야 자체 한글 기반이기 때문에 한국어가 아닌 여타 외국어 글쇠배열을 사용하다가 자체 한글 입력 모드로 들어가면 오른쪽 Ctrl/Alt를 인식 가능할 수도 있다. 그러나 외부 모듈은 그 자체가 한글 IME이고 무조건 한국어 키보드 드라이버와만 연결되기 때문에 그런 선택의 여지가 없다.

6. <날개셋> 한글 입력기는 MS IME와 마찬가지로 유니코드 BMP 영역에 있는 모든 한자들을 독음으로 입력할 수 있다. 그러나 현실에서 상용 한자 이외의 한자가 쓰이는 일은 매우 드물다. 그렇기 때문에, 좀 잉여스러워 보이긴 하지만 MS IME와 마찬가지로 '확장 한자 사용' 옵션을 켰을 때만 모든 한자들이 다 보이고 평소에는 상용 한자 4888자만 나타나게 했다. 이렇게 하는 게 처리 속도도 더 빠르고 말이다.
물론 이것은 사용자 후보나 단어 단위 한자 변환 동작에는 전혀 영향을 주지 않는다. 한글 하나만을 제1 후보 방식으로 기본 변환할 때에 한해서이다.

7. 편집기는 문서를 저장할 때 이미 있던 파일에다 덮어쓰는 경우, 임시 파일을 생성하여 저장한 뒤 임시 파일의 저장이 완전히 성공한 뒤에야 기존 파일을 지우고 임시 파일을 개명하는 방식으로 동작하게 했다. 저장 중에 프로그램이 뻗더라도 파일 내용이 송두리째 날아가는 일은 발생하지 않게 조치를 취했다. 어찌 보면 안전을 위한 기본 조치인데 <날개셋> 편집기는 지금까지 그런 정책을 채택하지 않고 있었다.
디스크의 용량이 극도로 부족할 때는 예외적으로 그렇게 복사본을 만들지 않게 하는 알고리즘도 필요할 듯도 하지만 일단은 거기까지 고려는 하지 않게 했다.

그리고 안전한 저장이라 하니까 생각하는데, <날개셋> 편집기는 자동 저장 기능은 여전히 지원하지 않으며 개발 계획에도 없다.

8. 다음으로 아주 잉여로운 GUI 변화 사항으로는...
TSF 시스템이 없는 운영체제에서는(Windows XP 미만의 초 구닥다리) 편집기의 'TSF 지원' 옵션이 흐리게 나오고, 자체 한자어 사전이 없는 운영체제에서는(Vista 미만) '단어 단위 한자 변환' 옵션이 흐리게 나오는 당연한 조치를 취했다. 물론 오늘날 운영체제에서는 아무 의미 없는 조치이지만, <날개셋> 한글 입력기는 공식적으로는 32비트 에디션 기준으로 윈도 95에서도 완벽하게 실행되는 거의 변태 같은 프로그램이기 때문에.. ㅎㅎ

- 블로그에 공지했던 입력 방식 유료 컨설팅 관련 설명은 도움말의 '일러두기'에도 당연히 짤막하게 추가되었다.

- UTF-8, UTF-16LE 같은 몇몇 용어를 표준 표기에 맞게 수정했으며,
- 빠른설정을 선택하는 목록 메뉴에서 '한글 로마자 입력기'가 신세벌식이나 복벌식보다 더 앞에, '기본 입력 설정' 바로 다음으로 나오게 순서를 변경했다. 이유는 두 말할 나위 없이 로마자 입력 방식이 두벌식/세벌식 다음으로 가장 널리 쓰인다고 판단되기 때문이다.

메이저한 굵직한 기능을 추가하기도 전에 사소한 변화 사항도 벌써 이만치 나왔다. 재미있다.
이런 경험들이 하나씩 쌓이면서 프로그램의 완성도는 갈수록 상승한다.

이미 보신 분도 계시겠지만, 사실 지난 1월에는 <날개셋> 한글 입력기 소개 페이지도 싹 갈아엎었다. 문서 만드는 게 코딩 이상으로 더 힘들 수 있다는 걸 실감한 시간이었다.

첫 화면에는 이 프로그램이 무엇인지 그 본질을 최대한 단순· 간단하게 소개한 뒤, 다운로드 페이지는 별도로 마련하고
프로그램에 대한 자랑질은 (1) 입력 아키텍처 쪽, (2) 세벌식 위주의 고급 활용 기능, (3) 편집기 및 외부 모듈 같은 구현체 소개
이렇게 세 단계로 완전히 세분화를 했다.

특히 (2)번의 경우.. 팔자에도 없던 움짤(gif)까지 최초로 만들어서..
기존 입력기에서는 이렇게 불편하게 고쳐야 하는 것을 이 프로그램으로 세벌식 + 관련 설정을 바꾸면 저렇게 곧바로 가능하다는 걸 바로 알 수 있게 했다. 왜 지금까지 이렇게 만들 생각을 안 했나 모르겠다.

마지막 '간단한 사용법'은 이 프로그램을 받아 놓고 도대체 무슨 기능부터 써 봐야 할지를 모를 사용자를 위한 팁 모음 같은 페이지이다.
내가 왜 코레일로 이직을 못 하고 있는지 궁금하신 분들은 한번 구경해 보시길~~ ㅎㅎ

다음으로 <날개셋> 타자연습이다.
타자연습의 경우 지난 2013년 한 해 동안은 새 버전 소식이 없었다.
그러다가 올해 초에는 입력기 7.4와 더불어 타자연습도 3.4가 나올 예정이다.

사용자 삽입 이미지
큰 기능 변화는 없고 아기자기한 외형 변경, 고해상도(high DPI) 모드에서의 일부 외형 glitch 수정 등이 이뤄졌다.
작은 크기에서 기존 32*32 아이콘을 줄인 밍밍한 아이콘이 아니라, 깔끔한 소형 전용 아이콘이 나오는 것을 주목할 것.
그리고 이번 기회에 연습글을 상당수 교체할 예정이다.

단문 연습용으로 너무 식상한 속담· 격언을 넘어서서 김성모 화백 어록이 제공된 게 지금까지 반응이 무척 좋았다. "내가 무릎을 꿇었던 건 추진력을 얻기 위함이었다" 같은 드립이 타자 연습글로 나오니까..ㅎㅎ
이번에는 일반 인터넷 유행어도 추가되어 "저 새는 해로운 새다" "찰지구나" "안녕하신가 힘세고 강한 아침" "병시나 산소" 등이 연습글로 제공될 예정이다.

그리고 허 성도 교수의 <우리 역사 다시 보기> 강연 녹취록을 적당히 편집하여 새 연습글로 추가했다. 분량도 적당히 많고, 내용 역시 매우 건전하고 훈훈하고 이념스러운 것 없고, 전국민에게 알릴 필요가 있는 좋은 내용이기에 즉시 추가했음.

이것 외에도 혹시 추가할 만한 좋은 연습글 있으면 추천받는다.
잘 알려지지 않은 인물의 선행/성공 일대기, 특정 사회 시스템을 돌아가게 하는 내부 사정 이야기, 언어 특성을 잘 살린 탁월한 운문이나 수필 등등이 좋을 것 같다..
아울러, <방망이 깎던 노인> 내지 <은전 한 닢>의 패러디 중 하나가 "재미있는 이야기" 카테고리에 들어갈 가능성이 있다.

끝으로, 세벌식 파워업도 2013년 한 해 동안 버전업이 없다가 최근에 간단한 업데이트가 행해졌다.
다른 프로그램을 사용하다가 파워업의 꼬마 윈도우를 클릭했을 때, "x벌식으로 바꿨습니다"와 함께 키보드 포커스가 잠깐 밖으로 나갔다가 다시 돌아와야 하는데..
지금까지 그렇지가 않아서 IE 11 같은 프로그램에서 글자판 전환이 곧장 반영되지 않던 문제가 있었다.
이번 패치는 이 문제를 해결했다.

IE 9와 IE 10에서 모두 원래 관찮았는데 하필 Windows 8.1 + IE 11에만 문제가 있는 걸 사용자의 제보를 통해 확인했다.

이상, 입력기, 입력기 소개 페이지, 타자연습에 파워업까지.. 오랜만에 본인의 본업 관련 소식을 쭉 전했다. 새해에는 세벌식 글자판이 더욱 널리 알려지고 쓰였으면 좋겠다.

Posted by 사무엘

2014/02/04 08:22 2014/02/04 08:22
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/927

Trackback URL : http://moogi.new21.org/tc/trackback/927

Comments List

  1. 세벌식 2014/04/24 22:07 # M/D Reply Permalink

    "세벌식-드보락" 사용자입니다.
    XP, 윈7 까지는 Shift+Ctrl로 "두벌식-쿼티"로의 단방 전환이 가능했으므로
    다른 입력기가 필요하지 않았는데,

    윈8.1에서는 단방 전환이 불가능하고 설정을 바꾸는게 엄청 번거로와져서
    방법을 찾다가 <날개셋입력기>를 설치하고 편리하게 사용할 수 있게 되었습니다.
    "윈도우키+스페이스바"로 "두벌식-쿼티"로의 단방 전환이 가능하기 때문입니다.
    컴퓨터를 전적으로 혼자 사용할 수는 없으므로 간편한 단방 전환 가능 여부는 매우 중요합니다.

    그런데...

    영영사전 프로그램을 사용하다가 발견한 문제점.
    (Longman Dictionary of Contemporary English 5th, Oxford Advanced Learner's Dictionary 8th 등등..)

    -. "날개셋-드보락"으로 설정을 하고 프로그램을 띄워도 "날개셋-쿼티"로 설정이 바뀜.
    -. "날개셋"에서 쿼티를 제거해봐도 여전히 쿼티로 바뀜.

    -. 바뀐 쿼티 상태로 그냥 입력을 하면 곧바로 입력이 되고,
    쿼티탓에 잘못 찍힌 글자를 지우고 드보락으로 전환하면 입력이 되지만,
    쿼티로 바뀐 상태에서 곧장 드보락으로 바꾸면 곧바로 입력이 되지 않고,
    입력창에 한번 클릭을 해야 입력이 시작됨.

    -. 윈도우 내장 드보락으로 설정하면 위의 문제가 생기지 않고 곧바로 드보락으로 입력이 가능함.
    하지만, 내장 드보락은 한글세벌식과 조합되지 않고 따로 설정이므로 한영전환시 번거롭고 불편함.


    <날개셋입력기> 7.4버전에서는
    드보락이 자꾸 쿼티로 바뀌거나, 작동이 불안정한 문제가 해결되었으면 좋겠습니다.
    부탁합니다...

    1. 사무엘 2014/04/25 09:58 # M/D Permalink

      안녕하세요?
      한글 IME는 키보드 드라이버 차원에서 동작하는 고유 글자판을 바꾸지는 못합니다. 그 쿼티는 자기가 쿼티 글자판을 구동시키는 모드가 아니라, 자기가 동작하지 않고 모든 글쇠를 응용 프로그램으로 보내는 모드입니다.
      그렇기 때문에 인위로 동작하는 드보락 모드 말고도, 필요한 경우 쿼티 글자판이 반드시 있어야 합니다. 제어판에서 쿼티를 삭제해도 '빈 입력 스키마'가 자꾸 생기는 걸 보셨을 텐데요. 이에 대한 자세한 설명은 도움말에 들어있습니다.

      다음 버전에서는 그 문제 자체가 개선되는 게 아니라, 쿼티 글자판을 없앨 수 없다는 안내문과 도움말 링크가 프로그램 UI에 추가되어 들어갈 것입니다.
      작업 자체는 굉장히 오래 전에 돼서 반영됐는데 7.11은 아직 그게 없군요. ^^ 7.4가 어서 나오긴 해야 합니다.
      감사합니다.

    2. 사샤나즈 2014/04/26 15:51 # M/D Permalink

      빈 입력 스키마가 작동할 때 작동하는 드라이버를 선택할 수 있도록 할 수는 없을까요?
      옛날에 새나루 입력기를 사용할 때는 쿼티용과 드보락용이 설치파일부터 나뉘어 있어 드보락 사용자도 쿼티로 바뀌는 일이 없이 사용이 가능했는데, 설치기에서 기본 드라이버를 선택할 수 있도록 하는 것은 어떨까 싶습니다. :)

  2. 사샤나즈 2014/04/26 15:47 # M/D Reply Permalink

    안녕하세요!
    오랜만에 입력기 관련 문서를 다시 살펴보다가 도움이 될 수 있을 듯한 문서를 찾아서 댓글을 달아 봅니다.

    "If your IME must store the dictionary file somewhere else, it must explicitly manipulate the Access Control Lists (ACL) of the dictionary files to allow access from app containers."
    http://msdn.microsoft.com/en-us/library/windows/apps/Hh967425.aspx
    http://msdn.microsoft.com/en-us/library/windows/apps/aa374872.aspx

    ACL이란 걸 명시적으로 지정해 놓으면 윈도8 modern 앺에서의 제한을 넘어서 ACL에 지정된 다른 경로에도 접근이 가능하다는 듯합니다. "dictionary file"만 말하고 있지만 글자판 관련 파일 등 다른 파일 접근도 상관 없지 싶네요.

    1. 사무엘 2014/04/26 18:30 # M/D Permalink

      반갑습니다. :)

      1. 새나루는 그렇게 키보드 드라이버의 customization까지 지원하는 게 인상적이더군요. 다만, 제 프로그램은 개발 방향의 특성상 그런 것까지 지원할 필요를 느끼지는 않아서 놔 두고 있습니다. “제 프로그램의 기능들을 활용해서 드보락도 덤으로 구현해서 대충 쓸 수 있다” 정도이지, 키보드 드라이버 차원에서 완전한 수준의 드보락 지원이 목표는 아니니까요.

      2. 그리고 소개하신 링크 문서는 저도 예전부터 봤습니다. 다만, 저게 구체적으로 뭘 의미하며 당장 내 프로그램에서 무슨 조치를 취하면 되는지 개념은 여전히 모르겠습니다. 당장 “Sharing information between processes: Use a web service to share data between Windows Store apps.” 이것도 뭘 말하는 건지 알 길이 없어요.
      그리고, 극단적으로 말씀드리자면, 데스크톱 앱에서 날개셋 제어판 실행 후, 입력 설정 파일을 '관리자 권한' 한번 줘서 Program Files 밑에다만 집어넣게 하면
      그건 메트로 앱에서도 공유가 가능하긴 합니다. 다른 이상하고 복잡한 방법을 찾느니 차라리 저게 현실적으로 더 나을지도 모릅니다. 깔끔한 방법은 못 되겠지만.
      메트로-데스크톱뿐만 아니라 32-64비트 장벽도 있으니 이거 참 골치 아프네요.

    2. 사샤나즈 2014/04/30 19:56 # M/D Permalink

      1. 음.. 혹시나 드라이버를 수동으로 바꾸더라도 날개셋 작동에 이상이 없게 된다면 (새나루의 경우는 키 입력을 받을 때 드라이버에 따라 바뀌지 않는 어떤 절대적인 값을 사용하는 것으로 기억합니다) 괜찮을 듯해요. MSKLC를 이용해 커스텀 드라이버도 만들 수 있으니 이것이 가능하다면 한글뿐 아닌 영문입력에서도 자유도가 상당히 높아질 거라고 생각합니다.

      2. 웹 서비스 이야기는 그 바로 위에 있는 on-the-fly learning에서 클라우드 서비스를 언급하는 맥락에서 보면 그 클라우드 서비스를 표현만 다르게 한 게 아닌가 싶네요. 윈도8부턴 설정 동기화 등을 중시하니까요.

      ACL 이야기로 돌아가면,
      http://msdn.microsoft.com/en-us/library/windows/apps/aa446596.aspx
      이 문서로 들어가면 SetEntriesInAcl 함수로 새 ACL을 만들라고 하네요. 여기서 날개셋이 파일을 읽을 수 있도록 접근 권한을 설정하길 요구하는 것일 텐데 아마 이 과정에도 관리자 권한이 필요하지 싶습니다.

      4/30/2014 덧:
      이번 IE 취약점 때문에 4월 26일자로 올라온 자료에 ACL이 언급되었길래 살펴봤는데, (30일자로 수정되었습니다만)
      http://cc.bingj.com/cache.aspx?q=acl+vgx.dll&d=4534163940053952&mkt=en-US&setlang=en-US&w=h-IUVpWHsTQN5nJ0klwNPS9ndQ5pKLjD
      cacls, 또는 비스타 이상부터는 icacls를 이용해 콘솔에서 ACL을 수정할 수가 있네요.

      icacls에 대해서는 여기에 패러미터 설명이 되어 있는데,
      http://technet.microsoft.com/en-us/library/cc753525.aspx

      위쪽 IE 취약점 관련 문서에서처럼 everyone 권한을, 지우는 대신 새로 준다면 되는건지, modern 앺에서 접근하려면 어떤 특정 권한을 따로 주어야 하는건지는 여전히 잘 모르겠네요..

    3. 사샤나즈 2014/05/02 13:16 # M/D Permalink

      http://support.microsoft.com/kb/2798317

      권한에 대해 좀더 봤는데,
      All Application Packages라는 그룹에 권한을 주면 modern 애플리케이션에서도 파일을 읽을 수 있게 되나 봐요.
      Windows 폴더가 현재 이 그룹에 읽기 권한을 주고 있네요.

      http://stackoverflow.com/questions/17761826/assigning-folder-permissions-to-all-application-packages-group
      이건 처음 올렸던 것처럼 코드로 직접 ACL을 만드는 방법에 관한 질문글인데 역시 All Application Packages 그룹 권한을 사용하고 있네요.

    4. 사무엘 2014/05/02 17:19 # M/D Permalink

      일일이 정보 리서치를 해 주셔서 고맙습니다.
      현재 작업 중인 새 버전은 한글 입력 알고리즘 쪽이 완전히 다시 만들어지다시피했는데 작년 11월 이후로 거의 반 년에 가까운 시간 동안 외부 모듈은 의외로 딱 하나(첫 타 씹힘 관련) 마이너한 버그가 고쳐진 것밖에 변화 내역이 없답니다.
      메트로 앱에서 입력 설정 동기화 관련 개선이 될 수 있을지는 모르겠지만, 나중에라도 참고하겠습니다. ^^

Leave a comment

1.

본인은 <날개셋> 한글 입력기의 개발자이며, 사용자로부터 프로그램과 관련된 문의 사항을 종종 메일로 받고 있다.
그런데, 단순 문의나 버그 신고, 제안을 넘어서 이런 한글/일반 문자 입력 방식을 고안해 놓은 게 있는데 이걸 혹시 날개셋에서 쓸 수 있게 만들어 줄 수 있느냐는 문의가 오기도 한다.

사실, 내 프로그램은 초보자가 당장 사용하기가 좀 어렵다는 것을 본인도 인정한다.
워낙 특이하고 구조가 복잡하기 때문에 프로그램의 개발 취지와 내부 구조를 어느 정도 이해하고 있어야 고급 기능들을 제대로 활용할 수 있다. 날개셋문자, 수식, 오토마타, 낱자 결합 규칙 같은 것들...

그러나 내 프로그램도 비록 여전히 내용이 어렵다는 비판은 있을지언정, 모든 기능들이 개념 설명과 문서화는 충분히 돼 있다.
스스로 설정을 이것저것 바꿔 보고 있는데 모르는 게 있어서 궁금한 부분만 묻는 것도 아니고,
아예 처음부터 끝까지 밥을 떠 먹여 달라는 부탁을 내가 일일이 다 들어 줄 수는 없다.

그분들이 날개셋 한글 입력기의 구조를 공부하는 게 어려운 것만큼이나,
역으로 그분들이 생각하고 있는 각종 독창적이고 기괴한 입력 방식 스펙을 내가 이해하고 의견을 맞추는 것도 만만찮게 어렵기 때문이다. 어느 쪽에서든 세상에 쉬운 일은 없다~!

그리고 만에 하나 내가 입력 설정 파일을 하나 만들어 줘도 그분들이 그걸 제어판에서 불러다 선뜻 쓸 수 있을 거라는 보장도 없고,
머릿속에만 존재하던 자기 입력 방식을 실제로 쓰다 보면 결국은 마음에 안 드는 게 생기고, 또 고치고 싶은 게 생기기 마련이다. 당사자는 손 하나 까딱 안 하면서 그걸 내가 일일이 다 고쳐서 애프터서비스를 해 줄 수도 없다. 프로그램 자체에 대한 서비스가 아니라 그 사람의 아이디어에 대한 서비스가 말이다.

그러니 내가 일일이 다 코치를 해 줄 수도 없고, 그렇다고 해서
정말로 날개셋 한글 입력기의 구조를 다 공부할 여력이 안 되는 분의 부탁을 고사만 하는 것도 최선의 해결책은 아니라 생각되기에...
이렇게 하기로 했다.

<날개셋> 한글 입력기를 이용한 문자 입력 방식 구축 컨설팅(?) 서비스는 앞으로 유료로 정식 제공할 것이다.

이 프로그램은 1.0 이래로 수익 모델은 한동안 대회 상금이 전부였다. 그러다가 1년 남짓 전부터 후원금을 받기 시작했으며 고맙게도 몇몇 분들께서 실제로 후원을 해 주셨다.
그 다음으로 제3의 수익 모델로는 저게 자연스럽고 적절하다고 여겨진다.

리눅스 배포사들도 리눅스 자체는 무료 배포하고, 각종 기술 지원을 유료로 함으로써 이윤을 내지 않던가.
그것처럼 <날개셋> 프로그램 자체는 누구나 무료로 사용 가능하되, 자기가 원하는 대로 프로그램을 세팅하는 기술 지원만을 유료로 하는 것이다.

현재 생각하고 있는 것은,
한 입력 방식에 대해서 customize된 ist 파일을 한 번만 만들고 애프터서비스 없이 끝내는 것이 3만 원, (단수?)
그리고 첫 ist 파일이 완성된 이후로 두 주 동안 최대 3회까지 입력 방식의 개정 요청까지 들어 주는 것이 5만 원 선이다. (복수?)

물론 만들어진 파일의 내부 구조와 원리에 대해서 각종 설명은 충분히 해 준다.
그리고 단수라 해도, 애초에 입력 설정이 예전에 접수된 주문대로 만들어지지 않았다면 수정을 해 준다. 주문 자체가 모호하고 불충분했던 것에 대한 추가 보완 내지, 단순 변심 수정 요청만을 받지 않을 뿐이다.

이건 양산된 컨텐츠를 뿌리는 게 아니라, 일종의 일대일 맞춤형 과외 같은 서비스이기 때문에 비용이 무슨 공산품 수준으로 저렴할 수는 없다.
저 비용을 지불하고 싶지 않으면 자기가 직접 날개셋 도움말을 독학하면서 수식을 입력하고, 비한글 입력의 경우 고급 입력기의 로직을 스스로 짜면 된다.
즉, 프로그램 자체가 무료인 이상, 무료 우회도로가 얼마든지 존재한다. 유료 고속도로는 단지 더 빠르고 편하게 가게만 해 줄 뿐이다.

거래는 이런 식으로 진행될 것이다.
사용자가 먼저 자기 입력 방식에 대해서 설명하고, 단수와 복수 중 원하는 서비스를 주문한다.
그러면 본인은 그 입력 방식에 대해서 내가 이해한 게 맞는지 되묻고, 그게 기술적으로 내 프로그램에서 가능한 입력 방식이라면 승락을 한다.
그래서 사용자가 서비스료를 후원 계좌로 입금하면 본인은 그 입력에 대한 설정 파일을 만들고 사용자에게 이것을 보내 준다.

입력 방식 컨설팅 수요가 얼마나 될지 앞으로 지켜보겠다.
오해가 없게 다시 말하지만, 자기가 직접 프로그램을 써 보면서 잘 모르는 것을 본인에게 문의하고 상담하는 건 당연히 얼마든지 무료이다.
머리부터 발끝까지 프로그램을 자기 입맛대로 설정을 다 맞춰서 떠 먹여 달라는 주문만이 유료이다.

2.

다음으로 <날개셋> 한글 입력기의 외부 모듈과 관련하여 지금까지 최상위 순위권으로 접수되어 온 질문에 대한 설명을 좀 다시 하겠다.
“드보락 자판을 쓰려고 하는데, 쿼티/빈 입력 스키마 글자판이 또 자꾸 새로 생기는 것” 말이다.

이미 아시는 분들도 있겠지만, 외부 모듈(IME)은 편집기처럼 자기 혼자 독자적으로 돌아가는 프로그램이 아니다. 운영체제 내지 응용 프로그램과도 조화를 이루며 동작해야 한다.
응용 프로그램이 생각하는 영문 모드는 “IME가 영문 글자를 보내는 모드”가 아니라 IME가 아무 키도 처리하지 않고 그걸 응용 프로그램으로 그대로 보내 주는 모드이다. 이때 지원되는 쿼티 배열은 IME보다도 아래인 키보드 드라이버 차원에서 제공되는 기능이다.

그렇기 때문에 <날개셋>도 여러 입력 항목 중에 아무 글쇠도 처리하지 않는 모드를 반드시 갖추고 있어야 하며, 날개셋의 영문 모드가 아니라 “운영체제가 지정하는 영문 모드”로 진입해야 할 때는 날개셋 프로그램이 자신을 그런 모드로 동기화해야 한다. 그렇기 때문에 그런 상황에서는 '빈 입력 스키마'가 지정되는 것이다.

<날개셋>으로 드보락 글자판을 아무리 설정해 봐도 그것은 운영체제의 관점에서는 영문이 아니라 한글 모드일 뿐이다. 응용 프로그램의 단축키가 드보락 방식으로 바뀌지는 않는다. 그 드보락이 native 쿼티를 완전히 대체할 수는 없다는 것을 이 자리를 통해 다시 밝히는 바이다.

3.

음, 그리고 이번에도 한영 상태 관련 이슈이다.
지금이 한글 모드인지 영문 모드인지, 지정돼 있는 글자판을 좀 더 쉽게 알 수 있게 할 수 없느냐는 문의도 지금까지 종종 받았다.
옛날에 삼성 전자에서 개발한 워드 프로세서인 훈민정음이 생각난다. 한글 모드일 때는 cursor가 검은 반전이 아니라 빨간색으로 바뀌었었다...!

이미 한영 상태 표시를 위해 입력 도구모음(language bar)에 아이콘이 있기 때문에 본인은 그걸 놔 두고 구태여 또 다른 UI를 만들 생각은 없음을 밝힌다. 게다가 훈민정음처럼 cursor의 외형을 바꾸는 것은 워드 프로세서 같은 응용 프로그램의 영역이지 한낱 IME가 관여할 수 있는 영역도 아니다.

다만 Windows 8의 style(modern, metro) UI의 경우 language bar가 없기 때문에 별도의 시각적 피드백이 필요하다. 입력란으로 키보드 포커스가 가면 현재의 IME 입력 모드가 간단한 사각형 모양으로 잠깐 나타났다가 사라진다. 이것은 <날개셋>도 지원한다.
그러나 이 기능을 굳이 style UI 말고 기존 데스크톱 UI에까지 지원해야 할 필요를 느끼지는 않는다.

Posted by 사무엘

2014/01/18 08:39 2014/01/18 08:39
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/921

Trackback URL : http://moogi.new21.org/tc/trackback/921

Comments List

  1. 세벌 2014/01/20 00:28 # M/D Reply Permalink

    문자 입력 방식 구축 컨설팅(?) 서비스는 앞으로 유료로 정식 제공v
    아하. 그렇죠. 모든 것을 무료로 할 순 없겠죠. 여기에도 수익모델이 있었군요.
    많이 버시고 또 그만큼 더 좋은 프로그램 만들어주시길.

    1. 사무엘 2014/01/21 01:45 # M/D Permalink

      네~ 감사합니다.

Leave a comment

두벌식 한글 입력 방식에는 초성과 종성의 구분을 위해 도깨비불 현상이라는 게 존재한다.
이것은 <날개셋> 한글 입력기의 내부에서는 다음과 같은 조건에서 발생한다. 쉽게 말해 두벌식 종성 + 두벌식 중성 + 오토마타 0상태라고 요약된다.

1. 현재 입력 중인 글자의 직전 마지막 타가 두벌식 타입으로 입력되었고, 종성이 존재한다. (초성이나 중성은 있든 없든 무관)

2. 그 상태에서 초성이 없고 중성이 존재하는 두벌식 타입의 날개셋문자가 새로 입력되었다. (종성은 있든 없든 무관)
여기서 두벌식 타입이라 함은, 오리지널 두벌식 또는 6.7에서 새로 추가된 두벌식 종성 타입이 모두 해당한다.

3. 종성까지 입력된 그 상태에서 새로 입력된 날개셋문자에 대한 오토마타 수식 계산 결과가 0이다. 보통 종성의 경우 이어치기 오토마타 수식은 n -> C ? n : 0인데, 이때는 중성이 입력되면 C가 아닌 B가 nonzero가 되므로 어차피 계산 결과는 0으로 귀착된다.

4. 혹은 양수 상태라 해도 그 상태로는 중성 and/or 종성의 낱자 결합이 불가능해서 어차피 다음 글자로 넘어가야 한다. (implied zero state)


이런 상태에서 다음 글자의 조합이 계속될 때는, 그냥 넘어가는 게 아니라 앞 글자의 종성을 적당히 떼어서 다음 글자의 초성에 미리 넣어 주는 게 도깨비불 현상이 하는 일이다.
자음을 분할하는 방식은 그냥 마지막 한 타만 떼는 기본 동작이 있고, 그 외에 특수 도깨비불 규칙이나 초-종성 공유 낱자 결합 규칙이 관여하기도 한다. 이에 대한 더 자세한 설명은 프로그램 도움말을 참고하도록 하시고.

<날개셋> 한글 입력기는 여러 낱자를 한꺼번에 입력하는 걸 지원한다. 초-중성, 중-종성을 한꺼번에 입력하는 건 물론이고 지금 글자의 종성과 다음 글자의 초성을 곧바로 입력하는 것조차 가능하다.
이와 비슷한 맥락으로 두벌식에서는 '굴' 상태에서 ㅡ를 입력해서 '구르'까지 만드는 것뿐만 아니라 ㅡ+ㅁ을 한꺼번에 입력해서 '구름'을 바로 만들 수도 있다.

다만, 그게 오리지널 두벌식 타입으로는 가능한데, 비교적 따끈한 새 기능인 '두벌식 종성' 타입에서는 중성과 종성을 중첩 입력하는 게 제대로 지원되지 않았다. 이것이 지난 7.11 버전에서 개선되었다.
오리지널 두벌식은 비록 종성이라 하더라도 다음 글자로 넘어갈 때 종성이라는 정체성이 없어지고 초성과 완전히 다름없게 처리된다. 그렇기 때문에 그 상태에서 중성+종성을 한꺼번에 입력하는 것이 자연스럽게 가능하다.

그러나 두벌식 종성은... 비록 다음 글자로 넘어가서 모음과 결합함으로써 외형상 초성으로 바뀌긴 하지만, 원래 자신이 종성이었다는 본디 정체성은 변함없이 유지되어야 한다.
자신이 이미 불변 종성인데 중성과 더불어 또 다른 종성까지 한꺼번에 입력되면, 이것은 도깨비불을 의도하는 건지 아니면 그냥 중성과 종성의 평범한 결합이나 분리를 의미하는 건지 프로그램이 논리적으로 명확하게 결정해야 한다.

오리지널 두벌식 타입의 종성 ㅁ (H2|_M)을 조합하는 상태에서 두벌식 ㅏ+ㅂ(H2|EO|_B)을 배당해 주면 응당 '맙'으로 바뀐다. 단지 bksp를 한번 누르면 ㅁ이 이제는 종성이 아니라 초성으로 되어 있을 뿐이다.
그러나 두벌식 종성 타입의 종성 ㅁ (H2J|_M)에다가 같은 입력을 공급하면 '받침ㅁ/ㅏㅂ'이 되고 ㅏ+ㅂ을 따로 조합하는 상태가 된다.

그리고 받침 ㅁ 대신 받침 ㄹ을 조합하는 상태에서 같은 입력을 공급하면 그 중성과 종성이 지금 글자와 결합하여 ㅏ+ㄻ을 조합하는 상태가 된다. 이것은 받침 ㄹ이 오리지널 두벌식이든 두벌식 종성이든 결과가 동일하다. 왜 그럴까?

가장 큰 이유는 입력 날개셋문자에 중성뿐만 아니라 종성이 존재하기 때문이다. <날개셋> 한글 입력기가 제공하는 기본 오토마타들은 한 번에 초-중-종이든 낱자가 하나씩만 들어온다고 가정하고 설계되어 있다. 그래서 C ? n : 0 수식의 값은 nonzero가 되어, 도깨비불 현상 대신 지금 글자의 조합이 계속 유지되게 되는 것이다.

물론, ㄹ+ㅂ의 경우와는 달리 ㅁ+ㅂ은 결합이 성립하지 않는다. 세 성분 중 한 성분이라도 결합이 되지 않으면 결합은 실패하므로 도깨비불 현상이 발생한다. 이때 오리지널 두벌식은 ㅁ을 초성으로 넘겨 주기 때문에 '맙'을 성공적으로 만들어 준다. 그 반면 두벌식 종성은 ㅁ을 종성으로 처리한다. 그래서 도깨비불 현상 후에도 두 종성은 서로 충돌하며 결합이 실패한다.

이 경우 프로그램은 최종적으로 도깨비불 없이 ㅁ이 마치 세벌식 종성이었던 것처럼 변경 없이 놔 두고, ㅏ+ㅂ만 다음 글자로 따로 떼어 내 준다. 이번 7.11이 취한 정책이다. 예전에는 그냥 조합이 끊어져 버렸었다.

두벌식 종성으로도 중성+종성이 충돌 없이 도깨비불 현상 처리가 되려면, 도깨비불은 결합 실패로 인해 뒤늦게 발생하는 게 아니라 오토마타 수식 차원에서 0이 돌아옴으로써 이 타이밍 때 곧바로 발생해야 한다.
애초에 중성+종성 날개셋문자가 C ? n : 0 수식을 nonzero로 통과했던 게 화근이었다. 이 수식을 !B && C ? n : 0으로 바꿔 주면 문제가 해결된다. 종성이 한번 입력된 뒤부터는 오로지 종성만 받아들이도록 말이다.

이렇듯, 두벌식 종성에서 중성뿐만 아니라 중성+종성 복합 입력의 도깨비불 현상을 처리하기 위해서는 프로그램의 내부 알고리즘도 개선되어야 하고, 사용자의 설정도 미묘하게 바뀌어야 함을 알 수 있다. 한글 입력기 하나에도 오묘한 면모가 은근히 많다.

<날개셋> 한글 입력기는 13년 동안 개발되면서 버전이 무려 7.x대까지 올라갔다. 편집기나 외부 모듈의 외형은 엄청 옛날 버전이나 지금이나 거의 바뀐 게 없지만, 이 프로그램이 진짜로 꾸준히 바뀌고 있는 부분은 입력 엔진과 이를 제어하는 제어판 쪽이다. 이 프로그램은 그야말로 어떤 변칙적인 한글 입력 방식도 만들 수 있고 한자 변환이나 bksp 동작 같은 주변 기능까지 전부 세밀하게 제어 가능한 기술 통합형 엔진을 추구하고 있기 때문이다.

살짝만 스포일링을 하자면, 현재 구상하고 있는 것은 고급 입력 스키마와 고급 입력기이다.
글쇠를 길게 눌렀다 떼는 건, 여러 글쇠를 한꺼번에 누르는 것, 타이밍까지 세벌식 자판에 최적화해 주는 입력 스키마..
그리고 지금의 최종 변환 규칙 같은 것을 입력기 단위로도 적용하여 한글로 일본어나 구결을 곧바로 입력할 수 있는 문자 생성기. 한글과 비한글 문자를 조합 상태에서 끌어들일 수 있는 그런 시스템을 생각 중이다.

이 정도까지 만들어 놓으면 프로그램의 버전은 7.x대 중후반은 올라갈 수 있을 것이고, 그 뒤에 입력기 개발은 진짜로 반쯤 접은 채 다음 글꼴 연구를 시작할 수 있을 것 같다.
NLP 쪽의 연동이 없이 한국어와 무관하게 한글 자체만의 engineering도 할 일이 정말 많다.

Posted by 사무엘

2013/12/01 08:22 2013/12/01 08:22
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/904

Trackback URL : http://moogi.new21.org/tc/trackback/904

Leave a comment

<날개셋> 한글 입력기 7.11

<날개셋> 한글 입력기 7.1은 다음 7.3이나 7.4가 나올 때까지 오랫동안 안정적으로 쓰일 수 있을 것 같았으나.. 시간이 흐르고 보니 부득이 소규모 7.11 업그레이드가 3주 남짓한 시간 만에 나오게 됐다.

이 버전에서는 외부 모듈이 다음과 같이 대대적으로 개선됐다.

1.
TSF B급 프로그램(메모장 같은)에서 '호환용 한글 자모'를 쓰고도 옛한글이 전혀 입력되지 않던 문제를 해결했다.
이것은 직전 버전인 7.1에만 있던 버그이다. TSF A급 프로그램에서 두벌식 도깨비불 현상에 의해 옛한글이 곧장 시작되었을 때 조합이 끊어지던 문제를 해결했었는데 불행히도 그게 TSF B급 프로그램에서는 심각한 오동작을 유발하고 있었다.
결국 A급일 때와 B급일 때를 인위적으로 나누어 따로 동작하게 하는 방식으로 두 토끼를 모두 잡았다.

한글 IME 개발이라는 게 이렇게 지저분하고 어렵다.
모호한 스펙 때문에 IME를 사용하는 구현체별로 문서화되지 않은 예측 불가능한 동작이 너무 많으며, 이것을 하나하나 다 맞춰 줘야 한다. 한 프로그램에다 동작을 맞춰 주면 다른 프로그램에서 오동작하는 게 왕왕 있다.

물론, TSF B급 프로그램에서는 '호환용 한글 자모'를 써서 첫 조합은 한 글자 길이를 보장시킨 뒤에 제한적으로 옛한글 입력이 가능하지만, 두벌식의 경우 도깨비불 현상으로 옛한글이 곧장 시작되었을 때 조합이 끊어지는 건 어쩔 수 없다.
이런 문제 때문에 MS에서는 논란의 여지를 없애기 위해 자기가 개발한 옛한글 입력기는 오로지 TSF A급 프로그램에서만 동작하게 제약을 걸었다. 지원하는 글자판 자체도 두벌식밖에 없기도 하니 말이다.

2.
Windows 8에는 일명 메트로라고 불리기도 한 Modern UI가 있고 거기서 일부 앱은 권한이 극도로 제한된 상태로 동작한다. 본인은 입력기를 테스트할 때 날씨(Weather) 앱을 실행한 뒤 장소 추가 대화상자를 꺼내 보곤 했다. 그런데 테스트를 하려면 인터넷 연결을 꼭 해야 해서 개인적으로 무척 성가시고 불편함을 느꼈다.

어쨌든, 그런 제한 모드에서는 IME가 자기 입력 설정을 불러올 수조차 없어서 어쩔 수 없이 설치 직후의 기본 입력 설정으로 동작한다. 이때는 입력 설정이 제대로 로딩되어 있는 다른 프로그램--데스크톱 앱 또는 권한 제약이 없는 Modern 앱--을 미리 실행해 놓고, 제약이 걸린 앱도 덩달아 같이 실행해야 입력 설정이 동기화된다. 이것은 기술적으로 더 어쩔 수 없는 귀결이다.

그런데 이번 버전에서는, 제약이 걸린 앱을 먼저 실행하고 제약이 없는 앱(데스크톱 앱 포함)을 “나중에” 뒤늦게 실행한 뒤, 제약이 걸린 앱으로 되돌아오더라도 입력 설정이 동기화되도록 프로그램을 개선했다. Modern 앱에서 <날개셋> 한글 입력기의 사용 편의성이 더 향상될 것으로 기대한다.
당연히.. 제약이 없는 앱을 실행한 뒤엔 그 프로그램에서 <날개셋> 한글 입력기 외부 모듈을 로딩도 하고서 돌아와야 한다.

3.
그리고 드디어, 드디어...
외부 모듈도 현대 한글뿐만 아니라 옛한글까지 bksp 낱자 단위로 지우기 및 달라붙기 같은 기능이 동작 가능해졌다. 물론 TSF A급 프로그램 한정이고, 단순한 한글 자모 나열이 아니라 filler까지 정규화가 잘 된 글자에만 한해서 말이다.

이 기능을 구현하는 기반은 사실 지난 6.5 버전 때 이미 다져져 있었다. 그러나 실제로 제공되지는 못하고 봉인되어 있었는데,
그건 TSF A급 프로그램에서 존재하던 옛한글 조합 관련 버그 때문이었다.
그래서 그 버그를 고치면서 봉인돼 있던 기능까지 다시 살펴보게 되었고, 결국 이것도 덩달아 구현에 성공한 것이다. 만세! 한글 처리 기술의 진보를 이뤘다.

외부 모듈과 관련된 위의 세 이슈가 중요한 것이고 다음은 사소한 변화 사항들이다.

(1) 이 프로그램은 입력 설정이 없는 경우 MS 한글 IME의 설정이 어떻냐에 따라서 세벌식이나 두벌식을 자동으로 가져온다. 그런데 0번 말고 2번에 배당되는 기본 한글 글자판은 언제나 세벌식 옛한글로 고정이었다.
이제부터는 0번이 두벌식으로 맞춰지면 2번의 옛한글 글자판도 두벌식 옛한글로 지정되게 바뀌었다.

(2) 영문 about 대화상자에 layerd 오타-_-를 잡았다. 2004년에 나온 3.0의 영문 GUI 때부터 지금까지 줄곧 존재했던 오타이다. -_-;;; 오타가 그 단어의 실제 발음과 직관적으로 잘 대응하는 편인 관계로, 오타가 있는 줄 9년이 넘게 꿈에도 모르고 있었다.
그리고 편집기의 편집 화면 옵션 대화상자에 있던 '이동줄'이라는 단어도 '스크롤 막대'라고 MS 표준 번역 용어로 바꿨다. 이 역시 해당 옵션이 처음으로 추가되었던 3.0 버전 때부터 썼던 단어인데 드디어 변경.. ㅎㅎ
사실 '이동줄'은 한글 윈도 3.1의 도움말에 있던 용어이다.

(3) 지난 7.1에서는 앞으로 '고급 입력 스키마'를 재개발할 것을 염두에 두고 기존 '동시 입력 스키마'를 제거했다.
그랬는데, 이 입력 스키마를 사용하고 있는 분으로부터 요청을 받고 그걸 다시 원상복귀시켰다.
다만 이제 이 입력 스키마는 이름 뒤에 '임시용'이라는 단서가 붙었으며 영문 명칭에는 아예 legacy라는 단어가 추가되었다.

(4) 화면 키보드 입력 도구가 지금까지 크기가 너무 작은 게 흠이었는데, 작게-중간-크게 3단계로 크기를 조절하는 기능을 추가했다.
물론 글쇠 자체는 여전히 16*16 고정된 크기로만 찍히지만, '중간'으로만 해도 고해상도 화면에서는 글쇠배열이 훨씬 더 시원스럽게 보일 것이다.

(5) 두벌식 종성으로 입력한 종성으로 중성+종성을 한꺼번에 입력하여 도깨비불 현상을 일으킬 때, 내부 처리가 좀 더 정확하게 되도록 입력 엔진을 개선했다. 내부 사연이 좀 복잡하므로 이에 대한 자세한 내역은 별도의 글로 다루도록 하겠다..

(6) <날개셋> 편집기의 찾기 기능을 다소 손질하여, 찾는 문자열 영역이 한글을 이루는 글자의 중간에 걸치는 것은 정상적인 찾기 결과로 인정하지 않게 했다. 그래서 'ㅎㆍ'를 검색하면 정말로 'ㅎㆍ'만 걸리지, 'ㅎㆍㄴ'이 걸리지는 않게 했다. 'ㅎㆍ'로 'ㅎㆍㄴ'을 찾는 건 '한글 낱자 단위로' 옵션을 켰을 때에만 가능하다.

업데이트가 귀찮으시더라도, 부디 최신 버전을 사용하여 프로그램의 원 저자가 의도한 모든 기능을 마음껏 활용하시기 바란다.
아울러, 10월 한 달간 두 분이 후원금을 보내 주셔서 누적 후원자 수는 세 분이 되었다. 태어나서 이런 걸 연달아 받아 보는 경험이 거의 처음이어서 감개무량하고 보람을 느낀다. 감사드리는 바이다.

Posted by 사무엘

2013/11/04 19:23 2013/11/04 19:23
Response
No Trackback , 14 Comments
RSS :
http://moogi.new21.org/tc/rss/response/895

Trackback URL : http://moogi.new21.org/tc/trackback/895

Comments List

  1. 김재주 2013/11/05 21:52 # M/D Reply Permalink

    날개셋 개발하시는데 있어서 정해둔 유닛 테스트 같은 게 있으신가요?

    미리 만들어 둔 테스트 셋트를 스크립트를 사용해서 검증하면 버그 예방에 상당한 도움이 될 것 같아서요.
    Static analyzer도 쓰시는지 궁금하고요.

    1. 사무엘 2013/11/06 00:03 # M/D Permalink

      역시 재주 님다운 수준 높은 질문이군요. ㅎㅎ
      TSF A급, B급, legacy 운영체제의 IME 환경 등.. 카테고리별 테스트 케이스는 있습니다. 하지만 매번 매뉴얼대로 꼼꼼하게 테스트를 하거나 자동화 절차까지 갖춰 놓은 정도는 아니구요.
      이번 7.1처럼 외부 모듈에서 아주 중요하고 민감하며, 변경시 side effect가 발생할 수 있는 부분은 그런 걸 더 신중하게 했어야 하는데 미처 생각지 못했던 부분에서 문제가 발생했었습니다.

      그리고 정적 분석은 마침 고맙게도 Visual Studio 2012에서 추가돼서 예전에 한번 전체 소스를 대상으로 돌려 본 적은 있습니다.
      하지만 생각만치 심각한 문제가 있지는 않았습니다. 또한 정적 분석을 제대로 활용하려면 함수 선언부에도 각종 메타정보를 다 공급해 줘야 하는데 그런 것까지는 활용을 못 했습니다. ^^;;

  2. Lyn 2013/11/08 10:32 # M/D Reply Permalink

    PVS Studio
    http://pvs-studio.viva64.com/

    도 추천드립니다.

    1. 사무엘 2013/11/08 21:23 # M/D Permalink

      오오, 고맙습니다. 정말 세상은 넓고 온갖 정보와 솔루션은 넘쳐나는군요..!

  3. 사샤나즈 2013/11/11 22:36 # M/D Reply Permalink

    오오오... Modern 앺에서 동기화 기능! 추가해주셔서 감사합니다! 이제 굳이 스카이프를 껐다 켜지 않아도 날개셋을 작동시킬 수 있겠군요! layerd도 고쳐졌네요 >.<

    어떤 프로그램에선 옛한글 입력하면 조합이 망가져 버리던 문제도 있었는데 아마 1번에서 말한 문제가 아니었나 싶네요! 프로그램 문제인가 하고 있었는데...

    1. 사무엘 2013/11/12 01:08 # M/D Permalink

      저도 바라던 소식입니다. 7.11이 가려운 곳 여러 군데를 긁어 주는 버전업이 됐군요. ^^
      저도 며칠간 써 봤습니다만 이번 버전은 진짜로 앞으로 몇 개월은 업데이트가 필요하지 않을 정도로 충분한 완성도를 갖추고 잘 만들어진 것 같습니다.

  4. 사샤나즈 2013/11/22 20:45 # M/D Reply Permalink

    이상하게 여전히 자꾸 두벌식으로 고정되는 경우가 있는데, 그 중 하나로 윈도8.1의 기본 스카이프 앺에서는 항상 날개셋이 두벌식으로 고정되는 거 같네요. 다른 프로그램에서 글자판을 모두 불러온 상태에서 다시 스카이프를 껐다가 켜도 계속 두벌식으로 고정되니 스카이프와 호환성 문제가 있는 것인지... @.@

    1. 사무엘 2013/11/23 07:33 # M/D Permalink

      음 그런가요? 정확하게 표현하자면, 데스크톱용 앱을 실행해서 날개셋을 로딩해 줬는데도 설정 동기화가 같이 되지 않는 '모던 앱'이 여전히 있다는 얘기지요? 내장 스카이프가 그 예 중 하나이고? (제가 갖고 있는 preview에는 그게 아직 포함되지 않아서 재연은 못 해 보겠네요)
      절 도와드리는 셈치고, 번거로우시겠지만 잘 적용되지 않는 조건/경우를 스스로 더 정확하게 구체적으로 정리해 보셨으면 좋겠습니다. ^^
      일단 7.11 이후로 당분간, 최하 내년 봄 이상까지는 날개셋은 버전업 계획이 잡혀 있지 않으니 시간은 많습니다.

      * 여담이지만 모던 UI라는 말은 또 스타일 UI로 공식적으로 또 바뀌었다네요? 저도 최근에 알았습니다. 어휴 자꾸 사람 헷갈리게.. 개인적으로는 메트로가 제일 고유명사스럽고 알아듣기 쉬웠는데.. -_-;;

    2. 사샤나즈 2013/11/23 15:25 # M/D Permalink

      테스트를 조금 더 해서 알아본 바로는 스카이프 앺과 윈도 스토어의 MetroTwit 앺에서 이런 증상이 나타납니다.
      탐색기나 기타 데스크탑 프로그램에서 입력기를 불러들여도 이 두 앺에서는 두벌식으로 고정되는데, 방금 찾은 임시방편은 데스크탑 IE를 켜고 페이지 내에 입력창이 있는 페이지를 IE에서 불러오면 그 즉시 증상이 풀립니다.

      //파폭이나 크롬, 또는 데스크탑용 MetroTwit을 켜도 즉시 풀리네요..
      나머지 Style UI(!) 앺들은 그냥 탐색기에서 입력해보는 것만으로(또는 Win+S를 눌러 검색 막대를 불러오는 것만으로) 입력기를 불러올 수 있게 되는데, 저 두 앺들만 특이하게 이런 증상이 있네요.

    3. 사무엘 2014/01/21 01:45 # M/D Permalink

      드디어 Windows 8.1 정식 버전을 설치해서 말씀하신 상황을 살펴봤습니다.
      하지만 스카이프의 채팅창만을 말씀하시는 거라면, Win+S만 눌렀다 되돌아와도 제 자리에서는 입력 설정의 동기화가 별 문제 없이 되는걸요.
      님의 블로그의 글에 댓글로 자세한 조건을 알려 드렸습니다.
      문제에 대한 재확인을 부탁드립니다.

    4. 사샤나즈 2014/01/21 06:09 # M/D Permalink

      문제를 영상으로 찍어 보았습니다. 첫 화면은 로그오프 뒤 처음 진입한 화면입니다.

      마지막 터치키보드가 나오지 않는 장면은 물리키보드를 썼습니다.
      http://sdrv.ms/1e8Pv4b

      환경은 64bit 영문입니다만 언어나 32/64bit 차이가 영향이 있는지는 잘 모르겠네요...

    5. 사무엘 2014/01/21 07:34 # M/D Permalink

      오옷, 굉장히 신속하게 답변해 주셔서 고맙습니다.

      데스크톱뿐만 아니라 메트로(Modern/Style/Win store app..-_-)에서도 곧장 Win+S를 누르면 되는군요. 그리고 32비트 전용 환경에서는.. 스카이프 → Win+S 만 갔다 와도 곧장 동기화가 문제 없이 돼 버립니다.
      또한 현재 <날개셋> 한글 입력기가 메트로와 데스크톱 사이에 입력 설정을 동기화하는 방식은.. 기술적으로는 비트 수를 가리는 방식이기도 합니다.
      그렇기 때문에 현재로서는 응용 프로그램의 비트 수를 의심해야 하지 않나 생각해 봅니다.

      혹시 스카이프는 메트로 기반이긴 하지만 32비트 프로그램이고, 동기화를 시켜 주는 프로그램들도 다 32비트라는 공통점이 있지 않은가요? 그렇잖아도 웹브라우저는 어지간해서는 여전히 32비트 프로그램이 대세잖아요? Win+S나 탐색기 같은 운영체제 셸이야 다 64비트일 테고.
      데스크톱에서는 <날개셋> 한글 입력기의 About 화면을 보면 동작하는 프로그램이 32비트인지 64비트인지 곧장 알 수 있습니다.

      이것을 확인 부탁드립니다~!
      비트수 때문이라는 게 판명되면.. 이 문제는 더 해결 가능하지 않고, 매뉴얼 '일러두기'에 아이템이 추가되어야 합니다.

    6. 사샤나즈 2014/01/27 12:23 # M/D Permalink

      아마 그 이야기가 맞는 것 같습니다.
      작업 관리자에서 스카이프를 32bit로 표시하고 있네요. 그 상태에서 같은 .NET 프로그램을 켜더라도 64bit로 돌아가는 .NET 프로그램을 켜면 스카이프 쪽과 동기화되지 않고 32bit 프로그램을 켜면 스카이프 쪽과 잘 동기화되네요!

      위에서 Firefox를 켰을 때 잘 동기화된다고 했었습니다만 64bit 빌드를 켰을 때는 동기화되지 않습니다. 이제 궁금증이 풀렸네요 :)

      이런 증상이 있는 스카이프와 MetroTwit 앺 모두 32bit로 돌아간다는 특징이 있군요!

    7. 사무엘 2014/01/28 09:20 # M/D Permalink

      OK! 메트로 앱은 C++/CLI 기반이어서 좀 managed 코딩 냄새가 나지만, 그래도 엄연히 비트 수를 구분하는 네이티브 기계어 프로그램이더군요. 저도 도움이 됐습니다. 감사합니다. :)

Leave a comment

<날개셋> 한글 입력기 7.1

1.

자, 내일 지구가 멸망하더라도 <날개셋> 한글 입력기의 개발은 개발할 거리가 있는 한 계속된다.
7.0 버전이 나온 지 약 100일 만에,
그리고 공휴일이 된 한글날을 전후하여 프로그램의 새 버전 소식을 전하도록 하겠다. 새 버전은 7.1이다. 이번에도 내 맘에 쏙 드는 새로운 버전이 잘 완성됐다.

7.1은 기본적으로는 역시 7.0의 버그를 고친 게 많다.
예전에 개발 근황글에서 먼저 언급했던 것처럼 Windows 8 Metro에서 옛한글이 입력되지 않는 문제, Visual Studio 2012의 일부 입력란에서 한글 연속 입력 시 한 타가 씹히던 문제를 해결했다.
7.0에서 처음으로 도입된 사용자 정의 후보 기능 자체에도 버그가 좀 있던 걸 고쳤다.
그리고..

2.

운영체제의 리치 에디트 컨트롤에 TSF 지원 확장과 관련된 오동작이 있다는 걸 도움말에 '알려진 문제'라고 추가 수록했다.

<날개셋> 한글 입력기의 외부 모듈은 꽤 옛날 버전부터 “TSF 지원 확장” 옵션이 있으며, 이걸 알고 실제로 쓰는 분들이 많은 줄로 본인은 안다. 이것은 한글 IME가 운영체제에다 요청할 경우, 운영체제의 표준 에디트 컨트롤과 Internet Explorer 브라우저 내부의 입력 폼을 TSF A급으로 실험적으로 바꿔 준다. 물론 XP에는 이런 기능이 없고 Vista 이상부터만 지원된다.

이렇게 TSF A급으로 임시 승격되고 나면 잘 알다시피 표준 에디트 컨트롤(가령, 메모장)에서도 단어 단위로 한자 변환이 가능하며 이미 완성된 글자도 낱자 단위로 지우고 역도깨비불 현상 같은 것도 <날개셋> 편집기를 쓸 때처럼 자유자재로 가능해진다.

다만, 이것은 마소에서 100% 지원은 해 주지 않는 비공식 실험적인 기능에 가깝다. 한글 IME 중에서 이런 요청을 하는 물건 자체가 날개셋밖에 없고 MS 한글 IME조차도 이런 짓은 안 한다. 그러니 동작의 기준으로 삼을 여타 프로그램 자체가 없고 내 프로그램에서 제대로 안 되면 다른 어디에도 해답이 없다. 그냥 사용자가 알아서 조심해서 쓰는 수밖에 없다.

그런데 사실은 이 옵션을 켤 경우, 표준 에디트 컨트롤과 IE뿐만 아니라, 리치 에디트 컨트롤도 영향을 받아서 TSF A급으로 바뀐다는 것을 모 사용자의 피드백을 통해 우연히 알게 되었다.
표준 에디트 컨트롤이 메모장이라면 리치는 '워드패드'와 같다. 전자와는 달리 후자는 글자별로 서체와 속성(진하게, 밑줄, 이탤릭 등)을 다르게 지정할 수 있고 글자의 크기도 조정할 수 있으며 문단 정렬이 가능하고 표나 그림도 삽입할 수 있다.

리치 에디트 컨트롤도 TSF A급으로 승격된다니 이것은 일면 바람직한 현상이지만...
참 안타깝게도, 지원하려면 좀 제대로 지원하지 여기에는 버그가 좀 있다.
cursor의 위치가 0 또는 1일 때.. 다시 말해서 문자열의 맨 처음 아니면 바로 그 다음 위치에서 한글 조합을 시작하면 두 글자가 조합으로 잡히고 깨진 문자가 삽입되는 등 온갖 오동작이 발생한다. 위치가 2 이상일 때부터는 이상이 없다.

카카오톡 PC 버전이나 스카이프(Skype) 같은 메신저 프로그램들의 대화창은 리치 에디트 컨트롤을 사용하는 대표적인 예다.
그렇기 때문에 이들 프로그램에서는 공통적으로 이런 문제가 발생할 수 있음을 밝힌다. 따라서 이런 데서는 먼저 '..'(마침표 두 개) 같은 문자를 먼저 찍어서 cursor의 위치를 2 이상으로 만든 뒤 한글을 입력하고 나중에 ..를 지우고 보내든가 해야 한다. 그게 싫으면 TSF A급 확장을 사용하지 말고.

다만, 리치 에디트 컨트롤을 사용하는 대표적인 기본 프로그램인 워드패드는 이런 확장 옵션이 필요 없이 진작부터 자체적으로 TSF A급으로 동작하기 때문에 저런 문제가 없다.

운영체제의 확장 지원을 통해서 TSF A급이 된 입력란은 한글을 조합할 때 종래의 검게 깜빡이는 사각형 cursor 대신, 조합 전체가 파란 블록으로 잡힌다는 차이가 있다. 그러나 워드패드나 MS Word처럼 원래부터 TSF A급인 환경은 한글 조합 중일 때 여전히 검게 깜빡이는 사각형 cursor가 나온다. 이런 외형으로 동작 방식을 구분할 수도 있다.

3.

그리고 덧붙여,
예전에는 어떤 에디트 컨트롤에다가 TSF 지원 확장 옵션을 켜거나 끈 걸 적용하려면, 제어판 대화상자를 닫은 뒤에 프로그램의 키보드 포커스를 다른 프로그램으로 옮겼다가 되돌아와야 했다. 그래야만 새 설정이 적용되었다.
하지만 이번 7.1은 창 포커스를 수동으로 바꾸지 않아도 제어판만 '확인'으로 닫으면 설정 변경이 바로 적용되게 개선했다.

4.

bksp 키의 동작 방식에 "연타 시 한번 정해진 동작을 계속 적용"이라는 옵션을 추가했다.
bksp 키의 동작 방식은 기본적으로 현재 한글을 조합 중이냐 그렇지 않느냐에 따라서 동작이 매번 달라지는데,
이 옵션이 켜지면, bksp든 Shift+bksp든 그 글쇠가 처음으로 누르던 순간에 결정된 동작 방식(조합 중이냐 아니냐)을 해당 글쇠를 연타하는 중에 계속 적용하게 한다. 즉, bksp로 인해서 한글 조합 여부가 달라지더라도 계속 낱자 단위 아니면 글자 단위로 지우게 한다는 뜻이다.

보통 한글을 조합 중일 때는 bksp는 낱자 단위로 지우고 Shift+bksp는 글자 단위로 한꺼번에 지운다.
그런데 반대로 한글을 조합 중이지 않을 때 평소에는 bksp는 언제나 글자 단위로 지우다가 Shift+bksp를 눌렀을 때만 예외적으로 낱자 단위로 지우게 하고 싶을 때가 있다.
그리고 bksp든 Shift+bksp든 글쇠를 연타하면, 그 다음부터는 한글 조합 상태이든 아니든 한번 결정된 단위로 계속 지우는 게 자연스러울 것이다.

이때 이 옵션을 사용하면 된다. 지금까지 제공되던 bksp 동작 옵션은.. 뭔가 2% 부족한 면모가 있었는데 이 옵션을 도입함으로써 드디어 완전체를 이뤘다.

5.

Windows 운영체제 내지 많은 응용 프로그램들은 여전히 한글은 조합이 오로지 한 글자 단위로만 만들어진다고 가정하고 동작하는 부분이 많다. 이 가정이 오랜 시간 동안은 참이었다. 그러나 이제 글꼴 처리 기술이 발달하고 옛한글을 여러 글자를 모아서 하나로 표현하는 게 가능해지면서 그 가정은 문제를 일으키고 있다.

프로그램에 따라서는 옛한글 내지 호환용 자모로 표현되지 않은 한글 자모는 조합 과정이 제대로 표시되지 않다가 조합이 끝나야 글자 전체가 표시된다. 최악의 경우는, 한글 조합을 호환용 한글 자모 한 글자로 시작하지 않으면, 조합이 되지 않고 그냥 튕기기도 한다. 이런 동작 때문에 <날개셋> 외부 모듈은 근본적으로 자체 구현체인 <날개셋> 편집기와 100% 동일하게 동작할 수가 없다.

이 점을 감안하여 이번 새 버전의 외부 모듈은, '한글 표현 방식' 옵션에서 '호환용 한글 자모 사용'을 체크하지 않을 경우 더 강한 경고 메시지가 아래에 표시되게 했다.

그리고 버그 신고 요령도 도움말에다 추가했다.
외부 모듈은 MS IME의 소스를 직접 보지 않는 이상 애시당초 100% 완벽하게 만드는 게 불가능하기 때문에, 오동작이 의심될 경우, (1) 프로그램이 최신 버전인지, (2) 도움말의 FAQ는 미리 읽어 보셨는지, (3) TSF 확장 지원 옵션을 끄고 한글 표현 방식을 원상복귀해 봤는지, (4) MS IME는 문제 없는데 이 프로그램만 그러는 게 확실한지 등등을 먼저 확인하고..

버그 신고시 운영체제의 버전과 언어, 비트수, 그리고 프로그램이나 웹사이트를 연 직후부터 모든 재연 과정을 일일이 설명할 것을 당부했다.

에필로그:
이렇듯, 7.1은 프로그램의 완성도를 강화한 여러 아기자기한 개선 사항들이 많으니, 7.0 포함 구버전을 사용하고 계신 분은 프로그램을 업데이트하시길 권한다.
앞으로 7.x 중반까지는, 내년 정도까지는 한글 입력 쪽으로 집중적인 기능 추가가 있을 예정이다.

Posted by 사무엘

2013/10/14 08:35 2013/10/14 08:35
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/887

Trackback URL : http://moogi.new21.org/tc/trackback/887

Comments List

  1. 김 기윤 2013/10/14 10:20 # M/D Reply Permalink

    아아, Bksp 동작 이해했습니다.
    예를 들어, 조합 중에는 낱자 단위로 지워지고, 조합 중이 아닐 때는 글자 단위로 지워지게 세팅한 경우,
    해당 옵션을 사용하지 않으면, 조합 중에 Bksp 를 눌러 글자를 다 지운 뒤에 뒷 글자를 지울 경우, 글자 단위로 지워지지만,
    해당 옵션을 켰다면, 조합 중에 Bksp 를 눌러 낱자를 다 지운 뒤, 다음 글자를 지울 경우, 이전에 낱자 단위로 지웠기 때문에, 계속해서 낱자 단위로 지운다는 말이군요.

    1. 사무엘 2013/10/14 17:35 # M/D Permalink

      옙~ 익숙해지면 무척 유용한 기능?옵션?이 될 거라 예상합니다. :)

  2. 사샤나즈 2013/10/14 17:39 # M/D Reply Permalink

    이제 Modern 애플리케이션에서도 옛한글이 문제 없이 입력되네요! 감사합니다 :D

    우연히 본 건데, 영문 About 페이지에 세벌식(three-layerd) 에 e가 빠져 있는데 아마 오타가 아닌가 싶네요 @.@

    1. 사무엘 2013/10/14 21:32 # M/D Permalink

      우와, 대박이네요. 저 스펠링은 지금의 about 화면이 생긴 이래로 수 년째 있었을 텐데..
      정말 꼭꼭 숨어 있어서 오타인 줄 꿈에도 몰랐습니다. ㅎㅎ

  3. 김선민 2013/10/16 19:00 # M/D Reply Permalink

    정말 잘 쓰고 있습니다.^^

    1. 사무엘 2013/10/17 22:19 # M/D Permalink

      ㅋㅋ 감사합니다. :)

Leave a comment

1.

잘 알다시피 올해 하반기부터 드디어 <날개셋> 한글 입력기가 7.x 시대로 진입했다. 1.0이 개발된 지 13년 만의 일이다.
수없이 많은 소프트웨어들이 넘쳐나는 시대에 딱 하나 정도는 내 손으로 직접 만든 프로그램을 나 자신이 유용하게 쓰고 있다는 게 뿌듯하다. 그것도 우리나라의 고유 문자인 한글을 전문적으로 다루는 독특한 프로그램이고, 사람이 다루는 수많은 정보들 중 가장 기본적이고 원천적인 것에 속하는 텍스트 데이터를 취급하는 프로그램이니 말이다.

7.0은 공개된 지 40일이 넘게 지난 현재까지 다음과 같은 몇몇 버그들이 발견되어 고쳐졌다.

편집기

(1) 한 줄당 200칼럼이 넘는 1920급의 가로 해상도에서, 그리고 '자동 줄바꿈' 옵션을 끈 상태에서 <날개셋> 편집기의 문서창을 최대 크기로 곧장 열었을 때 글자가 제대로 표시되지 않고 오동작이 발생하는 문제를 확인하여 고쳤다.
이것은 이번 7.0에서 처음으로 등장한 문제는 아니고 예전 버전부터 있었다. 단지 재연 조건이 흔치 않기 때문에 지금까지 발견되지 않았던 것이다.

(2) 사용자 정의 후보 변환을 쓰면, 사용자가 선택한 후보의 다음 후보들까지 한 줄에 하나씩 나란히 다 삽입됨

외부 모듈

(1) Windows 8의 Modern UI에서 옛한글이 여전히 입력되지 않음.
이것은 다른 문제가 아니라, Modern UI에서는 레지스트리에 접근이 되지 않아서 옛한글 표현 방식 옵션이 제대로 전달되지 않아서 발생한 현상이다. 내가 미처 생각하지 못한 상황이었으며 문제는 즉시 해결했다.

(2) Visual Studio 2012의 일부 검색 입력란에서 한글이 연속 입력될 때 다음 음절의 첫 타가 씹히던 문제.
<날개셋> 한글 입력기로부터 받은 문자 조작을 운영체제의 TSF layer로 옮기는 핵심 루틴을 모처럼 고쳐야 할 정도로 대단히 어려운 문제였다. 다른 프로그램들은 이렇게만 써 주면 아무 문제 없이 동작하는데, 저 프로그램은 특이하게 동작해서 그랬다.

(3) 이 외에 프로그램을 아주 극단적으로 특수하게 사용하지 않는다면 마주칠 일이 거의 없는 사소한 문제

또 일부 제어판 GUI에서 리스트박스의 아이템 높이가 현재 시스템 글꼴의 세로 크기를 정확하게 반영하도록 고치고(고해상도 환경 대비), 일부 영문 GUI의 텍스트와 도움말 본문을 살짝 수정했다.

2.

<날개셋> 한글 입력기 7.0에 뒤이어 올여름엔 Windows도 8.1이 나왔다.
윈도 8과 윈도 8.1의 관계는
윈도 98과 98 SE
윈도 95와 95 OSR2
윈도 XP와 XP sp2

의 관계에 얼추 대응하는 듯하다. 이제는 버전도(3.x, 4.0)도, 연도(95/98/2000)도, 고유명사도 아니고(XP/Vista), 버전과 무관한 숫자를 브랜드명으로 쓰는 이상한 관행이 생겼다. 잘 알다시피 윈도 7의 내부 버전은 6.1이고, 8과 8.1의 버전은 6.2이다.

잠깐 써 봤는데 생각만치 큰 차이는 없다. 시작 '버튼'만이 부활했을 뿐 그걸 클릭한다고 해도 과거의 시작 메뉴가 뜨는 것은 아니며, 여전히 전체 화면을 차지하는 시작 화면이 나온다.
<날개셋> 한글 입력기나 타자연습, 파워업이 윈도 8.1만을 위해 딱히 업데이트되어야 할 필요는 다행히 없는 것 같다. 다들 주요 기능들이 잘 동작한다.

차이라면 차이를 찾은 게 뭐냐 하면 8.1의 Metro(Modern) UI는 보안 모드에서도 TSF A급으로 동작하게 된 듯하다.
한글에 대해 한자 변환을 해 보면 한자들의 훈과 음이 뜨지 않고 유니코드 BMP 한자가 아니라 한국 상용 한자 4888자만 달랑 뜨는 모드가 있는데, 그게 바로 보안 모드이다.
날씨 앱을 실행한 뒤, 지역 추가 버튼을 눌렀을 때 뜨는 입력란이 보안 모드에 속한다.

보안 모드에서는 IME가 ProgramData나 사용자의 문서 디렉터리에도 전혀 접근을 할 수 없어서 자신의 동작에 필요한 파일을 제대로 읽을 수 없다. 그래서 한자 후보도 그렇게 볼품없게 나오는 것이다.
다만, 모든 Metro UI가 보안 모드인 건 아니다. 가령, Metro용 Internet Explorer는 주소 입력란이 보안 모드가 아니기 때문에 한자 후보가 데스크톱과 똑같이 제대로 뜬다.

8 시절에는 보안 모드에서는 파일도 제대로 못 읽을 뿐만 아니라 입력란이 TSF A급으로 동작하지도 않았는데
8.1 평가판을 써 보니, 그때도 비록  한자의 훈과 음은 안 뜨지만 TSF A급으로 동작하여 backspace 달라붙기 기능도 잘 되고, 단어 단위 한자 변환도 잘 되더라. 이걸 확인했다.

2-1.

8.1에만 해당되는 건 아니고 8부터 그랬던 것이긴 하지만,
원래 운영체제의 에디트 컨트롤은 특별히 TSF A급 확장으로 동작하고 있지 않을 때는 딱히 후보 창을 표시할 위치를 설정해 주지 않았었다. 그래서 MS IME든 날개셋에든 한자 후보 변환을 시켜 보면, 한자 선택창이 cursor의 위치와 관계없이 언제나 화면 우측 하단에 고정되어 나타나곤 했다. 윈도 7까지만 해도 말이다.

그랬는데 8부터는 에디트 컨트롤도 후보 창이 cursor의 아래에 나타난다.
MS에서 딱히 이런 동작까지 일부러 신경 써서 바꿀 것 같지는 않았는데 의외이다.

하지만 메뉴를 오른쪽 정렬로 띄우는 옵션은 도대체 왜 넣었는지 알 길이 없다. 아랍권이 아니면 전혀 필요 없을 기능인데 왜 한글/영문판에다가도 기본으로 선택시켰는지 원?

3.

드디어 공개한다. 내 홈페이지의 영문 버전을 개설했다.
본인에 대한 아주 최소한의 소개와 <날개셋> 한글 입력기 페이지만 존재한다.
Kim Yongmook's Official Home Page
Nalgaeset Hangul Input System

새로 만드는 영문 사이트는 prg4.html 같은 구식 주소 대신 ngs라는 디렉터리를 통째로 사용하며, 인코딩도 UTF8로 돼 있다.
도움말 전문이 영어로 좀 번역돼야 하는데 도저히 그럴 엄두가 안 나니, 외국인에게는 세벌식 같은 것보다는 현실적으로 훨씬 더 필요한 기능만 중점적으로 소개해 놨다. 바로 한글 로마자 입력 기능. 한영, 한자 키를 재정의 가능한 것도 덤이다.

그나저나 설치 프로그램 자체도 다국어 UI가 지원돼야 하는데 이건 비주얼 스튜디오가 기본으로 제공하는 설치/배포 프로젝트만으로 어찌할 수 없는 사항인지? 이 역시 아쉬운 점이다.
어쨌든, <날개셋>이 벌써 7.0까지 나왔으니, 이제는 내 프로그램을 국제적으로 알리는 것에도 신경을 쓸 계획이다.

Posted by 사무엘

2013/08/20 08:37 2013/08/20 08:37
Response
No Trackback , 29 Comments
RSS :
http://moogi.new21.org/tc/rss/response/868

Trackback URL : http://moogi.new21.org/tc/trackback/868

Comments List

  1. 김기윤 2013/08/20 09:19 # M/D Reply Permalink

    윈도우 8.1의 버전이 6.2 었나요!? 6.3으로 알고 있었는데 제가 잘못 알고 있었군요..

    Windows 8 영문 위키 페이지의 latest preview release 에 버전이 6.3 (Build 9431) 이라 적혀 있어서 영락없이 6.3 인줄 알고 있었습니다..

    1. 사무엘 2013/08/20 09:44 # M/D Permalink

      응? 저의 정보가 out-of-date인 걸수도 있습니다. 제가 지난 6월? 7월쯤에 직접 받아서 써 본 8.1 preview는 내부 버전이 여전히 6.2여서 말이죠~! 그 새 버전도 올라갔는가 봅니다.
      Modern UI가 모두 TSF A급으로 바뀌고 내부적인 안정성도 더욱 향상되었더군요. 문자 입력 쪽으로는 확실히 좋아진 점이 있었습니다.

    2. 김기윤 2013/08/24 01:57 # M/D Permalink

      이런 글을 보았습니다.

      http://www.neowin.net/news/final-windows-81-rtm-version-number-may-be-639600

      최종적으로는 6.3 이 되는 듯 합니다~

    3. 사샤나즈 2013/08/29 18:22 # M/D Permalink

      6.3 맞습니다. 8.1 프리뷰에서 빌드가 6.3.9431로 나와요.

  2. 근성인 2013/08/20 15:11 # M/D Reply Permalink

    영문 페이지에서도 룩킹포유 소개에 많은 내용을 쓸 것이라 생각하고 눌러봤는데, 진짜였어...

    1. 사무엘 2013/08/20 21:31 # M/D Permalink

      후훗~~~ 그건 당연한 거 아님?? ㅋㅋㅋ

  3. 사샤나즈 2013/08/29 18:49 # M/D Reply Permalink

    8.1은 프리뷰 버전일 뿐이라 보고를 보류하고 있었는데, 이번 유출된 RTM 버전에서 해 보니 같은 문제가 있길래 올려 봅니다.
    http://sdrv.ms/19Pt9SX (기본 입력기)
    http://sdrv.ms/17kZUZM (날개셋)

    Modern UI IE11에서 주소를 칠 때 기본 입력기에서는 자동완성이 되는데, 날개셋 입력기에서는 자동완성이 되지 않는 문제가 있습니다. 프리뷰에서도 RTM에서도 같은 현상이 있네요..

    1. 사무엘 2013/08/30 04:29 # M/D Permalink

      흠, 한글도 아니고 영문 모드의 동작 방식 차이는 IME 차원에서 만들어 낼 수 있는 게 아닌 거 같은데.. ㅡ,.ㅡ;; 두 가지 사항을 추가적으로 확인 부탁드립니다.

      1. 날개셋의 영문 자판도 드보락 같은 게 아니라 '빈 입력 스키마와 호환' 옵션이 맞춰진 쿼티이죠?

      2. 예전의 윈도 8은 안 이랬는데 8.1부터만 차이가 발생하나요?

    2. 사무엘 2013/08/30 05:17 # M/D Permalink

      내부 버전이 여전히 6.2이던 시절의 8.1 초기 스냅샷으로도 말씀하신 현상을 정확하게 재연 확인하였기에 자문자답을 하겠습니다.

      '빈 입력 스키마와 호환' 옵션이 맞춰진 쿼티는 자동 완성이 되고, 드보락처럼 IME가 인위로 생성한 영문 입력은 suggestion만 위에 뜨지 자동 완성이 되지는 않는군요.
      이것은 IE의 동작 방식 자체가 일부러 바뀐 것입니다. 제 프로그램과는 무관한 현상입니다.
      게다가 과거의 윈도 8은 둘 모두 자동 완성이 됐는데 8.1부터는 둘을 구분하게 바뀐 것이네요..! 생각도 못 했는데 꽤 재미있는 차이를 발견하셨습니다.

    3. 사샤나즈' 2013/08/30 16:23 # M/D Permalink

      그럼 현재는 딱히 해결책이 없는 거군요. 답변 감사합니다. ㅠㅠ

      그런데 윈도8.1이 최초로 유출되었던 빌드 9364, 이후 빌드 9385, 프리뷰로 정식 배포된 빌드 9431, 유출된 RTM 빌드 9600 모두 6.3이었는데 6.2인 적이 있었나요..?

    4. 사무엘 2013/08/30 22:26 # M/D Permalink

      1. 제가 갖고 있는 물건은 빌드 번호가 9431짜리인 프리뷰입니다.
      윈도 운영체제의 About 화면에서는 버전 6.3, 빌드 9431이라고 나타나지만,
      윈도 API로 내부 버전값을 구해 보면 6.2.9200가 잡히거든요. (날개셋 편집기의 About 대화상자에서 확인 가능)
      RTM은 어찌 되었나 궁금합니다.

      2. 음 그리고 말이 나온 김에.. 하나 좀 여쭙시다.
      윈도 8이나 8.1에서..
      날개셋 프로그램들의 대화상자 중에 수식을 입력받는 입력란을 아무거나 가 보세요.

      가령, 편집기에서 "찾기-문자 영역", 혹은 입력기 제어판에서 "편집기 계층-최종 변환 -> 적용 조건" 등.
      거기서 A+B를 입력해 보면, A+B가 되는 순간 cursor가 왼쪽으로 가 버리는 현상이 있습니까?
      윈도 8부터만 나타나는 버그 같거든요. 확인 부탁드립니다.

  4. ellif 2013/09/13 08:53 # M/D Reply Permalink

    오랜만입니다.

    혹시 나래셋에 가능하시다면 리프식 로마자 표기법 인풋 추가 가능한가요.
    http://e11if.tk/lifroma

    검토해주시고 적용해주시면 표기법 홍보에도, 외국인분들에게도 도움이 될 것 같습니다.
    댓글 읽어주셔서 감사합니다.

    1. 사무엘 2013/09/13 21:11 # M/D Permalink

      안녕하세요?
      연구하신 것은 한글→로마자로 대응하는 변환 규칙일 뿐이지 딱히 글쇠배열 같은 입력 방식을 규정하고 있지는 않네요.
      원하는 것을 분명히 해 주시고, 직접 입력 방식을 만들다가 모르는 기능이나 기술적으로 막히는 게 있으면 제게 질문해 주시면 좋겠습니다.

      그나저나 규칙이 굉장히 파격적인 한편으로 흥미롭네요. 특히 쌍자음을 알파벳 하나에다 대응시킨 건 F-ㄸ 하나만 어쩔 수 없이 좀 이질적이고 나머지는 생각보다 직관적인 거 같습니다. ㅎㅎ

    2. 사샤나즈 2013/10/09 21:14 # M/D Permalink

      글 아래쪽에 링크하신 프로그램을 보고 유추하건대 아마 원하시는 것이 아마 리프식 로마자 표기법으로 입력하면 그에 따라 한글이 입력되는 그런 것인 듯합니다. 아마 히라가나 입력처럼 만들 수 있을 것 같네요.

    3. ellif 2013/10/09 22:49 # M/D Permalink

      예를 들어서 '.arira@' 이라고 입력하거나 'arira@', 또는 'arirang'을 입력하면 '아리랑'이 나오는 경우이겠지요. 리프식 로마자로 입력시에는 몇가지 고려해야 할 스펙이 더 있어서 고민되기는 합니다. 가령 '^'나 '@', '~'의 입력시에는 ㅇ이 아니라 @, ㅐ가 아니라 '~'를 넣어야 할 때는 어떻게 해야 하냐라던가...()

      이런 스펙은 문과인 저의 한계상 개발할 수 없습니다. 그래서 굳이 부탁을 드리려고 했던 것입니다.

    4. 사무엘 2013/10/10 00:15 # M/D Permalink

      한글을 조합 중일 때의 여부에 따라(초성 입력 중일 때, 중성 입력 중일 때, 한글을 조합하는 상태가 아닐 때 같은) 조건부로 다른 글자가 입력되는 글쇠 정도는 제 프로그램으로 구현이 가능하지만,
      cursor 앞뒤에 있는 글자 문맥에 따라 서로 다른 글자가 조건부로 찍혀야 하는 것은 구현할 수 없습니다.
      리프식 로마자 표기법에 기반한 로마자 한글 입력법은 모든 규칙을 딱 저 형태로 추스릴 수 있는가요?
      스스로 생각하기에, 아래아한글이 제공하는 것 같은 기존 한글 로마자 입력 방식보다 기술적으로 더 변칙적인 게 존재한다고 여겨지는지요?

    5. ellif 2013/10/17 23:07 # M/D Permalink

      리프식 로마자 표기법이 일반적인 한글 자판 입력과 다른 매커니즘이 발생하는 경우는 다섯 가지 정도입니다.

      1) 초성 .의 경우에는 처음에 어두에 찍는 .를 ㅇ로 변환,
      2) 입력 중 .을 찍고 곧바로 모음 입력이 이루어지는 경우는 'ㅇ+자음'으로 자동 변환, 자음 모음이 이루어지면 .를 그대로 유지 (ga. → '가.' ga.a → '가아' ga.q → '가.ㄱ' )
      3) y는 'ㅣ' 출력 후 추가 모음에 따라 처리, 마찬가지로 w도 'ㅡ'출력 후 추가 모음에 따라 처리.
      4) .e의 경우에는 'ㅇ'-'의'로 입력했다가 다음에 .ege 를 '의게'로 읽지 않도록 몇몇 경우에는 자동 보정을 해준다거나,정확하게 .Ege로 입력할 때만 '에게'로 출력하면 될 문제(이 경우 .ege는 '의게'로 입력됩니다. 워드프로세서에서도 쉽게 정정할 수 있는 부분이지요.) '엑에'를 입력할 경우는 '.Eg.e'로 중간에 .을 찍으면서 초성 구분이 되니까 매커니즘이 헷갈릴 이유는 없다고 봅니다.
      5) @, ~, ^, _, )는 초성에서는 그대로,
      중성 입력시에는 ~, ^, _, )는 ㅐ, ㅓ, ㅡ, ㅚ로 변환, 그 상태에서 한 번더 입력할 시에는 ㅐ~, ㅓ^, ㅡ_, ㅚ)를 출력
      종성에서는 @-> 종성ㅇ, @@ ->'ㅇ@'를 출력하면 됩니다.

      일단 고어 지원까지 당장 고려하기는 어렵지만, A는 아래아,B는 여린비읍(cf. BAig ㅸ.ㅣㄱ) (. Z는 반시옷(Zam - △ㅏㅁ), H는 여린히읗 정도 입력까지 지원해두면 좋을 것 같습니다.

    6. 사무엘 2013/10/19 20:31 # M/D Permalink

      2) '.'가 '아'로 바뀌는 부분은 현재의 <날개셋> 한글 입력기로 구현 가능한 기술 수준이 아니네요.

      한 글쇠가 현재 초/중/종성을 입력하는 상황이냐, 한글 조합 중이 아니냐에 따라서 조건부로 서로 다른 문자나 한글 자모를 입력시키는 것은 괜찮지만, 이미 화면에 표시된 문자가 한글과 비한글 사이를 왔다 갔다 해야 하는 것은 일반적으로 구현 가능하지 않다고 생각하시면 됩니다.

      또한 이미 입력된 자모가 다른 성분의 자모로(가령, 초성에서 중성으로) 변하는 것은 불가능은 아니지만 굉장히 복잡한 편법을 동원해야 하며 어렵습니다. 같은 성분의 자모로의 변화는 문제 없이 가능합니다.

    7. ellif 2013/10/19 21:25 # M/D Permalink

      제가 글을 쓰면서 혼선을 드렸던 모양인데요, .를 치면 그냥 'ㅇ'만 반환하면 됩니다. '.a' 가 '아'가 되지요. 말씀하시는 대로라면 오히려 arira@을 쳤을 때 ㅏ리랑이 아닌 아리랑을 반환하기 어려운 문제가 있다고 보이네요.

      그리고 리프식 로마자 표기법은 하나의 입력 체계만 받아야 할 것입니다. (영어는 한영키로 수정하고요)
      키보드 자판은 조만간 생각해서 만들어보겠습니다.

    8. ellif 2013/10/21 18:24 # M/D Permalink

      일단 키보드 자판안은 이러면 될 것 같습니다.
      http://e11if.tk/lifroma_key

    9. 사무엘 2013/10/21 23:22 # M/D Permalink

      ga. → '가.' ga.a → '가아' ga.q → '가.ㄱ'

      라고 명시를 하셨으니, 이미 입력했던 멀쩡한 마침표가 한글 자모로 바뀌거나 vice versa가 일어나야 하는 건 사실이지 않은가요? 그것이 제 프로그램으로 가능하지 않다는 얘기입니다.
      글쇠배열은 잘 봤습니다. 다만 ㅇ과 .이 중첩 배당되어 있는 건 어떻게 처리해야 할지 고민해 봐야 할 것 같습니다.
      얘기가 길어지는데요, 이와 관련해서 혹시 제게 더 하실 말씀이 있으면 메일로 의견을 주고받는 게 어떨까 싶습니다. ( sebulsik 드림위즈)

  5. 사샤나즈 2013/10/09 21:13 # M/D Reply Permalink

    이전에 윈도8 Modern 환경을 지원해 주실 때 비 Modern 환경에서 한번 입력기 로드를 한 뒤여야 제대로 작동을 한다고 하셨습니다만, PC 사용시에 Modern 환경으로 먼저 들어갈 때가 생각보다 잦아, 설정을 불러오지 못하고 해당 애플리케이션 속에서 강제로 두벌식에 묶이는 현상을 겪습니다.

    말씀해주신 것에 따르면 현재 그럴 수밖에 없는 것이겠습니다만, 혹시 설정을 강제로 다시 불러오도록 시도하는 단축키라든가를 만들 수는 없을까요? 해당 애플리케이션을 완전히 껐다 켜면 어찌됐든 입력기가 다시 제대로 작동합니다만 때때로 이렇게 되면 애플리케이션상에 써놓은 글이 날아가 버린다거나 (따라서 그 전에 어떻게든 백업을 해야 한다거나) 하는 일이 발생하기 때문에 이런 기능이 있으면 어떨까 싶습니다.

    1. 사무엘 2013/10/10 00:16 # M/D Permalink

      예. Modern과 비 Modern 사이엔 레지스트리, 공유 메모리, 파일 등 그 어떤 수단으로도 입력 설정을 주고받을 방법이 절대적으로 없어서 이건 도저히 불가피하게 취해진 제약입니다. 윈도 8이 무슨 철학으로 개발되었는지 이해가 안 되고 참 안타까운 면모이죠. 다른 해결책은 아직 딱히 떠오르는 건 없네요. :-(

      단, Program Files라든가 윈도 시스템 디렉터리처럼, write를 할 때 관리자 권한이 필요한 디렉터리는 Modern 앱들도 read용으로 접근이 됩니다.
      그렇기 때문에 비 Modern 프로그램에서 미리 그런 위치에다가 만들어 놓은 입력 설정 파일을 읽게 하면 문제를 이론적으로 “피해 갈 수는” 있지만..
      그 디렉터리들은 그런 용도로 사용하라고 있는 게 아니며, 입력 설정을 바꿀 때마다 사용자에게 UAC 대화상자를 노출시키면서 지저분한 방법으로 Modern UI를 지원할 의향은 없습니다.

    2. 사무엘 2013/10/14 17:34 # M/D Permalink

      아.. 인제 무슨 뜻인지 알겠네요.
      그 점은 미처 생각을 못 했네요.
      Modern부터 먼저 띄워 버린 뒤에 나중에 데스크톱에서 설정 동기화를 했다면, 이미 띄운 모던 앱으로 돌아오더라도
      현재 프로그램 구조상 거기는 아마 설정 동기화가 안 될 겁니다.
      다음 버전에서 개선 가능한 사항인지 한번 검토해 보겠습니다. :)

    3. 사샤나즈 2013/10/14 17:42 # M/D Permalink

      아뇨, 일단 제약 자체는 이해합니다만 그런 얘기가 아니었습니다.

      비 Modern 환경에서 한 번 불러온 뒤에 Modern 환경에서 불러오면 작동을 하지만, Modern 환경에서 먼저 불러오고 비 Modern 환경에서 불러온 뒤에 다시 아까 그 Modern 환경으로 돌아와도 작동은 하지 않더군요. 그렇다면 이 경우에 강제로 설정을 다시 불러오면 이미 비 Modern 환경에서 불러온 설정을 갖고 다시 Modern 환경에서 작동을 할 수 있지 않을까 해서 문의드린 것입니다.

      사실 Modern 환경에만 해당되는 것이 아니라 데스크탑 IE에서도 설정을 제대로 불러오지 못하는 현상이 이따금 나타나기에 이런 간접적인 해결책이 있다면 좀더 편할 것 같기에 말씀드려 봅니다.
      //오타가 있기에 수정을 했더니 답변보다 아래로 내려와 버렸네요. 하하하...

    4. 사샤나즈 2013/10/14 17:45 # M/D Permalink

      가능하다면 좋겠네요! 완전한 해결책은 아니지만 간접적인 해결책이라도 될 수 있길 바랍니다 :D 감사합니다!

    5. Lyn 2013/10/17 21:53 # M/D Permalink

      소켓 어떤가요 (....)

  6. Lyn 2013/10/17 21:52 # M/D Reply Permalink

    오늘 정식 업데이트 된 빌드 넘버는 6.3(9600) 입니다

    1. 사무엘 2013/10/17 22:26 # M/D Permalink

      1. 오 드디어 8.1 정발됐군요.!

      2. 실제로 MSDN을 보시면요,

      IMEs may need to share data about the user’s input preferences between apps that are in different app containers. Use a web service to share data between Windows Store apps.

      이걸 무슨 도움말이랍시고...
      그런데 소켓 쓰라는 말이나 다름없죠..;;

Leave a comment

날개셋 한글 입력기 7.0

마지막 버전의 공개 이후로 4개월이 넘는 시간 만에 드디어 <날개셋> 한글 입력기 7.0이 나왔다.
6.8 이후로 내부적으로 굉장히 많은 변화를 겪었으며, 지난 4월에 한번 중간 개발 근황을 올린 이후로도 또 바뀐 게 많다.

도대체 더 만들거나 개선해야 하는 기능이 아직 얼마나 남아 있을까? 이제 7.x가 이 프로그램의 거의 마지막 메이저 버전이 되지 않을까 하는 두려운 생각도 들지만, 시간이 흐르면 또 생각이 달라질지도 모른다.

1. 아이콘

아이콘은 비록 프로그램의 동작과 직접적인 관계가 있는 요소는 아니지만 그래도 사용자에게 프로그램의 첫인상을 결정하는 중요한 외모에 속한다. 이번 7.0 버전은 구현체를 구성하는 EXE 형태의 프로그램들의 아이콘이 환골탈태했다. 짠~

사용자 삽입 이미지

윗줄부터 좌에서 우로 1 2 3 / 4 5 6으로 번호를 매기자면,
편집기(분홍 2), 변환기(노랑 1), 입력 패드(청록 3)의 순이다.

새로운 아이콘은 요즈음 MS가 Windows 8 이래로 추구하고 있는 간결한 디자인 컨셉을 반영함과 동시에, 프로그램의 성격을 함축적으로 드러내고 이들이 동일 브랜드에 소속된 프로그램임을 나타낼 수 있는 형태로 그려졌다.
먼 옛날, 2004년의 3.0 버전부터 거의 9년 동안 사용되어 온 편집기의 빨간 수첩 아이콘(6)은 드디어 역사 속으로 사라질 것이다.

편집기는 1.x 시절부터 통용되어 온 익숙한 빨강 계열 색상을 반영하면서 종이에도 펜으로 뭔가를 쓰는 도구, 즉 텍스트 편집기임을 형상화했다.
변환기는 뭔가 변환을 하는 프로그램이 전통적으로 사용하는 상징인 동그란 화살표를 반영했다.
입력 패드는 '터치 입력'을 표현하기 위해 종전의 태블릿 그림 대신 그냥 손가락을 형상화했다.

3개 프로그램의 아이콘을 16*16, 32*32, 48*48까지 다 그리는 데 이틀이 꼬박 걸렸다. 모두 도트 노가다의 산물이다. -_-;;
그러고 보니 사각형 밑으로 알파 채널이 가미된 어두은 그림자도 넣었어야 했는데.. 일단 제낀다.

예전 글에서 잠시 소개한 적이 있는데,
<날개셋> 편집기가 1.x~2.x 시절에 최초로 사용한 16컬러짜리 빨간 수첩 아이콘은 비주얼 C++이 예제로 제공하던 아이콘을 그냥 그대로 차용한 것이었다. 국산 텍스트 에디터인 EditPlus도 거의 같은 컨셉의 아이콘을 좌우 대칭시키고 살짝 고쳐서 아직까지 사용하는 중이다.

<날개셋> 3.0부터 지금까지 사용한 아이콘은 그 아이콘을 트루컬러+알파채널 형태로 리메이크한 형태이다.
변환기나 입력 패드는 그런 것조차 없이 인터넷에 올라 있는 공개 아이콘 라이브러리를 검색하여, 적절해 보이는 아이콘을 임의로 차용해서 잠시 써 왔다.

그러다가 이제 7.0부터는 편집기, 변환기, 입력 패드가 모두 자체 제작한 동일 컨셉의 아이콘을 쓰게 되었으니 본인은 기쁘다.

물론, <날개셋> 한글 입력기 전체를 대표하는 파랑 계열의 브랜드 아이콘은 여전히 바꿀 계획이 없다.
그리고 외부 모듈은 그 브랜드 아이콘을 흑백 형태로 고친 것으로, 잘 알다시피 Windows 8의 IME 아이콘 디자인 가이드라인을 따른 형태이다.

이번 버전에서는 외부 모듈의 도구모음줄 아이콘에 전통적인 16*16뿐만이 아니라 20*20 크기도 추가되었다. 그래서 120dpi 해상도를 사용할 때도 도구모음줄이 깔끔하게 표시된다.

2. Windows 8 지원 강화

역시 예전 글에서도 언급했었다. 이 정도면 이제 <날개셋> 한글 입력기는 MS가 만들지 않은 싸제 한글 IME 중에서는 2013년 현재 Modern UI에 대한 대비까지 온전히 갖춰진 유일한 프로그램이라 할 수 있다.

일단, Modern UI에서 IME가 데스크톱 모드와 완전히 동일하게 동작하는 것은 기술적으로 원천적으로 불가능하다는 점을 분명히 하고자 한다. Modern UI 모드에서는 IME가 동작하는 데 제약이 너무 심하다. 내 문서, ProgramData 디렉터리마저 접근이 안 되는 건 너무했다. 사실, 이 모드에서는 MS 자기네가 만든 IME조차 제대로 동작하지 못한다.
Windows 8을 대비하느라, 실질적으로 새로운 기능이 추가된 게 없이도 <날개셋> 외부 모듈의 코드가 꽤 늘어나고, 실행 파일의 크기도 더 커지게 됐다.

데스크톱에서 쓰던 한글 입력 설정을 그 환경에서도 그대로 공유하려면, 데스크톱 프로그램에서도 최소한 하나 이상 <날개셋> 한글 입력기를 외부 모듈로 사용하는 프로그램을 띄워 놓고 Modern UI를 사용하시기 바란다.
자세한 것은 도움말 “VI. 외부 모듈 - 일러두기 - 알려진 문제 - Vista 이상...”에 있는 Windows 8 관련 항목을 참고할 것.

3. 후보(한자) 변환 기능의 세분화

거의 5.x 시절부터 계획되었던 것인데 드디어 7.0에 와서야 실현되었다.
<날개셋> 한글 입력기는 내부적으로 한자/후보 변환 글쇠가 4종류 존재하며, 그 중 1번만이 현행과 같은 한자/초성 특수문자 변환으로 용도가 예약되어 있다. 나머지 2~4에 대해서는 변환할 후보 리스트를 사용자가 지정할 수 있게 되었다. 한글을 일본어 문자로 바꾸거나 구결로 바꾸거나 여타 특수문자로 바꾸는 등, 거의 상용구 치환 수준의 활용이 가능하다.

사용자 삽입 이미지사용자 삽입 이미지
(인증샷. KS X 1001에 없는 각종 특수문자들이다. 게다가 옛한글인 아래아 '한'에다가 surrogate 한자들을 잔뜩 배당한 것을 볼 수 있다.)

이 custom 후보 변환 기능에 대해서 사용자가 알아야 할 점은 다음과 같다.
첫째, 과거의 "<날개셋> 고급 입력기"에 존재하던 사용자 후보 변환은 후보 데이터의 mapping에 사용되는 key가 오토마타 상태 번호인 반면, 이번에 추가된 후보 변환은 전적으로 cursor 앞의 문자열이 key라는 점이 다르다.

둘째, 원본 문자열과 대상 문자열은 한 글자여도 되고 여러 글자여도 된다. 그리고 조합 중이든 그렇지 않든 상관없다. 단, 조합이 끝난 여러 문자열을 한꺼번에 치환하려면 '단어 단위로 한자 변환' 옵션이 켜져 있어야 되며, 그런 동작을 기술적으로 지원하는 구현체에서만(가령 TSF A급) 기능을 활용할 수 있다.

셋째, custom 후보 변환 기능은 내장형이냐 외장형이냐, 그리고 입력기 계층 소속이냐 편집기 계층 소속이냐라는 두 속성을 모두 지원하는 형태로 설계되었다.

내장형은 모든 후보 변환 규칙이 입력 설정 내부에 저장되며 언제나 메모리에 상주한다. 즉, 후보 변환 과정에서 디스크 액세스가 발생하지 않는다. <날개셋> 고급 입력기의 사용자 후보 변환 기능도 기술적으로는 내장형인 셈이다.
그러나 외장형은 입력 설정에다가는 데이터 파일 이름만 지정해 놓고, 후보 변환 중에는 디스크를 액세스하여 해당 파일을 뒤진다.

외장형은 대용량의 후보 데이터를 다루는 데 적합하며, 특히 동일한 파일을 쓰도록 지정하면 여러 입력 항목들이 동일한 후보 데이터를 불필요한 메모리 낭비 없이 공유할 수 있다는 장점이 있다. (단, Windows 8 Modern UI에서는 파일 시스템에 접근이 되지 않아 외장형은 사실상 제대로 쓸 수 없다는 점도 유의 필요).

외장형 데이터 파일을 그나마 사용자가 내용을 쉽게 고칠 수 있는 텍스트 파일, 그리고 더욱 방대한 데이터를 빠르게 검색할 수 있는 바이너리 파일 형태가 모두 존재할 수 있는데 이번 버전에서는 바이너리 포맷은 보류하고, 일단 텍스트 파일까지만 구현했다.

이 후보 변환 규칙은 각 입력 항목이 가질 수도 있고, 편집기 계층이 가질 수도 있다.
입력 항목은 내장형과 외장형 이렇게 2개를 갖고 있으며, 이것은 각각 '후보 변환 2'와 '후보 변환 3'에 해당한다.
그러나 편집기 계층은 내장형 아니면 외장형 중 하나로 형태를 취사선택만 할 수 있으며, '후보 변환 4'가 바로 여기에 대응한다.

지금까지 통상적인 한글-한자나 초성-특수문자 변환은 '후보 변환 1'이었고 단축글쇠 규칙에서 '한자' 키를 보면 C0|0x82라는 값이 배당돼 있었는데,
후보 변환 2~4를 쓰려면 먼저 단축글쇠부터 0x83~0x85를 Shift+한자 같은 데에다 배당해 주면 된다.
또한, 후보 변환 2~3에는 특정 입력 방식에 종속적인(local) 규칙을 지정하면 되고, 후보 변환 4는 어떤 입력 방식을 쓰든 똑같이 공유되는(global) 규칙을 지정하면 된다.

외장형 후보 변환에 대해서 설정을 누르면 사용할 파일을 묻는 대화상자만 달랑 뜨는 반면, 내장형 후보 변환에 대해서 설정을 누르면 간단한 후보 변환 데이터 편집 대화상자가 뜬다.
여기서 먼저 원본 문자열부터 지정하거나 추가해 준 뒤, 그 원본 문자열을 치환할 후보 문자열들을 등록하면 된다.

사용자 삽입 이미지

이때 후보 문자열뿐만 아니라, 한자로 치면 훈과 음에 대응하는 설명문도 사용자가 다 지정할 수 있다.
이곳뿐만 아니라 기존의 <날개셋> 고급 입력기도 후보 문자열에 덧붙여 설명문을 지정하는 기능이 같이 추가되었다.

또한 후보 변환 데이터만을 한꺼번에 불러오거나 저장하는 기능이 있는데, 여기서 저장한 파일을 곧바로 '외장형' 후보 변환에다가 지정해서 사용이 가능하다! 이런 식으로 내장형과 외장형 변환 사이에도 데이터 공유를 하면 된다. 이런 면모까지 다 고려해서 기능이 설계된 것이다.

이 사용자 후보 변환 기능은 원본에 대응하는 변환 후보가 하나밖에 없는 경우, 별도의 선택 UI를 출력하지 않고 곧바로 그 문자로 바꿔 버린다. 가령, 기존 후보 변환 1은 엔(円), 김(金)처럼 대응하는 한자가 하나밖에 없더라도 관례적으로 선택 UI를 언제나 출력한다. 그러나 후보 변환 2~4는 진짜 상용구 변환처럼 쓸 수 있게 그 경우 사용자에게 아예 질문을 하지 않게 했다. 위의 그림에서 '수단'은 일본어 スダン로 곧바로 치환하는 후보 문자열이 들어있다.

4. 그 밖에..

Windows 8 지원 강화와 사용자 후보 변환 기능만으로도 0.2 만치 변화는 충분히 달성했으며 7.0의 명분이 서지만,
이것 말고도 이번 버전에서는 단축글쇠의 경우, 조합 중인 상태일 때만 동작하고 나머지 상황에서는 그냥 응용 프로그램으로 넘겨 주게 하는 '조합 중일 때만' 옵션이 추가되었다.

그리고 프로그램을 설치할 때 설치 프로그램 차원에서 “<날개셋> 한글 입력기를 운영체제의 기본 입력기로 자동 지정할까요?”라는 질문에 대한 답변을 받게 했다. 명색이 한글 IME인데 이런 옵션 정도는 넣어야 할 것 같아서.

하지만 이게 모든 OS에서 가능한 건 아니다. Windows 9x 계열에서는 아마 MSI의 버그 때문에 사용자의 선택 결과가 레지스트리에다 반영이 되지 않아서 기능이 지원되지 않는다.
그리고 반대로 완전 최신인 Windows 8은 전통적인 이런 방법으로 기본 입력 언어를 지정하는 게 동작하지 않는다.
그래서 현재로서는 이 명령이 유효한 운영체제는 Windows 2000부터 7까지로 국한되나... XP와 7이 포함되어 있다는 것만으로도 이런 preference 지정 기능이 있는 것이 나쁘지는 않을 것이다.

또한 <날개셋>이 운영체제의 기본 IME로 지정되어 있는 채로 프로그램을 제거하려 하면, 작업이 더 진행되지 않으며 '텍스트 서비스 및 입력 언어' 제어판 대화상자가 바로 뜨고 기본 IME 지정부터 해제하라는 경고문이 나오게 했다.
왜 이런 안전 조치를 진작에 취하지 않았나 모르겠다.

지난 2월 이래로 4개월 동안 쌓이고 쌓인 작업이 7.0이라는 브랜드로 아주 잘 마무리 되었다.
이제야 나도 감금 상태에서 벗어난 수능 출제 위원이 된 듯한 홀가분한 기분이다.
다음 버전은 오는 10월쯤에 또다시 한글 입력 관련 기능의 강화를 테마로 한 7.1을 목표로 하고 있다.

<날개셋> 한글 입력기는 PC Windows 환경에서 한국어가 아닌 한글 자체의 입력 기술을 한데 통합하는 솔루션으로서 앞으로도 지존의 위치를 유지해 나갈 것이다.
끝으로, '날개셋계속개발'이라는 명의로 후원금을 보내 주신 분께 감사드린다.

Posted by 사무엘

2013/07/01 08:22 2013/07/01 08:22
Response
No Trackback , 21 Comments
RSS :
http://moogi.new21.org/tc/rss/response/849

Trackback URL : http://moogi.new21.org/tc/trackback/849

Comments List

  1. 김재주 2013/07/01 12:47 # M/D Reply Permalink

    조만간 윈도 8.1이 나온다는데 이것도 서비스팩의 탈을 쓴 신버전 수준이라고 하니 날개셋도 준비하셔야 할 걸요..?

    1. 사무엘 2013/07/01 18:43 # M/D Permalink

      Vista에서 7로 넘어갈 때 그랬던 것처럼
      규제· 제한이 8.1은 완화되면 완화됐지 또 골치아픈 게 생긴다거나 하지는 않았으면 좋겠네요.

      (하지만 경험상 새 Windows 버전이 나올 때마다 날개셋 역시 자주 업데이트를 해 줘야 했습니다. 매번 바뀌는 게 있어서.. ㅡ,.ㅡ;;)

    2. 사샤나즈 2013/07/19 13:36 # M/D Permalink

      이번에 입력기 액션에 좀 변화가 있습니다. 이전에는 한글을 칠 때 한 음절이 끝나면 조합이 그때그때 종료되었는데, 이번 8.1에서는 단어단위로 조합을 끊는 것 같습니다. 단어 입력하다 지우면 조합이 끝난 앞의 음절도 자모단위로 지워지네요. 그게 가장 큰 변화네요 @.@

  2. 정용태 2013/07/02 23:32 # M/D Reply Permalink

    먼저 7.0버전 축하드립니다!! 그동안 연락도 못드리고 회사 일정에 따라 달렸더니 벌써 날짜가 이렇게 돼버렸군요 ㅜㅜ 앱개발은 일정진행도 그렇고 하루하루가 전쟁터 같아서 원... 뭐 하나 업데이트하면 사이드이펙트 마구마구 발생해주고요..ㅋㅋ 철덕생활도 향유하지 못하고 있어서 용묵님이 올리신 안보및 철덕관련 글 읽고 하악대는 것으로 아쉬움을 달랩니다. ^^

    1. 사무엘 2013/07/03 05:59 # M/D Permalink

      반갑습니다! 역시 개발자로서 치열하게 지내고 계시는군요. 저도 비슷한 상황이어서 이번 7.0은 어김없이 꽤 처절하게 개발됐습니다. 출근길 지하철 안에서 후보 데이터 저장 기능을 구현하고, 퇴근길 지하철 안에서 열기 기능을 구현한 적도 있었지요. ㅎㅎ
      그래도 한 번 철덕은 영원한 철덕이 아닐까요? 레일러 14호에서 횡천 역 글 잘 봤습니다. ^^

  3. 사샤나즈 2013/07/18 21:53 # M/D Reply Permalink

    업데이트 나왔나 한 번 들러보는 걸 잊고 있었는데 오늘 와 보니 7.0 버전이 나왔군요. 7.0 축하드립니다!
    드디어 modern app들에서도 날개셋을 제대로 사용할 수 있게 되어 기쁩니다. :) 현재 modern IE에서 날개셋으로 댓글을 작성하는 중입니다!
    전에 말씀드렸던 아이콘도 이제는 깨지지 않고 잘 나오네요. 이 문제로 꼬박 이틀동안 도트를 찍으셨다니 그저 감사할 따름입니다. ㅠㅠ

    원인모를 문제를 좀 발견하긴 했는데 현재 윈도 8.1 프리뷰를 쓰고 있어서, 며칠 뒤에 데스크탑에 있는 윈도8 가상 머신에서 다시 확인해봐야겠네요.

    개발해주셔서 감사합니다 :)

    1. 사무엘 2013/07/19 03:18 # M/D Permalink

      반갑습니다. 드디어 Win8 Modern 앱에서도 한글 입력이 잘 된다니 제가 다 반갑네요.
      무슨 문제인지는 모르겠으나, 이상 현상은 정확한 재연 조건과 함께 친절히 알려 주시면 좋겠습니다.

      그리고 본문에도 언급했듯이, 데스크톱 앱에서 <날개셋> 한글 입력기 외부 모듈을 먼저 구동해 놓아야 Modern 앱에서도 사용자가 지정해 놓은 입력 환경 설정을 가져올 수 있습니다. 그렇게 하지 않으면 Modern 앱에서는 그냥 세벌식 최종이나 두벌식 같은 기본 입력 설정만 나오게 됩니다. 혹시 문제가 이런 거라면 참고하시기 바랍니다~!

    2. 사샤나즈 2013/07/19 13:48 # M/D Permalink

      기본입력설정 외의 커스텀 입력 설정은 잘 로드되는 걸 확인했는데, 옛한글 입력이 modern 앺에서 제대로 되지 않는 문제가 있어요. 일단 아직 데스크탑에 접근하지 못해서 윈도 8에서도 같은 문제가 일어나는지는 확인하지 못했습니다. 윈도 8에선 제대로 된다면 단순히 8.1 프리뷰의 문제일 가능성이 있을 테니 제대로 확인해보고 다시 제보하도록 하겠습니다.

    3. 사무엘 2013/07/19 16:32 # M/D Permalink

      한양 PUA 옛한글은 Modern UI에서 제대로 입력되지 않을 겁니다. 변환 테이블 파일을 열어야 하는데 그 파일로 접근이 안 되면 입력할 수 없습니다.
      그러나 Windows 8.x대에서 구닥다리 한양 PUA를 쓸 일은 없을 테고, 일반 표준 방식은 별다른 문제가 없어야 할 텐데 옛한글은 한글 표현 방식 옵션을 무엇으로 지정해서 입력하고 계신지를 꼭 알려 주셨으면 합니다.

      참고로 '호환용 한글 자모 사용' 옵션을 안 켜면 운영체제의 정책상 제대로 입력되지 않을 가능성이 높습니다. (첫 한글 조합은 반드시 한 코드 포인트짜리로 시작해야 함)

    4. 사샤나즈 2013/07/19 19:22 # M/D Permalink

      일단 8.1에서의 표현 방식 설정은 이렇습니다.
      http://sdrv.ms/1972P8T
      윈도8 프리셋이 있길래 그대로 사용했습니다. 아직 8에서도 증상이 있는지 확인해보진 못했네요..

    5. 사무엘 2013/07/20 09:15 # M/D Permalink

      1. 아, 옛한글이 표현되지 않는 원인은 아주 간단하네요.
      Modern UI에서는 IME가 레지스트리에 접근을 할 수 없습니다.
      그래서 옛한글 표현 방식 옵션을 불러오지 못하고 언제나 '현대 한글만 사용' 옵션처럼 프로그램이 동작해서 그렇네요.
      이 옵션도 데스크톱 앱과 Modern 앱 사이에서 공유가 되게 통로를 따로 만들어야겠습니다.
      다음 버전 7.1에서 개선해야겠습니다. 올해 하반기(10월쯤) 계획입니다.

      2. 윈도 8은 일부 Modern UI에서만 에디트 컨트롤들이 TSF A급이었지만 8.1은 모든 Modern UI 에디트 컨트롤이 TSF A급으로 바뀌었더군요. 중요한 차이인 것 같습니다~!
      그래서 비록 파일 시스템에 접근이 안 되어 한자의 훈과 음은 표시를 못 하더라도 단어 단위 한자 변환은 어디서나 되고, Bksp 달라붙기, 조합이 끝난 글자도 낱자 단위로 지우기 같은 기능이 동작하는 걸 확인했습니다.

    6. 사샤나즈 2013/07/21 21:49 # M/D Permalink

      감사합니다! :)
      Modern 앺들은 설정을 AppData 쪽의 앺 폴더에 저장하던데, 혹시 그쪽은 접근이 가능한가 모르겠네요.

    7. 사무엘 2013/07/22 21:36 # M/D Permalink

      내 문서, ProgramData 처럼 일반 사용자가 데스크톱에서 자유롭게 고칠 수 있는 디렉터리들은 의도적으로 전혀 접근을 할 수 없답니다.
      Program Files나 오히려 Windows system 디렉터리 같은 곳만 접근 가능한데, 여기는 평범한 권한으로 파일을 기록을 할 수 없을 뿐만 아니라 32/64비트 용도가 구분되어 있어서 일반 데이터를 집어넣기에도 영 좋지 않은 위치이죠. 왜 저런 정책을 썼는지 알 수 없는 면모입니다.

    8. 사샤나즈 2013/07/25 19:59 # M/D Permalink

      ProgramData 말고 Users\%USERNAME%\AppData 폴더요. 들어가보면 프로그램들이 자기 폴더를 많이 가지고 있는데, 날개셋은 이쪽을 쓰지 않는 듯해서 질문드렸어요.

  4. 사샤나즈 2013/07/26 13:56 # M/D Reply Permalink

    혹시 터치 키보드에 대응할 계획이 있나요?
    원래 윈도 7에도 화상 키보드가 있었지만 윈도 8부터는 터치 키보드라는 것이 새로 생겼어요. 데스크탑에서는 작업 표시줄 마우스 오른쪽 클릭 -> Toolbars -> Touch Keyboard (영어 OS라 한국어로 뭐라고 쓰여 있는지 모르겠네요) 으로 접근할 수 있습니다.

    기본적으론 이렇게 생겼는데...
    http://sdrv.ms/17FxqGB
    이게 지원되지 않는 날개셋 입력기는 아래와 같은 ㄱ레이아웃으로 나옵니다.
    http://sdrv.ms/1dXfWHz
    기본 레이아웃을 지원하지 않으므로 이러한 확장 레이아웃으로만 나오며 또한 자판을 바꿔도 이 레이아웃은 두벌식/쿼티 레이아웃으로 고정됩니다. 물론 실제 터치하면 원래 설정한 자판으로 입력되긴 합니다만, 터치하기에 좋지 않은 레이아웃이고 또한 자판이 달라 헛갈리네요...

    혹시 이 부분을 지원할 계획이 있으신가요?

    1. 사무엘 2013/07/26 07:02 # M/D Permalink

      두 질문에 대한 답변을 한꺼번에 드립니다.

      1. 네, IME라는 게 어차피 모든 사용자에게 똑같은 영향을 주면서 설치되는 프로그램이기도 해서, <날개셋> 한글 입력기는 여전히 전통적인 Program Files만 고수하지 Users\%USERNAME%\AppData는 사용하지 않습니다. Modern UI에서는 접근되지 않는 위치인 건 마찬가지이기도 하고요.
      기계 종류와 사용자 계정에 모두 독립적인 유용한 데이터 저장/공유 위치는 ProgramData밖에 없는데 이게 막혀 있는 타격이 가장 큽니다.

      2. 터치 키보드는 그냥 고정된 글쇠배열 중 하나만을 표시할 수 있는 형태여서 제 프로그램의 관점에서는 전혀 유용하지 않답니다. 즉, 세벌식이나 기타 custom 배열을 표시시키는 방법이 “없다고” MSDN의 터치 키보드 관련 API 문서에 명시까지 돼 있을 정도입니다. (관련 문의가 워낙 많았나 보죠)

      MS IME의 경우도, 세벌식으로 맞춰 놨거나 옛한글 입력기를 쓰고 있더라도 저 배열은 여전히 두벌식 고정이죠.
      다만, 터치 키보드는 배열 customize가 원래 되지 않는다고 도움말 문서에라도 명시해 놓는 건 나쁘지 않은 아이디어인 것 같습니다.
      그리고 두벌식 배열 고정이더라도 더 심플한 기본 레이아웃을 지원이라도 하는 게 많이 도움이 될까요? 궁금합니다.

    2. 사샤나즈 2013/07/26 13:58 # M/D Permalink

      정말 기본 IME에서도 배열이 바뀌지 않네요. 윈도에서도 터치용으로 멋진 IME가 나올 가능성이 되지 않을까 싶었는데 아쉽군요. 저도 그 문서를 읽어보고 싶은데 혹시 어디 있는지 알려주실 수 있나요?

      폴더 부분에서는 분명 뭔가 방법이 있을 듯 싶은데 어렵네요. Modern 앺은 분명 Users\%USERNAME%\AppData\Local\Packages 쪽을 쓰고 있긴 합니다만, app package에 기본적으로 있는 부분이 아닌 그 뒤에 추가되는 부분을 여기에 쓰고 있습니다. 패키지 자체는 %PROGRAMFILES%\WindowsApps에 저장됩니다. 이들 절대경로를 직접 쓸 수는 없고 따로 제공되는 API를 통해, 또는 ms-apps:// 라는 별도의 프로토콜을 이용해 폴더를 불러들여 사용합니다. (먼저 언급하신 내 문서 등도 마찬가지인데 이 경우 앺에서 권한을 처음에 명시해야 하므로 입력기에선 쓸 수 없겠네요)

      레이아웃 부분은 꽤 영향이 큽니다. 키의 크기 및 간격이 큰 기본 터치 최적화 레이아웃에 비해 클래식 레이아웃은(이렇게 부르더군요) 크기가 작기 때문에 입력이 한층 어렵습니다. 어차피 물리 키보드에서도 두벌식 쿼티 자판이 각인된 채로 다른 입력방식을 쓰고 있으니 터치도 그렇게 적응할 수도 있겠지만 이건 또 다른 문제지 싶습니다.

    3. 사무엘 2013/07/26 19:32 # M/D Permalink

      http://msdn.microsoft.com/en-us/library/windows/apps/hh802865.aspx 에서
      “There is no way to request support for other layouts, or to add new touch optimized layouts dynamically.”
      라는 문장을 확인하시면 되겠습니다.

      그러고 보니 클래식 레이아웃은 진짜로 키보드를 전부 다 옮겨 놓은 반면, 터치 최적화 레이아웃은 문자 글쇠 부분만 들어있군요. 세벌식은 신세벌식 방식이 아닌 이상 그런 레이아웃을 적용할 수 없을 테고..
      터치 키보드에 대한 추가 지원이 필요한지는 제가 좀 더 리서치를 해 보겠습니다. 저는 글쇠배열 customize가 안 된다는 대목에서 이미 가능성을 버려서 말이죠.

      데스크톱 모드에서는 <날개셋> 한글 입력기도 자체적으로 화면 키보드를 띄워 주는 기능이 있지만, 용도가 데스크톱 한정이고 운영체제의 터치 키보드에 비해서는 크기가 너무 작은 게 흠이네요.

  5. njw 2013/08/18 15:49 # M/D Reply Permalink

    안녕하세요. 세벌식을 사용하면 타자가 빨라진다는 얘길 듣고 이 곳까지 와서 날개셋이라는 프로그램도 받아서 연습도 했지만 하루이틀만에 익혀지는 것이 아니다 보니 잠깐 익히다 포기..한 사람입니다. 원체 세벌식으로 배우셨던 분들은 괜찮겠지만 입문을 두벌식으로 했던 요즘 친구들에게 세벌식을 다시 배우는 일은 좀 복잡하고 귀찮은 일이라 아마 저와 같은 사람이 알게 모르게 있을 것 같습니다. 그래서 말인데요, 혹시 두벌식 모아치기 프로그램을 개발하실 생각은 없으신지요? ^^ 예전에도 두벌식 모아치기 자판이 있었다고 봤는데 당시엔 그것을 사용하기엔 과부하가 걸려서 열이 발생하는 등의 이유로 정식화가 안 된 걸로 알고 있습니다. 요즘엔 환경도 많이 좋아졌고, 일반 사람들에겐 세벌식을 배우기보다는 두벌식에 모아치기 프로그램만 적용해서 사용하는게 더 편리하겠다는 생각도 듭니다. 세벌식 모아쓰기를 사용하면 물론 말하는 속도처럼 빨리 써지겠지만 굳이 그 정도로 빨리 써야 할 일도 일반 사람들에겐 드물 것이라는 생각입니다. 제가 이 아이디어를 얻은 건 타자 어플 중에 딩굴 키보드를 보고 느낀 것인데요, 스마트폰 어플에서 구동 가능할 정도라면 컴퓨터에서도 무리없이 가능할 것이라는 생각에서 올려봅니다. ^^a 글이 두서없네요. 여기에 글을 올리는 것도 맞는지..

    1. 사무엘 2013/08/19 02:00 # M/D Permalink

      안녕하세요?
      두벌식은 자음이 초성과 종성 구분이 되지 않기 때문에 구조적으로 제대로 된 모아치기 내지 동시치기를 구현할 수 없습니다. 만들더라도 굉장한 편법을 동원해야 하고 한계가 있을 수밖에 없지요.
      세벌식이 그런 식으로 타속 향상 연구를 할 수 있는 반면, 두벌식은 겨우 음절 구분을 어떻게 할지 연구하는 것에 머물러야 하지요.

      현재 <날개셋> 한글 입력기의 다음 버전에서는 동시치기에 최적화된 입력 스키마 관련 연구가 반영될 예정인데요, 새로 개발된 기능 중에 일부는 두벌식에도 제한적으로 적용 가능한 기능이 있을지 모릅니다. 하지만 세벌식과 같은 수준으로 초-중-종을 한 번에 동시에 입력하는 건 불가능하며, 그 이유는 설명이 필요하지 않을 것입니다. '딩굴 키보드'는 무슨 기능을 갖추고 있는지가 문득 궁금하네요.
      감사합니다.

  6. njw 2013/08/19 12:34 # M/D Reply Permalink

    네, 우선 딩굴 키보드는 옵션 터치모드선택 중에 모아치기라는 선택사항이 있습니다. 사용해본 결과 아주 매우 짧은 시간간격동안 모음을 먼저 치고 초성을 치는 실수가 있는 경우 바로잡아 주는 기능 즉 초성과 중성을 동시에 혹은 중성을 아주 짧은 차이로 먼저 쳐도 한 글자로 만들어주는 기능인 듯합니다. 물론 두벌식인지라 종성은 따로 쳐야 하므로, 세벌식과 같이 한 박에 치는 게 아닌 받침이 있는 글자의 경우 두박자로 글자 하나가 완성되는 느낌을 줍니다만 이렇게 해놓고 치니 속도가 빨라졌기에 글을 끄적여봤습니다. ^^ 답변 감사합니다.

Leave a comment

다음 버전 개발 근황 ㅋ

<날개셋> 한글 입력기 6.8이 나온 지 벌써 두 달 정도 시간이 지났다. 이 버전은 잘 알다시피 외부 모듈까지 Windows 8을 정식 지원하기 시작한 첫 버전이라고 선전... 은 했는데, 그 후로 Win8 사용자들로부터 역시 여러 미흡한 점들이 보고되었다..

  • IE의 주소 입력란 말고, 웹페이지 폼의 입력란에서 글자를 입력하는 중에 한/영 상태 버튼을 우클릭하면 메뉴 항목들이 disabled되어 나오는 것: 무척 괴이한 현상이지만 어쨌든 해결함
  • Modern(Metro) UI의 IE에서는 데스크톱 모드에서 맞춰 놓은 입력 설정이 제대로 반영되지 않고 동작하는 것: 파일 읽기에 문제가 있는 듯
  • 날씨(Weather) 같은 일부 자바스크립트 기반 앱에서는 <날개셋> 한글 입력기 커널 자체가 제대로 구동되지 못하고 영문만 입력되는 것: 역시 커널 DLL 파일에 접근하는 과정에 문제가 있는 듯. 권한 문제?

저것 말고 여전히 Windows 8의 Modern UI에서 <날개셋> 한글 입력기의 사용에 문제가 있는 분은 운영체제의 부팅 이후로 문제를 재연하는 모든 step을 마우스 클릭 단위로 상세하게 알려 주시기 바란다. 난 Windows 8 안 써서 그쪽 UI를 잘 모른다..;;더구나 데스크톱 앱과는 달리, Modern 앱들은 디버깅을 위해서 꼭 인터넷 접속을 해야 한다는 게 개인적으로 굉장히 불편하다. 정작 내 프로그램은 인터넷 같은 건 전혀 사용하지 않는데...

또한 근본적으로 Win8은 기존 데스크톱 환경과 Modern(메트로) 환경 사이에 장벽을 너무 많이 쳐 놨다. 그래서 데스크톱을 근간으로 하고 있으면서 Modern용 프로세스의 안에서도 서식해야 하는 외부 모듈에게 보안상 걸리는 제약이 너무 많다. 서로 memory mapped-file도 공유가 안 되고, Modern 프로세스 안에서는 대부분의 디렉터리에 접근도 안 되고.. 내 문서, ProgramData 다 안 된다.

Program Files와 Windows 디렉터리만 접근을 허용한다고 하는데, 전자는 32비트와 64비트가 따로 존재하기 때문에 사전이나 테이블 같은 공용 데이터를 놔 두기에는 적절하지 않은 위치이며 더구나 관리자 권한이 없으면 파일을 쓸 수도 없다. Windows\IME는 공식 설정상으로는 애초에 운영체제의 보급 IME들만이 사용하는 위치이다. 도대체 IME는 뭐 어떻게 동작하면서 Modern와 데스크톱 사이에 설정을 공유하라는 건지 모르겠다. 결국 레지스트리를 파일처럼 정보 공유 매체로 다루는 수밖에 없어 보인다.

뭐, 다음 버전을 개발하는 과정에서 이 이슈 말고도 다른 쪽으로도 <날개셋> 한글 입력기는 6.8 이래로 소스 코드가 많이 바뀌었다. 6.8은 다행히도 그 버전 자체만의 예기치 못한 버그가 들어있지 않으며 그럭저럭 잘 만들어졌다. 그래서 이 버전에 대한 유지 보수를 따로 할 필요가 없이 다음 버전인 7.0이 잘 개발되고 있는 중이다. 본인으로서는 다행스러운 점이다.

다음 버전 개발 근황을 좀 마이너한 아이템 위주로 늘어놓자면 이렇다.

1. 한컴 2바이트 코드와 한양 PUA 코드 변환과 관련된 모든 기능들은 드디어 <날개셋> 커널에서 완전히 삭제되었다. legacy 문자 코드에 대한 지원은 이미 4.8x대에서부터 차츰차츰 줄어들고, 커널에 있던 코드가 플러그 인 변방으로 이동하는 식으로 리팩터링이 진행되고 있었는데 그게 다 끝을 본 것이다. 이제 커널인 ngs3.dll에는 그런 문자 코드의 처리와 관련된 일체의 코드(프로그램)가 들어있지 않다.

2. 유니코드 문자열로부터 한글을 읽거나 쓰는 알고리즘을 미세하게나마 좀 더 최적화하고, 문자 인코딩을 자동 판단하는 알고리즘도 더 똑똑하게 개선했다. 한글이 없이 특수문자만 가득한 2바이트 인코딩을 제대로 판단을 못 하거나, 1바이트 아스키 문자 나열을 UTF16으로 오인하는 경우를 대폭 줄였다.
이 프로그램은 예나 지금이나 유니코드 UTF16, UTF8, 완성형(CP949), 그리고 조합형 코드(CP1361)을 자동 인식할 수 있다.

3. <날개셋> 편집기는 지난 3.0 시절부터 ‘기타 가져오기’ 기능을 통해 콘솔 프로그램의 출력 결과를 그대로 가져오는 기능이 있는데, 이 기능이 먼 옛날 버전부터 지금에 이르기까지 무척 비효율적으로 구현되어 있었음을 발견하여 대대적으로 개선했다.
언제든지 ‘취소’를 누르면 작업이 즉시 취소된다. stdout뿐만 아니라 stderr의 출력 결과도 가져온다. 그리고 프로그램의 실행이 끝난 뒤에도 작업 스레드가 정상적으로 끝나지 않고 강제 종료되고 있었던 것을 고쳤으며, 이 때문에 heap과 stack 메모리에서 발생하던 숱한 메모리 누수들도 덩달아 해결했다..

4. <날개셋> 편집기는 MFC를 쓰지 않고 자체 개발된 이래로 '창' 메뉴를 보면, 현재 선택되어 있는 문서 창의 항목에 체크가 표시되지 않는 버그가 있었다.. =_=;; 이걸 뒤늦게 인지하여 고침.

5. 외부 모듈의 경우 잘 알다시피 아이콘이 Windows 8 스타일의 흑백 배색으로 바뀌었는데, 표준 가이드라인에 따르면 겉의 테두리가 회색이 아니라 사실은 50% 알파가 적용된 검정이었다. 그것을 고쳤다.
그리고 사용 중인 글자판의 종류를 판단할 때, 비록 알파벳과 한글을 모두 입력할 수 있는 모호한 글자판이라도 한글(가/한) 판정이 후하게 나도록(A) 알고리즘을 살짝 고쳤다.

6. 외부 모듈은 제어판을 열어서 ‘확인’을 눌러서 종료하면 새로 바꾼 입력 방식이 모든 프로그램에서 곧바로 적용되어야 한다. 하지만 32비트 프로그램과 64비트 프로그램 사이에서는 이것이 동기화가 되지 않던 문제가 있었다. 새 버전은 이것을 해결했다. <날개셋> 한글 입력기가 64비트 플랫폼을 지원한 건 4.x시절 말기부터이고 시기적으로는 무려 5~6년이 지났는데 지금까지 이 점에 대해서는 전혀 생각을 못 하고 있었다.

7. 한글 로마자 입력 방식에서 표준 방식은 O+A로는 ‘ㅘ’가 되지 않고 오로지 W+A로만 ‘ㅘ’가 되게 규칙을 수정했다..

8. 일반적인 세로 스크롤용 휠뿐만 아니라 가로 스크롤 휠도 이제 드디어 지원한다. 일부 노트북 PC에서 터치패드 한쪽 끝을 가로로 드래그하면 이 메시지가 가는 경우가 있는데, 덕분에 편집기나 화면 인쇄 등 주요 화면에서 가로 스크롤이 가능해졌다.

<날개셋> 한글 입력기는 글쇠배열이나 오토마타 같은 걸 자유롭게 사용자 정의 가능하고 한글 입력과 관련된 거의 모든 아이디어들을 한데 기술할 수 있는 기반을 마련한 것으로 잘 알려져 있다. 하지만 그것 못지않게 이 프로그램의 독특한 면모는 바로 다양하고 개성 있는 구현체들이다. 문자 입력 기능을 제공할 수 있는 모든 형태의 구현체를 제공하기 때문이다.

편집기는 자체 한글 텍스트 에디터로, 문서 편집 창이 뜨는 일반적인 응용 프로그램과 가장 비슷한 형태이다. 전용 환경이다 보니 제공되는 기능이 가장 많고 특히 텍스트 필터를 써 볼 수 있는 사실상 유일한 구현체이다.
흔히 IME라고 불리는 외부 모듈은 EXE가 아니라 DLL이다. 범용성과 존재감이 가장 큰 구현체이다. 제공하는 기능의 양은 편집기보다 적지만, Windows 95부터 8까지의 모든 운영체제들의 특이사항을 커버하느라 코드의 양은 이게 편집기의 그것보다 더 많다.

변환기는 문자를 입력하는 기능은 없지만 한글의 표현과 관련된 호환성 유지를 위해 필요한 기능들을 한데 담은 유틸리티로, 간단한 대화상자 형태이다.
끝으로 입력 패드는 포인팅 장비를 이용한 문자 입력 기능만 제공하는 작은 프로그램으로, EXE 형태이지만 IME 내부 자료구조에 대한 훅킹을 통해 동작한다.

이런 모든 경우를 다 생각해서 개발되었다는 뜻이다. 이 구현체들은 심지어 도움말 내지 About 명령조차 서로 전부 제각각인 위치에 있을 정도로 사용자 인터페이스가 천차만별이다. (편집기는 프로그램의 도움말 메뉴, 외부 모듈은 입력 도구모음줄의 도움말 버튼, 변환기는 프로그램의 시스템 메뉴, 입력 패드는 시스템 트레이의 우클릭 메뉴)

개인적인 생각은 이들 프로그램의 아이콘도 마치 MS Office의 Word, Excel 등처럼 뭔가 한 제품에 속한다는 통일성이 느껴지는 형태로 바꾸고 싶다. <날개셋> 편집기의 지금 아이콘도 써먹은 지 벌써 10년이나 됐는데..

가끔은 까마득한 옛날의 1.x와 2.x버전을 꺼내서 실행해 본다. 내가 세상에 이런 완전 캐허접한 프로그램만으로 옛날에 정보 올림피아드 입상을 했구나 하는 생각이 든다. 1은 텍스트 에디터 하나 제대로 만들 기술도 없던 상태에서 그냥 세벌식 자판만을 위한 똘끼어린 최소한의 기술 데모일 뿐이었고 2는 버전 3을 만들기 위한 숱한 시행착오 단계였다.

3에서는 진짜 최소한의 뿌리와 기반이 갖춰지긴 했으나 아직도 허접한 UI와 외부 모듈의 안정성을 갖추기 위해 갈 길은 멀고도 험했다. 4는 버전 3이 경험한 시행착오들을 수습하면서 운영체제에 대한 독자적인 기술과 노하우가 차츰차츰 쌓이던 단계였고, 개발 8주년이 된 버전 5가 돼서야 내가 보기에 슬슬 쓸 만한 물건이 나오기 시작했다. 그리고 그 컨디션이 6에서 계속되는 중이다.

이 정도로 혼자 오래 꾸준히 개발한 프로그램이니, 내가 무슨 게임을 만든 것도 아닌데 이 프로그램에 대한 나의 애착과 중독성은 상당한 수준이다.
일단 결과물 자체부터 내가 매우 애용하고 있다. 비록 현실적으로는 외부 모듈이 가장 대중적으로 쓰이는 구현체일지 모르나 내가 가장 애용하는 구현체는 편집기이다. 자체적으로 문서를 편집하는 기능을 갖춘 일반적인 애플리케이션이며, 가장 먼저 개발되기도 했기 때문이다. 그냥 습관적으로 띄워서 뭐라도 글을 쓰고 한글 오덕질을 하고 싶은 생각이 절로 든다.

결과물뿐만이 아니라 도움말도 계속 읽어보고 싶고, 딱히 코딩을 안 해도 소스 코드를 꺼내서 뭐라도 리팩터링이나 최적화를 하고 싶다. 불행인지 다행인지 이 프로그램에 대한 모든 정체성과 권리는 본인이 혼자서 완전히 꽉 잡고 있기 때문이다. 1인 독재. <날개셋> 한글 입력기의 모든 바이너리들은 100% 자작 코드로만 이뤄져 있다.

그런데 여기에만 매여 있느라 다음 다른 연구도 제대로 못 할 정도인 건 문제인 것 같다.
이것과 관련된 개발 말고 다른 분야에는 도무지 관심이 생기질 않아서, 이걸 못 하고 덕업일치를 못 하느니 프로그래밍은 확실하게 취미 수준으로 접고 차라리 철도 같은 업종 전환도 고려할 정도로 진로가 좀 이상한(?) 방향으로 흘러가고 있다. 난 어지간한 다른 IT 분야 엔지니어들과는 애초부터 입문한 계기도 달랐고, 적성이나 취향도 다른 것 같다.

Posted by 사무엘

2013/04/13 08:30 2013/04/13 08:30
Response
No Trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/817

Trackback URL : http://moogi.new21.org/tc/trackback/817

Comments List

  1. Lyn 2013/04/13 16:36 # M/D Reply Permalink

    다음버전은 샤방샤방한 스킨 기능을 붙여서 (...)

  2. 김재주 2013/04/13 20:09 # M/D Reply Permalink

    이왕 이렇게 된 거
    사전과 형태소 분석 기능, 입력 패턴 분석 등의 알고리즘을 추가하여

    단어 입력중에 단축리스트가 떠서 입력속도를 단축시킬 수 있는
    우주최강 한국어 입력기로 재탄생하심이 어떨지...

  3. 사무엘 2013/04/13 22:27 # M/D Reply Permalink

    Lyn: ㅋㅋㅋ 스킨이라니.. ^^

    김재주: 언어 처리까지 들어가는 건 일단 날개셋의 개발 범위가 아닙니다만, 운영체제 차원에서도 자동 완성 쪽을 굉장히 많이 밀고 있기 때문에 그런 걸 무시할 수는 없을 것 같습니다. 글쇠 수가 적은 환경에서는 굳이 중국어/일본어 같은 언어가 아니라 영어까지도 자동 완성이 팍팍 쓰이니까.
    한국어로 범위 확대는, 한글만 갖고도 할 수 있는 일을 다 끝낸 다음에 생각해 보죠. ㅎㅎ

  4. 김재주 2013/04/14 14:20 # M/D Reply Permalink

    뭐 개발하시게 되더라도 입력기 자체게 포함된다기보다는 외부 모듈 같은 형식으로 추가하시게 될 것 같네요 아무래도 분야가 비슷하긴 해도 약간 다르니까요

    아니면 안드로이드 및 아이폰으로 레알 진출하는 것도 한가지 방벙이 될 것 같습니다 ㅋㅋ

  5. 이수동 2013/04/14 14:25 # M/D Reply Permalink

    안마태 소리글자 자판. ist 파일을 좀 구하려고 합니다
    자료가 있으며 링크 사이트라도...
    설명에는 날개셋 환경설정에서 하라고 되어 있는데요
    안마태 파일은 없네요
    한번 써보고 싶어서요
    한글 검색하다가 안마태 키보드를 보게 되었네요

    날개셋 좋은 아이디어네요

    훌륭하신 프로그램 타인에게 많이 공유 하도록 하겠습니다

    1. 사무엘 2013/04/15 07:29 # M/D Permalink

      안마태 소리글판은 제가 (주)안마태 연구소와 모종의 계약을 맺은 관계로, 이제 날개셋에서 정식으로 유형 파일을 제공하지 않습니다.
      손수 입력 설정을 맞춰서 쓰거나 예전 버전에 들어있던 파일을 스스로 찾아서 쓰는 것까지는 저나 그 회사 측에서 일일이 간섭할 수 없는 영역이지만, 바로 불러다 쓸 수 있는 파일을 응용 프로그램 차원에서 드리지는 않게 되었습니다. 이 점 양해해 주세요.

  6. 팥알 2013/04/15 13:23 # M/D Reply Permalink

    신세벌식 자판 원안에서 홀소리 ㅣ와 받침 ㅎ이 들어간 자리의 글쇠값은 이런 수식으로 들어가 있는데요.

    D&&(!E || E==0x15 || E==0x2B || E==0x40) ? H3|I_ : H3|_H

    이렇게 하면 ㅟ, ㅚ처럼 첫소리 없는 겹홀소리만 따로 넣지 못하는 점이 아쉽습니다.
    아래처럼 수식을 바꾸면 어떨까 싶습니다.

    D&&!E || E==0x15 || E==0x2B || E==0x40 ? H3|I_ : H3|_H

    1. 사무엘 2013/04/15 14:32 # M/D Permalink

      오, 그렇게 생각할 수도 있겠군요. 하지만 어차피 이중모음의 첫 시작인 ㅗ,ㅜ를 Shift와 함께 누르기 때문에 다음 타도 대체로 shift를 누른 채로 누르는 경우가 많지, 그걸 non-shift로도 입력할 수 있게 하는 건 그렇게 큰 의미가 있을 것 같지는 않습니다.

    2. 팥알 2013/04/15 15:16 # M/D Permalink

      아, 윗글쇠를 누른 채로 뒤에 나오는 홀소리까지 넣으면 겹홀소리만 넣을 수 있군요.
      거기까지는 생각하지 못했습니다.

  7. 사샤나즈 2013/04/27 12:13 # M/D Reply Permalink

    이건 버그까진 아닌데, 높은 DPI에서 작업 표시줄의 아이콘이 좀 깨져 보이네요...
    기본 IME에선 그렇지 않길래 혹시 알고 계시나 해서 올려 봐요.
    테스트한 DPI 설정값은 120DPI (125%)입니다.

    http://sdrv.ms/1228tAI

    1. 사무엘 2013/04/27 21:16 # M/D Permalink

      실제로 그렇게 표시되는 건 처음 보네요. (특히 제가 가진 물건이 해상도 낮은 맥북이어서 100보다 높은 DPI는 완전 관심 밖 ㅎㅎ)
      제 프로그램은 아직 16*16 아이콘에만 맞춰져 있는데, 이제는 그런 것까지 신경 써야 할 때가 됐네요.
      알려 주셔서 고맙습니다. ^^

  8. 터프엉클 2013/05/27 13:35 # M/D Reply Permalink

    간단한 사항을 추가할 수 있을까요? 사용하다가 개인적으로 이런 것이 추가되면 좋겠다는 것을 적어봅니다.
    제가 텍스트 작업을 하다보면 저장할 때 ansi 형식이기 때문에 UTF8 문자가 들어있을 경우 저장이 안됩니다.
    그런데 구체적으로 어떤 문자 때문에 저장이 안되는 것인지 알 수가 없습니다. 특히 많은 양을 편집할 때 말입니다.

    1. ANSI 형식으로 저장할 때 UTF8 문자 등의 문자가 있어서 저장이 안될 경우 해당 첫번재 문자로 커서가 이동하면 어떨까요? 그럼 수정이 간편할 듯합니다.
    2. “다른 이름으로 저장”을 할 때, 파일 형식에서 ANSI나 UTF8 등 한글에서 지원하는 형태만이라도 선택할 수 있게 하면 어떨까 합니다.

    그럼.. 계속 좋은 프로그램 발전시키시길 바랍니다.

    1. 사무엘 2013/05/27 16:30 # M/D Permalink

      안녕하세요?

      <날개셋> 편집기는 저장하는 인코딩으로 표현할 수 없는 문자가 들어간 파일을 저장할 경우, 저장 후에 “현재 인코딩으로 저장할 수 없는 문자가 있습니다.” 경고문를 표시해 주고, 그게 무슨 문자인지 코드 포인트까지 알려 줍니다.
      그래서 그 코드 포인트값을 "문자 영역 검색" 기능으로 찾으면 그 문자가 어디 있는지도 곧장 알 수 있습니다.

      또한, 문서의 인코딩을 바꾸는 명령은 “파일-저장 옵션”에 따로 갖춰져 있습니다. 여기서 UTF8이나 UTF16을 선택하면 됩니다. 참고하시기 바랍니다.

Leave a comment

여러 기호(또는 문장 부호)들 중에서 따옴표는 컴퓨터로 입력할 때 좀 유별나게 처리되고 다뤄지는 면모가 있는 문자이다.
일단 따옴표는 기호가 쌍으로 붙은 큰따옴표와, 하나만 있는 작은따옴표로 나뉜다. 전자는 어떤 발언을 직접 인용할 때, 그리고 후자는 발성이 타인에게 실제로 들리지는 않는 혼잣말이나 생각을 인용할 때 통상 쓰인다.

그러나 이런 물리적인 구분이 명확하지 않은 경우도 있다. 재미있는 것은, 따옴표로 둘러싸인 인용문의 내부에 또 인용문이 또 등장할 때는 물리적인 구분과는 무관하게 맞은편 따옴표가 작은→큰→작은..의 순으로 번갈아가며 쓰인다는 점이다. 또한 따옴표들은 완전한 문장이 아니라, 문장 내부의 특정 단어를 단순히 강조하는 용도로도 쓰인다.

따옴표는 괄호와 마찬가지로 열고 닫는 구분이 있다. 그러나 타자기나 컴퓨터의 글자판에는 괄호와는 달리 여닫는 따옴표가 따로 배당되어 있지 않다. 방향 구분이 없는 "와 '가 각각 큰따옴표와 작은따옴표의 역할을 대신한다.

텍스트 에디터는 코딩용으로도 쓰이고 키보드에 배당된 아스키 문자가 그대로 입력되는 게 중요한 경우가 많기 때문에, 따옴표도 있는 그대로만 입력받는다. 그러나 워드 프로세서 정도 되면, 지금 입력하는 문맥에 따라 해당 문자를 여닫는 따옴표로 알아서 치환해서 입력해 준다. 여기서 아주 재미있는 차이가 존재하는데, 아래아한글은 전통적으로 이런 구분을 한글 글자판을 쓸 때만 하는 반면 MS 워드는 글자판 구분 없이 언제나 그렇게 동작한다.

글쎄, 한글 입력 방식에서는 세벌식 최종 글자판이 여는 큰따옴표와 닫는 큰따옴표가 따로 배당되어 있고 그걸로도 모자라 "까지도 있다. 이것은 컴퓨터에서는 다소 잉여스러운 설계인지도 모르겠다. 그 대신, 영미 문화권의 텍스트 문서에서는 tilde 글쇠의 아래에 있는 `가 종종 여는 작은따옴표로 쓰이고 기존 '(어퍼스트로피)는 닫는 작은따옴표로만 쓰이는 경우가 있다. 한국에서는 보기 힘든 관행인 듯.

얼마 전에 본인은 여닫이 구분이 없는 따옴표만 쓰인 빽빽한 영어 성경 텍스트의 따옴표들을 여닫이 구분이 있는 형태로 일괄 변환할 수 있겠느냐는 부탁을 주변으로부터 받은 적이 있었다. 그냥 "만 달랑 들어있으면 왠지 아마추어스러운 티가 팍 날 테니, 인쇄해서 책으로 낼 텍스트라면 그 정도 배려는 해 주는 게 좋을 것이다.

"를 계속 찾으면서 “와 ”로 번갈아가며 대치만 하는 걸로 일이 끝이면 얼마나 좋았겠냐만, 이거 패턴이 의외로 간단하지만은 않음을 알 수 있었다.
작은따옴표는 어퍼스트로피가 존재하기 때문에 닫는 따옴표의 개수가 더 많아진다. 더구나 s로 끝나는 단어의 뒤에 붙은 어퍼스트로피는 닫는 작은따옴표와 형태적으로 구분할 방법이 없다.

그리고 큰따옴표와 작은따옴표 모두, 인용문이 여러 문단에 걸쳐서 길게 반복되는 경우라면, 이전 문단에서는 닫는 따옴표로 마무리가 되지 않은 채 다음 문단에서 또다시 여는 따옴표가 나온다. 물론, 그렇지 않고 앞 문단에서는 여는 따옴표로 시작해서, 다음 문단에서는 닫는 따옴표로 곱게 끝나는 인용도 따로 있고 말이다.

그리고 아까 얘기했던 중첩 인용도 문제가 될 수 있다. 열큰(여는 큰따옴표)와 작큰(작은 큰따옴표) 다음에 입력되는 큰따옴표는 여는 큰따옴표가 되어야 하는데, 이런 점을 고려하지 않고 기계적으로 따옴표를 치환하면 “(열큰) “(열큰) ”(닫큰) ”(닫큰)의 순으로 등장해야 할 따옴표가 “(열큰) ”(닫큰) “(열큰) ”(닫큰)으로 잘못 짝지어질 위험이 있다.

텍스트에는 최대 3단계의 중첩 인용이 존재하더라. 이거 생각보다 꽤 복잡하지 않은가?
텍스트 매크로, 찾기/바꾸기 등 여러 방법 중 과연 어느 것이 가장 적합할지 고민했는데 결국은 여러 차례의 바꾸기 기능을 사용하기로 결정을 내렸다. 여는 따옴표가 확실한 조건을 지정해 준 뒤, 나머지 따옴표는 모두 닫는 것으로 간주하는 게 가장 속 시원하다. 구체적인 절차는 다음과 같다.

1. 줄의 맨 첫 칸에 등장하는 따옴표는 반드시 여는 따옴표이다. 상식적으로 문단이 닫는 따옴표로 시작하지는 않을 테니 말이다. 그래서 줄의 처음을 의미하는 정규 표현식 ^를 사용하여, 첫 칸의 따옴표부터 다 여는 걸로 모두 바꾼다.

2. 그리고 공백(whitespace) 다음에 등장하는 따옴표는 반드시 여는 따옴표이므로 그렇게 바꿈.

3. 끝으로, 여는 따옴표의 다음에 등장하는 따옴표도 반드시 여는 따옴표이다. (여는 큰따음표 다음의 작은따옴표. 그리고 vice versa)

4. 위의 조건들을 만족하지 않고 아직도 방향이 결정되지 않은 따옴표들은 모두 닫는 따옴표이다. 치환.

이 작업을 큰따옴표/작은따옴표별로 다 해야 하기 때문에 '모두 바꾸기'를 무려 8번이나 해 줘야 한다.
그러나 <날개셋> 편집기에서는 '일괄 치환' 텍스트 필터에다가 다음과 같은 조건을 주면 일격에 상황 종료. 굉장히 유용하다.

"\n\"","\n“"
"\n'","\n‘"
" \""," “"
" '"," ‘"
“',“‘
"‘\"",‘“
',’
"\"",”

따옴표가 특별한 의미로 쓰이는 곳에서 따옴표 자체를 지정해야 하다 보니, 글자를 알아보기가 몹시 힘들다. 게다가 코딩용 폰트가 아닌 폰트는 여는 따옴표와 닫는 따옴표도 형태를 분간하기가 쉽지 않은 경우가 태반.
타자기 내지 컴퓨터 키보드에서 따옴표의 방향 구분이 별 의미 없다고 간주하여 괜히 없앤 게 아닌 듯하다.

아울러, 데이터베이스 같은 곳에서는 문자열 내부에 또 큰따옴표가 들어있을 때, 문자열의 시작을 '큰따옴표 두 개'로 표현하는 경우가 있다. 다음은 그런 문자열을 원래대로 복원하는 일괄 치환 조건이다.

"\"\"","\""
"\"",

그러고 보니 방향 구분이 없는 큰따옴표는 "위와 같음"(상등)을 의미하는 기호로도 쓰이며, 심지어 작은/큰따옴표가 각각 분과 초를 의미하는 단위로도 쓰인다. 신기하다. 본인은 이 경우까지 고려하지는 않았다.

Posted by 사무엘

2013/02/18 08:28 2013/02/18 08:28
,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/797

Trackback URL : http://moogi.new21.org/tc/trackback/797

Comments List

  1. 김 기윤 2013/02/19 15:49 # M/D Reply Permalink

    일정 규칙이 있는 변환을 해야 할 경우, 짧으면 2~3시간에서 길면 일주일만에 코드를 작성해서 자동으로 돌리면 매우 쉽게 해결되는 문제임에도 불구하고, 프로그래밍이나 관련 지식을 잘 모르기 때문에 그걸 직접 반년에서 일년에 걸쳐서 직접 하시는 분들도 있습니다. 프로그래머의 입장에서는 왠지 안타깝습니다.. 그런 분들을 본다면 도와드리고 싶기도 하고..

    1. 사무엘 2013/02/20 09:45 # M/D Permalink

      그걸 다 손으로 한다니.. 정말 ㅎㄷㄷㄷ
      그래서 컴퓨터 프로그래밍은 사람의 능력을 극대화해 주는 위대한 스킬임이 틀림없어 보입니다.
      또한, 텍스트 에디터는 겉보기로는 간단해 보여도 메모장 같은 진짜 간단한 물건과, 프로그래머용의 덕후스러운 전문적인 물건 사이의 수준 차이가 넘사벽급인 분야 중 하나입니다. 전문가용은 당연히 자동화, 매크로 같은 기능이 엄청나게 발달해 있지요.

  2. 박철현 2013/02/20 21:24 # M/D Reply Permalink

    프로그래머의 중요한 역할을 다시금 알게 되었습니다.
    좋은 정보 고맙습니다. ^^

    1. 사무엘 2013/02/21 16:10 # M/D Permalink

      사실, 컴공 비전공자라도 파이썬 정도 언어로 파일 여닫기, 문자열 다루기, 간단한 반복과 조건 같은 것만 학교에서 배워 놓으면 앞으로의 인생이 아주 편리해지지 않을까 싶습니다.
      아니, 요즘은 파이썬까지 갈 것도 없고 웹브라우저만 있으면 바로 돌릴 수 있는 자바스크립트가 있죠.

  3. 십삼각 2013/12/03 22:04 # M/D Reply Permalink

    1. 사실 (여닫이 구분이 있는) 따옴표, (여닫이 구분이 없는) 따옴표, 아포스트로피, 같음 기호(〃), 프라임 기호(분·초, 피트·인치)는 각각 별개 기호죠. 유니코드에서도 전부 구분하고 있는 걸로 압니다. 다만 편의상 혼용하는 것이긴 한데... 저는 개인적으로 다른 건 구분 안 하더라도 같음 기호의 경우에는 "보다 〃가 더 모양이 좋아서 이쪽을 씁니다.

    어떻게 보면 말줄임표 대신 온점 세 개를 쓰는 현상, 가운뎃점 대신 아래아를 쓰는 현상과 연관지어볼 수도 있지 않을까 싶네요.

    2. 원래 ` 기호는 발음 구분 기호인 '악상 그라브(영어로 grave accent)'죠. 이걸 따옴표 대용으로 쓰는 건 개인적으로 부적당하고 보는데, 의외로 이런 경우가 많은 것 같습니다. 외국뿐만 아니라 한국 사이트에서도(뉴스 기사라든지) 자주 보이더군요. 그런데 이 경우 작은따옴표는 `와 '로 짝을 이루는데 큰따옴표는 짝을 이루지 못하기 때문에 일관성이 떨어지는 구분법이 아닌가 싶습니다.

    개인적 추측으로 타자기 시절에 악상그라브는 `로, 악상테귀는 '(´)로 쓰던 것이 현재의 키보드에까지 남아있는 것이 아닌가 싶긴 한데 확인할 길은 없네요.

    3. 세벌식은 큰따옴표는 여는 것과 닫는 것이 각각 있는데, 작은따옴표는 여닫이 구분이 없는 걸 보고 의아했던 적이 있습니다. 혹시 그렇게 된 유래를 아시는지요?

    1. 사무엘 2013/12/04 21:26 # M/D Permalink

      유익한 설명을 보충해 주셔서 고맙습니다.
      〃(ditto mark)는 모양이 좋은 정도가 아니라 아예 정말로 '상등'이라는 용도로 쓰라고 만든 글자이군요. 이걸 즐겨 써야겠습니다. ^^
      가로 줄표만 해도 길이와 용도별로 종류가 한두 가지가 아니지요.
      기호의 혼동, 그리고 관련 지식의 부족으로 인해 글꼴 자체가 잘못 만들어지는 경우도 적지 않아서 문제라고 들었습니다. 서체 디자이너 내부에서도 각성의 움직임이 있구요.

      세벌식 최종 글자판의 따옴표 배당 내력에 대해서는 저도 자세히 알지 못합니다. 그저 그러려니 하고 받아들였지요.

  4. ㅇㅅㅇ 2014/08/16 11:18 # M/D Reply Permalink

    3. 끝으로, 여는 따옴표의 다음에 등장하는 따옴표도 반드시 여는 따옴표이다. (여는 큰따음표 다음의 작은따옴표. 그리고 vice versa)

    이걸 위해서
    “',“‘
    "‘\"",‘“
    이걸 넣으셨는데, 실제로 해 보면 제대로 동작하지 않습니다.

  5. ㅇㅅㅇ 2014/08/16 11:26 # M/D Reply Permalink

    좀 연구해 봤는데, 처음에는 일단 일괄 치환에다가 다음 여섯 줄을 넣고 돌리고,
    "\n\"","\n“"
    "\n'","\n‘"
    " \""," “"
    " '"," ‘"
    ',’
    "\"",”

    그 다음에는 일괄 치환에 다음 네 줄을 넣고 반복 적용에 체크하고 돌리는 수밖에 없을 것 같습니다.
    “”,““
    “’,“‘
    ‘”,‘“
    ‘’,‘‘

  6. ㅇㅅㅇ 2014/08/16 15:32 # M/D Reply Permalink

    이 글에서는 여는 괄호 뒤의 따옴표를 고려하지 않고 있기도 해서, 보충해서 새 글을 썼습니다.
    http://chojogensho.tistory.com/2

    1. 사무엘 2014/08/16 18:53 # M/D Permalink

      음, 이 글은 올린 지 오래 돼서 저 규칙들의 세부 메커니즘이 기억이 나지는 않습니다만.. ^^
      보충 설명을 해 주셔서 고맙습니다.

Leave a comment

날개셋 한글 입력기 6.8

1. 6.8 버전의 의미

<날개셋> 한글 입력기 6.8이 나왔다. 2013년에 나온 최초의 버전이다.
사실 6.71과 6.8의 변화량은 6.7과 6.71 사이의 변화량보다도 적을지도 모른다.
새로운 기능이 추가된 게 없고, 양 버전 사이의 바이너리 호환성이 깨진 것도 없다.

그러나 6.71의 다음 버전을 6.72 대신 6.8로 잡은 것은, 이 버전에서 드디어 외부 모듈이 Windows 8 운영체제를 정식 지원하기 시작했기 때문이다. 비록 내 주변에 Win8 쓰는 사람은 아직 한 명도 못 봤지만..;;;

사용자 삽입 이미지

원래 계획은 6.7의 바로 다음 버전을 6.8로 하고 Win8을 바로 지원하는 프로그램을 만드는 것이었다.
하지만 여건상 그렇게는 못 하고 중간에 6.71을 거치게 됐다. 일단 Win8과 관련하여 편집기의 당장 급한 이슈만 해결하고, 더 근본적인 연구가 필요한 사항은 다음 버전의 숙제로 미룬 것이다.

6.71은 0.01만 올리기에는 해 놓은 게 많지만 그 내역이 딱히 존재감이 없다.
그 반면, 6.8은 절대적인 양은 0.09만 한 변화는 아니지만 그게 바로 'Windows 8 지원'이라는 존재감 큰 변화이다.
그래도 지금 두 버전의 변화 사항을 합하면 6.7 이후로 0.1쯤은 충분히 올릴 명분이 된다.

2. 수익 모델

이번 6.8 버전은 지금보다 더 이른 1월 중에 나올 수도 있었다.
그러나 본인의 직장 스케줄이 다소 바빠지고, 거기에다 투잡 같은 일종의 부업까지 뛰느라 한동안 <날개셋> 쪽으로 연구 개발을 전혀 할 수 없었던 관계로 프로그램의 완성이 늦어졌다. 시간이 없고 너무 힘들어서 이제 앞으로 투잡 같은 건 당분간 안 하련다.

투잡이라는 게 내가 생활고-_-에 시달려서 하는 건 아니고, 이게 그나마 <날개셋> 한글 입력기의 기술로 금전적인 이득을 얻는 통로라는 의미와 명분이 있어서 종종 해 왔다. 내 프로그램은 엔진 그 자체는 일반인을 대상으로 유료로 판매하는 상업용 소프트웨어가 아니고 심지어 광고 노출로 돈을 버는 것도 아닌데, 대회 상금이 아니면 이게 이윤을 창출해 온 유일한 방법이다.

별 게 아니라, 바로 <날개셋> 한글 입력기로 구현할 수 있는 입력 방식을 떼어서, 날개셋이라는 브랜드를 떼어내고 해당 코드만 최적화 static link하여 고객이 원하는 문자 입력 솔루션을 외주 개발하는 것이다. 물론 핵심 루틴은 빌드가 가능한 static library 형태로만 주고 소스 공개 안 한다.

세상에 날개셋 같은 완전 universal한 솔루션도 직접적인 수익 모델이 없으며, 표준 두벌식 다음으로 가장 인지도가 높고 구조적으로 우수한 공 병우 세벌식 같은 글자판조차도 만년 듣보잡 신세를 면치 못하고 있는데.. 한글 입력 방식 그 자체만으로 이제 무슨 사업을 하고 수익을 낼 게 있는지에 대해서는 한글 입력기의 개발자인 나조차도 회의적이다. 그래도 프로그램 만들면 개발비를 준다고 하고, 노력 대비 수지가 맞다고 여겨지니까 한다.. ^^

아무래도 일반적인 입력 방식은 레드 오션이 된 지 오래이니 진입할 틈새가 없고, 장애인용이나 동시치기 속기 같은 특수한 마이너 분야를 노려야 하지 않을까 싶다. 모바일이 아닌 PC용이라면 더욱 그러하다.

다만, 난 예전에도 공언했듯이 이미 소속된 직장이 있는 데다, 자체적으로 글꼴 연구도 해야 하고 나만의 연구 개발도 여전히 계속해야 하는데... 자꾸 외부에서 부탁하는 걸 받아서 하면 내가 자기 계발을 할 시간을 빼앗기기 때문에 이것도 큰 딜레마이다. 외부로 품팔이를 하지 않고 내가 하는 일만으로 경제적으로 자립할 수는 없을까? 이것도 점점 생각하지 않을 수가 없음을 느낀다. 정 답이 없으면 난 농담 반 진담 반으로 한 10년쯤 뒤엔 그냥 철도로 업종을 바꿔 있을 수도 있다. ㅋㅋ

3. Windows 8 이모저모

자, 암울한 돈 얘기는 그만 하고, 다음 주제인 Windows 8로 넘어가겠다. Windows 8에서는..

(1) 32비트 시절 이래로 전통적이던 관행을 깨고, 모든 프로그램이 동일한 입력기를 공유하는 설정이 추가되었으며 이것이 기본으로 적용되어 있다. 단, 옵션을 바꾸면 예전처럼 스레드별로 따로 놀게 할 수도 있다.

(2) active 입력기와 default 입력기의 구분이 없어졌다. 한 프로그램에서 입력기를 바꾸면(active) 그게 곧 default가 되며, 다음에 실행되는 프로그램은 그 입력기를 기본으로 사용하고 있다. 이것은 예전 Windows 버전처럼 동작하게 하는 옵션이 없으며, 그냥 개념을 저렇게 간소화시킨 듯하다.

(3) language bar(입력 도구모음줄)가 극도로 단순해졌다. 시스템 트레이에 '입력기 아이콘'과, 이 입력기의 '상태 아이콘'이라는 단 두 개의 아이콘만이 고정되어 나타나며, 나머지 자질구레한 기능들은 '상태 아이콘'을 우클릭했을 때 나타나는 메뉴를 통해 선택하게 되어 있다. 단, 옵션을 바꾸면 예전의 전통적인 길쭉하고 버튼 많은 language bar 방식을 쓸 수도 있긴 하다.

Win8의 디자인은 사실 TSF가 도입되기 전에 윈도우 95~ME가 사용하던 internat.exe 기반의 indicator 방식으로 되돌아 간 것이나 마찬가지이다. 그때도 IME 아이콘은 시스템 트레이에 입력기 아이콘과 상태 아이콘 둘만 있었기 때문이다. 디자인이 돌고 돌아 복고풍이 채택된 것 같다.

<날개셋> 한글 입력기 6.8은 이제 이 새로운 상태 아이콘을 지원한다. 이 아이콘은 우클릭을 하면 전체 기능을 선택하는 메뉴가 나오고 좌클릭을 하면 글자판(한/영 상태 같은)을 전환하는데, 글자판을 전환하는 규칙이 예전의 글자판 전환 버튼과는 살짝 다르다.

Windows 운영체제는 내부적으로 한글 아니면 영문이라는 이분법적인 구도로 자체 상태를 정의한다. 그러나 <날개셋> 한글 입력기 엔진은 임의의 n개의 입력 항목을 가질 수 있다. 그래서 기존 글자판 전환 버튼은 입력 항목이 딱 2개 존재할 때만 toggle 방식으로 동작하고, 3개 이상일 때는 메뉴를 표시하여 무슨 글자판을 지정할지 사용자가 직접 선택하게 했다.

하지만 Windows 8의 새로운 상태 표시 겸 글자판 전환 버튼은 동작 방식이 약간 다르다. 메뉴를 선택해야 하는 동작은 전적으로 우클릭이 전담한다. 그리고 좌클릭을 했을 때는 언제나 직전에 사용하던 non-trivial 글자판과 trivial 글자판만을 toggle 형태로 왔다 갔다 한다. trivial이란 '빈 입력 스키마', 또는 '빈 입력 스키마와 호환되게' 옵션이 지정되어 아무 글쇠도 처리하지 않는 '영문' 모드이고, non-trivial은 그렇지 않고 글쇠를 자체 처리하는 '한글' 모드에 대응하는 입력 항목이다. 실제로는 한글 이외의 다른 문자를 입력하더라도 말이다.

내가 살펴보니 기존 데스크톱 말고 메트로(Modern UI) 모드에서는 별도의 IME 툴바 같은 것 자체가 화면에 나타나지 않다 보니, 문자 입력란이 포커스를 받으면 IME가 자신의 한/영 모드를 근처에다 잠깐 표시했다가 사라지는 기능까지 제공하는가 보다. <날개셋>의 이번 버전은 그것까지는 구현하지 않았다. 일단 동작하는 것 그 자체에 의의를 두련다.

4. 다음 버전 계획

이번 6.8 버전은 <날개셋> 한글 입력기 6.x대의 마지막 버전을 염두에 두고 있다. 물론 Win8 지원과 관련해서 미흡한 부분이 또 발견되거나 사소한 기능 개선들의 양이 일정 수준을 넘어선다면 부득이 6.8x가 또 나와야겠지만, 새로운 기능이 추가된다거나 하면 반드시 7.0으로 갈 것이다.

그리고 혹시나 해서 말인데, Windows 8을 쓰고 있지 않다면 6.71하고 6.8이 아무 차이가 없느냐 하면 그건 물론 아니다. 예전 글에서 언급되었던 버그들이 고쳐졌다. 특히 6.71은 버그 때문에 사용자 정의 조합을 편집할 수가 없으니, 이 기능을 사용한다면 6.8로 업그레이드가 필수이다.

Win8 지원 작업이 완료되고 나면, 그 다음 버전은 다시 오랜 숙제로 남아 있는 입력 엔진 쪽의 기능 추가에 초점을 맞출 것이다.

  • 한자를 누르면 일반 한자 변환 모드가 되지만 Shift+한자를 누르면 사용자가 정의한 후보 리스트로 변환. 이를 위한 준비 작업은 이미 거의 5.x 버전 시절부터 해 놓았지 싶다. 한자 변환 명령을 4종류로 세분화했음.
  • 입력 패드 쪽으로 다양한 새로운 기능 추가
  • 임의의 글쇠뿐만 아니라 임의의 글쇠 동작까지 인식하는(동시치기, 길게 누르기 등등..!) '고급 입력 스키마' 완성

이게 다 갖춰지면 7.0 번호는 다 따 놓은 당상이리라.

5. 기타 잡설

(1) 세상에는 온갖 기괴한 한글 입력 방식이 존재한다. 그런 것들 중에는 정말 참신하고 의미 있는 발명인 것도 있다. 내부 메커니즘은 두벌식에 속하거나 세벌식에 속하거나 그 중간에 속할 수 있다.
그러나 공 병우 세벌식은 너무 직관적이고 평이하고 당연한 구조여서 딱히 튀는 게 없다. 그렇기 때문에 이건 다른 어떤 입력 방식보다도 더욱 의미 있고 fundamental한 발명이다.

세상에 기계간의 글자판 통일까지 염두에 두고서 사람 손으로도 이렇게 한글을 빠르고 편하게 잘 칠 수 있는 글자판은 공 병우 식 말고는 딱히 생각해 낼 수 없다. 한글교라는 종교가 있다면 이게 진짜 한글교의 핵심 교리 내지 이념이라 하지 않을 수 없다. 한글 입력기를 만든다면 이 방식부터 마스터를 한 뒤 더 복잡하고 편법이 필요한 물건으로 내려가는 게 순서일 것이다. 이것이 내가 예나 지금이나 공 병우 세벌식 덕후요 빠돌이인 이유이다.

(2) 텍스트 에디터라는 건 생각보다 굉장히 만들기 어려운 물건이다.
<날개셋> 편집기도 겉보기로는 시대에 너무 뒤떨어진 전/반각 비트맵 글꼴을 사용하고 있지만...
그 대신 MS Word 같은 다중 블록에다 세로쓰기도 지원하고, 다단계 undo까지 갖추고 있다.

또한 텍스트의 여러 군데가 동시다발적으로 변경되었을 때 필요한 부분만 문단을 다시 정돈하고, 딱 필요한 최소한의 구간만 화면을 업데이트하는 것은 <날개셋> 한글 입력기도 무려 6.x대 버전에 와서야 완벽한 구현체가 나왔을 정도이다. 타이포그래피 시스템을 그 정도로 제약하고 단순화하고도 절대로 호락호락 만들 수 있는 게 아니다.

하물며 텍스트 서식과 복잡한 유니코드 complex script를 지원하고, 장치 독립적인 레이아웃을 구현해야 하는 위지윅 워드 프로세서는 에디팅 엔진의 복잡도와 난해함이 어디까지 치솟을지 나조차도 선뜻 감을 못 잡겠다.

Posted by 사무엘

2013/02/10 19:32 2013/02/10 19:32
Response
No Trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/794

Trackback URL : http://moogi.new21.org/tc/trackback/794

Comments List

  1. Paul Sohn 2013/02/11 18:54 # M/D Reply Permalink

    공밀레 소리가 들려오는군요.

    1. 사무엘 2013/02/11 23:04 # M/D Permalink

      공밀레~~ 공밀레~~~ ㅜ.ㅜ

  2. likesam 2013/02/12 11:14 # M/D Reply Permalink

    항상 감사히 사용하고 있습니다.
    얼마전 부터 install할 때 후원관련 내용이 나오던데, 저도 2013년을 맞아 미뤄두었던 소액송금이라도 하여야 하겠네요.. ^^

    1. 사무엘 2013/02/12 17:24 # M/D Permalink

      특히 이번엔 Windows 8 사용자의 오랜 염원이 이뤄진 만큼 한글 입력에 많은 보탬과 도움이 되었으면 좋겠습니다.
      후원까지 해 주신다면 더욱 고맙습니다. ^^

  3. 비밀방문자 2013/02/14 22:29 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2013/02/15 13:33 # M/D Permalink

      감사합니다.
      말씀하신 이메일 주소로 신청서를 보내 드렸습니다.
      그런 실물이 있으면 나중에 매스컴 같은 데서 공개적으로 세벌식 글자판을 소개할 때도 도움이 되겠죠. ^^

  4. 사샤나즈 2013/03/24 21:50 # M/D Reply Permalink

    아직 모던앺(메트로) 환경이 제대로 지원되지는 않는 건가요? 이전 글에는 시험판에서 돌아가는 스크린샷이 있었는데, 실제로 모던앺에서 날개셋 입력기를 사용하려면 trivial-nontrivial 토글 메뉴 부분이 비어 버리면서 입력기의 처리가 안 되고 영문 쿼티만 입력되네요...
    이렇게요. http://sdrv.ms/Y82Qn0
    빈 부분을 클릭하면 이런 메시지가 떠요 (6.8인데도) http://sdrv.ms/WZLIQw

    예외적으로 모던 IE10의 주소창에서는 딱히 문제없이 작동하고, 모던 IE10으로 들어간 웹 페이지에서는 두벌식/쿼티만 사용 가능하네요...

    그래도 이전 버전은 모던앺에서 입력기 선택조차 불가능했던 것과 달리 모던앺에서도 입력기 선택이 가능하네요!

    사실 6.8 뜬 것 안 지도 며칠 안 됐고 깔고 나서 그냥 아직 안 되는 기능이구나 하다가 오늘에야 아래 1월 7일의 글을 읽고 혹시 사실은 버그가 아닌가 해서 올려 봐요.

    1. 사무엘 2013/03/25 00:36 # M/D Permalink

      말씀하신 증상은 프로그램의 업그레이드 혹은 삭제/설치가 제대로 되지 않아서 발생하는 현상입니다. 6.71보다 낮은 버전(가령 6.7이나 6.5 등)을 쓰고 있다가 6.8을 곧바로 설치하셨나요? 그리고 혹시 재부팅이 필요하다는 메시지가 떴는데 '아니요'를 누른 적은 없는지요?

      제가 Windows Installer의 특성을 제대로 모르기 때문에 어떻게 해야 정확하게 이런 식으로 버전이 꼬일 수 있는지는 알지 못하지만, 가끔 저런 식의 문의가 들어온 적이 있긴 합니다. <날개셋>을 사용하는 프로그램이 없는 상태에서 기본 입력기를 다른 걸로 바꾼 뒤, 현재의 날개셋 프로그램을 제거한 뒤 6.8을 clean install을 하실 것을 권합니다.

    2. 사샤나즈 2013/03/25 21:22 # M/D Permalink

      그게 OS를 아예 새로 설치한 직후에 날개셋 입력기 설치 파일이 없어서 새로 받아 설치한 거라 이전에 업그레이드하거나 하지는 않았어요. 그래도 말씀대로 재설치도 해 보고 복구 버튼도 눌러 보고 했는데 영 진전이 없네요...

      하다하다 안 돼서 아예 가상 머신에다 새로 설치했는데도 똑같은 증상이 나타나요 ㅠ_ㅠ

      사용 OS는 가상 머신까지 모두 윈도 8 엔터프라이즈 64비트예요.

    3. 사무엘 2013/03/27 06:08 # M/D Permalink

      저는 반대로 어떻게 해야 저런 상황을 만들 수 있는지를 영 모르겠네요.
      스크린샷의 IE는 데스크톱 앱이지 않습니까?
      데스크톱용 IE에서도 날개셋이 동작을 하는 부분과 안 하는 부분이 있다는 얘기인가요?
      제가 윈도 8의 기능이나 구조를 잘 모르는 걸수도 있으니 좀 더 자세한 설명을 부탁드립니다.

    4. 사샤나즈 2013/04/03 02:26 # M/D Permalink

      아 아, 그 쪽이 아니라 화면 왼쪽에 원노트를 끼워놓은 걸 보셔야 해요. 일부러 모던 앺에서 입력기를 쓰면서 태스크바에서 입력기 상태를 볼 수 있도록 모던 앺을 스냅 모드로 끼워 놓은 거예요. 스크린샷을 찍을 때 입력 포커스는 모던 앺인 원노트에 두었어요. 데스크탑 IE10에선 딱히 별 문제 없어요.

    5. 사무엘 2013/04/03 07:19 # M/D Permalink

      아, 이제 말씀하신 사항들을 모두 파악했습니다. Modern UI도 다 같은 UI가 아니군요.

      1. Microsoft 계정 로그인 입력란 + IE 10의 주소 입력란에서는 날개셋이 잘 동작합니다. 6.8 버전은 딱 이걸 기준으로만 만들어졌습니다.

      2. 그러나 IE 10의 웹 페이지 내부 입력란에서는 두벌식+영문만 동작하구요. (아마 권한이나 다른 문제 때문에 imeconf.dat 파일을 못 읽은 듯)

      3. 그리고 다른 입력란(Win8에 기본 내장돼 있는 프로그램만..) 중에서는 날씨+장소 추가 입력란을 들어가 보니, 날개셋을 고르면 영문만 입력되고 아마 이건 ngs3.dll 커널 자체를 로딩을 못 한 패닉 상태인 것 같습니다. 설마 디지털 서명 없다고 퇴짜 놓은 건가..

      상황 설명에 감사드립니다.
      안 되는 건 재연 가능한 구체적인 시나리오를 알려 주셔야 문제를 확인하고 고치든지 할 수 있지요.

    6. 사샤나즈 2013/04/04 02:28 # M/D Permalink

      Windows 8 and Windows Server 2012 Compatibility Cookbook : http://www.microsoft.com/en-us/download/details.aspx?id=27416

      이 문서에서
      'Third-party IMEs must be digitally signed' 라는 걸 보아 아마 그럴 것 같아요.

      이 문서의 Third-party input method editors 부분에서 윈도 8에서의 IME에 대한 요구사항 및 해결법들이 나와 있는데 아마 개발에 도움이 될 거예요!

Leave a comment
« Previous : 1 : ... 2 : 3 : 4 : 5 : 6 : 7 : 8 : 9 : 10 : ... 12 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/07   »
  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:
1219383
Today:
74
Yesterday:
531