토론:옛한글

마지막 의견: 5년 전 (InternetArchiveBot님) - 주제: 외부 링크 수정됨 (2019년 4월)

첫가끝 편집

은 자모 바탕 설치했는데도 파이어폭스로 보면 글이 잘 안 나옵니다. 메모장에는 아무 문제도 없으면서요. 독일바퀴 2006년 7월 17일 (월) 16:59 (KST)답변

위키백과토론:옛한글이 좀 더 해결에 적당한 장소일 것 같습니다. --Kjoonlee 2006년 7월 29일 (토) 15:00 (KST)답변

‘새’ 옛한글 편집

대한민국 산업자원부 기술표준원에서 새로운 옛한글 표준안을 만들었네요.[1] 이에 대해서 자세한 정보를 아시는 분 있나요? --Puzzlet Chung 2007년 11월 29일 (목) 17:29 (KST)답변

흥미로운 소식이네요. 어떤 방식인지, 또 유니코드 버전 몇부터 포함될 것인지 궁금합니다. 한 번 KATS 측에 문의해보는 것도 좋을 것 같네요. 조만간 저는 기말고사 끝나고 문자 코드에 관한 레포트를 써서 제출하려고 하는데, 그 전에 제가 직접 문의를 해보도록 하겠습니다. 뭐 다른 분들도 조사해 주시면 감사한 일이구요. ― Yes0song 2007년 12월 2일 (일) 01:21 (KST)답변
퍼즐릿 정 님의 질문과는 다소 다른 내용의 질의를 해서 답변을 받았습니다[2]. 그리고 기술표준원의 새로운 옛한글 표준안은 단순히 그 동안 유니코드에서 제공하지 않았던 자모들을 추가로 더 제공하는 모양입니다. 기술표준원 측에서 배포한 보도자료 내용, 그리고 제가 받은 답변 내용을 종합하여 글을 수정하도록 하겠습니다. ― Yes0song 2007년 12월 10일 (월) 17:51 (KST)답변

정규화 알고리즘 문제 편집

제가 알기로는 ‘듀ᇰ’(U+1103, U+1172, U+11F0)이 ‘듀ᇰ’(U+B4C0, U+11F0)으로 치환되는 것은 정규화 알고리즘의 버그가 아니라, 정상적인 처리방법이라고 알고 있습니다. 실제로 GNOME에서는 두 가지 모두 정상적으로 출력됩니다. 문제는 정규화 알고리즘이 아니라, 윈도우에서 두번째 방법을 제대로 처리하지 못하는 것이죠. --마소리스 2007년 12월 27일 (목) 16:49 (KST)답변

버그가 맞네요. 유니코드 5.1에서 수정한다고 합니다. --마소리스 2008년 1월 26일 (토) 16:14 (KST)답변
반가운 소식이네요. 어떠한 계기로 바뀌게 되는지 자세한 내용을 알 수 있을까요? --Puzzlet Chung 2008년 1월 29일 (화) 17:58 (KST)답변
KLDP에 관련글이 있습니다. 요약하자면, KS X 1026-1에서 새로운 옛한글 자모가 추가되고, 옛한글을 코드로 나타내는 방법이 확정지어져서, 올해 출시될 유니코드 5.1에 반영된다고 합니다. 하지만 아쉽게도, 옛한글 표준 자판이나, 글꼴은 아직 계획하고 있지 않다고 하더군요. --마소리스 2008년 1월 29일 (화) 18:37 (KST)답변

U+200D(ZERO WIDTH JOINER) 편집

유니코드 5.0 공식 문서[3]에서 Hangul Compatibility Jamo: U+3130–U+318F 부분을 보았는데, 아래와 같은 내용이 있었습니다.

Normalization. When Hangul compatibility jamo are transformed with a compatibility
normalization form, NFKD or NFKC, the characters are converted to the corresponding
conjoining jamo characters. Where the characters are intended to remain in separate sylla-
bles after such transformation, they may require separation from adjacent characters. This
separation can be achieved by inserting any non-Korean character.
* U+200B zero width space is recommended where the characters are to allow a line break.
* U+2060 word joiner can be used where the characters are not to break across lines.

옛한글의 정규화 알고리즘 버그를 막기위해 사용해야할 separation은 U+200D(ZERO WIDTH JOINER)이 아니라, U+2060(WORD JOINER)이 되어야 되는것 아닐까요? --마소리스 2008년 2월 12일 (화) 15:01 (KST)답변

