노무현 대통령 배너
BLOG main image
왕미친놈의 왕미친세상입니다. 미친 소리는 써도 되지만, 근거 없는 소리는 쓰면 안 됩니다.


AcroEdit는 가끔 옛한글이 포함된 문서를 사용자의 동의 없이 수정하는 버그를 갖고 있습니다. 오래전에 발견했지만 줄곧 다른 버그 리포팅에 밀려 있던 벌레를 다시 발견했습니다. 나중에 올려야지 하다 보니 깜빡 잊고 있었죠.

  • 참고 : 이 문서는 많은 그림을 포함하고 있어서 읽어오는 데 오래 걸릴 수도 있습니다. 느긋하게 기다려 주십시오.

벌레의 유형

불러온 파일의 원형을 유지하지 못하게 만드는 벌레입니다. 이 벌레는 추가적인 다른 벌레를 발생시키고 있습니다.

아크로에디트에서 편집한 뒤에 뭉개진 글자 - ᄒᆞᆫ

아크로에디트에서 편집한 뒤에 뭉개진 글자 - ᄒᆞᆫ

개발자의 답변

2010년 2월 22일 버그 리포팅을 한 상태입니다.

벌레의 발견

옛한글을 텍스트 편집기에서 시험하다가 발견했습니다.(옛한글과 텍스트 편집기 참고) 그런데 그때 올리지 않았더니 오랫동안 기억 속에 묻혀 버렸습니다.

이 벌레는 파일 내용을 제멋대로 바꾸어서 사람을 화딱지 나게 만드는 벌레입니다. 크게 두 경우가 있습니다. 한 경우는 클립보드로 붙이기, 다른 한 경우는 파일을 불러왔다가 저장하기입니다.

클립보드에서 붙이기

예제 코드는 다음 문장입니다.

[code html] <span class="jamocomposed_block" style="font-family: '돋움 옛한글','Dotum Old Hangul','바탕 옛한글','Batang Old Hangul','궁서 옛한글','Gungsuh Old Hangul','굴림 옛한글','NewGulim Old Hangul','은 자모 바탕 확장','Un Jamo Batang Ex','UnJamoBatangEx','은 자모 바탕','Un Jamo Batang','UnJamoBatang','은 바탕','Un Batang','UnBatang',Code2002,Code2001,Code2000,serif; font-size: 105%;">ᄒᆞᆫ말ᄊᆞ미 듀ᇰ귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ</span> [/code]

위 내용을 텍스트 파일로 저장하면 536바이트가 됩니다. 이 htm 파일은 utf-8로 인코딩되어 있습니다.

시험용 파일 Test-1.htm : 536바이트

시험용 파일 Test-1.htm : 536바이트

위 파일을 메모장에서 열면 아래와 같습니다.

메모장에서 본 내용

메모장에서 본 내용

이상태에서 그대로 복사하여 티스토리에 편집창의 HTML 모드에서 붙여넣기를 하였습니다. 테스트 블로그에 있는 문서입니다.

옛한글이 잘 나타난 화면

옛한글이 잘 나타난 화면

그냥 Test-1.htm 파일을 파이어폭스에서 보면 다음과 같습니다.

잘 보이는 옛한글

잘 보이는 옛한글

위 그림에서 보이는 내용을 소스 보기 하면 다음과 같습니다.

소스 보기 : Test-1.htm

소스 보기 : Test-1.htm

위 소스 보기 화면에서 내용을 복사하여 아크로에디트에 붙여넣기를 하였습니다.

처참하게 깨져 버린 옛한글

처참하게 깨져 버린 옛한글

참고로 저 상태에서 utf-8로 저장하면 491바이트가 됩니다.

시험용 파일 Test-2.htm : 491바이트

시험용 파일 Test-2.htm : 491바이트

원인은 알 수 없지만 용량이 줄어 버렸습니다. 물론 파일 내용도 바뀌었습니다.

메모장에서 본 내용 그림에 나타난 소스를 복사하여 아크로에디트에 복사하였습니다.

메모장의 내용을 아크로에디트로 복사하여 붙여넣기를 한 다음 저장한 화면

메모장의 내용을 아크로에디트로 복사하여 붙여넣기를 한 다음 저장한 화면

그런데 겉보기에는 아무런 이상이 없지만, 아무튼 이번에도 이상한 점이 발견되었습니다.

시험용 파일 Test-3.htm : 533바이트

시험용 파일 Test-3.htm : 533바이트

원본은 분명히 536바이트였는데, 지금은 533바이트입니다. 겨우 3바이트이지만, 내용이 바뀌었습니다.

옛한글을 제대로 나타내지 못하는 화면

옛한글을 제대로 나타내지 못하는 화면

어찌된 일인지 아크로에디트로 저장한 Test-3.htm 파일은 옛한글을 제대로 나타내지 못하고 있습니다. 앞서 나타난 옛한글이 깨지는 결과는 파이어폭스의 문제라고 생각할 수도 있으나, 지금 이 결과는 아크로에디트의 문제로 봐야 할 듯싶습니다.

파일을 불러왔다가 저장하기

클립보드는 복사되는 과정에서 변형이 일어날 수 있다는 의혹도 제기할 수 있습니다. 그래서 아예 파일을 직접 읽어오기로 했습니다.

메모장에서 본 내용 : 536바이트

메모장에서 본 내용 : 536바이트

위 내용을 아크로에디트에서 직접 불러오겠습니다. 불러오기에 앞서 메모장을 닫습니다. 이것은 혹시나 메모장에서 간섭이 생길 수도 있기 때문입니다.

아크로에디트에서 Test-1.htm 파일 불러오기

아크로에디트에서 Test-1.htm 파일 불러오기


아크로에디트에서 Test-1.htm 파일을 불러온 화면

아크로에디트에서 Test-1.htm 파일을 불러온 화면

위 그림은 앞서 나온 메모장의 내용을 아크로에디트로 복사하여 붙여넣기를 한 다음 저장한 화면 그림과 매우 비슷합니다. 이것을 Test-4.htm 파일로 저장했습니다.

아크로에디트에서 Test-1.htm 파일을 Test-4.htm 파일로 저장

아크로에디트에서 Test-1.htm 파일을 Test-4.htm 파일로 저장

Test-1.htm 파일과 Test-4.htm 파일은 모두 536바이트입니다. 그러면 이것을 파이어폭스에서 보면 어떻게 될까요?

Test-4.htm 파일은 미스테리를 담은 파일??

Test-4.htm 파일은 미스테리를 담은 파일??

편집도 않고 그냥 불러들였다가 다른 이름으로 저장만 했을 뿐인데 왜 이런 일이 생기는지 알 수 없었습니다.

아크로디프 프로그램에서 파일 비교

Test-1.htm 파일과 Test-4.htm 파일을 비교해 보겠습니다.

HxD 프로그램에서 비교한 Test-1.htm 파일과 Test-4.htm 파일

HxD 프로그램에서 비교한 Test-1.htm 파일과 Test-4.htm 파일

Test-1.htm 파일과 Test-4.htm 파일은 확실하게 다른 점이 있습니다. 원본인 Test-1.htm 파일을 아크로에디트에서 불러와서 아무런 수정도 없이 Test-4.htm 파일로 저장하기만 했을 뿐인데, 1바이트가 변형되어 있습니다.

이 두 파일을 아크로에디트에서 비교하면 어떻게 될까요? 정확하게는 AcroDiff(아크로디프)에서 비교하면 어떻게 될까요? AcroDiff 프로그램은는 파일 비교를 해 주는 유틸리티로서 아크로에디트에 포함되어 있습니다. 일종의 헬퍼 프로그램이죠.

AcroDiff(아크로디프) 프로그램 실행 화면

AcroDiff(아크로디프) 프로그램 실행 화면

여기에서 빨간 네모 표시를 클릭하여 파일을 왼쪽 창에 불러올 수 있습니다.

AcroDiff 프로그램에서 파일 불러오기

AcroDiff 프로그램에서 왼쪽 창에 파일 불러오기


AcroDiff 프로그램에서 왼쪽 창에 파일을 불러온 화면.

AcroDiff 프로그램에서 왼쪽 창에 파일을 불러온 화면. 이 상태에서는 내용은 나타내 주지 않습니다.

위 그림에서 파일 내용은 나타내 주지 않습니다. 파일 내용이 안 나타난다고 당황하지 마시기 바랍니다. 위 화면에서 빨간 네모 부분을 클릭하여 오른쪽 창에도 파일을 불러옵니다.

AcroDiff 프로그램에서 오른쪽 창에도 파일을 불러온 화면.

AcroDiff 프로그램에서 오른쪽 창에도 파일을 불러온 화면. 이 상태에서는 내용은 나타내 주지 않습니다.

오른쪽 창도 내용이 나타나지 않습니다. 이 화면에서 비교 실행(빨간 네모)을 클릭하여 파일 비교를 합니다.

두 창의 내용을 비교한 화면

두 창의 내용을 비교한 화면

놀랍게도 AcroDiff는 두 파일의 다른 점을 찾아내지 못하고 있습니다. 이로써 아크로에디트의 저장 과정이 아니라 불러오기에서 문제가 생김을 추측해 볼 수 있습니다.

벌레의 원인

벌레의 원인은 알 수 없었습니다. 다만 한글 깨짐 현상이 있습니다 문서와 관련이 있으리라 추측해 봅니다. 또한 아크로디프 프로그램에서 파일 비교 항목에서 보이듯이, 저장 과정에서 문제가 생긴 것이 아니라 파일을 불러왔을 때 파일 내용이 이미 변형되었으리라 추측할 수 있습니다.

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다. 다음 두 벌레는 ᄒᆞᆫ자의 화면 표시와 관련한 버그를 소개하고 있습니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

유니코드 지원이란?

우리가 흔히 "프로그램이 유니코드를 지원한다"라고 말할 때는 그 프로그램이 유니코드를 나타낼 수 있느냐가 아니라, 그 프로그램의 메뉴나 오류 메시지를 표현하는 코드 페이지가 유니코드이냐를 뜻합니다. 당연한 말이겠지만, 그 프로그램에서 유니코드 문자를 입력할 수 있는지는 전혀 고려하지 않습니다.

이때 프로그램 메뉴나 오류 메시지를 유니코드로 나타내는 경우에 네이티브로 유니코드를 지원한다는 표현을 사용하기도 합니다.

유니코드 출력

그렇다면 유니코드를 지원하는 프로그램만 유니코드를 올바르게 나타낼 수 있을까요? 유니코드를 지원하지 않는 프로그램은 유니코드를 올바르게 나타낼 수 없을까요? 그렇지는 않습니다. 유니코드 지원과 유니코드 표현은 아무런 관련도 없습니다. 아, 관련이 있기는 합니다. 특정 코드 페이지를 지원하는 프로그램은 그 코드 페이지에 해당하는 문자를 나타내기가 좀 더 쉽습니다.

그렇지만 그 둘 사이의 관계가 절대적이지는 않습니다. 화면 표시는 그저 화면 표시일 뿐 그 이상의 것이 아니기 때문입니다. 물론 텍스트 편집 프로그램의 경우에는 화면 표시가 매우 중요한 요소이지만, 실제 프로그램의 실행과는 별로 관련이 없습니다.

좀 더 전문적인 용어를 써서 말한다면, 유니코드 출력은 문자 인코딩(Character encoding)의 문제이고, 유니코드 지원은 문자 집합(Character set)의 문제입니다.

유니코드를 지원하지 않는 프로그램의 유니코드 출력 예시

CLCL

멀티 클립보드 프로그램인 CLCL은 유니코드를 지원하지 않는 프로그램, 곧 지원하는 문자 집합이 유니코드가 아닙니다. 그러나 클립보드 지원 프로그램이기 때문에 클립보드에 복사한 내용 가운데 유니코드가 있을 경우 그것을 잘 출력해 줍니다. 물론 이 경우 폰트가 잘 지원되어야 하지만, 그에 대해서는 논외로 합니다. 한편 CLCL도 유니코드 출력이 기본 기능은 아닙니다. 추가적인 DLL 파일이 필요하지만, 그것만 설치한다면 아무 문제 없이 유니코드 출력이 가능합니다. 더구나 그 DLL 파일이 유니코드를 네이티브로 지원하지도 않습니다.

예시 1 : 유니코드를 잘 나타내는 CLCL

예시 1 : 유니코드를 잘 나타내는 CLCL


예시 2 : 유니코드를 뭉개져 버린 CLCL

예시 2 : 유니코드를 뭉개져 버린 CLCL


위 두 화면은 유니코드를 CLCL이 어떻게 나타내는지를 보여주고 있습니다. 예시 1은 기본 출력인데, 현재 유니코드로 설정한 상태입니다. 기본값은 TEXT입니다. 예시 2TEXT일 때의 화면 출력을 보여 주고 있습니다. 게다가 예시 1예시 2는 현재 화면에 보이는 상태 그대로 붙여넣기가 가능합니다. 다시 말해 화면 출력과 프로그램의 유니코드 지원이 별 상관이 없다는 뜻이지요.

Notepad++

좀 더 확실하게 보여줄 필요가 있다면, 텍스트 편집기 가운데 유니코드 버전과 ANSI 버전을 함께 제공하는 프로그램을 선택하면 됩니다. 대표적인 프로그램이 바로 Notepad++입니다.

메모장의 유니코드 출력 - 옛한글은 한국어 영역이 아닌 유니코드 영역에 있다.

예시 3 : 메모장의 유니코드 출력 - 옛한글은 한국어 영역이 아닌 유니코드 영역에 있다.


Notepad++ ANSI 버전의 유니코드 출력

예시 4 : Notepad++ ANSI 버전의 유니코드 출력


Notepad++ 유니코드 버전의 유니코드 출력

예시 5 : Notepad++ 유니코드 버전의 유니코드 출력


위의 세 그림은 유니코드 버전이냐는 사실과 유니코드를 출력할 수 있느냐는 사실과는 관련이 적음을 보여주고 있습니다. 유니코드를 출력할 수 있느냐는 오로지 프로그램이 유니코드 폰트 및 유니코드 합자를 지원하는 알고리듬을 가지고 있느냐에 좌우됩니다.

관련 문서

 

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 30 - "Haansoft PDF"의 성능은?

ᄒᆞᆫ글2010 베타버전에서 출력한 PDF 파일을 살펴보다가 이상한 점을 발견하여 한컴오피스2010 베타버전의 PDF 출력 버그 라는 글을 올렸습니다. 이 글은 그 글의 후속편입니다.

  • 참고 1 : 이 글은 매우 많은 그림을 포함하고 있어서 읽어오는 데 시간이 오래 걸릴 수도 있습니다. 느긋하게 기다려 주십시오.
  • 참고 2 : 이 글에서 사용한 PDF 파일 및 문서 파일을 압축 파일로 제공합니다. PDF-Output.zip 파일(1.31 MB)을 받으세요.

벌레의 유형

ᄒᆞᆫ글 씨! Haansoft PDF 가상 프린터는 그저 겉모양만 만들면 되는 게 아니랍니다.

개발자의 답변

이 글은 버그 리포팅을 하지 않았습니다. 지난 번 버그 리포팅으로 충분하다고 여겼기 때문입니다.

벌레의 발견

