목차

• ver. 20050111
  • dvipdfmx 20040912에 따른 map 파일 생성, DHUcs를 위한 *.fd, *.map 파일 생성
• ver. 20041023
  • dvipdfmx 최근판의 fakebold 옵션 지원. config 파일에서 m의 값과 b의 값이 동일한 경우 cid map에 -b 옵션이 자동 추가됨.
• ver. 20040705
  • ovp 교정루틴 수정 및 관련 버그 픽스
• ver. 20040420
  • sty파일에 \def\hfontfamilynameprefix{xx} 및 \ProvidesPackage{xxttf} 추가.
• ver. 20040322
  • 한자영역이 들어있지 않은 폰트를 사용한 경우에 omega에서도 한자가 식자되도록 교정하는 루틴을 추가함.
• ver. 20040202
  • omega의 디폴트 cmap을 Identity-H로 수정. dvipdfmx 20020202(cvs)의 변경사항을 반영.
• ver. 20031121
  • windows98에서 완성형글꼴을 제대로 처리하지 못하던 문제 수정.
  • Lambda에서 쓰일 cmap을 폰트별로 지정할 수도 있게 함. 개별적 cmap은 각진괄호 [ ] 안에 지정한다. 예컨대 다음과 같이 설정하면 Identity-H는 오직 Lambda 사용시의 Hybatang.ttf에만 적용되고, 다른 폰트에는 OmegaCMap:에서 지정한 것 또는 프로그램의 기본값인 UniKSCms-UCS2-H가 적용된다.

FONTmj: f=bt m=Hybatang.ttf[Identity-H]

• ver. 20031117 .sty 파일의 MapHangulFamily{}{} 부분을 교정하는 루틴을 추가.(이제 스크립트 실행 후 막바로 test.tex을 에러없이 컴파일할 수 있다.) -d 옵션을 주면 이 기능을 사용하지 않는다.
• ver. 20031111 Truetype Collection(TTC) 폰트 지원. 예컨대 다음과 같이 설정하면 batang.ttc의 2번 인덱스, 즉 궁서글꼴이 선택된다:

FONTgs: m=batang.ttc(2)

• ver. 20031110
  • 스타일파일의 설정을 hfont.tex과 ksx1001.tex을 참조하여 고침
  • 람다용 cmap과 sfd를 CONFIGFILE에서 사용자가 지정할 수 있도록 함. 이러한 지정이 없을 경우 기본값은 각각 UniKSCms-UCS2-H와 Unicode임. 예:

OmegaCMap: Identity-H
OmegaSFD: UKS-HL

• ver. 20031026 cfg 파일 끝에 행끝문자가 없을 때 설정이 윗줄에 이어 써지는 버그 수정
• ver. 20031025 사용자가 f 필드를 정의하지 않았을 경우 FONTxx의 xx를 f 필드의 값으로 사용토록 함
• ver. 20031023 완성형 한글TrueType 폰트 처리루틴 추가. Release. cf. 867
  
  

1. Perl
   Windows 시스템의 경우 ActivePerl을 추천합니다. CygWin이나 Unix/Linux 시스템에서는 Perl이 대부분 설치되어 있을 것입니다.
2. HLaTeX 0.991 이상
   HLaTeX의 설치에 대해서는 HLaTeX 페이지를 참고하십시오.