Uniscribe의 버그? 편집

또한 이 글꼴들은 IE에서는 제대로 동작하지 않지만, 파이어폭스에서는 제대로 동작하는 것으로 보아 IE의 문제로 보인다.

이것은 Uniscribe의 버그일 가능성이 높습니다. 2006년도 최신 usp10.dll 역시 정규화(글꼴 랜더링엔진의 정규화) 관련문제가 있어서 GSUB feature가 내장된 한글 글꼴을 제대로 랜더링해주지 못합니다. WkPark (토론)

정규화의 두가지 편집

오해의 소지가 있어서 글을 씁니다. 한글 정규화는 두가지 다른 접근방법이 혼용되어 사용될 여지가 있는데

  • 코드의 정규화: 다중 초성 + 다중 중성 + 다중 종성 => 정의된 영역의 음절 대치 혹은 좀 더 간소화된 코드로 정규화하는 코드레벨의 정규화
  • 글꼴 랜더링할때 정규화: 텍스트를 글꼴 랜더링엔진을 통해서 정규화하는 과정. 텍스트 내의 코드와는 무관한 글꼴 엔진 내부에서의 정규화.

Uniscribe는 트루타입의 GSUB 랜더링 메카니즘의 해석기로 볼 수 있으며 Uniscribe가 텍스트의 정규화를 수행합니다. Uniscribe는 글꼴 랜더링엔진의 일부로 볼 수 있고, 입력받은 한글텍스트 코드를 정규화하는 것과 무관한 방식으로 내부에서 정규화를 수행하고 이를 글꼴 렌더링 엔진으로 적절히 보내는 역할을 합니다.

반면, 미디어위키의 한글텍스트 정규화는 *코드의 정규화*입니다. WkPark (토론) 2008년 5월 19일 (월) 06:06 (KST)답변

PUA 글꼴 및 기타 편집