벌레는 한컴오피스2010 베타버전의 PDF 출력 버그 글을 작성하면서 발견했습니다. 그 글을 작성하면서 복사&붙여넣기도 시험했는데, 처음에는 모두 실패했습니다. 그래서 옛한글이 들어 있는 PDF 파일의 내용을 복사할 수 없는 벌레라는 글을 준비하였습니다. 그런데 그게 아니라는 사실이 밝혀져서 실험을 중심으로 바꾸었습니다.

사용할 프로그램 : PDF 보기 프로그램

참고로 이 실험에 쓰인 PDF 파일은 모두 PDF-Output.zip 파일(1.31 MB)에 들어 있습니다.

배점 기준 및 평가 방법

본의 아니게 PDF 보기 프로그램의 성능 테스트를 하게 되었습니다. 하는 김에 확실하게 점수도 매기기로 했습니다.

  • 항목별 최하점은 0점이고, 최고점은 5점입니다.
  • 우선 4글자로 모두 정상 출력하면, 5점을 줍니다.
    • 출력한 글자가 1글자 비정상 출력하면 감점 1점하는 방식입니다.
    • 출력한 글자가 1글자 이상이라도 일치하는 글자가 없으면 0점입니다.

배점 기준 및 평가는 지극히 주관적이며, 다른 사람이 하면 다른 점수가 나올 수 있습니다.

복사한 뒤에 메모장에 붙여넣기를 합니다. 메모장의 글꼴 서식은 함초롬바탕 12포인트 보통 형태입니다.

메모장에 붙여넣기를 한 뒤의 모습

메모장에 붙여넣기를 한 뒤의 모습

검증 1 : Adobe Reader

Adobe Reader에서의 복사 화면

Adobe Reader에서의 복사 화면

파일명 복사 전 복사 & 붙여넣기 점수
HWP2010-to-PDF-CutePDF.pdf
3
HWP2010-to-PDF-ezPDF.pdf
3
HWP2010-to-PDF-Foxit.pdf
3
HWP2010-to-PDF-Haansoft-PDF.pdf
3
HWP2010-to-PDF-PDF로_저장.pdf
3
HWP2010-to-PDF-PDFCreator.pdf
0
HWP2010-to-PDF-PDF-Pro.pdf
3
OpenOffice-to-PDF-CutePDF.pdf
5
OpenOffice-to-PDF-ezPDF.pdf
5
OpenOffice-to-PDF-Foxit.pdf
5
OpenOffice-to-PDF-Haansoft-PDF.pdf
5
OpenOffice-to-PDF-PDF로_내보내기.pdf
5
OpenOffice-to-PDF-PDFCreator.pdf
3
OpenOffice-to-PDF-PDF-Pro.pdf
5
HCell-to-PDF-Haansoft-PDF.pdf
3
HCell-to-PDF-PDF로_저장.pdf
3
HShow-to-PDF-Haansoft-PDF.pdf
(없음) 0
HShow-to-PDF-PDF로_저장.pdf
(없음) 0
- - 57

검증 2 : Foxit Reader

Foxit Reader에서의 복사 화면

Foxit Reader에서의 복사 화면

아울러 이제부터는 복사 전 그림은 뺍니다. 똑같은 거 또 넣어봐야 시간 낭비라고 생각해서리...

파일명 복사 & 붙여넣기 점수
HWP2010-to-PDF-CutePDF.pdf
3
HWP2010-to-PDF-ezPDF.pdf
3
HWP2010-to-PDF-Foxit.pdf
3
HWP2010-to-PDF-Haansoft-PDF.pdf
3
HWP2010-to-PDF-PDF로_저장.pdf
3
HWP2010-to-PDF-PDFCreator.pdf
0
HWP2010-to-PDF-PDF-Pro.pdf
3
OpenOffice-to-PDF-CutePDF.pdf
3
OpenOffice-to-PDF-ezPDF.pdf
5
OpenOffice-to-PDF-Foxit.pdf
3
OpenOffice-to-PDF-Haansoft-PDF.pdf
3
OpenOffice-to-PDF-PDF로_내보내기.pdf
3
OpenOffice-to-PDF-PDFCreator.pdf
0
OpenOffice-to-PDF-PDF-Pro.pdf
3
HCell-to-PDF-Haansoft-PDF.pdf
3
HCell-to-PDF-PDF로_저장.pdf
3
HShow-to-PDF-Haansoft-PDF.pdf (없음) 0
HShow-to-PDF-PDF로_저장.pdf (없음) 0
- 44

검증 3 : UNIDOCS ezPDF Reader

UNIDOCS ezPDF Reader에서의 복사 화면

UNIDOCS ezPDF Reader에서의 복사 화면

파일명 복사 & 붙여넣기 점수
HWP2010-to-PDF-CutePDF.pdf
3
HWP2010-to-PDF-ezPDF.pdf
3
HWP2010-to-PDF-Foxit.pdf
3
HWP2010-to-PDF-Haansoft-PDF.pdf
3
HWP2010-to-PDF-PDF로_저장.pdf
3
HWP2010-to-PDF-PDFCreator.pdf (없음) 0
HWP2010-to-PDF-PDF-Pro.pdf (없음) 0
OpenOffice-to-PDF-CutePDF.pdf
5
OpenOffice-to-PDF-ezPDF.pdf
5
OpenOffice-to-PDF-Foxit.pdf
5
OpenOffice-to-PDF-Haansoft-PDF.pdf
5
OpenOffice-to-PDF-PDF로_내보내기.pdf
5
OpenOffice-to-PDF-PDFCreator.pdf
3
OpenOffice-to-PDF-PDF-Pro.pdf
3
HCell-to-PDF-Haansoft-PDF.pdf
3
HCell-to-PDF-PDF로_저장.pdf
3
HShow-to-PDF-Haansoft-PDF.pdf (없음) 0
HShow-to-PDF-PDF로_저장.pdf (없음) 0
- 52

검증 4 : ePapyrus PDF-Pro 4 Free

ePapyrus PDF-Pro 4 Free에서의 복사 화면

ePapyrus PDF-Pro 4 Free에서의 복사 화면

파일명 복사 & 붙여넣기 점수
HWP2010-to-PDF-CutePDF.pdf
3
HWP2010-to-PDF-ezPDF.pdf
3
HWP2010-to-PDF-Foxit.pdf (없음) 0
HWP2010-to-PDF-Haansoft-PDF.pdf
3
HWP2010-to-PDF-PDF로_저장.pdf
3
HWP2010-to-PDF-PDFCreator.pdf
0
HWP2010-to-PDF-PDF-Pro.pdf (없음) 0
OpenOffice-to-PDF-CutePDF.pdf
3
OpenOffice-to-PDF-ezPDF.pdf
3
OpenOffice-to-PDF-Foxit.pdf
3
OpenOffice-to-PDF-Haansoft-PDF.pdf
3
OpenOffice-to-PDF-PDF로_내보내기.pdf
3
OpenOffice-to-PDF-PDFCreator.pdf
0
OpenOffice-to-PDF-PDF-Pro.pdf
3
HCell-to-PDF-Haansoft-PDF.pdf
3
HCell-to-PDF-PDF로_저장.pdf
0
HShow-to-PDF-Haansoft-PDF.pdf (없음) 0
HShow-to-PDF-PDF로_저장.pdf (없음) 0
- 33

PDF 보기 프로그램별 결과 및 분석

일단 분석에 들어가기에 앞서 위의 표에서 (없음)으로 표시된 부분은 복사할 수 없거나 복사 결과 공백만 복사된 경우, 또는 처음부터 선택이 되지 않는 경우입니다.

프로그램 옛한글 복사 성공 횟수 점수
Adobe Reader 6 57
Foxit Reader 1 44
UNIDOCS ezPDF Reader 5 52
ePapyrus PDF-Pro 4 Free 0 33

개인적으로 이 결과는 매우 마음에 들지 않습니다. 지금까지 너무 무거워서 사용하지 않았던 Adobe Reader는 성능 면에서 최고의 결과를 보이며, 옛한글 복사 성공 횟수와 배점에서 최고점을 기록하였고, 가볍고 빨라서 자주 쓰던 ePapyrus PDF-Pro 4 Free단 하나의 옛한글도 제대로 복사하지 못하는 최악의 결과를 보여주었습니다. 게다가 Foxit Reader의 경우는 매우 이해하기 힘든 결과였습니다. 나름대로 유니코드 지원 등을 내세운 새 버전의 제품임에도 옛한글과 관련하여 이런 결과를 보였다는 말은 다른 유니코드도 별로 다르지 않으리라는 예상이 가능하기 때문입니다. 특히 Foxit Reader 및 ePapyrus PDF-Pro 4 Free는 옛한글이 제대로 복사되지 않았고, 심지어 영역 설정도 되지 않은 때가 있어서 한 글자 한 글자 따로 영역을 지정하여 복사해야 하는 경우도 있었습니다. 옛한글과 유니코드를 자주 다룬다면 절대로 Foxit Reader 및 ePapyrus PDF-Pro 4 Free, 이 두 제품을 사용하지 않기를 바랍니다.

한편 PDF 가상 프린터 가운데 최고 점수를 받은 제품은 UNIDOCS ezPDF Builder 2006 Free입니다. 솔직히 이 실험을 하기 전에는 그런 회사 및 제품이 있다는 사실조차 몰랐습니다. 아무튼 좋은 점수를 받은 그 제품을 알게 되어 다행입니다.

제가 Adobe Acrobat을 구하지 못해서 시험하지 못했습니다. 혹시나 구할 수 있다면 대신 시험을 해 주실 분은 실험하신 뒤에 댓글을 좀 남겨 주십시오.

벌레 분석 및 덧붙이는 말

원래 이 실험을 하게 된 까닭은, 앞서 밝혔듯이, 우연히 복사&붙여넣기를 했는데, 아주 엉뚱하게 되었기 때문입니다. 그래서 PDF 보기 프로그램의 성능 테스트 겸 가상 프린터의 성능 테스트를 하게 되었습니다.

옛한글 및 유니코드와 관련하여, PDF 가상 프린터 가운데 가장 성능이 좋은 것은 UNIDOCS ezPDF Builder 2006 Free이며, Haansoft PDF도 그다지 나쁘지 않은 성능을 보였습니다. 8개 제품 가운데 공동 2위를 하였으니까요. 다만 기이하게도 ᄒᆞᆫ글과 함께 쓰면 오히려 결과가 좋지 않습니다.

또한 옛한글과 유니코드를 자주 쓴다면 Foxit Reader 및 ePapyrus PDF-Pro 4 Free는 쓰지 않는 것이 좋을 듯싶습니다.

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다.

관련 문서

내부 문서

외부 문서

PDF 보기 프로그램

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 29 - 옛한글이 포함된 파일의 PDF 출력 버그

ᄒᆞᆫ글2010 베타버전에서 출력한 PDF 파일을 살펴보다가 이상한 점을 발견했습니다. 그래서 PDF 파일 출력에 대한 사항을 살펴보게 되었습니다. 매번 느끼지만 옛한글과 얽히면 판도라 상자처럼 온갖 악(벌레)이 튀어나옵니다. 특별히 이번 포스팅은 놈팡이 백수가 드리는 일요스페셜 또는 월요일 선물이라고 생각하시면 됩니다.

  • 참고 1 : 이 글은 매우 많은 그림을 포함하고 있어서 읽어오는 데 시간이 오래 걸릴 수도 있습니다. 느긋하게 기다려 주십시오.
  • 참고 2 : 이 글에서 사용한 그림과 출력한 PDF 파일 및 문서 파일을 압축 파일로 제공합니다. PDF-Output.zip 파일(1.31 MB)을 받으세요.

벌레의 유형

ᄒᆞᆫ글 씨! 옛한글을 화면에 잘 나타내면 끝이 아닙니다. 화면 출력뿐만 아니라 프린트 출력이나 PDF 출력도 잘 나타내 주어야 합니다.

개발자의 답변

2010년 2월 1일 버그 리포팅을 한 상태입니다.

벌레의 발견

ᄒᆞᆫ글에서 올바르게 나타나는 옛한글

ᄒᆞᆫ글에서 올바르게 나타나는 옛한글


PDF 파일에서 해괴하게 바뀐 옛한글 - 이건 어느 프로그램에서 출력했을까요?

PDF 파일에서 해괴하게 바뀐 옛한글 - 이건 어느 프로그램에서 출력했을까요?

사용할 프로그램

오피스웨어 프로그램

  • 한컴오피스2010 베타버전 : 처음에는 ᄒᆞᆫ글만 시험
  • OpenOffice Writer v3.1.1 : Writer만 시험

PDF 제작 프로그램

위에서 PostScript?라는 부분은 gsdll32.dll 파일을 발견하였기 때문에 표시하였습니다.

PDF 보기 프로그램

검증 1 : ᄒᆞᆫ글에서 출력하기

ᄒᆞᆫ글에서 프린트 - PDF 출력

ᄒᆞᆫ글에서 프린트 - PDF 출력

위와 같이 인쇄 화면을 불러 PDF로 출력하는 가상 프린터를 선택하여 [인쇄] 단추를 클릭하면 만들 수 있습니다.

PDF를 지원하는 가상 프린터 1

PDF를 지원하는 가상 프린터 1


PDF를 지원하는 가상 프린터 2

PDF를 지원하는 가상 프린터 2

위의 그림 가운데 Microsoft XPS 부분과 PC-000의 Samsung ML-1610 부분은 PDF 출력 가상 프린터가 아닙니다.

혹시 시험해 보고 싶은 사람은 프로그램마다 파일로 출력하는 방식이 다르므로 각자 프로그램 설명서를 참조하여 출력하기 바랍니다. 이 글에서는 다루지 않습니다.

각각의 PDF 출력 프로그램을 이용하여 PDF 파일을 만들었습니다. 이것을 PDF 보기 프로그램을 살펴보겠습니다.

  • 알파벳 순서로 시험했으므로 첫 번째 파일 또는 이상이 있는 파일만 나타내겠습니다.
  • 출력 품질 자체는 비교하지 않습니다.
  • 복사 작업은 평가하지 않습니다. PDF 출력의 경우 옛한글을 정상적으로 복사할 수 없었습니다.

Adobe Reader

012

ePapyrus PDF-Pro 4 Free

012

Foxit Reader

이미 결론이 난 듯하죠? 하지만 ᄒᆞᆫ글만큼은 끝까지 해보겠습니다.

012

UNIDOCS ezPDF Reader

012

결론 1

한컴오피스2010 베타버전에서 제공하는 Haansoft PDF 가상 프린터의 출력과 PDF로 저장하기 기능으로 저장한 PDF 파일에서는 옛한글이 제대로 나타나지 않았습니다.

검증 2 : 오픈오피스에서 출력하기

오픈오피스에서도 한컴오피스2010 베타버전에서 제공하는 Haansoft PDF 가상 프린터의 출력 기능이 작동합니다. 또한 오픈오피스에도 PDF로 내보내기 기능이 존재합니다.

오픈오피스의 예제 글귀

오픈오피스의 예제 글귀

앞서 올린 글에서 밝혔듯이 함초롬 글꼴은 ᄒᆞᆫ글에서만 예쁘게 나옵니다.

0123456

결론 2

위 그림과 같이 오픈오피스에서 출력한 PDF 파일은, 비록 그 겉모습은 예쁘지 않았지만, 단 하나의 오류도 나타내지 않았습니다. 심지어 한글과컴퓨터사에서 제공하는 Haansoft PDF 가상 프린터에서도 정상 출력하였습니다.