3. ttf2tfm, ttf2pk (freetype-contrib)
   • ttf2tfm/ttf2pk는 1.5 버전 이상이 필요합니다. 참고. ttf2tfm/ttf2pk 설치(http://doc.ktug.or.kr/ktug-doc/makettfavailable/node18.html)
   • 추가적으로, Lambda를 위한 설정을 하려면 Omega-패치가 적용된 ttf2tfm이 필요합니다.
     • Unix/Linux 시스템에서는 다음 패치를 적용하여 ttf2tfm을 컴파일하여야 합니다.
       http://ftp.ktug.or.kr/KTUG/freetype/contrib/ttf2pk-1.5-20020430.patch
     • Windows에서는 MiKTeX-KTUG과 W32TeX에서 이 패치가 적용된 ttf2tfm이 포함되어 배포됩니다.
4. Linux teTeX의 경우, Lambda를 위한 설정 과정에서 ovp2ovf가 잘 작동하지 않으면 다음 파일을 다운받아 이용해보십시오.
   ovp2ovf
   
   

1. 유니코드 및 완성형 한글 TrueType 글꼴에서 TFM 추출
2. DVIPDFMx, PDFLaTeX, HLaTeX/Lambda를 위한 TFM과 map 파일 생성 기능
3. 스타일 파일과 폰트정의(*.fd) 파일의 자동 생성
4. DVIPDFMx와 PDFTeX 및 ttf2pk를 위한 cfg 설정 파일 자동 업데이트
5. 테스트 파일의 생성
   
   

1. 글꼴을 준비하고 글꼴 이름과 글꼴 대응을 미리 정해둔다.
   
   
2. config-my 파일을 작성한다.

   FOUNDRY:	my
   #FONT..:	f=family m=medium.ttf b=bold.ttf l=light.ttf
   FONTmj:	f=bt m=nbatang.ttf	b=h2mjrb.ttf
   FONTgt:	f=gt m=dotum.ttf	b=hmfbg.ttf
   FONTgl:	f=gl m=gulim.ttf	b=h2drrb.ttf
   FONTgr:	f=gr m=ynch05.ttf
   #FONTgs:	f=gs m=gungseo.ttf	b=gungseobold.ttf
   

   이 예는 본문에서 들고 있는 폰트 대응을 따랐습니다. 다만 mj는 family name을 bt로 바꾸었습니다.
   
   
3. 다음과 같이 실행한다.

   #> perl ttf2hlatexfont.pl -c config-my
   

   
   
   
4. 만들어진 test.tex 파일을 LaTeX으로 돌려본다.
   
   
5. 필요하다면 만들어진 파일들을 texmf-tree로 인스톨한다. (스크립트의 -i 옵션)
   
   

• FIXME
  
  

• TFM 파일의 이름짓기는 한글TeX글꼴이름에서 토론된 내용을 바탕으로 하고 있습니다.
• 한글TrueType글꼴사용
  
  

1. PDFLaTeX에서는 기울임 글꼴을 지원하지 않습니다. 그러므로 oblique(slanted) 시리즈의 글꼴이 만들어지지 않습니다.
2. PDFLaTeX에서 만들어진 한글PDF는 텍스트의 검색 추출이 되지 않습니다.
3. PDFLaTeX은 Omega/Lambda를 지원하지 않습니다. 즉, PDFLambda 형태로 쓰지 않습니다.
   
   

1. 일부 한글 TrueType 글꼴은 상징문자(심볼)나 한자가 포함되어 있지 않을 수 있습니다. 원래 이런 글꼴로 TFM을 추출하였을 때 해당하는 문자가 본문에 쓰이면 Bad Font Metric 에러가 나타나므로, 자신이 사용하려 하는 글꼴이 한자 영역을 포함하고 있는 것인지 확인하여야 합니다. 하지만 20031116 버전부터는 이러한 에러를 교정하는 루틴이 추가되었으므로 TTF 이용이 훨씬 편리해졌습니다.
   그러나 자동 교정은 사람이 일일이 확인하며 수정하는 것에 미칠 수 없습니다. 자동교정된 부분이 문제가 있다고 판단되면 .sty 파일을 열어 수정하시기 바랍니다. 예를 들어 스타일 파일에서

   \MapHangulFamily{gl}{xxgl,xxgt,xxgt}
   

   와 같이 되어 있는 경우, 두번째 { } 안에 순서대로 한글영역에는 xxgl, 기호영역에는 xxgt, 한자영역도 xxgt가 각각 지정된 것입니다. 이 부분을 사용자의 선택에 따라 다른 글꼴로 교체할 수 있습니다.
   
   

1. 이 스크립트는 Omega/Lambda용 subfont 추출을 위한 sfd 파일과 cmap 파일을 사용자가 설정할 수 있도록 하고 있습니다. 새로운 cmap/sfd 파일을 사용하여 발생하는 문제에 대해서는 사용자 자신이 책임을 져야 할 것입니다.
2. Unicode cmap으로 Identity-H를 사용하는 경우 조합형 글꼴을 포함하는 아주 큰 파일의 경우 DVIPDFMx가 처리하지 못하는 문제가 있습니다.
3. UKS-HL.sfd를 사용하는 경우 em-dash ligature나 en-dash ligature를 처리하지 못하는 문제가 있습니다.
   
   

1. 예를 들어 -i c:\texmf-myttf 와 같은 형태로 스크립트를 실행한 경우 c:\texmf-myttf가 생깁니다. 이 디렉토리를 TEXMF-ROOT로 등록하고 Refresh Filename Database를 실행하십시오. 예컨대, MiKTeX의 경우 initexmf -u, teTeX의 경우 mktexlsr
2. 스크립트가 만들어낸 설정파일(cfg)들은 기존의 설정 파일에 필요한 새로운 설정을 추가한 것입니다. 이 파일들은 새로 만들어진 texmf 트리 아래에 놓여 있습니다. 이 파일들이 효력을 발휘하도록 하려면, 자신의 TEXMF TREE들 가운데 가장 먼저 놓인 TEXMF TREE의 설정 파일 위치로 해당 파일들을 옮기든가, 아니면 새로 만든 TEXMF TREE를 가장 앞쪽 순위로 가져다두든가 하면 됩니다. 만들어지는 설정파일들은 다음과 같습니다.
   1. dvipdfmx.cfg : cid-xxttf.map을 포함하도록 추가됩니다.
   2. pdftex.cfg : xxttf-pdftex.map이 포함되도록 추가됩니다.
   3. ttf2pk.cfg : xxttf2pk.map이 포함되도록 추가됩니다.
      
      

489:
  print CFG @Lines,"\n\% ${foundry}ttf -- added by ttf2hlatexfont.pl\n$line\n";

  '^^b0^^a1^^b2^^e5^^b5^^cb^^b8^^b1^^ba^^f5^^bd^^db'.
  '^^c0^^c1^^c3^^a7^^c5^^eb^^c8^^d1 ^^a8^^b1^^a1^^db^^aa^^a2^^a5^^d2'.
  ' ^^ca^^a1^^cc^^e5^^cf^^cb^^d2^^b1^^d4^^f5^^d7^^db^^da^^c1^^dd^^a7'.
  '^^df^^eb^^e2^^d1^^e5^^b7^^e7^^fb^^ea^^e1^^ed^^c7^^f0^^ad^^f2^^f1'.
  '^^f5^^d7^^f8^^bd^^fb^^a3^^fd^^e7'

일단 ps 파일을 만드는 데 성공하였습니다. ttf2pk.cfg에서, 원래 맨 마지막 줄에 있던 산돌폰트의 맵 파일의 위치를 이리저리 바꾸니 잘 됩니다. ttfonts.map 바로 밑에 놓으니 잘 됩니다. --Progress

ttf2pk.map의 ttfonts.map에 혹시 +가 붙어있지 않았던 것은 아닌지요? 그렇지 않으면 다른 맵 파일 위치에 좌우되는 경우는 동일한 폰트 정의가 들어 있는 경우뿐인데.... 어떤 문제인지 확인해주실 수 있으신지요? --Karnes

+가 붙어있지 않았던 것은 아닙니다. (실은 전에도 이 비슷한 문제를 겪은 적이 있습니다.) 다른 맵과 중복되는 동일한 폰트 정의 문제도 아닙니다. 그리고 일전에 TeX root 디렉토리를 추가하면서 texmf 디렉토리를 localtexmf 바로 밑에 두어야만, 잘 인식되던 문제는 여전합니다. (777) --Progress

희한하군요.... 거 참.... 혹시, 산돌폰트 map 파일의 파일이름이 ttf2pk용과 dvipdfmx용이 동일하거나 하여 map 파일 찾기 문제가 발생한 것은 아닌지요? 아무튼지간에, 이번에 올리신 test.pdf는 처음시작하기에 원래 같은 이름의 파일이 링크되어 있었습니다. 덮어쓰기 문제가 발생하여서 처음시작하기가 이상해져버렸습니다... test.pdf와 같은 평범한 이름의 파일은 지양해주시면 감사하겠습니다. 처음시작하기의 파일 이름을 수정해야겠습니다. --Karnes

죄송합니다. 저도 test.pdf로 올리고 나서 얼른 삭제하려고 UploadedFiles를 찾아가서 체크박스에 표시하고 delete하려 했더니, 안 지워졌습니다. sdtest.pdf라 지으려 했거든요. 가능하시면 제가 올린 파일을 바꿔주십시오. 참, map 파일은요, TTF2HLaTeXFont 스크립트를 쓰면서 config 파일의 내용에 따라 자동으로 다르게 생성되는 것 같습니다. 이를테면 제가 foo font를 쓰기 위해 config-foo 라고 config 파일을 만들면, dvipdfmx용 map은 cid-foottf.map으로, dvips용 map은 foottf2pk.map으로 생성됩니다. 그러니 map 파일을 혼동하지는 않을 것입니다. ^^. 암튼 재미있습니다. 운영체제의 문제가 아닌가, 그리고 MiKTeX의 구조적 문제가 아닌가 생각해봅니다. --Progress

저도 ttf2pk가 제대로 동작하지 않아서 truetype 글꼴을 쓴 경우 dvips나 odvips로 ps를 만들 수 없습니다. ttf2pk.cfg를 이리저리 손대 보아도 안 되는군요. dvipdfmx가 잘 돌아가니까 별 문제가 없기는 하지만, PS 프린터로 인쇄하기 위해 pdf를 만든 후에 다시 ps로 변환하니까 좀 비효율적입니다. (단, dvips/odvips는 아직 ttf를 type 8 글꼴로 임베드하는 기능이 없는데 반해 - 없는 것 같습니다. 맞지요? - dvipdfmx는 ttf를 임베드할 수 있어서 좋기는합니다.) 저는 Linux Fedora Core1을 쓰고 있습니다. 다음과 같은 에러 메시지가 나옵니다.

 kpathsea: Running mktexpk --mfmode ljfzzz --bdpi 1200 --mag 1+0/1200 --dpi 1200 ungtm4
    /usr/bin/mktexpk: line 255: 24354 Segmentation fault     ( ttf2pk -t -q $NAME ) >/dev/null 2>&1
    mktexpk: don't know how to create bitmap font for ungtm4.
    dvips: Font ungtm4 not found, characters will be left blank.

ttf2tfm/ttf2pk는 freetyp1 cvs를 받은 후에 여기에 있는 패치를 적용해서 ofm 파일 등을 만들 때에는 아무 문제 없이 동작했습니다. mktexpk는 1.28 (2002-11-11)이고, kpathsea는 3.4.5입니다.혹시 비슷한 일을 겪으신 분 계신지 궁금합니다. 참, 편리한 스크립트를 만들어 주신 김도현님께 감사 드립니다.-- 신정식

ttf2tfm/ttf2pk에 대해서 이루어진 패치는 제가 알기로 세 개인 것으로 알고 있습니다. 하나는 박원규 님의 것이었고, 나머지 둘은 조진환 님의 패치였습니다. 조진환 님의 첫번째 패치는 -l 및 -L 옵션, 즉 ligature를 처리하는 것이었는데, 이것은 1.5버전에서 반영된 것으로 알고 있습니다. 두번째 패치는 -o 옵션, 즉 Omega/Lambda 지원인데 이것은 공식 버전에는 반영되지 않은 것 같습니다. 박원규 님의 패치는 ttf2tfm/ttf2pk를 freetype2 와 연동한 것이었던 것으로 알고 있습니다만, 역시 이것이 정식 버전에 반영되지 않은 것으로 기억합니다. 결국 CJK Truetype을 이용하기 위한 ligature 처리는 현재의 모든 ttf2tfm/ttf2pk에서 가능하지만 Omega/Lambda를 위한 ttf2tfm/ttf2pk는 Windows에서는 MiKTeX-KTUG 2.2/2.3, W32TeX에 포함된 것에서만 지원되고 fpTeX은 이것이 불가능한 것으로 보입니다. Unix, Linux 쪽에서는 freetype1 cvs를 통해서 받은 다음 위의 패치를 사용자가 직접 적용해야 할 것으로 생각됩니다. 만약 ttf2tfm이 1.4 버전 이하라면 한글 TrueType조차도 처리할 수 없을 것이라고 생각합니다. ---Karnes

자세한 답변에 감사드립니다. 하지만, 저도 이미 ttf2tfm/ttf2tk CVS (오늘 다운로드 받은 따끈따끈한. 즉 1.5 이후인) 소스에 여기 있는 Omega/Lambda를 위한 패치를 적용했습니다. 그렇지 않다면, 김도현님의 펄 스크립트를 돌리는 단계에서 (ttf에서 ofm을 생성할 수 없으므로) 더 나아갈 수 없거든요. 문제는 어떤 이유에서인지 ttf2pk -q -t fontname가 segmentation fault를 내는데에 있습니다. debug optin을 주고 컴파일해서 gdb로 추적해 보아야할 듯 싶습니다. ---신정식

위에 올린 글은 신정식 님께 드리는 말씀이었다기보단, 그냥 써둬야 할 문제라고 생각해서 메모해둔 것입니다. segmentation fault는 제가 알 수 없는 문제입니다마는, 우선 freetype1 라이브러리가 문제가 된 것은 아닌지 의심해봅니다. 혹시 문제와 해결책을 발견하시면 알려주시면 감사하겠습니다. 제가 가지고 있는 한컴리눅스에서는 별 문제없이 잘 돌아가고 있습니다. ---Karnes

제가 그 작업을 하던 때가 늦은 (이른?) 시간이어서였는지 정신이 없었나 봅니다. 제 컴퓨터에 있던 두 개의 freetype1-contrib tree 가운데 하나에만 패치를 적용한 듯 싶습니다. 그런데, 왜 ofm은 제대로 만들어졌는지는 저도 모를 일입니다. 어쨌든, 다시 정신을 차리고 패치를 적용하고 컴파일해 보니 아무 문제가 없습니다. 괜히 문제도 없는데, 있는 것처럼 해서 죄송합니다. --- 신정식

올려주신 test.pdf는 전적으로 정상입니다. 제가 의미없는 문자열을 나열한 것은 만들어진 tfm들을 하나하나 다 확인하기 위한, 의도적인 것이었습니다. 즉 KS-HLaTeX.sfd의 각 평면(plane)별로 하나씩 글자를 집어넣다보니 그렇게 되었습니다. 아시다시피 한글평면은 0..9, 기호는 04..07, 한자는 10..29까지로 구성되어 있습니다. 하나의 TTF에서 만들어지는 tfm갯수가 34개가 되고 이들을 하나씩 다 테스트해보기 위한 것이었습니다... 그리고 test.pdf같은 평범한 파일이름 문제는 제게도 일말의 책임이 없지 않습니다. 테스트파일의 이름을 testlatex.tex과 같이 바꾸어야겠습니다. 관리자 입장에서도 더이상 변경의 여지가 없다고 확신하는, 평범한 이름의 파일이 올라 있다면 이것의 권한을 읽기전용으로 변경해두는 등의 방책을 강구할 수 있을 것으로 생각합니다. -- DohyunKim

아, 그렇군요. 테스트 파일의 컴파일은 항상 깔끔하게 잘되는데, 내용이 비범(?)한지라 한번 확인해두고자 함이었습니다. ^^. 감사합니다. --Progress