KTUGFaq

KTUG FAQ

로그인:
비밀번호:
가입
Your mode of life will be changed for the better because of new developments.
FrontPage › 한글검색및추출
PDF / 한글 검색 및 추출

ko.TeX과 pdf 한글 검색 및 추출

ko.TeX은 한글의 검색과 추출이 가능한 pdf를 만들 수 있도록 제작되었다. pdfTeX으로 컴파일할 때, 다음과 같은 지시가 필요하다.
  • type 1 폰트 사용시
    \input glyphtounicode\pdfgentounicode=1
    
  • 트루타입 사용시
    \usepackage{dhucs-cmap}
    


ko.TeX의 developing branch에 속하는 xetexko와 luatexko에서는 다른 절차 없이 당연히 한글의 검색과 추출이 가능한 pdf가 생성된다.

oblivoir 클래스는 위와 같은 설정을 자동으로 행하므로 다른 지시가 필요하지 않다.


여기서부터 예전 내용입니다.

PDF 한글 텍스트의 검색 추출이 필요한 이유

  • 개방적인 온라인 문서를 PDF 형식으로 제공한다면 텍스트의 검색과 추출은 필수적이다.
  • 구글 신 등 검색 엔진에서 대상 문서를 검색할 수 있게 하기 위해서 필요하다.

TeX에서 한글 텍스트의 검색 추출 가능한 PDF 제작

영문 문서의 경우 PDF에 사용된 폰트가 "참조 불가능한" PK 비트맵인 경우 텍스트열의 검색과 추출은 불가능하다. 그러나 Type 1이나 트루타입과 같이 인코딩 정보를 가지고 있는 폰트가 사용되었다면 가능하다. MetaFont는 pdf로 변환하는 DVI드라이버가 "참조할 수 없는" 글꼴이므로 MetaFont 글꼴을 사용하도록 제작된 DVI는 검색 추출 가능한 PDF를 만들 수 없다. MetaFont로 제작된 것이라 해도 DVI드라이버가 "참조가능한" 글꼴로 치환하도록 하는 방법이 있다. 예를 들면 dvips -P pdf와 같은 옵션은 적절한 font map을 제공함으로써 치환 가능한 Type 1 글꼴로 Computer Modern 글꼴을 대신 사용하게 함으로써 깔끔한 PDF를 생성해낼 수 있는 ps 파일로 번역해준다.

HLaTeX의 경우 기본 글꼴은 UHC이다. 이 글꼴은 Type 1 글꼴이기는 하나 한글 문자 영역을 256자씩 잘라서 만든 subfont 형식의 vf 폰트로 이루어져 있다. 실제의 pfb들은 자소들만을 포함하고 있고 vf를 통하여 이 자소를 조합하여 한글 문자를 표현한다. 이와 같은 원리상 UHC 글꼴을 사용하여 제작된 PDF는 텍스트의 검색과 추출이 원천적으로 불가능할 수밖에 없다. dvipdfmx를 이용하든 pdflatex을 이용하든 마찬가지이다. UHC 글꼴은 화면에 한글이 표시되는 데 만족하여야 할 것이다.

DVIPDFMx는 한글 트루타입/오픈타입 글꼴에 대하여 CID 폰트 기술을 적용함으로써 검색 추출 가능한 PDF를 만들어낼 수 있는 기능을 갖추고 있다. 이것은 현재 여러 DVI 드라이버 중에서 DVIPDFMx만이 가진 기능이며 subfont 기술과 CID 폰트 기술을 결합하여 구현한 것으로 알고 있다. 기술적인 더 자세한 사항은 DVIPDFMx의 소스 코드를 참고하라. 그러므로 .tex 소스로부터 .dvi를 만들어내기까지는 subfont 형식의 폰트 참조를 하고 그 이후 DVI의 번역 과정에서 subfont를 CID 트루타입 글꼴과 연계하여 우리가 원하는 PDF를 얻어내는 것이다. 그 결과 tex 번역기에게는 subfont 형식으로 조성된 .tfm 파일들을 통하여 폰트 정보를 알려주어야 하고 이 폰트 정보가 subfont인 것과 거기에 상응하는 .ttf 폰트에 관한 정보는 dvipdfmx.cfg와 .map 파일을 통하여 dvipdfmx에게 알려주어야 한다.

오픈 소스 글꼴 가운데 은글꼴은 이 목적에 사용하기에 가장 적합하다. 일반적으로 subfont 한글 .tfm 폰트와 거기에 상응하는 .ttf(.otf), 그리고 DVIPDFMx를 위한 map 파일이 갖추어지면 한글 입력된 .tex 소스로부터 검색과 추출이 가능한 .pdf를 얻어낼 수 있다.