검증 3 : ᄒᆞᆫ셀과 ᄒᆞᆫ쇼에서 출력하기

지금까지 PDF 보기 프로그램에 따라 화면 출력 결과가 다르지 않았기 때문에 이제부터는 어도비 리더만 보이겠습니다. 또한 다른 PDF 가상 프린터는 제외하고, 한글과컴퓨터에서 제공하는 두 기능만 사용하겠습니다.

ᄒᆞᆫ셀은 흉칙한 모양을 보여줍니다.

ᄒᆞᆫ셀은 흉칙한 모양을 보여줍니다.


ᄒᆞᆫ셀은 흉칙한 모양을 보여줍니다.

ᄒᆞᆫ셀은 또다시 흉칙한 모양을 보여줍니다.


ᄒᆞᆫ쇼는 예쁜 모양을 보여줍니다.

ᄒᆞᆫ쇼는 예쁜 모양을 보여줍니다.


ᄒᆞᆫ쇼는 예쁜 모양을 보여줍니다.

ᄒᆞᆫ쇼는 예쁜 모양을 보여줍니다.

벌레 분석 및 덧붙이는 말

처음 이 벌레를 발견했을 때 Haansoft PDF 또는 PDF로 저장하기 기능에서 오류가 있다고 생각했습니다. 그런데 실험을 해 본 결과 그 두 기능보다는 한컴오피스의 출력 기능에 벌레가 사는 듯싶습니다.

이번 글을 작성하면서 발견한 벌레입니다. 벌레에도 급과 격이 있음을 보여주는 엄청난 놈입니다. ᄒᆞᆫ글2010 베타버전과 옛한글 표기 오류에서 발견한 벌레는 애송이였습니다. 이 벌레야말로 압권입니다.

모가지가 떨어진

모가지가 떨어진

위의 벌레는 ᄒᆞᆫ글 ᄒᆞᆫ글이라는 글귀를 입력한 뒤에 실수로 스페이스바를 계속 누르고 있어서 발견한 벌레입니다. 본문 작성하면서 단순노동[각주:1]에 짜증도 나고 했는데, 이걸 발견한 순간 헛웃음이 나오면서 짜증이 사라지더군요. 저는 별수없이 남의 불행을 먹고 사는 버그 리포터인가 봅니다. "혹시 나 변태?"라는 걱정도 들더군요.

본문에서 사용한 PDF 파일의 섬네일 이미지도 첨부해 봅니다.

모두 18개의 섬네일 이미지

모두 18개의 섬네일 이미지

장장 이틀간(준비까지 사흘간) 작성한 포스팅을 마치겠습니다. 2월에도 기운 내서 힘 차게 잘 지내시기 바랍니다. ^.^b

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다.

관련 문서

내부 문서

외부 문서

PDF 제작 프로그램

PDF 보기 프로그램

이 글은 스프링노트에서 작성되었습니다.


  1. 프린트를 수십 번 하고, 그것을 다시 문서 보기 프로그램으로 열었습니다. 그 작업을 하다 보면 그게 왜 단순노동인지 뼈저리게 느끼게 됩니다. 거기에 더하여 스크린샷도 그만큼 찍어서 편집하고 웹에 올리는 작업을 해 보면, 못 느끼면 목석이지 사람이 아닙니다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전과 함초롬 글꼴의 모양

한컴오피스2010 베타버전에서 추가된 글꼴인 함초롬체는 매우 예쁩니다. 그런데 진짜로 예쁜지, 아니면 ᄒᆞᆫ글에서 예쁘게 표현한 것인지 궁금하였습니다.

벌레의 유형

ᄒᆞᆫ글 씨! 이것이 버그인지 아닌지 알쏭달쏭합니다. 답변 좀 해 주세요.

개발자의 답변

2010년 1월 31일 버그 리포팅이 아닌 문의를 한 상태입니다.

벌레의 발견

여러 프로그램에서 함초롬 글꼴을 72포인트로 나타내 보았습니다.

한컴오피스 ᄒᆞᆫ글2010 베타버전에 나타난 함초롬 글꼴

한컴오피스 ᄒᆞᆫ글2010 베타버전에 나타난 함초롬 글꼴


한컴오피스 ᄒᆞᆫ셀2010 베타버전에 나타난 함초롬 글꼴

한컴오피스 ᄒᆞᆫ셀2010 베타버전에 나타난 함초롬 글꼴


한컴오피스 ᄒᆞᆫ쇼2010 베타버전에 나타난 함초롬 글꼴

한컴오피스 ᄒᆞᆫ쇼2010 베타버전에 나타난 함초롬 글꼴


오픈오피스 Writer 3.1.1 버전에 나타난 함초롬 글꼴

오픈오피스 Writer 3.1.1 버전에 나타난 함초롬 글꼴


Microsoft 엑셀 뷰어에 나타난 함초롬 글꼴

Microsoft 엑셀 뷰어에 나타난 함초롬 글꼴


메모장에 나타난 함초롬 글꼴

메모장에 나타난 함초롬 글꼴


파이어폭스에 나타난 함초롬 글꼴

파이어폭스에 나타난 함초롬 글꼴


인터넷 익스플로러 6에 나타난 함초롬 글꼴

인터넷 익스플로러 6에 나타난 함초롬 글꼴

벌레 분석 및 덧붙이는 말

함초롬 글꼴은 한컴오피스에서는 예쁘게 보였지만 다른 오피스나 응용 프로그램에서는 그다지 예쁘지 않습니다. 함초롬 글꼴을 웹페이지에 적용하려던 계획은 중단해야 할 듯싶습니다. 블로그에 함초롬 글꼴을 사용하기 힘들다는 사실이 슬플 뿐입니다.

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다.

관련 문서

어째 갈수록 내용보다는 관련 문서(참조 문서)가 더 많은 듯하네요. ^^;;

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 28 - 유니코드 버그 4 및 글꼴 (표기) 버그 2
- 옛한글 합자와 일반 글자는 다른가요?
- 왜 옛한글은 무조건 함초롬체로 표시하나요?

ᄒᆞᆫ글2010 베타버전에서 옛한글을 한양PUA가 아닌 유니코드 한글 자모 영역을 이용하여 나타내 주고 있습니다. 이는 대단히 좋은 현상입니다. 그런데 조금 이상한 현상을 발견했습니다. 이런 이상한 현상을 접하면 접할수록 옛한글과 얽힌 녀석은 판도라 상자라는 생각이 새록새록 솟아납니다.

벌레의 유형

ᄒᆞᆫ글 씨! 옛한글의 자모 합자는 일반 글자로 취급해야 합니다. 절대 일반 글자처럼 취급하면 안 됩니다. 그리고 왜 옛한글은 무조건 함초롬체로 표시해 버리나요? 함초롬체가 아닌 다른 글꼴을 사용할 수 있는 옵션을 추가해 주면 좋겠습니다.

개발자의 답변

2010년 1월 30일 버그 리포팅을 한 상태입니다.

벌레의 발견

ᄒᆞᆫ글2010 베타버전에서 은 글꼴을 적용하다가 발견했습니다.

예시 1 : 깨끗하게 나타난 옛한글과 글귀

예시 1 : 깨끗하게 나타난 옛한글과 글귀


예시 2 : 무언가 어긋난 옛한글

예시 2 : 무언가 어긋난 옛한글

위 예시 그림 두 개를 살펴보면 여러 가지가 다릅니다.

  1. 맨 먼저 옛한글의 모양이 확연하게 다릅니다. 한쪽으로 기울어져 있는데, 굳이 검증이 필요 없어 보입니다.
  2. 옛한글의 글자 외형이 현대 한글의 글자 외형과 달라 보입니다. 서로 다른 글꼴처럼 보입니다.
  3. 글자의 자간이 다릅니다. 그러나 이것은 문단 배열과 관련한 워드프로세서의 기능이므로 논외로 합니다.

일단 위 세 가지 다른 점을 발견했습니다. 3번은 벌레가 아니므로 논하지 않겠습니다.

검증 1 : 기울어진 옛한글

예제 1 잘라내기 예제 2 잘라내기

기울어진 옛한글 문제는 근본적으로 옛한글이 화면에 보이는 모양과는 달리 한글 1자가 아니라 한글 낱자 3개이기 때문에 발생한 문제입니다. 다만 그 합자 처리가 매끄럽지 못하기 때문에 발생한 벌레이지요.

그런데 저것이 한글 낱자 3개라는 사실이 이해가 안 된다면 다음 메모장 화면을 보시기 바랍니다.

예시 3 : 메모장에서 72포인트 굴림 글꼴로 나타낸 ᄒᆞᆫ글

예시 3 : 메모장에서 72포인트 굴림 글꼴로 나타낸 ᄒᆞᆫ글


예시 4 : 메모장에서 72포인트 굴림 옛한글 글꼴로 나타낸 ᄒᆞᆫ글

예시 4 : 메모장에서 72포인트 굴림 옛한글 글꼴로 나타낸 ᄒᆞᆫ글

위의 예시 3예시 4는 단지 글꼴을 바꾸었을 뿐인데, 화면에 보이는 모양이 달라졌습니다. 이는 한글 낱자 3개를 하나로 합쳐서 보여주는 기능을 가진 글꼴인지, 아니면 그저 이미 완성된 글자만을 보여주는 글꼴인지에 따라 이처럼 다른 결과를 보여줍니다.

그런데 문제는 이러한 낱자를 합자 처리한 그 결과물은 1문자처럼 처리하는 게 아니라 1문자로서 처리해야 한다는 점입니다. ᄒᆞᆫ글2010 베타버전에서 예시 1의 경우에 옛한글의 자모 합자를 1문자로서 처리했다면 문단 정렬에 따른 자간이 변하더라도 그 장폭이 그대로 유지되었을 것입니다. 그러나 그저 겉보기에만 1문자처럼 처리했기 때문에 문단 정렬에 따른 자간 변화에 대응하여 각각의 낱자가 각각 1글자로써 작용하여 각각 자간을 넓혔기 때문에 예시 2와 같이 왼쪽 위에서 오른쪽 아래로 기울어진 형태를 가지게 되었으리라 여겨집니다.

재미있는 점은 키보드 방향키로 커서를 옮겨 보면 옛한글의 한글 낱자 사이를 이동하지 않고, 옛한글을 1글자로서 인식합니다.

검증 2 : 옛한글의 글꼴

먼저 은 바탕 글꼴로 ᄒᆞᆫ글을 나타내면 다음과 같습니다.

예시 5 : 메모장에서 72포인트 은 바탕 글꼴로 나타낸 ᄒᆞᆫ글

예시 5 : 메모장에서 72포인트 은 바탕 글꼴로 나타낸 ᄒᆞᆫ글

이 모양은 확실히 예시 1의 모양과 다릅니다.

글꼴 외양 비교 1 글꼴 외양 비교 2

위 그림 두 개를 살펴보면 첫 번째 그림에 나타난 글꼴은 순서대로 함초롬바탕, 함초롬돋움 각각 1글자, 은 바탕 2글자이며, 두번째 그림은 달랑 1글자로 은 바탕 글꼴입니다. 이때 두 그림 모두 빨간 동그라미연두 동그라미로 표시한 부분이 차이가 납니다. 게다가 예시 1의 글자는 함초롬바탕의 글자와 매우 비슷합니다.

아마도 ᄒᆞᆫ글2010 베타버전에서는 옛한글을 무조건 함초롬 글꼴로 나타내도록 했나 봅니다. 한글과컴퓨터사에서 옛한글을 잘 나타내도록 열심히 노력했음을 보여주는 대목입니다. 그런데 그게 반드시 좋을까요? 아니라고 생각합니다. 예시 4굴림 옛한글 글꼴은 새굴림 글꼴을 바탕으로 만들었기 때문에 상당히 좋은 품질을 보여줍니다. 이런 글꼴의 경우에도 함초롬 글꼴로 나타낸다? 저는 그것을 바라지 않는데요. 적어도 환경 설정이나 사용자 설정에서 사용자가 결정할 수 있는 기회를 주었어야 한다고 생각합니다. 또한 글자 모양에서 경우에 따라서 옛한글을 강제로 함초롬으로 나타내거나 강제로 함초롬을 적용하지 않는 옵션이 주어져야 함은 당연하고요.

벌레 분석 및 덧붙이는 말

벌레에 대한 분석은 이미 했으므로 간단히 요약하겠습니다.

  1. 문단 정렬과 관련하여 옛한글의 한글 자모 합자를 1글자로서 처리해야 글자가 기울어지는 버그가 안 생긴다고 생각합니다.
  2. 옛한글을 표시할 글꼴을 사용자가 선택할 수 있어야 합니다. 또한 때에 따라서는 기본 글꼴(함초롬 글꼴)을 적용할 수도 있어야 하고요.

제가 버그 2를 보면서 문득 생각난 것이 표현의 자유입니다. 옛한글을 나타내는 것은 표현의 자유에 관한 사항입니다. 그런데 그 때문에 함초롬 글꼴만 사용해야 한다면, 그것은 표현의 자유를 위해 표현의 자유를 억압하는 꼴입니다. 저는 그런 반쪽짜리 표현의 자유보다 진정한 표현의 자유가 더 좋답니다.

1월 31일에 오후에 궁극의 벌레를 다시 발견했습니다. 스크린샷을 첨부합니다.

환골탈태급 벌레! 누가 저것을 한 글자라고 여길까요?

궁극의 환골탈태급 벌레!

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 27 - 유니코드 버그 3 및 글꼴 버그 1 - Unicode Full Set 지원??

ᄒᆞᆫ글2010 베타버전에서는 Unicode Full Set을 지원한다고 밝히고 있습니다. 자세한 사항은 한컴오피스2010 오픈베타 홈페이지에 있는 기능 설명서를 다운로드하여 읽어보기 바랍니다. 그런데 이때 Unicode Full Set은 무엇을 뜻할까요? 2009년 10월 1일 발표한 최신 유니코드 5.2일까요? 그게 아니라면 2008년에 발표한 유니코드 5.1? 2006년 발표한 5.0? 그게 아니면…? 저는 적어도 유니코드 5.0은 지원하리라 생각했습니다. 왜냐하면 한컴오피스2007이라는 제품이 있었기 때문입니다. 그런데 아니더군요. ᄒᆞᆫ글2010 베타버전유니코드 4.1도 제대로 지원하지 않았습니다.

벌레의 유형

ᄒᆞᆫ글 씨! ᄒᆞᆫ글에서 지원한다는 유니코드 버전 좀 알려주면 덧납니까? 사용자가 ᄒᆞᆫ글 프로그램에서 지원하는 유니코드 버전을 알기 위해 그 고생을 하도록 합니까?

개발자의 답변

2010년 1월 28일 버그 리포팅을 한 상태입니다.

벌레의 발견

일단 나는 한글 자모 영역만을 살펴보고는 ᄒᆞᆫ글2010한컴오피스2010 베타에서 유니코드 5.2 또는 유니코드 5.1을 지원한다고 믿고 말았다. 조금만 더 신경을 썼더라면 전혀 그렇지 않음을 알았을 텐데, 지금 생각하면 참 어리석었습니다.

유니코드 지원이란?