이 문서는 상당히 오류가 많이 보이고 지협적인 문제로 점철되어 있습니다. 편집하려다가 포기하고 문제점을 몇개 지적합니다.

  1. PUA 코드를 직접 쓰면 안됩니다. PUA코드는 비표준입니다. 오피스 2003 이후부터는 이러한 비표준 PUA코드를 쓰지 않고 표준적인 트루타입 GSUB를 지원하는 글꼴을 쓰는 것으로 해결하였다고 합니다. 우리는 그냥 첫가끝코드를 쓰면 되보 글꼴은 유니스크리브가 알아서 모아주는 것이죠.
  2. 옛한글 자모에 관한 정보 역시 마찬가지.. 틀린정보 잘못된 정보 투성이... (이부분은 따로 편집을 해야 할 듯..
  3. 표준은 지키라고 만들어진 것입니다. 표준이 아닌 것은 절대로 쓰지 말아야 합니다. PUA코드를 첫가끝 코드르 바꿔주는 프로젝트가 KTUG에서 있었습니다. 링크는 나중에 추가하죠.

WkPark (토론) 2008년 5월 25일 (일) 22:32 (KST)답변

좋은 편집 감사드립니다. 그러나 personal use area는 personally use하라고 만든 것입니다. 이를 절대로 쓰면 안된다는 말은 사실이 아니며, 어떠한 PUA 규약(?)을 쓰는지 명시하고 공용(?) 문서에서 사용하는 것도 큰 문제는 되지 않는다고 생각합니다. 아무튼 백과사전은 가이드가 아니고 어떠한 사안에 대해 위키백과의 편집자들이 찬성하는지 반대하는지 알 수 없도록 글을 작성해야하므로 백:중립에 따라 문구를 수정하였습니다. --Kjoonlee 2008년 5월 27일 (화) 13:54 (KST)답변

PUA영역을 사용하는데는 원론적으로 문제가 없습니다. 지금 제가 지적하는 부분은 한양 PUA코드입니다. 이 코드 영역을 직접 사용하는 것이 문제입니다. 이렇게 되면 우리는 한양 PUA영역을 지원하는 글꼴을 반드시 사용해야 됩니다. 글꼴 종속적인 문서가 만들어지는 것이죠. 그래서 M$는 한양 PUA코드를 버렸습니다. 그리고 글꼴 종속적이지 않은 GSUB기술을 적용한 새로운 오피스 글꼴을 내놓은 것이지요. (이와 관련된 얘기는 unfonts-devel에 이미 언급되어 있으므로 아시리라 생각됩니다.) 제가 쓴 내용은 이미 표준인 첫가끝 코드가 존재하는데 한양 PUA코드를 쓸 이유가 전혀 없다는 것입니다. 개인적인 문서라면 얼마든지 가능합니다. 그걸 공용문서나 표준문서에 써야할 이유는 전혀 없습니다. 그리고 PUA영역은 Personal이 아니라 Private Use Area입니다. 글꼴 내부적으로 사용해야만 하는 영역입니다;; --WkPark (토론) 2008년 5월 27일 (화) 23:26 (KST)답변
호환성과 유용함을 위해 사용하는 사람도 있을 수 있습니다. en:MUFI 처럼요. De jure standard가 아니라 de facto standard가 있음을 인정하셔야 합니다. --Kjoonlee 2008년 5월 28일 (수) 21:53 (KST)답변

해도 되나 하면 안되나의 가치판단은 독자의 몫입니다. 이는 백과사전이 대신 해주어서는 안됩니다. --Kjoonlee 2008년 5월 28일 (수) 22:04 (KST)답변

일반적인 목적에서 일반 사용자가 PUA영역을 사용할 이유가 있나요? "표준"이라고 지칭하는 문서는 "표준"에 의거해서 작성되어야 합니다. 그 "표준"문서에선 PUA영역을 당연히 사용하면 안됩니다. 또 표준적으로 만들어야 할 소프트웨어에서 제멋대로 국가의 표준을 어기면서 PUA코드영역을 쓴것은 잘못된 것입니다. 그래서 M$도 스스로 자신의 잘못을 다행스럽게 돌이켰구요. 저 위에 제가 써놓은 얘기의 문맥을 오해하지 마세요. PUA 무조건 쓰지 말라는 그 얘기가 아니예요. WkPark (토론) 2009년 1월 12일 (월) 22:38 (KST)답변
en:MUFI의 경우 MUFI 표준을 MUFI PUA를 써서 만들고 있습니다. --Kjoonlee 2009년 1월 15일 (목) 08:30 (KST)답변

표준인 첫가끝 코드가 있는 이상 한양 PUA 코드는 안 쓰는 것이 맞다고 생각해요. 더 나은 것도 아니잖아요..? 위에서 이야기하셨듯이, 특별한 호환성 문제가 아니라면 모두 표준을 쓰는 것이 맞다고 봐요. --Cyberkagami (토론) 2010년 10월 9일 (토) 08:12 (KST)답변

채움문자 문제 편집

한양 PUA 코드의 경우, 초·중·종성 채움 문자를 각각 U+F784, U+F806, U+F86A으로 할당하고 있다.

한양PUA코드는 완성형 코드 방식입니다. 초/중/종 채움문자가 전혀 필요하지 않죠. 많약 쓸 이유가 있다면 첫가끝 코드의 채움문자를 그냥 사용하면 됩니다.

옛한글 자모 계열의 글꼴의 경우, 정확히 어떤 것이 채움 문자인지는 알려져 있지 않으나 추정 가능하다. 옛한글 자모 계열의 글꼴은 첫소리는 한 글자 당 6종류(ㄱ을 예로 들면 ‘가’의 ㄱ, ‘과’의 ㄱ, ‘고’의 ㄱ, ‘강’의 ㄱ, ‘광’의 ㄱ, ‘공’의 ㄱ)를, 가운뎃소리는 한 글자 당 2종류(ㅏ를 예로 들면 ‘가’의 ㅏ, ‘강’의 ㅏ)를, 끝소리는 한 글자 당 4종류를 할당하고 있다. 따라서 초·중·종성 채움 문자도 각각 6개, 2개, 4개가 된다는 것을 짐작할 수 있다. 이에 따라 초·중·종성 채움 문자는 각각 U+4E00~4E05, U+5100~U+5101, U+5200~U+5203이라고 생각된다.

이것은 넌센스입니다. 옛한글 자모 계열 글꼴은 한양 PUA코드 지원 글꼴과는 다르게 그 코드를 직접사용하라고 만든 글꼴이 전혀 아닙니다.
이 글꼴에 중간중간에 채움문자처럼 들어간 것은 글꼴을 디자이너가 글꼴 조합시 구현하기 쉽게 넣었을 가능성이 높습니다.

옛한글 자모 계열 글꼴 편집

한양정보통신에서는 한국어판 윈도 시리즈에 내장된 자사의 굴림·궁서·돋움·바탕, 굴림체·궁서체·돋움체·바탕체, 새굴림·새궁서·새돋움·새바탕에 대응되는 ‘옛한글 자모’ 계열의 글꼴을 만들어냈다. 그 글꼴들은 굴림 옛한글 자모·궁서 옛한글 자모·돋움 옛한글 자모·바탕 옛한글 자모이다. 위의 한양 PUA 코드와 달리 PUA 영역을 이용하지 않고 자체적인 코드 정렬을 하고 있다.

그 이유는 자모글꼴은 그 코드를 직접 쓰라고 만들어진 글꼴이 아니기 때문입니다. 이것의 코드 포인트를 PUA영역으로 옮긴 후에 GSUB를 넣게되면 첫가끝을 지원하는 표준적인 글꼴로 만들 수도 있습니다. 이미 2003년 즈음에 MS와 접촉을 했으나 별 소득을 얻지는 못했지만 그 결과물은 은바탕 옛한글지원을 위한 기술로 남게되었으며 은글꼴 차기버전은 표준적인 GSUB를 지원하게 될 것입니다.
이하의 내용은 넌센스입니다. --WkPark (토론) 2008년 5월 28일 (수) 18:23 (KST)답변

이 글꼴의 특징 중에 하나로 한글을 조합할 때 필요한 다양한 모양의 자소들을 제공하고 있다는 점을 들 수 있다. 예를 들어 첫소리 ㄱ은 6종류의 형태가 있다(‘가’의 ㄱ, ‘과’의 ㄱ, ‘고’의 ㄱ, ‘강’의 ㄱ, ‘광’의 ㄱ, ‘공’의 ㄱ). 이들 자소는 한양 PUA에서 사용된 자소가 모두 포함돼 있다.

이 글꼴은 유니코드의 한중일 통합 한자 영역의 상단 일부(첫소리: U+4E06~U+50ED, 가운뎃소리: U+5102~U+51BD, 종성: U+5204~U+5437; 채움 문자는 여기서 제외)를 임의로 사용하고 있어, 기존 글꼴의 한자와 충돌한다는 문제점이 있다.

이 글꼴을 이용하여 《훈민정음》 언해본의 첫 구절을 쓰면 다음과 같다.

틀:옛자모

이 글꼴로 옛한글을 쓰는 것이 가능하기는 하지만 입력하기 어렵고, 이것으로 작성된 문서는 전체 용량이 커진다는 단점이 있다. 한양 PUA 코드에서는 완성된 형태의 글자 외의 글자는 U+F784~U+F8F7 영역의 자소들을 이용해 합성하도록 하고 있어, 이들 글자들은 정사각형 형태의 글자 모양을 완전히 유지하지 못하는 단점을 이미 위에서 언급했다. 이 옛한글 자모 글꼴은 이 ‘단점’을 굳이 보완하고자 할 때에 한해서만 사용이 적합하다.

코드 정규화 문제 편집

미디어 위키 어플 의존적인 문제로 점철되어 있으므로 아예 토론으로 돌립니다.

이하 인용:

유니코드 콘소시엄에서는 정규화(normalization) 알고리즘을 제정하고 있다. 이것은 미디어위키 등에서 사용되고 있다.

그런데 현재의 정규화 알고리즘에는 첫가끝 코드에 치명적인 버그가 있다. 예컨대 ‘듀’(U+1103, U+1172)는 이 알고리즘을 거치면 ‘듀’(U+B4C0)로 치환이 되는데, 문제는 이 뒤에 옛한글 종성이 붙을 경우이다. 예컨대 ‘듀ᇰ’(U+1103, U+1172, U+11F0)은 따로 완성형 한글 음절이 없으므로 치환을 하면 안 된다. 그런데 정규화 알고리즘에서는 이것을 인지하지 못하고 ‘듀’만 따로 ‘듀’로 치환, ‘듀ᇰ’(U+B4C0, U+11F0; 즉 듀+ᅟᅠᇰ)의 잘못된 형태로 바꾸어 버린다. 위키백과를 구동하는 미디어위키에서도 같은 버그가 발생한다.

이 버그는 유니코드 5.1에서 수정될 예정이다.

한국어 위키백과에서는 이 버그를 피하기 위해 편집자들이 다음과 같은 몇 가지 방법을 사용하고 있다. 듀ᇰ을 예로 든다.

  1. 가운뎃소리를 문자 참조(character entity reference)로 대체한다.
    • 예: ᄃᅠᅲᅟᅠᇰ
  2. 첫소리와 가운뎃소리 사이에 <nowiki></nowiki>를 집어 넣는다.
    • 예: ᄃᅠ<nowiki></nowiki>ᅟᅲᅟᅠᇰ
  3. {{첫가끝}} 틀에서 제공하는 회피법(첫소리와 가운뎃소리 사이에 | 삽입)을 사용한다.
    • 예: {{첫가끝|ᄃᅠ|ᅟᅲᅟᅠᇰ}}
  4. 첫소리와 가운뎃소리 사이에 U+200D(ZERO WIDTH JOINER)를 첨가한다.
    • 예: ᄃᅠ&#x200D;ᅟᅲᅟᅠᇰ

위 방법 중 4번은 한글 조합과 관계 없는 다른 문자(ZERO WIDTH JOINER)를 더하게 되어 표준적인 음절을 만들어 낼 수 없다는 문제가 있다.


인용 끝

정규화라는 것이 그 자세한 알고리즘까지 언급한 것은 아니라고 볼때 미디어위키만의 문제라고 생각됩니다. 유니코드 5.1에서 수정될 문제도 아닐 것 같군요. --WkPark (토론) 2008년 5월 28일 (수) 18:23 (KST)답변

자모 조합 편집

본문에서 L+V+T*를 허용한다고만 했는데, 자모 조합을 할 때 L*이나 V*도 허용되나요? 토론 중간엔 다중 초성/중성 이야기도 있어서 좀 헛갈리게 되네요. --Cyberkagami (토론) 2010년 7월 17일 (토) 16:30 (KST)답변

ᄇᄉ툐ᅡᅵᆸᆺᆮ 같은 것도 되는 걸 보니 허용되나 봐요. --Cyberkagami (토론) 2010년 8월 7일 (토) 06:51 (KST)답변

외부 링크 수정됨 (2018년 11월) 편집

안녕하세요 편집자 여러분,

옛한글에서 3개의 링크를 수정했습니다. 제 편집을 검토해 주세요. 질문이 있거나, 봇이 이 문서나 링크를 무시하기를 바라신다면 간단한 자주 묻는 질문에서 더 많은 정보를 찾아보세요. 다음 변경사항을 적용했습니다:

봇의 문제를 수정하는 것에 관해서는 자주 묻는 질문을 참조해 주세요.

감사합니다.—InternetArchiveBot (버그를 제보하기) 2018년 11월 8일 (목) 23:48 (KST)답변

외부 링크 수정됨 (2018년 11월) 편집

안녕하세요 편집자 여러분,

옛한글에서 1개의 링크를 수정했습니다. 제 편집을 검토해 주세요. 질문이 있거나, 봇이 이 문서나 링크를 무시하기를 바라신다면 간단한 자주 묻는 질문에서 더 많은 정보를 찾아보세요. 다음 변경사항을 적용했습니다:

봇의 문제를 수정하는 것에 관해서는 자주 묻는 질문을 참조해 주세요.

감사합니다.—InternetArchiveBot (버그를 제보하기) 2018년 11월 25일 (일) 07:13 (KST)답변

외부 링크 수정됨 (2019년 4월) 편집

안녕하세요 편집자 여러분,

옛한글에서 1개의 링크를 수정했습니다. 제 편집을 검토해 주세요. 질문이 있거나, 봇이 이 문서나 링크를 무시하기를 바라신다면 간단한 자주 묻는 질문에서 더 많은 정보를 찾아보세요. 다음 변경사항을 적용했습니다:

봇의 문제를 수정하는 것에 관해서는 자주 묻는 질문을 참조해 주세요.

감사합니다.—InternetArchiveBot (버그를 제보하기) 2019년 4월 14일 (일) 22:49 (KST)답변

"옛한글" 문서로 돌아갑니다.