pdftex(현재 버전)의 경우는 트루타입 글꼴은 인식하지만 tex과 마찬가지로 .tfm만을 참조한다. 그러므로 예컨대 UnBatang.ttf를 pdftex에게 알려주기 위해서는 이것을 일단 ac00에서 시작하는 수십 개의 subfont tfm들로 만든 다음 각각의 tfm subfont에 해당하는 인코딩 정보 파일(.enc)을 함께 제공해야 한다. pdftex은 .tex 문서로부터 subfont 참조 형식으로 폰트를 사용하여 pdf를 만들어내기 때문에 한글 텍스트는 각각의 해당 서브폰트 내에서의 인코딩 위치로만 참조될 뿐이므로 비록 트루타입을 사용하였다 하나 텍스트의 추출에는 실패할 수밖에 없다.
(!) pdftex 자신이 이 문제를 해결할 수 있도록 개선되는 것이 최선이지만 Hangul-ucs는 패키지 수준에서 cmap 정보를 pdf에 추가하는 루틴을 통하여 pdftex에서도 한글 텍스트의 검색과 추출을 가능하게 하는 dhucs-cmap 패키지를 제공한다.

사용자 수준의 pdf 제작 지침

이상을 요약하면 다음과 같다.

Hangul-ucs를 이용하여 문서를 작성한다. 한글 텍스트를 UTF-8로 입력하고 기본 글꼴(은글꼴)을 사용하거나 별도의 트루타입 패키지를 이용하되 UHC 글꼴만은 사용하지 말고, latex -> DVIPDFMx을 거쳐 pdf를 만들거나, pdfTeX을 위한 dhucs-cmap을 이용한다.

% \usepackage{ifpdf}
\ifpdf
\usepackage{dhucs-cmap}
\pdfmapfile{+unttf-pdftex-dhucs.map}
\fi

검색과 추출을 원하지 않는다면

PDF 제작자가 문서의 열람은 가능하게 하되 검색과 추출 또는 인쇄 등을 제한하고자 할 경우가 있다. 학위논문이나 상업성있는 문서 등이 그러한 경우일 것이다. DVIPDFMx는 이러한 경우에 적절한 옵션을 줌으로써 PDF의 특정 기능에 암호를 걸 수 있게 하고 있다. PDFEncryption을 참고하라.

KC2006과 pdf 한글 텍스트 검색 추출

KTUGBoard:5686
KC2006PDFTeX, LaTeX/dvips/ps2pdf, LaTeX/DVIPDFMx를 이용하여 한글 텍스트의 검색 추출이 가능한 pdf를 만들 수 있도록 설정되어 있다. 다음은 테스트 파일이다.
@extraction.zip (163.75 KB)
이 테스트 파일에 사용된 기법은 다음과 같다.

dvi driver 사용 폰트 방법
PDFTeX truetype dhucs-cmap
PDFTeX type 1 dhucs-cmap or \pdfgentounicode=1
DVIPDFMx truetype *
DVIPDFMx type 1 *
dvips type 1 *

이 테스트에 사용된 각 드라이버 버전은 다음과 같다.
  • dvipdfmx : 20051229(cvs)
  • pdftex : 1.40.0-20060725
  • dvips : 5.95b


DeleteMe 한글추출에 관한 이슈를 정리 부탁드립니다. 그리고 페이지 이름도 제안해주세요. 한글검색및추출하기 ?

DeleteMe HLaTeX의 경우라도 UHC 대신 은글꼴을 사용함으로써 텍스트의 검색 추출이 가능하게 만들 수는 있지만 hyperref을 붙여서 여러 가지 PDF 장치들을 만들어넣는 데 좋은 방법이 되지 못하기 때문에 pdf 제작만을 target으로 하고 "반드시" EUC-KR을 써야만 한다면 hangul-k 패키지를 이용하는 방법이 있습니다. 그러나 일반적으로 DHUcs는 바로 이 목적을 의식하고 제작된 패키지이므로 좀더 나은 결과를 얻을 수 있다고 생각하고 있습니다. 또 Omega/Lambda는 텍스트의 검색 추출은 역시 트루타입 글꼴과 DVIPDFMx를 이용하여 가능하기는 하겠지만 pdf 제작에 이런저런 한계를 가지고 있는 까닭에 pdf 제작용으로 추천하기 어렵습니다. 결론은 온라인 문서 제작에 HLaTeX이 썩 좋은 선택은 아니라는 것입니다만, 이것은 주관적인 판단입니다. ---Karnes

^
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2011-09-15 11:56:11
Processing time 0.0496 sec