유니코드 지원은 크게 두 가지로 나뉩니다. 하나는 유니코드 코드표를 지원한다는 뜻입니다. 다른 하나는 유니코드를 화면에 나타낼 수 있게 한다는 뜻이지요. 워드프로세서를 제외한 오피스 프로그램이라면 당연히 코드표만 지원하면 완벽한 지원으로 볼 수 있습니다. 그러나 워드프로세서는 사정이 다릅니다. 코드표로는 아무런 의미도 없기 때문입니다. 워드프로세서란 문서를 실제로 출력해 주어야만 그 기능이 완성된다는 점에서 보면 ᄒᆞᆫ글2010은 유니코드를 제대로 지원하지 못하고 있습니다.

'한컴오피스의 유니코드 지원'을 말한 사람은?

이런 헛소문을 퍼뜨린 사람이 누구인지를 검색해 보았습니다. 검색하다가 보니 제 블로그가 상당히 많이 눈에 띄더군요. 헛!

각설하고 우선 한글과컴퓨터 한컴오피스2010 오픈베타 홈페이지에서 그 헛소리를 발견했습니다. 오호 애재라!

Unicode Full Set 지원? 정말??

Unicode Full Set 지원? 정말??

저처럼 눈 나쁜 사람을 위해 그 부분만 잘랐습니다.

저처럼 눈 나쁜 사람을 위해 그 부분만 잘랐습니다.

함초롬돋움과 함초롬바탕 글꼴이 가독성과 미려함이 좋습니다. 하지만 Unicode Full Set을 지원하지는 않습니다. 검증은 아래에서 하기로 하고 다른 웹페이지도 살펴보죠.

베타뉴스한컴오피스 2010 Beta 설명에서도 Unicode Full Set을 지원한다고 그러네요.

베타뉴스에 나타난 Unicode Full Set을 지원 글귀

베타뉴스에 나타난 Unicode Full Set을 지원 글귀

조금 다른 기사도 있습니다. 이투데이한컴, 오피스시장 점유율 20%에 도전한다라는 기사인데, 여기에 유니코드 글꼴에 대한 내용이 나옵니다.

함초롬체를 직접 언급한 이투데이 기사

함초롬체를 직접 언급한 이투데이 기사

이렇게까지 언론에서 말할 정도라면… 애초에 Unicode Full Set 지원을 말한 사람은 한글과컴퓨터사라는 뜻이겠죠? 더구나 유니코드를 지원하는 글꼴은 한컴오피스2010 베타에서 새롭게 제공하는 함초롬체라는 뜻이고요. 그렇지 않습니까?

'한컴오피스의 유니코드 지원'은 Unicode Full Set일까?

'한컴오피스의 유니코드 지원'은 Unicode Full Set일까요? 유감스럽게도 최신 버전은 아닙니다. 다시 말해 유니코드 5.2Full Set으로 지원하지는 않는다는 뜻입니다.

이것은 위키백과의 한컴 2바이트 코드 문서에 나타난 사항을 검증하면서 발견하였습니다(ᄒᆞᆫ글2010 베타버전과 유니코드 버그 1 및 문자표 버그 1 참조). 그 글에서 밝혔듯이, 이 문자표와 관련한 사항은 또 다른 판도라 상자였습니다.

위키백과의 한컴 2바이트 코드 문서에서 틀린 점을 발견했는데, 그 부분 덕분에 이 버그를 발견하게 되었습니다.

위키백과의 한컴 2바이트 코드 문서의 마지막 부분

위키백과의 한컴 2바이트 코드 문서의 마지막 부분

위 화면에서 빨간색 네모로 묶은 부분은 틀린 내용입니다. 그래서 [출처 필요]라는 출처를 요구하는 태그가 붙어 있습니다(제가 붙였습니다. ^.^v). U+470C의 한자는 䜌이며, 이것은 유니코드 5.2에서 옳은 표기입니다. 여기에서 중요한 부분은 또 다른 유니코드 번호인 U+9FBB와 그 아래에 파란 밑줄 부분입니다. U+9FBB에 해당하는 한자가 나타나지 않았는데, 이는 화면 글꼴인 굴림 글꼴에 저 번호에 해당하는 글자가 없기 때문입니다. 다르게 말하면, 아니 조금 심하게 말하면, 굴림 글꼴은 유니코드를 제대로 지원하지 못하는 글꼴이라는 말이 됩니다. 그렇다면 ᄒᆞᆫ글은 저것을 잘 나타낼까요? 파란 밑줄 부분이 사실이라면 저 한자는 나타낼 수 없습니다.

일단 유니코드 문자표는 없나요? 문서에서 부수별 한자 색인 목록이 있는 PDF 파일(RSIndex.pdf 파일)을 아도비 리더에서 불러오겠습니다.

어도비 리더에서 불러온 부수 색인 파일 136쪽의 400% 확대 화면

어도비 리더에서 불러온 부수 색인 파일 136쪽의 400% 확대 화면

그런데 U+470C 문자와 U+9FBB 문자가 서로 모양이 같습니다. 다만 U+9FBB가 지나치게 위로 치우쳐 있습니다. 이런 경우는 저 문자가 실제로 문자로 쓰이는 게 아니라, 다른 문자의 일부로써 쓰일 때 주로 나타나는 현상입니다.

실제 문자표 파일(CodeCharts-MulticolHan.pdf 파일)에서는 어떻게 나타나는지 살펴봅시다.

어도비 리더에서 불러온 한자 파일 747쪽 제1단의 200% 확대 화면

어도비 리더에서 불러온 한자 파일 747쪽 제1단의 200% 확대 화면

U+9FBB가 지나치게 위로 배치되어 있습니다. 그런데 그 앞에 나온 문자들도 만만치 않습니다. 위로 치우치거나 왼쪽으로 치우쳐 있습니다. 이 말은 이 문자들이 정상적인 글자로 쓰이지 않고 다른 용도로 쓰인다는 추측을 가능하게 합니다. 이는 곧 위키백과의 한컴 2바이트 코드 문서의 마지막 부분 그림에 나타난 빨간 네모 안의 내용이 틀렸다는 근거이기도 하지요.

이제 앞서 언급한 ᄒᆞᆫ글이 저 문자를 잘 나타내는지를 살펴보겠습니다. 위키백과의 한컴 2바이트 코드 문서의 마지막 부분 그림의 파란 밑줄 부분이 사실이라면 저 한자는 나타낼 수 없고, 그것이 거짓이라면 나타낼 수 있어야 합니다.

문자표를 불러 유니코드 문자표 탭에서 9FBB를 찾습니다.

ᄒᆞᆫ글2010의 문자표에서 나타나지 않은 U+9FBB 코드 포인트

ᄒᆞᆫ글2010의 문자표에서 나타나지 않은 U+9FBB 코드 포인트

ᄒᆞᆫ글2010의 문자표는 코드 포인트 U+9FBB에 해당하는 글자를 나타내지 못하고 있습니다.
이때 코드 포인트는 흔히 코드 값으로 부르는 것의 정식 명칭인데, 유니코드에서 다른 글자와 겹치지 않는 그 글자만의 고유값을 가리킵니다. 현재까지 유니코드에 배정된 코드 포인트는 모두 111만4112개입니다.

단순히 글꼴에서 표시해 주지 못할 뿐이라는 생각도 할 수 있습니다. 하지만 저 문자표의 글꼴은 현재 커서가 놓인 곳의 글꼴을 따르게 되어 있습니다. 그리고 지금 커서가 놓인 곳은 글꼴은 함초롬돋움 글꼴입니다.

현재 글꼴은 함초롬돋움

현재 글꼴은 함초롬돋움

아, 함초롬돋움함초롬바탕은 다를 수 있다고요? 그럼 바꿔 보겠습니다.

현재 글꼴은 함초롬바탕

현재 글꼴은 함초롬바탕


글꼴은 바뀌어도 U+9FBB 코드 포인트의 글자는 나타나지 않습니다.

글꼴은 바뀌어도 U+9FBB 코드 포인트의 글자는 나타나지 않습니다.

그렇다면 다른 글꼴도 시험해 보겠습니다. 유명한 셰어웨어 유니코드 글꼴Code2000로 바꾸겠습니다. 물론 함초롬체도 유니코드 글꼴입니다.

한글이 밉게 나와서 자주 쓰지 않는 Code2000 글꼴

한글이 밉게 나와서 자주 쓰지 않는 Code2000 글꼴

참고로 저는 아직 Code2000 라이선스를 갖고 있지 않습니다. 다시 말해 비등록 사용자인 셈이지요. 이 글을 쓰기 위해 다운로드해서 설치했습니다.

Code2000 글꼴로 바꾼 뒤 잘 나타나는 코드 포인트 U+9FBB의 글자

Code2000 글꼴로 바꾼 뒤 잘 나타나는 코드 포인트 U+9FBB의 글자

위 그림에서 자주색 테두리를 친 부분은 유니코드 4.1에서 추가된 부분입니다. 다시 말해 2005년 3월 31일에 이미 유니코드 표준이 된 글자입니다. 그렇다면 이투데이 기사의 내용대로 함초롬체 개발에 2년이 소요되었더라도 이미 추가했어야 할 글자라는 뜻입니다. 참고로 파란색 테두리를 두른 부분은 유니코드 5.1에서 추가된 부분입니다.

한자의 모양을 화면에 나타내지 못한다고 해서 유니코드를 지원하지 않는다는 말은 잘못되었다는 의견도 있을 수 있습니다. 그러나 저 글자 가운데 어떤 글자도 ᄒᆞᆫ글의 한자 사전에서 음과 훈, 한어병음 가운데 어느 하나도 나타나 있지 않습니다. 물론 음과 훈은 정해져 있지 않고, 한어병음도 정해져 있지 않을 수 있습니다. 그러나 단 하나, 정해져 있는 것이 있습니다. 바로 획수입니다.[각주:1]

획수조차 나타나지 않는 한자 사전

획수조차 나타나지 않는 한자 사전

도대체 무엇을 근거로 Unicode Full Set을 지원한다는 말을 했을까요?

벌레 분석

Unicode Full Set을 지원한다는 말은 그저 광고 문구로만 볼 수 없습니다. 상당히 많이 기대한 ᄒᆞᆫ글의 유니코드 지원이지만, 결과적으로 한글 자모만의 지원이라는 생각이 듭니다. 물론 한국에서 개발한 프로그램이므로 한글 자모만 지원되어도 충분할 수 있습니다. 그러나 그것이 Unicode Full Set 지원을 뜻하지는 않는다고 생각합니다.

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


  1. 정해진 것이 하나 더 있습니다. 바로 글자의 외형(glyph)입니다. 다만 글자의 외형은 글꼴에서 지원하지 않으면 나타낼 수 없으므로, 실제로 정해진 것은 바로 획수입니다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

최근 제 블로그의 CSS 설정에서 글꼴 하나를 삭제하고 몇 가지 작업을 더하였습니다. 그런데 그 뒤로 제목의 옛한글이 이상하게 나타나는 현상이 일어났습니다.

벌레의 유형

이 벌레는 모여야 할 때 흩어지는 벌레입니다.

개발자의 답변

2010년 1월 22일 버그 리포팅을 하였습니다.

벌레의 발견

파이어폭스에 나타난 이상한 옛한글

파이어폭스에 나타난 이상한 옛한글

처음에는 파이어폭스에서 발견했습니다.

인터넷 익스플로러에 나타난 이상한 네모

인터넷 익스플로러에 나타난 이상한 네모

인터넷 익스플로러에서도 확인했습니다.

어, 그런데, 분명히 저 제목에 쓰인 글꼴은 은 돋움 글꼴로서 옛한글을 지원하는 글꼴입니다.

글꼴 실험 1 - 보통 글씨

왜 저렇게 이상하게 보일까요? 이상하게 여겨져서 테스트를 하기로 했습니다. 이번에 실험한 글꼴은 은 돋움, 은 바탕, 은 자모 돋움, 은 자모 바탕입니다.

[code html] <div style="font-size: 1.4em; line-height: 100%;"> <p>font-weight:normal;</p> <p>한글 자모 영역(U+1100~U+11FF)을 이용한 합자 테스트</p> <p style="font-family: '은 돋움'; ">은 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 바탕'; ">은 바탕 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 돋움'; ">은 자모 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 바탕'; ">은 자모 바탕 : &#x1112;&#x119E;&#x11AB;</p> <p>호환용 한글 자모(U+3130~U+318F)를 이용한 합자 테스트</p> <p style="font-family: '은 돋움'; ">은 돋움 : &#x314E;&#x318D;&#x3134;</p> <p style="font-family: '은 바탕'; ">은 바탕 : &#x314E;&#x318D;&#x3134;</p> <p style="font-family: '은 자모 돋움'; ">은 자모 돋움 : &#x314E;&#x318D;&#x3134;</p> <p style="font-family: '은 자모 바탕'; ">은 자모 바탕 : &#x314E;&#x318D;&#x3134;</p> </div> [/code]

위와 같은 코드를 넣은 HTML 파일을 만들어서 시험을 했습니다. &#x1112;&#x119E;&#x11AB;&#x314E;&#x318D;&#x3134;은 앞서 자주 나왔던 그 문자, 바로 ᄒᆞᆫ입니다. 자세한 사항은 스프링노트 : 문자 인코딩 관련 사항을 참조하기 바랍니다.

그 결과는 아래와 같습니다.

IE6에서 본 옛한글 보통 글씨

IE6에서 본 옛한글 보통 글씨

한편 위에서 호환용 한글 자모의 합자는 지원하지 않음을 알게 되었습니다. 그러므로 코드를 조금 고치겠습니다.

글꼴 실험 2 - 굵은 글씨

보통 글씨의 합자는 잘 나타내지만, 반대로 호환용 한글 자모의 합자는 지원하지 않아서 코드를 고쳤습니다.

[code html] <div style="font-size: 1.4em; font-height: 130%; font-weight:bold;"> <p>font-weight:bold;</p> <p>한글 자모 영역(U+1100~U+11FF)을 이용한 합자 테스트</p> <p style="font-family: '은 돋움';">은 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 바탕';">은 바탕 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 돋움';">은 자모 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 바탕';">은 자모 바탕 : &#x1112;&#x119E;&#x11AB;</p> </div> [/code]

참고로 1.4em제 블로그기사 제목(title) 글자 크기입니다.

파이어폭스에서 본 옛한글 굵은 글씨

파이어폭스에서 본 옛한글 굵은 글씨

은 자모 돋움은 변함없이 옛한글을 보여주지 못하고 있습니다. 또한 보통 글씨에서 옛한글을 잘 보여주던 은 돋움도 옛한글을 보여주지 못하고 있습니다. 현재 은 돋움 글꼴이 아까보다는 확실히 굵게 보이고 있습니다.

글꼴 실험 3 - 볼드 글꼴 지우기

은 돋움 글꼴은 굵은 글씨에 해당하는 볼드 글꼴이 따로 있습니다. 은 돋움 글꼴은 UnDotum.ttf 파일이며, 은 돋움 글꼴의 굵은 글씨는 굵은 은 돋움 글꼴이 담당하는데, UnDotumBold.ttf 파일입니다. 이 파일이 있다면 은 돋움 글꼴에 볼드 속성을 요청하면, 이 파일에서 읽어오게 됩니다. 개인적으로 이 굵은 은 돋움 글꼴은 너무 굵어서 좋아하지 않습니다. 정확히 말하면, 너무 굵어서 읽기 힘든 면이 있기 때문에 싫어합니다.
하지만 이번에는 굵기 때문에 제목에 넣었는데 오히려 옛한글을 제대로 나타내지 못하니 환장할 노릇이지요.

아무튼 이번에 이 글꼴 파일을 제거한 뒤 다시 부팅하겠습니다. 뭐, 글꼴 캐시만 지우고 웹브라우저를 다시 시작하면 되지만, 확실히 하기 위해 다시 부팅했습니다.

파이어폭스에서 본 옛한글 굵은 글씨 (글꼴 없음)

파이어폭스에서 본 옛한글 굵은 글씨 (글꼴 파일 없음)

정확한 글꼴 파일 없이 자체적으로 볼드 속성을 구현한 경우에는 제대로 나타나고 있습니다. 그렇다면 범인은 굵은 은 돋움 글꼴인가 봅니다.

글꼴 실험 4 - 다른 은 글꼴

이번에는 은 바탕이나 은 돋움 이외의 글꼴도 포함하여 살펴보겠습니다. 편의상 편집하여 표시하겠습니다. 양해 바랍니다.

은 바탕 글꼴이 지원하는 유니코드 영역의 일부

은 바탕 글꼴이 지원하는 유니코드 영역의 일부

위 그림은 은 바탕 글꼴이 지원하는 유니코드 영역(Supported Unicode Blocks)의 일부입니다. 위 그림에서 빨간 네모 테두리를 두른 곳을 살펴보면, 하나는 한글 자모 영역이며, 다른 하나는 호환용 한글 자모입니다. 이 가운데 한글 자모 영역이 있는 글꼴을 테스트하려고 했는데, 모든 은 글꼴에서 자모 영역을 발견하였고, 그에 따라 모든 은 글꼴을 대상으로 삼았습니다.

[code html] <div style="font-size: 1.4em; font-height: 100%; font-weight:normal;"> <p>font-weight:normal;</p> <p>한글 자모 영역(U+1100~U+11FF)을 이용한 합자 테스트</p> <p style="font-family: '은 바탕';">은 바탕 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '굵은 은 바탕';">굵은 은 바탕 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 봄';">은 봄 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 디나루';">은 디나루 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '굵은 은 디나루';">굵은 은 디나루 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '가는 은 디나루';">가는 은 디나루 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 돋움';">은 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '굵은 은 돋움';">굵은 은 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 그래픽';">은 그래픽 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '굵은 은 그래픽';">굵은 은 그래픽 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 궁서';">은 궁서 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 바탕';">은 자모 바탕 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 돋움';">은 자모 돋움 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 노벨';">은 자모 노벨 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 소라';">은 자모 소라 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 펜';">은 자모 펜 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 펜흘림';">은 자모 펜흘림 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 필기';">은 자모 필기 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 자모 필기a';">은 자모 필기a : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '굵은 은 자모 필기';">굵은 은 자모 필기 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 신문';">은 신문 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 타자';">은 타자 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 바다';">은 바다 : &#x1112;&#x119E;&#x11AB;</p> <p style="font-family: '은 옛글';">은 옛글 : &#x1112;&#x119E;&#x11AB;</p> </div> [/code]

테스트 결과는 다음과 같습니다.

모든 은 글꼴의 옛한글 합자 지원 테스트 결과

모든 은 글꼴의 옛한글 합자 지원 테스트 결과

옛한글 합자를 지원하는 글꼴만 따로 모으면 다음과 같습니다.

옛한글 합자를 지원하는 은 글꼴 모음

옛한글 합자를 지원하는 은 글꼴 모음

벌레의 원인

이 벌레에 대해서는 원인을 알지 못합니다. 저는 글꼴의 내부 구조에 대해 아는 바가 전혀 없기 때문입니다.

비슷한 벌레

글꼴 및 화면 표시와 관련한 버그는 다음과 같은 것이 있습니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

요즘 한컴오피스 2010 베타버전을 사용하다 보니 조금 이상한 현상을 발견했습니다. 한/글에서는 제대로 보이는 괄호가 웹페이지에서는 약간 다르게 보이는 현상입니다.

  • 참고 : 이 글에 나타난 사항을 바탕으로 블로그의 글꼴 설정을 바꾸었습니다.

벌레의 유형

남들은 다 날씬해 보이기를 바라는데, 이 벌레는 홀로 뚱뚱해 보이기를 바라고 있습니다.

개발자의 답변

버그 리포팅을 하지 않았습니다. 이 글을 쓰기 시작할 때까지는 적용되어 있던 글꼴 가운데 돋움 옛한글 글꼴(ODOTUM.TTF)은 MS 오피스2000 팩키지 또는 확장 팩에 포함되어 있던 글꼴입니다. 현재 이 파일에 대한 지원을 MS에서 중단한 상태입니다. 그래서 그 글꼴을 삭제하였습니다. 생각 같아서는 굴림 옛한글 글꼴도 삭제하고 싶지만, 그것이 기본 글꼴에 대한 확장이라서 그냥 두었습니다.

벌레의 발견

파이어폭스에 나타난 이상한 괄호

파이어폭스에 나타난 이상한 괄호

처음에는 파이어폭스에서 발견했습니다.

인터넷 익스플로러에 나타난 이상한 괄호

인터넷 익스플로러에 나타난 이상한 괄호

인터넷 익스플로러에서도 확인했습니다. 제 컴퓨터에 있는 IE6은 대개 이런 용도로만 쓰입니다.

글꼴 실험 시작

왜 저렇게 이상하게 보일까요? 어떤 글꼴인지 알 수 없어서 하나하나 살펴보기로 했습니다. 대상은 제 블로그에 설정한 글꼴과 몇몇 다른 글꼴입니다.

[code html] <div style="font-size:10pt;"> <p style="font-family: '굴림';">굴림 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '굴림체';">굴림체 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '돋움 옛한글';">돋움 옛한글 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '바탕 옛한글';">바탕 옛한글 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '굴림 옛한글';">굴림 옛한글 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '굴림 옛한글 자모';">굴림 옛한글 자모 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '궁서 옛한글';">궁서 옛한글 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '은 돋움';">은 돋움 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '은 바탕';">은 바탕 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '은 자모 돋움';">은 자모 돋움 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '은 자모 바탕';">은 자모 바탕 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '은 자모 노벨';">은 자모 노벨 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '은 자모 소라';">은 자모 소라 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '함초롬바탕';">함초롬바탕 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: '함초롬돋움';">함초롬돋움 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: 'Code2002';">Code2002 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: 'Code2001';">Code2001 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: 'Code2000';">Code2000 : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> <p style="font-family: 'serif';">serif : &#x1112;&#x119E;&#x11AB;을 지우기(Del 키)를 할 때</p> </div> [/code]

위와 같은 코드를 넣은 HTML 파일을 만들어서 시험을 했습니다. &#x1112;&#x119E;&#x11AB;은 앞서 자주 나왔던 그 문자, 바로 ᄒᆞᆫ입니다. & 문자HTML 참조 코드 또는 글자 엔티티(character entity)임을 나타내고 있습니다. 뒤에 수치가 따라왔으므로 HTML 참조 코드입니다(스프링노트 : 문자 인코딩 관련 사항 참조). 이 코드는 옛한글 지원 여부를 알아보려고 넣었습니다.

다만 위에서 <div style="font-size:10pt";>라고 나타난 부분은 앞으로 바뀌게 됩니다. 이때 이 실험은 처음 시작할 때와 코드가 조금 바뀌었으며, 여기에 밝힌 사항은 이미 실험에 성공하였기에 나타난 사항임을 염두에 두기 바랍니다.

10포인트 글꼴 테스트

10포인트 글꼴에서는 이상을 발견할 수 없었습니다. 처음에는 이것 때문에 조금 헤맸습니다. 하지만 구글링 결과 글꼴 버그가 특정 크기에서만 나타나는 경우도 있다고 했기 때문에 급히 코드를 약간 고쳤습니다.

10포인트 글꼴 테스트

10포인트 글꼴 테스트

10포인트보다 큰 글꼴의 크기별 테스트

편의상 편집하여 표시합니다. 양해 바랍니다.

11포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음

11포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음

12포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음

12포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음


13포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음

13포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음


14포인트 글꼴 테스트 : 돋움 옛한글 글꼴에서 이상 발생

14포인트 글꼴 테스트 : 돋움 옛한글 글꼴에서 이상 발생


16포인트 글꼴 테스트 : 돋움 옛한글 글꼴에서 이상 발생

16포인트 글꼴 테스트 : 돋움 옛한글 글꼴에서 이상 발생


18포인트 글꼴 테스트 : 돋움 옛한글 글꼴에서 이상 발생

18포인트 글꼴 테스트 : 돋움 옛한글 글꼴에서 이상 발생


20포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음

20포인트 글꼴 테스트 : 모든 글꼴에서 이상 없음

이보다 더 큰 글꼴에서의 테스트는 저에게 필요가 없기에 여기에서 멈추었습니다. 마지막 20포인트 글꼴에 빨간 네모로 표시한 부분이 옛한글을 잘 나타내고 있는 글꼴입니다.

  • 참고로 저는 Code2000 계열 글꼴을 가지고 있지 않기에 위 그림들에서 Code2000 계열 글꼴에서 옛한글이 모두 깨지고 있습니다. 그리고 MS 오피스 확장 팩 글꼴은 제가 가진 MS Word 2000과 함께 딸려왔습니다.

벌레의 원인

이 글을 쓰기 시작할 때까지는 적용되어 있던 글꼴 가운데 돋움 옛한글 글꼴(ODOTUM.TTF)은 MS 오피스2000 팩키지 또는 확장 팩에 포함되어 있던 글꼴입니다. 아마도 그 파일에 어떤 벌레가 숨어 있었나 봅니다.

비슷한 벌레

글꼴 및 화면 표시와 관련한 버그는 다음과 같은 것이 있습니다.

관련 문서

내부 문서

외부 문서

(없음)

이 글은 스프링노트에서 작성되었습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 7 - 캡션의 옛한글 버그 확인

한컴오피스 베타버전 버그 7에서 주장한 버그에 대해 확인하겠습니다. 그 글에서 캡션에 “ᄒᆞᆫ”과 같은 한글 완성형 코드에 없는 글자, 곧 유니코드에서만 조합할 수 있는 문자가 오면, 낱자 1개당 물음표(?) 1개가 생긴다고 가정했습니다. 그것을 확인해 보겠습니다.

1. 가정

캡션에 입력한 옛한글 낱자 1개에 물음표(?) 1개가 생긴다.

2. 확인

2010년 1월 3일 버그 리포팅을 하고 12일에 재현 및 확인합니다.

3. 재현

3.1. 재현 방법

1. 그림을 추가한 뒤 테스트 블로그로 올린다. 이때 캡션에 옛한글을 포함한다.

2. 그림은 임의로 지정한다.

3. 캡션에는 ᄉᆞ(ㅅㆍ), ᄒᆞᆫ(ㅎㆍㄴ), ᄆᆞᆺ(ㅁㆍㅅ)을 사용한다.

3.2. 재현

테스트 블로그에 가서 물음표 개수를 세었습니다. 글자가 흐릿하지만, 아래 그림을 보아도 됩니다.

4. 결론

앞서 밝혔던 낱자 1개에 물음표 1개라는 가정이, 적어도 지금까지는, 틀리지 않음을 증명했습니다. 물론 논거가 겨우 4개에 불과하므로 예단은 금물이지만, 뭐 이 정도로 만족해야죠. 나머지는 한글과컴퓨터사의 개발진이 밝혀야 할 문제라고 생각합니다.

덧붙여, 다음 뷰에서 나타나는 물음표(?)도 낱자의 개수에 따라 달라졌습니다. 다시 말해 낱자 1개에 물음표 1개가 성립했습니다.

5. 관련 문서

5.1. 내부 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? 2

5.2. 외부 문서 - 테스트 블로그

캡션 옛한글 블로그 올리기 문서

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

옛한글을 다음 뷰에서 제대로 나타내는지를 검사하는 문서입니다.

나랏말ᄊᆞ미 듀ᇰ귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ


'미쳐보자' 카테고리의 다른 글

IE6 No More 수정  (2) 2010.02.07
옛한글과 텍스트 편집기  (0) 2010.01.05
테스트 - 글자 손상 테스트  (0) 2010.01.03
글자 그대로  (0) 2009.12.24
프리웨어 라이선스 이야기  (0) 2009.11.29
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

ᄒᆞᆫ글 Character-Hanguel-0.gif Character-Hanguel-1.gif

위의 검정 글씨자주색처럼 보여야 합니다. 빨간색처럼 보이면 글꼴이 없거나 설정이 잘못된 경우입니다.

어떤 텍스트 편집기에서 우연히 ᄒᆞᆫ글을 복사하여 붙였다가 빨간색처럼 보이는 현상을 접한 뒤로 옛한글을 입력하지도 복사해 붙이지도 않은 기억이 난다. 아무튼 지금 다시 도전해 보려고 합니다.

목적

옛한글 입력은 힘들므로 우선 옛한글을 화면에 잘 나타내는 텍스트 편집기를 찾아 보자.

평가 항목

  1. 가변폭 글꼴이 가능한가? :
    • 대부분의 옛한글 글꼴가변폭 글꼴입니다. 따라서 텍스트 편집기에서 지원하는지를 먼저 살펴야 합니다.
    • 글꼴 목록에서 굴림체굴림이 함께 나타나면 됩니다.
  2. 유니코드 붙이기가 가능한가?
    • 유니코드, 정확하게는 UTF-8 문자셋으로 붙여넣기를 할 수 있는가? (Copy & Paste)
    • 참고로 윈도에서는 유니코드라고 부르는 것은 유니코드 리틀 엔디언입니다. 유니코드 빅 엔디언은 그냥 유니코드 빅 엔디언으로 표기합니다.
    • 예문에서 데이터를 읽어오게 됩니다.
  3. 유니코드저장할 수 있는가?
    • 2번에서 읽어온 예문을 UTF-8 문자셋으로 저장할 수 있는가를 평가합니다.
  4. 3번에서 자신이 저장한 파일에서 유니코드 자료를 읽어 올 수 있는가?
    • 이것도 역시 정확하게는 UTF-8 문자셋으로 저장한 파일을 읽어 올 수 있는가를 평가합니다.
  5. 3번에서 다른 프로그램에서 파일로 저장한 UTF-8 문자셋 자료를 읽어올 수 있는가?
  6. 5번에서 불러온 것을 다시 유니코드저장할 수 있는가?
  7. 4번에서 다른 텍스트 편집기에서 불러온 UTF-8 문자셋 자료를 복사하여 붙여넣기를 할 수 있는가? (Copy & Paste)
  8. 7번에서 붙여넣기 한 것을 다시 유니코드저장할 수 있는가?
  9. 위의 1~8번 과정을 가변폭 글꼴로 다시 시험합니다.

이때 당장은 유니코드의 여러 가지 형태를 모두 평가할 수는 없습니다. 따라서 달랑 두 가지만 따집니다. 하나는 유니코드 리틀 엔디언, 다른 하나는 UTF-8입니다. 특히 UTF-8에 중점을 두어 평가하게 됩니다.

저게 끝나면 오피스웨어도 점검을 해 봐야겠습니다.

평가 방법

위의 항목에 점수를 부여하게 됩니다. 그러나 항목 별로 약간의 차별을 두게 됩니다. 다만 1~8번을 따로 순위를 매기고, 9번은 따로 순위를 매깁니다. 9번을 따로 매기는 까닭은 설명하지 않아도 아시겠죠? 그리고 종합 순위는 9번 항목 때문에 매기지 않습니다. 사실상 텍스트 편집기의 성능 시험은 8번까지로 끝이라고 보시면 됩니다.

여기에서 미리 밝힐 사항은 윈도의 메모장읽기 쓰기가 모두 가능하며, 붙여넣기가 가능했습니다. 다른 프로그램이 저장한 자료도 거의 대부분 완벽하게 읽어왔습니다.

  • 1번 항목은 점수가 없습니다. 이것은 9번 항목을 위한 옵션이기 때문입니다.
  • 2번 항목은 10점입니다. 예문에 나타난 대로 보여주어야 합니다.
  • 3번 항목은 10점입니다. 단, 2번에서 정상적으로 붙여넣기를 하지 못한 경우에는 메모장의 파일 데이터로 대체하며, 그것을 불러와서 받은 점수에서 3점 감점합니다.
  • 4번 항목은 10점입니다. 저장한 뒤 그것을 불러온 뒤 복사하여 위키백과에 붙여넣기를 함으로써 정상적으로 보이는지를 검사합니다. 이는 데이터가 변형되더라도, 실제로 그 내용은 그대로 유지되는지를 알아보기 위한 것입니다.
  • 5번 항목은 제대로 불러온 것의 갯수에 3을 곱합니다. 다시 말해 5개의 프로그램에서 저장한 것을 불러오면 5 x 3 = 15점이 됩니다. 불러오더라도 이상이 있으면 감점 처리합니다.
  • 6번 항목은 저장한 뒤 메모장에서 불러오고, 그것을 다시 위키백과에 붙여넣기를 함으로써 정상적으로 보이는지를 검사합니다. 이는 데이터가 변형되더라도, 실제로 그 내용은 그대로 유지되는지를 알아보기 위한 것입니다. 역시 제대로 완료하면 편집기 하나당 3점을 배정합니다.
  • 7번 항목은, 화면에 잘 나타내 주면, 편집기 하나당 3점입니다.
  • 8번 항목은 6번 항목을 참조하여 점수를 매깁니다.

예문

위키백과옛한글 문서에 나타난 예문을 조금 고쳐서 사용합니다. 일부러 돋움 글꼴을 써서 옛한글을 깨지도록 했습니다.

<span class="jamocomposed_block" style="font-family: '돋움 옛한글','Dotum Old Hangul','바탕 옛한글','Batang Old Hangul','궁서 옛한글','Gungsuh Old Hangul','굴림 옛한글','NewGulim Old Hangul','은 자모 바탕 확장','Un Jamo Batang Ex','UnJamoBatangEx','은 자모 바탕','Un Jamo Batang','UnJamoBatang','은 바탕','Un Batang','UnBatang',Code2002,Code2001,Code2000,serif; font-size: 105%;">나랏말ᄊᆞ미 듀ᇰ귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ</span>

원문은 위와 같으나 실제로 사용하는 코드는 다음과 같습니다.

{{첫가끝|

나랏말ᄊᆞ미 듕귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ

}}

이는 듀ᇰ귁이라는 코드가 윈도 시스템 또는 글꼴에서 약간의 버그를 보이고 있어서 듀ᇰ라고 바뀌는 경우도 있기 때문입니다.

이것은 위키백과의 사용자 페이지에서 확인할 수 있습니다. 결국 아래 두 그림 가운데 한 가지의 형태를 따르면 됩니다.


텍스트 편집기 목록

간혹 이건 IDE 아니냐고 할 만한 놈이 있기는 하지만, 다음과 같은 텍스트 편집기를 대상으로 작업을 하게 됩니다.

마치며

현재까지 예상으로는 편집 능력에서는 거의 최하를 다투는 메모장이 압도적인 1위를 하지 않을까 생각합니다. 이게 단순히 텍스트를 붙여넣고 저장하고, 클립보드로 복사하고, 클립보드에서 붙여넣는 능력이 매우 탁월하다는 사실을 이번에 알게 되었기 때문입니다. 아무튼 기대가 됩니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 7 - ᄒᆞᆫ글과 블로그 4 : ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? 2

지난번에 이어 이번에도 글자가 손상되는 현상을 발견했습니다. 지난번에는 그저 글꼴 문제로 글자가 엉뚱하게 보이는 현상이었습니다. 하지만 이번에는 아예 글자를 뭉개 버렸습니다.

1. 벌레의 유형

이보세요, ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’이라는 이름만 제대로 나타내 주면 안 되겠습니까? 아니, 이제는 그저 그 엉뚱하게 보이던 그 글자라도 그냥 놔두었으면 합니다. 사용자가 직접 span 태그를 써서 모양을 나타낼 수 있도록 말입니다.

그림 1 글자가 나타나야 할 자리가 뭉개져 있습니다.

위 그림처럼 되면 정말 난감합니다. 그 자리에서 바로 수정할 수 없다면 나중에 그게 무슨 글자인지조차 알 수 없게 될 수도 있기 때문입니다.

2. 개발자의 답변

2010년 1월 3일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

3.1. 처음에는 몰랐습니다.

처음에는 캡션에까지는 신경 쓰지 못하였습니다. 나중에 블로그의 CSS를 고친 뒤에 보니까 옛한글이 캡션에 들어가면 그 부분이 뭉개진 형태(???)로 나타납니다.

3.2. HTML로 저장한 경우

HTML로 저장한 경우에는 이 벌레가 생기지 않습니다. 그러니 더욱 모를 수밖에요.
제 경우는 다른 이름으로 저장 >> HTML로 저장을 하여 살펴본 뒤에 블로그로 올리기 기능을 사용합니다. HTML로 바꾸었을 때 이 현상이 일어났더라면 좀 더 일찍 알아차렸을 테지요.

4. 벌레의 원인

이 벌레의 원인에 대해서는 현재로서는 알 수 없습니다.
다만 제 예상으로는 '유니코드 문자표에 없는 문자'인 ᄒᆞᆫ자가 포함되어 있기 때문에 생기는 현상으로 여겨집니다. 이때 물음표 하나(?)는 ᄒᆞᆫ자에 포함된 음소 하나를 가리킨다고 여겨집니다. 제 예측이 맞다면 ᄉᆞᆱ과 같은 글자는 물음표 4개(????)가 될 것입니다.

ᄒᆞᆫ글이 잘 보였으면 좋겠습니다. (올린 뒤 수정했음)

5. 비슷한 벌레

[벌레와 팁/버그] - 다음뷰, 옛한글도 한글이란다.

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

6. 관련 문서

6.1. 내부 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그 카테고리는 어디에?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.

[벌레와 팁/버그] - HTML 태그 해석 오류 문제

[벌레와 팁/버그] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

[프로그램/설치] - 한컴오피스2010 베타버전 설치기

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

난 판도라 상자를 열었을까?

요즘 저런 생각을 절로 하고 있습니다. 괜히 건드리면 안 될 물건을 건드리지 않았나 후회해 봅니다.

최근 두 개의 글을 올렸습니다. 최근이고 뭐고, 새해 첫날에 옛한글 관련 포스팅을 두 개나 올려 버렸죠.

그런데 갈수록 험난한 길이 보입니다. 오늘은 (X)HTML 코드를 텍스트 편집기에 복사해 붙여넣기를 했다가 그게 엉뚱하게 바뀌는 현상을 경험했습니다. 난감합니다. 이걸 버그 리포팅을 하자니, 특정 프로그램을 너무 때리는 것이 되지 않나 싶고, 버그 리포팅을 안 하자니 그래도 버그인데 안 할 수도 없고…. 더구나 그 편집기에서는 옛한글이 포함된 (X)HTML 문서를 읽어올 경우 경고 없이 허락도 받지 않고 마음대로 바꾸어 버립니다.

벌레가 줄줄이…

그 편집기만의 문제가 아니었습니다. 대부분의 편집기에서 옛한글을 입력하기 힘들다는 현실을 깨닫게 되었습니다. 아니, 진작에 알고 있었지만 지금까지 외면해 왔습니다. 양심이 가슴 한쪽을 쿡쿡 찌르는군요.

죄송합니다, 세종대왕님!

이 모자라고 모자란 후손은 세종어제 훈민정음조차 컴퓨터에 제대로 나타내지 못하고 있습니다.

아무튼 벌레가 줄줄이 나타나고 있습니다. 그래서 아예 옛한글을 잘 나타내는 텍스트 편집기(가칭)라는 글을 준비하고 있습니다. 입력까지는 바라지도 않습니다. 어차피 우리가 쓰는 키보드로는 입력이 불가능합니다. 입력하려면 반드시 특별한 입력 소프트웨어가 필요합니다. 웹에서 입력할 수 있게 해주는 웹사이트가 있는데, 아쉽게도 모질라 파이어폭스나 구글 크롭에서는 동작하지 않습니다. 오직 인터넷 익스플로러에서만 동작합니다. 오호 통재라, 오호 애재라! 그렇습니다. 한글을, 옛한글을 가장 못 나타내는 웹브라우저가 인터넷 익스플로러인데도 옛한글 관련 툴은 인터넷 익스플로러용이 가장 많습니다. 아마 그놈이 가장 못 나타내기 때문에 더 열성적으로 그놈만 지원하는 것일까요?

글꼴은 반드시 필요해!

글꼴이 갖춰져야 위와 같이 볼 수 있습니다.

글꼴이 갖춰져야 위와 같이 볼 수 있습니다.

다음뷰, 옛한글도 한글이란다.라는 글에 나온 내용을 볼 수 없는 사람도 있습니다. 다시 말해 그 글에 나타난 예시에서 맨 윗줄의 내용이 맨 아랫줄의 내용처럼 보일 수도 있습니다. 하지만 다음뷰에 나타난 ??? (물음표 세 개)처럼 보이는 사람은 없으리라 생각합니다. 만약 ???로 보이는 사람이 있다면 웹브라우저를 바꾸는 게 문제가 아니라 당장 운영체제를 바꾸는 게 낫습니다.

옛한글을 보려면 윈도XP 이상의 윈도 운영체제, 맥 OS X 이상, 리눅스 커널 2.4 이상이 필요하지요. 더구나 리눅스의 경우 X윈도의 버전과 거기에 쓰이는 데스크탑(윈도의 Explorer. ←이게 데스크탑을 작동하는 인 동시에 윈도 탐색기입니다.)인 GNOME(그놈) 및 KDE의 버전도 따져 봐야 합니다.

한글 입력과 표현에 대한 자세한 정보는 다음과 같은 사이트에서 구할 수 있습니다. 다만 한양 사용자 정의 영역 코드(Hanyang private use area code; 한양 PUA 코드)는 표준 문제로 도태되고 있습니다. 표준 방식은 한글자모 코드(Jamo-Composed code; 일명 첫가끝 코드)입니다.

제가 윈도를 쓰므로 윈도용 입력기를 소개합니다.

위의 여러 글을 읽으면 글꼴도 소개하고 있지만 여기에서 따로 소개합니다. 참고로 MS에서 배포한 글꼴은 윈도에서만 써야 합니다. 리눅스나 맥 OS에서는 사용하면 안 됩니다. 이것을 어기고 다들 리눅스나 맥 OS X에서 쓰시는데, 라이선스 위반입니다. 특히 문화재청(국가기록유산 홈페이지 등), 디지털 한글박물관, 국립국어원 등에서 배포하는 글꼴은 윈도 전용 라이선스 글꼴로서, 한양 UPA 방식을 따릅니다. 그러므로 해당 사이트를 사용하지 않는다면 그 글꼴을 설치하지 않는 것이 좋습니다.

  • 은 글꼴 :: 다운로드 - 압축을 푼 뒤 %SystemRoot%\Fonts 폴더에 복사하면 됩니다.
  • Microsoft 옛한글 글꼴 (링크 삭제) - 기이하고 신기하고 이상하게도 Microsoft Internet Explorer에서는 옛한글을 제대로 보여주지 못하는 때가 있습니다. 그리고 반드시 윈도에서만 사용해야 라이선스를 가집니다. 이것은 한양 PUA 지원하는 비표준 글꼴입니다. 익스플로러에서 잘 나타내지 못하는 이유도, 처음에는 MS가 사용자 영역(UPA)를 지원했으나 나중에 유니코드 사용자 영역에 대한 공식적인 지원을 하지 않고 있기 때문입니다. 따라서 보이면 다행, 안 보여도 어쩔 수 없습니다.
  • Code 2000 - 셰어웨어 글꼴(유료). 한글이 예쁘지는 않지만, 모든 자소가 포함되어 못 나타내는 글자는 없습니다.

어?! 그래도 안 나오네!

이렇게까지 했는데도 안 나오는 경우가 있다.

USP10.DLL 파일이 문제였다.

이게 뭐냐고? Uniscribe Unicode script processor (줄여서 유니스크라이브(Uniscribe))라는 것인데, 이게 겨우 버전 1밖에 안 되는데도, 빌드넘버에 따라 성능 차이가 심합니다. 참고로 내가 가진 파일의 버전은 1.626.5756.0, 날짜는 2006년 10월 13일이며, 파일 크기는 503296 바이트입니다. 이 파일의 최신 버전은 윈도 7에 포함된 1.626.7600.16385로서, 날짜는 2009년 7월 14일이며, 파일 크기는 612 KiB입니다. 최근 나온 Microsoft® Office 2010 베타버전에는 1.626.7600.16385 버전의 파일이 들어 있는데, 날짜는 2009년 8월 4일이며, 파일 크기는 639824 바이트입니다. 다시 말해 버전은 윈도 7에 포함된 파일과 같으나 날짜와 파일 크기는 다릅니다.

아무튼 이 파일을 복사하여 교체하면 되는데, 작업이 좀 복잡합니다. 그래서 그런지 MS오피스 2010 베타버전도 설치 과정에서 시스템 폴더를 쓰지 않고 자신의 공유 폴더에 넣어 두고 있습니다.

이렇게 고생고생해서 겨우 옛한글을 보게 되었습니다. 저는 판도라 상자를 열었을까요? 그 판도라 상자는 희망의 판도라 상자일까요? 절망의 판도라 상자일까요?

남은 이야기

그리고 제 블로그는 읽기가 좀 불편함을 알게 되었습니다.

한글이나 한자는 1글자, 영문이나 숫자는 0.5글자로 계산한다는 가정하고, 보통 한 줄에 글자는 25자 정도 되어야 읽기 좋습니다. 그보다 적으면 읽기는 편할 수 있으나 빨리 지루해진다고 하며, 그보다 많으면 너무 행이 길어서 빨리 지친다고 합니다. 그런데 제 블로그는 무려 50글자를 넘겼습니다. 무려 두 배나 많습니다.

물론 지금도 제 블로그의 글꼴 크기는 꽤 큰 편입니다. 그런데도 글자가 많은 것은 본문의 폭이 720 픽셀이기 때문입니다.

그래서 글꼴 크기가 작으면 글자가 뭉개져서 보기 흉해지는 옛한글 문제도 생기고 해서 겸사겸사 글자 크기를 좀 더 크게 하기로 했습니다. 어차피 제 자신이 보려고 블로그에 글을 올리고 있으니, 눈 나쁜 저에게는 더 좋은 일이지요.

그리고 바꾸는 김에 지금까지 미뤄 왔던 CSS 글꼴 설정도 손을 보았습니다. 글꼴 적용 순서는 은 돋움, 은 자모 돋움, 은 바탕, 은 자모 바탕, 돋움, 돋움 옛한글, 굴림 옛한글, Code2002, Code2001, Code2000의 순서입니다.

그리고 위의 은 글꼴을 받아서 설치하고 나서도 제 블로그의 글자가 이상하게 보인다면 댓글 남겨 주십시오.

마지막으로 스크린샷 몇 개!

글꼴이 달라지기는 했지만, 옛 한글은 잘 나옵니다.

글꼴이 달라지기는 했지만, 옛 한글은 잘 나옵니다.




참고 자료

내부 자료

외부 자료

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

요즘 열심히 옛한글 관련 포스팅을 하고 있습니다. 일단 한글과컴퓨터한컴오피스2010 베타버전 때문에 더 열심히 하고 있지요. 그런데 제가 ᄒᆞᆫ글이라는 이름을 꼭 제대로 나타내고 싶어하기 때문에 문제가 발생하고 있습니다. 적당히 포기하면 편할 텐데 말입니다. 제가 사소한 데 목숨을 거는 스타일이라서 말입니다. 물론 이 글의 제목에서는 다음뷰만 거론했지만, 다음뷰의 상황이 가장 나쁘기 때문이지 다른 사이트도 별로 다르지 않습니다.

ᄒᆞᆫ글 (안 보이시나요? 아래 자주색 그림처럼 보여야 옳습니다.)
이렇게 보여야 옳습니다.(이렇게 보여야 옳습니다.)
이렇게 보이면 안 됩니다.(이렇게 보이면 안 됩니다.)

벌레의 유형

대부분의 사이트에서 발생하는 벌레입니다. 벌레라기보다는 무사안일한 태도 때문이라고 생각합니다. 블로그 서비스를 이용하는 사람은 그 목적이 매우 다양하여, 화학식, 물리학이나 수학의 수식, 언어학의 음성 기호, 한국어의 옛한글 등도 블로그에서 표현하려고 들 것입니다. 그런데 서비스를 제공하는 측에서 그러한 다양한 요구가 생기리라는 것을 예측하지 못하고 평범한 환경만을 대상으로 블로그 서비스 및 메타블로그 서비스를 기획, 개발했기 때문에 벌어진 일입니다.

게다가 블로그 가운데 유니코드(utf-8)를 쓰는 블로그도 많은데, 메타블로그가 유니코드가 아닌 euc-kr과 같은 코드를 쓴다면? 당장 그 메타블로그가 표현해줄 수 있는 문자 수가 확 줄어들게 된다. 어처구니없게도 여러 블로그를 아우르게 되는 메타블로그가 블로그보다 더 표현력이 떨어지는 이상한 현상이 발생하게 되는 것이다.

개발자의 답변

  • 다음 뷰에는 2010년 1월 1일 버그 리포팅을 한 상태입니다. 메타블로그임에도 비슷하게도 나타내지 못하고 있습니다.
  • 스프링노트에는 2009년 12월 31일 기능 제안(옛한글 입력 및 출력)한 상태입니다.
  • 티스토리에는 2010년 1월 1일 제안(글꼴 정보 추가 요청)한 상태입니다.
  • mixsh에는 2010년 1월 1일 제안(글꼴 정보 추가 요청)한 상태입니다.

벌레의 발견

응?! ???글 씨? 저거 또 무엇인고?

응?! 다음뷰 온 박스에 쓰인 ???글 씨? 저거 또 무엇인고?

위에서 view on 박스를 보면 조금 문제가 심각합니다. 다른 경우는 ㅎ.ㄴ 처럼 보이는데 저것은 아예 ???라고 나타납니다. 혹시나 하는 마음에 다음뷰도 살펴보았습니다.

다음뷰에서도 ???로 나타내고 있습니다.

다음뷰에서도 ???로 나타내고 있습니다.

아, 글씨, 도대체 이게 어찌된 일일까요? 아무튼 조금 난감한 경우입니다.

mixsh에서도 엉뚱하게 나타납니다. 그래도 대강은 알아볼 수 있겠네요.

mixsh에서도 엉뚱하게 나타납니다. 그래도 대강은 알아볼 수 있겠네요.

mixsh(믹시)는 그저 글꼴 정보가 지정되지 않았기 때문에 발생한 문제입니다.

티스토리 블로그 제목 : 이건 사용자가 글꼴을 지정할 수 있습니다.

티스토리 블로그 제목 : 이건 사용자가 글꼴을 지정할 수 있습니다.

위의 그림에 나타난 티스토리 블로그게시물 제목은 사용자가 글꼴을 지정할 수 있습니다. 현재 귀찮아서 안 하고 있습니다. 또한 어느 정도 사람들이 "왜 나타낼 수 없지?" 또는 "왜 저렇게 이상하게 나타나지?"라는 생각을 어느 정도 할 때까지(적어도 댓글에다가 "항의"를 적을 때까지) 그냥 둘까도 생각했습니다만, 조만간 고쳐야겠습니다.

티스토리 관리 화면. 이건 티스토리에서 해 주어야 합니다.

티스토리 관리 화면. 이건 티스토리에서 해 주어야 합니다.

티스토리 관리 화면에 관해서는 이미 제안한 상태입니다.

스프링노트. 정확하게 나와 있죠? (자주색 동그라미 부분)

스프링노트. 정확하게 나와 있죠? (자주색 동그라미 부분)

스프링노트 화면에서는 정확하게 나타내고 있습니다. 하지만 기본 기능이 아니라 HTML 모드를 사용하여 직접 HTML 태그를 입력하였습니다. 이렇게 직접 입력하는 방식은 티스토리 블로그 제목에서도 통용될 수 있습니다. 아무튼 옛한글의 입력과 출력을 스프링노트에 제안한 상태입니다.

벌레의 원인

앞서 말했듯이 이런 벌레가 생긴 까닭은 개발자나 기획자의 무사안일함 때문이라고 생각합니다.

옛한글을 전혀 사용하지 않을 로마자 문화권도 아닌데, 좀 더 넓은 안목에서 옛한글도 표현할 수 있게 지원하면 좀 좋겠습니까?

비슷한 벌레

화면 표시와 관련한 버그로는 V3 계열 백신의 폴더 경로명 표기 벌레와 ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?가 있습니다.

관련 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 6 - ᄒᆞᆫ글과 블로그 3 : ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

블로그로 올리기 기능을 사용하여 블로그에 글을 올리면 몇 가지 글자가 깨지고 있음을 알게 되었습니다. 또한 이 버그는 다른 이름으로 저장하기 - HTML 문서를 선택하여 저장한 문서에서는 나타나지 않는 문제이기도 합니다. 블로그로 올리는 데이터에도 CSS 설정이 포함되어 있는데, 어찌된 영문인지 전혀 작동하지 않습니다.

1. 벌레의 유형

이보세요, ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’이라는 이름만 제대로 나타내 주면 안 되겠습니까? 왜 HTML 문서에서는 제대로 보이는데, 블로그에 올리기만 하면 망가지는 모습을 보입니까?

그리고 ‘ᄒᆞᆫ글’을 제대로 보여주지도 못하면서 CSS 데이터는 왜 함께 올리는 거죠?

● 참고 : 블로그의 글 제목은 ᄒᆞᆫ글에서 제대로 보내 주어도 티스토리 측에서 제대로 보여주지 않습니다. 이는 ᄒᆞᆫ글이 함께 보내는 CSS 설정은 블로그에 올린 글의 본문에만 적용되기 때문입니다. 티스토리에서 블로그 글 제목 부분은 블로그 본문에 해당하지 않습니다.

2. 개발자의 답변

2010년 1월 1일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

가. 처음부터 발견했습니다.

문자열 ‘ᄒᆞᆫ글’이 들어간 글을 처음 올렸을 때 ‘ᄒᆞᆫ글’을 제대로 화면에 표시할 수 없음을 발견하였습니다.

나. HTML로 저장한 경우

● 참고 : 제 컴퓨터에는 옛한글을 보여주는 글꼴(함초롬바탕 등)을 이미 설치한 상태입니다. 이러한 글꼴이 없다면 제대로 된 올바른 결과를 볼 수 없습니다.

● 참고 : 아래 그림에서는 옛한글이 모두 함초롬바탕 글꼴을 통해 보이고 있습니다. 그런 까닭에 모양이 조금 이상합니다. 공개 글꼴인 은 글꼴로 보아도 좀 더 예쁜 모양으로 나타납니다.

다른 파일로 저장하기 전 ???글 파일

옛한글 표현이 매끄럽지 못하지만, 어쨌든 과 같은 화면 표시가 아닌 한글 조합 규칙에 맞는 화면 표시이다.

HTML 파일로 저장하여 IE에서 보기

IE에서도 잘 보입니다. 그러나 글자 모양이 역시 매끄럽지 못합니다. 이는 글꼴 문제이고, 모양 자체는 이 글의 취지와는 맞지 않으므로 그냥 두겠습니다.

HTML 파일로 저장하여 파이어폭스에서 보기

파이어폭스에서도 잘 보입니다.

다. 버그 발견

아무튼 내 컴퓨터에 HTML 파일로 저장하여 볼 때는 윈도가 자동으로 그 내용을 표시할 수 있는 글꼴을 적용하여 보여주었기 때문에 블로그에서는 제대로 표현할 수 없게 된다는 점을 깨닫지 못했습니다. 그러다가 블로그에 글을 게시한 다음에야 발견하게 되었습니다. http://salm.pe.kr/154 문서를 보시면 ‘ᄒᆞᆫ글’을 표시하지 못하고 있습니다.

이상하게 나타나는 옛한글

현재 블로그에 적용하기 위해서 첫가끝 방식(조합 방식으로 표현한 옛한글 표현 방식)을 지원하는 한컴오피스 글꼴이 있는지를 문의한 상태입니다. 문의한 이유는 한글과컴퓨터에서는 한양 사용자 정의 영역 코드(Hanyang private use area code; 한양 PUA 코드)만을 지원했기에 첫가끝 방식도 지원하는지는 알 수 없었기 때문입니다. 물론 메모장을 이용하여 함초롬 글꼴이 첫가끝을 지원함을 확인하기는 했지만, 어디까지나 만약이라는 것이 있기 때문입니다.

그밖에 옛한글을 표현하지 못하는 예시는 다음과 같습니다.

라. 또 다른 버그 - 올바르게 표현할 수 없다면 미리 알려달란 말입니다.

또 다른 버그는 이렇게 화면에 올바르게 표시할 수 없는 경우에도 아무런 경고가 없다는 것입니다. 또한 화면에 올바르게 표시할 수 없을 때에는 대부분 프린트 출력도 제대로 되지 않는다는 문제점도 함께 나타납니다.

예전 ᄒᆞᆫ글2005에서는 텍스트 파일로 저장할 때 KS 형식을 선택하면 나타낼 수 없는 문자가 있음을 알려주었습니다. 그런 배려가 한컴오피스2010 베타버전에는 없는 듯싶어 아쉽습니다.

제가 너무 예민하게 굴고 있나요? 그냥 그깟 옛한글 좀 화면에 안 나오면 어떠냐고요? 하지만 이 소프트웨어의 이름, 이 프로그램의 이름은 ‘ᄒᆞᆫ글’입니다. ‘한/글’이나 ‘’이 아니란 말입니다. 아무리 자기 영역이 아니라지만, 자기 이름조차 제대로 나타낼 수 없는 소프트웨어를 제가 왜 써야 하죠?

그러한 문제점을 알려주도록 프로그램을 짜면, 그것을 알려 줄 때 시간이 많이 걸린다면, 미리 시간이 많이 걸린다는 메시지를 내보내면 되지 않을까 생각합니다.

4. 벌레의 원인

앞서 말했듯이 사용자의 컴퓨터에 글꼴이 없으면 나타낼 수 없습니다. 현재 함초롬 글꼴(글꼴 종류가 여럿이므로 뭉뚱그려 함초롬 글꼴로 칭하겠습니다.)로 설정하면 정상적으로 옛한글을 볼 수 있습니다. 그렇기 때문에 HTML로 로컬 시스템에 저장했을 때는 제대로 보이게 됩니다.

문제는 블로그입니다. 블로그에는 제 나름의 CSS 설정을 가지고 있습니다. 이 CSS에는 글꼴 정보도 포함되어 있습니다. 하지만 CSS를 설정하는 방식이 틀려 있다면? 당연히 적용되지 않습니다.

http://salm.pe.kr/154 문서의 본문 부분의 소스 코드를 보면 다음과 같습니다.

[code html] <div class="article"> <p class="HStyle0">한컴오피스 2010 ᄒᆞᆫ글 <p class="HStyle0">블로그 보내기 시험용 문서 <p class="HStyle0">개요 HTML로 보내기 시험용 문서 <p class="HStyle0">
<p class="HStyle0">글자 그대로 <p class="HStyle2">1. 단계 1 <p class="HStyle3">1.1. 단계 2 <p class="HStyle4">1.1.1. 단계 3 <p class="HStyle5">1.1.1.1. 단계 4 <p class="HStyle6">1.1.1.1.1. 단계 5 <p class="HStyle7">1.1.1.1.1.1. 단계 6 <p class="HStyle8">1.1.1.1.1.1.1. 단계 7-1 <p class="HStyle8">1.1.1.1.1.1.2. 단계 7-2 <p class="HStyle8">1.1.1.1.1.1.3. 단계 7-3 [/code]

위의 코드를 보면 아무리 좋게 봐주어도 CSS에서 지정한 글꼴이 HTML 본문에 적용된다고 볼 수 없습니다. 위의 코드에서 CSS 설정은 그저 주석으로 처리될 뿐이기 때문입니다.

한글과컴퓨터의 개발진에서는 저 코드를 블로그 서비스 제공회사에서 어떻게든 처리해 주기를 바랐던 것일까요? 아니면 저렇게 해놓으면 HTML 코드를 파싱하는 웹브라우저 모듈에서 인식해 줄 것으로 여겼던 것일까요?

그것도 아니면 사용자가 일일이 하나하나 저것을 블로그 스킨의 CSS 설정에 복사해 넣으라는 말일까요? 하지만 그것도 불가능하죠. ᄒᆞᆫ글에서 작성한 문서는 그때마다 CSS 설정이 달라집니다. 그런데 어느 것에 맞추어서 CSS를 작성하고, 또 그것을 HTML 헤더에 복사해 넣으라는 뜻일까요? 물론 달랑 첫가끝 방식을 지원하는 글꼴에 대한 정보만을 블로그 스킨의 CSS 설정에 입력하는 방법이 그나마 가장 나은 방법입니다.

결국 한글과컴퓨터 측에서 글꼴이 없다면, 글꼴이 있더라도 블로그 설정에서 그 글꼴을 사용하지 않는다면, 글의 내용이 제대로 보이지 않을 수 있음을 알리는 수밖에 없습니다.

그게 아니라면 주석으로 처리된 CSS 설정을 아예 자바스크립트로 바꾸어 강제 적용하는 방법뿐이라고 생각합니다.

5. 비슷한 벌레

아직 없습니다.

6. 관련 문서

가. 내부 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그 카테고리는 어디에?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.

[벌레와 팁/버그] - HTML 태그 해석 오류 문제

[벌레와 팁/버그] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

[프로그램/설치] - 한컴오피스2010 베타버전 설치기

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.
일부 글자가 깨져 보일 수도 있습니다. 이는 나중에 팁으로 올리겠습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 5 - ᄒᆞᆫ글과 블로그 2 : 카테고리는 어디에?

지난 버그 리포팅에서 한글과컴퓨터 한/글 2010 도움말에는 ‘블로그 게시판’이라는 기이한 용어마저 등장하고 있다고 알려 드렸습니다. 그런데 이번에는 블로그에 게시할 때마다 나타나는 이상한 현상에 대해 알려드리겠습니다. 바로 ‘게시물 위치’가 전혀 나타나지 않는다는 점입니다.

1. 벌레의 유형

이보세요, ᄒᆞᆫ글 씨! 도대체 ‘어디’에 올리라는 말인가요? 그냥 ᄒᆞᆫ글 씨가 알아서 해줄 테니 등록 단추를 클릭하라는 말인가요? 도대체 왜 게시물 위치는 공백으로 남겨 두셨나요?

도대체 왜 게시물 위치는 공백인가요?

2. 개발자의 답변

2010년 1월 1일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

가. 처음부터 발견했습니다.

이 버그는 블로그로 보내기 기능을 처음 사용할 때부터 발견하였습니다. 다만 그게 내 컴퓨터에서만 발생하는 문제인지, 아니면 다른 컴퓨터에서도 발생하는 문제인지를 알 수 없었습니다.

그래서 일단 버그 리포팅을 보류했고, PC 방에 들렀다가 확인 작업을 마쳤습니다.

그리고 위와 같이 게시물 위치가 나타나지 않을 때 블로그로 올리기를 하면 블로그에는 분류 없음으로 표시하게 됩니다.

나. 블로그 계정 등록 설정부터 차근차근 살펴봅시다.

블로그 계정 관리 대화상자. 계정 등록하기 아이콘(자주색 표시된 + 아이콘)을 클릭!

계정 등록하기 대화상자

블로그 계정 관리 대화상자에서 계정 등록하기 아이콘(자주색 표시된 + 아이콘)을 클릭하면 계정 등록하기 대화상자가 나타납니다. 거기에 알맞은 값을 입력해 줍니다.

알맞은 값을 입력한 모습

우선 하나하나 살펴보죠. 위의 정보는 티스토리의 경우입니다. 다른 블로그를 이용하시는 분은 도움이 안 될 수도 있습니다.

1) 계정 이름

계정 이름은 사용자가 설정할 수 없습니다. 모든 값을 입력한 뒤 설정 단추를 클릭하면 자동으로 설정해 줍니다.

2) 블로그 정보

가) API

MetaWeblog API(메타웹로그 API)를 선택합니다. MetaWeblog API를 선택하는 설정은 MS WORD 2007에 티스토리 연결하기에 나타난 사항을 참조하였습니다. 참고로 블로그(blog)라는 이름은 Web log에서 따온 말로 여겨집니다(→위키백과).

나) API 주소

자신의 티스토리 블로그 주소에 api를 붙이면 됩니다. 제 경우는 http://salm.pe.kr/api 가 됩니다. 반드시 자신의 API 주소를 넣어야 합니다.

3) 계정 정보

가) 사용자 ID

자신의 티스토리 블로그 계정의 사용자 ID를 입력합니다.

나) 사용자 암호

자신의 티스토리 블로그 계정의 사용자 암호를 입력합니다.

4) 자동 접속

앞서 입력한 사용자 ID와 사용자 암호는 1회용입니다. 그것은 단순히 입력한 계정 정보가 옳은지만 확인합니다. 다음부터는 파일을 블로그로 보낼 때마다 암호를 물어보게 되지요. 그게 싫다면, 좀 더 편하고 싶다면, 자동 접속에 체크 표시를 하면 됩니다. 다만 보안상 조금 위험하죠.

위와 같은 순서로 블로그 등록 작업을 하면 됩니다.

다. 버그 발견

실제로 버그를 발견하게 된 때는 위의 설정대로 계정을 등록한 뒤 글을 올린 때입니다.

게시물 위치에 아무 것도 없습니다.




콤보박스를 아래로 내려 보아도 없습니다.



위의 그림에서 보듯이 게시물 위치에 아무 것도 없습니다. 그냥 공백이죠. 제가 잘못한 줄로만 알고 블로그 계정을 등록했다 지우기를 여러 차례 했습니다. 결국 PC 방에 와서야 버그라고 확신하게 되었습니다.

라. 또 다른 버그 - 목록이 비었으면 다시 읽어 와야 하지 않나?

또 다른 버그는 위와 같이 목록이 비어 있다면 당연히 다시 불러와야 하지 않느냐 하는 점입니다. 아니, 자동으로 다시 읽지는 않더라도 “다시 읽기” 단추라도 달아 줘야 하지 않나요?

새로고침 단추가 있는 스프링노트의 [블로그로 보내기] 대화상자

제가 너무 예민하게 굴고 있나요? 하지만 웹서비스 가운데 하나인 스프링노트에는 저와 같은 구성을 가진 블로그로 보내기 기능이 있습니다.

참고로 ᄒᆞᆫ글의 블로그 관련 기능은 앞으로 자주 스프링노트와 비교당할 겁니다. 왜? 내가 좋아하는 프로그램이니까 더더욱 까댈 겁니다.

물론 저 블로그로 보내기 기능에 버그가 있어서 버그 리포팅을 한 상태입니다. 우연히 ᄒᆞᆫ글의 블로그로 올리기 기능과 비슷한 버그입니다.

4. 벌레의 원인

무엇이 원인인지 모르겠습니다.

그래도 추측이라고 해본다면, 지난번에 올린 ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.라는 글처럼 게시판카테고리의 차이가 아닐까 의심해 봅니다. 게시판이 없는데 게시판을 찾겠다고 하니까, 아예 카테고리조차 찾지 못한다는 의심을 지울 수 없네요.

5. 비슷한 벌레

스프링노트 - 블로그로 보내기 - 새로고침 버그와 관련이 있습니다. 둘 다 블로그로 글 내용을 보낼 때 나타나는 버그이지요.

6. 관련 문서

가. 내부 문서

[벌레와 팁] - 스프링노트 - 블로그로 보내기 - 새로고침 버그

[벌레와 팁] - ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.

[벌레와 팁] - HTML 태그 해석 오류 문제

[벌레와 팁] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

[프로그램/설치] - 한컴오피스2010 베타버전 설치기

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.
일부 글자가 깨져 보일 수도 있습니다. 이는 나중에 팁으로 올리겠습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 4 - ᄒᆞᆫ글과 블로그 1 : 블로그에는 게시판이 없거든요.

한컴오피스2010 베타버전에서 야심차게 포함시켰을 블로그로 올리기 기능은 문제점을 드러내고 있네요. 일단 기본 전제인 HTML로 저장하기 기능이 너무나 미흡합니다.

더구나 한글과컴퓨터 한/글 2010 도움말에는 ‘블로그 게시판’이라는 기이한 용어마저 등장하고 있습니다.

1. 벌레의 유형

이보세요, ᄒᆞᆫ글 씨! 도대체 블로그에 ‘게시판’이 있습니까? 블로그에는 게시판이 없거든요. 없는 것은 어떻게 찾나요?

2. 개발자의 답변

2009년 12월 31일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

가. 게시판은 없습니다.

일단 블로그에는 게시판이 있지만 없습니다. 무슨 귀신 씨나락 까먹는 소리냐고요? 그게, 블로그 자체가 게시판을 이용하여 만들어진 웹로그 시스템입니다. 그렇지만 “게시판”이라는 이름으로 불리는 것은 없습니다. 굳이 따지자면, 방명록이 유일한 ‘게시판’입니다.

나. 게시판을 가리키는 ᄒᆞᆫ글의 기능

며칠 전부터 영 눈에 거슬리는 것이 있습니다. 바로 블로그로 올리기 기능을 사용할 때마다 게시물 위치라는 표현을 쓰고 있습니다. 그리고 도움말(단축키는 F1)을 불러서 읽어보았습니다. 거기에서 놀라운 사실을 알게 되었죠.


‘블로그 게시판’이라는 기이한 용어 등장


여기에도 등장

ᄒᆞᆫ글이 맞고 제가 틀릴까요? 그런데 말입니다. 티스토리에는 ‘게시판’이라는 이름을 가진 항목이 없습니다.

참고로 저 두 그림에서 “하나 만 있는 경우입니다.”라는 말은 띄어쓰기가 틀려 있다. “하나만 있는 경우입니다.”라고 써야 옳다.


아무리 봐도 게시판은 안 보입니다. 대신 ‘분류’가 있습니다.


아무리 봐도 ‘분류’를 말하는 게 아닐까요?

아무리 생각해 봐도 ‘게시판’은 위 그림에 나타난 분류를 뜻하지 않나 싶습니다. 그런데 문제는 이 ‘분류’를 가리키는 말은 따로 있습니다.


분류를 정하는 카테고리 설정

예, 그렇습니다. 카테고리가 분류를 가리키는 말입니다. Category를 해석하면 ‘분류’가 되니 당연하다면 당연한 말이겠지요. 안 그래요?

흠, 티스토리만 그런 것인가? 아닙니다.


텍스트큐브 블로그도 ‘분류’라고 합니다.

텍스트큐브 블로그도 분류라고 부르고 있습니다. 친절하게 Categories라고 영어로 병기해 주었습니다.

위의 두 블로그만 그럴까요? 아닙니다. 다음 블로그도 네이버 블로그도 모두 카테고리라고 부르고 있습니다.

4. 벌레의 원인

사람들이 쓰는 용어가 무엇인지 확인하지 않고 개발실 또는 연구실에서 작업한 듯싶다. 그렇지 않고서야 어찌 블로그에서는 전혀 쓰이지 않는 게시판이라는 용어를 쓸 수 있을까?

설령 그렇다고 하더라도 그것이 ‘카테고리’ 또는 ‘분류’를 뜻한다는 말이라도 달아 주었더라면 도움말을 참조하는 사람에게 혼동을 주는 일은 없으리라 생각합니다.

5. 비슷한 벌레

비슷한 벌레는 찾을 수 없었습니다.

6. 관련 문서

가. 내부 문서

[벌레와 팁] - HTML 태그 해석 오류 문제

[벌레와 팁] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

[프로그램/설치] - 한컴오피스2010 베타버전 설치기

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

1. 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

한컴오피스2010 베타버전에 포함된 ᄒᆞᆫ글이 가진, 버그라고 하기에는 조금 그렇지만, 아무튼 미흡한 점을 지적하고자 합니다.

1.1. HTML은 구조적 문서이거든요.

ᄒᆞᆫ글 씨! 여보세요! HTML은 구조적 문서이거든요. 내가 만든 구조는 어디에다 팔아먹으셨나요?

그림 1 index.html 파일을 읽어온다.

그림 2 인터넷 익스플로러에서 불러온 모습

그림 3 ???글2010에서 불러온 모습

언뜻 보면 ᄒᆞᆫ글2010은 HTML을 잘 불러왔다고 여겨집니다. 하지만 인터넷 익스플로러에서 불러온 모습과는 많이 다릅니다. 그래서 혹시나 하는 마음에 스타일을 불렀습니다.

그림 4 깡그리 무시된 문단 관련 태그

HTML 문서를 읽어 올 때 문단 관련 태그를 모두 바탕글 스타일로 읽어오고 있습니다. 원래 HTML은 스타일이 없지 않느냐고요? 아니요. HTML은 스타일이 없더라도 존재합니다. 그 자체로 구조적 문서를 이루기 때문이죠. 그리고 문단 관련 태그가 각각의 기능을 가지고 있는 기능성 구조를 이루고 있습니다. 예컨대 P 태그는 당연히 문단 태그입니다. 그것만 있느냐? H1, H2, …, H6 태그도 문단 기능이 있어서 P 태그 없이도 문단을 구성할 수 있습니다. 그밖에 인용문을 가리키는 blockquote 태그, 입력 내용을 그대로 보여주는 PRE 태그 등도 P 태그 없이 문단을 구성할 수 있습니다. 제가 아는 태그만 주워섬겨도 이 정도네요.

그런데 지금 ᄒᆞᆫ글 씨께서는 모조리 뭉개버리고 바탕글이라는 스타일 하나만 남겼습니다. 구조적인 문서를 읽어다가 비구조적인 문서를 만들어 버린 셈이 되었네요.

1.2. CSS도 좀 챙겨!

ᄒᆞᆫ글 씨! 여보세요! CSS는 HTML의 스타일이거든. 그건 도대체 어디에다 팔아먹은 거냐고? 도대체 알 수가 없는 일입니다.

게다가 HTML 문서를 읽어 올 때나 저장할 때 CSS 파일을 전혀 인식하지 않습니다. 저장할 때야 HTML 문서 안에 스타일을 포함시키기 때문이라지만, 읽어올 때는 CSS 내용을 읽어 와야 옳다고 생각하는데요.

요(要)는 HTML은 구조와 내용이 분리된 언어입니다. 그것을 ᄒᆞᆫ에서 읽어왔는데, 그 구조를 모두 없애버리면(문단 태그와 DIV 태그를 모두 없애 버리면) 굳이 읽어 들여야 할 이유가 없지 않을까요? 그것을 다시 저장하면 “구조적 문서”가 “비구조적 문서”로 바뀌므로 오히려 손해가 되는 측면도 있습니다.

더구나 다른 이름으로 저장에서 HTML 문서로 저장하거나, 웹브라우저로 보내기를 하거나, 웹서버로 올리기를 하거나, 모두 HTML 문서의 형태가 중시되는데, 아예 CSS는 전혀 고려하지 않는 모습을 보이고 있습니다. 특히 ᄒᆞᆫ글2010에서 새로 추가된 블로그로 올리기 기능도 실제로는 HTML 형식으로 보내게 되어 있으니 더욱 문제는 심각하다고 할 수 있습니다.

1.3. 결론

ᄒᆞᆫ글 씨! 여보세요! HTML 문서 읽어오기나 HTML 저장하기 등의 기능은 빛 좋은 개살구거든. 그냥 읽어오기에 앞서 “이 기능은 그저 내용만 확인할 수 있습니다.”라고 안내문이나 넣지 그래.

그게 아니라면 좀 더 확실히 지원하라고. CSS도 읽어서 ᄒᆞᆫ글 스타일로 변환하고. HTML로 저장할 때도 CSS 이용할 수 있는 옵션을 좀 만들어 달라고.

이 글은 한컴오피스2010에 포함된 ᄒᆞᆫ글에서 작성한 문서입니다.
일부 깨져 보이는 글자는 일부러 수정하지 않고 두었습니다. 그에 대한 팁은 나중에 올리겠습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

카테고리

분류 전체보기 (1005)
스크립트 (22)
벌레와 팁 (126)
소프트웨어 (240)
하드웨어 (6)
이야기 (24)
말의 나무 (506)
미쳐보자 (22)
일기 (48)
아이폰 (10)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

«   2024/03   »
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

글 보관함