오늘(30일) TeXLive를 업데이트하니 xdvipdfmx가 버전업되었네요(dvipdfmx와 함께). TeXLive 갱신 후에

1. installPOST 실행
2. fc-cache 실행

을 해줄 필요가 있습니다. (XeTeX users only)

14356에서 김영욱 교수님의 요청으로 만든 shortcut과 Karnes/2008-09#e5d78074c1aa87246dae8922e8bcb3fc에 있는 TeX 스타일을 합쳐서 간단 설치용으로. (기존 설정들은 백업하지 않음)

• KC2008-TL-notepadpp-style.kcupdate

• 

한TeX 1.5에 포함되어 있던 샘플 문서를 xoblivoir 문서로 변환.

• chemtex을 사용하는 예제는 좀더 최신의 패키지로 바꾸었어야 했을까?
• 제일 유명하고 화려한 htexdemo를 수정하는 것이 가장 골치아팠음. 그림을 처리하는 방식이 너무나 다르기 때문에...
• 원본 샘플도 함께 넣어두었음.
• xoblivoir를 oblivoir로 바꾸면 pdftex 컴파일 가능함. (즉, xoblivoir에 아무런 폰트 설정을 해두지 않았음.)
  
  
• 
  
  
  
  
• HTeX15-Samples.zip (149.38 KB)

FancyDocumentGallery에 있는 2004년판 simplesample을 XeLaTeX 문서로 변환하였다.

• simplesample2008.pdf (503.15 KB)
• simplesample2008.zip (373.36 KB)

참고로 당시는 hangul-k가 나오기도 전. 그래서 hangul-nojosa를 쓰던 문서였다. 비교를 위해서 pdf 문서의 링크를 걸어둔다.

• simplesample.pdf

당시에도 마음만 먹으면 이 정도 폰트 사용이 가능했다. 그러나 tfm을 일일이 만들어주어야 했고, 다른 폰트를 사용하려면 상당한 결심이 필요했다. 이 문서는 매우 정성을 들인 것이었다고 생각되지만, 위의 2008은 대충대충 수정했으니... 이제야말로 'simple'하다고 하겠다.

언제 시간이 나면 xoblivoir로 바꿔볼까나...

아마 KTUG에서 제일 유명한 또는 인기있는 샘플을 들라면, Progress 님의 shadowsample일 것이다. 도처에서 이 예제의 코드가 복제되고 활용되는 것을 본다.

xoblivoir를 이용하도록 약간 손본 것을 올려둔다. Progress 님이 보시면 제대로 된 판본을 만들어주실 것이다.

• shadowsample_sample.zip (13.45 KB)
• sahdowsample_sample.pdf (242.11 KB)
  
  

Jonathan Kew의 BachoTeX2008 (2008/05/02) 발표 슬라이드의 일부

달라졌다기에는 뭣하지만 어쨌든 달라진 것.

1. dvi를 사용하지 않는다
   • 의문점 : 느리고(pk 글꼴을 생성해야 하니까), 무겁고(yap의 경우 ps 그림을 디스플레이하려고 얼마나 버벅대는지 경험해보신 분은 알 것임... 차라리 dviout처럼 그냥 못 그린다고 하고 말 일이지...), 불완전하고(dvi viewer에서 보이지 않는 결과가 꽤 많지, 아마?), 불편한(문제가 생기면 대책이 없는...) dvi viewer를 계속 사용하는 이유는 무엇일까? 이 모든 문제가 dvi viewer를 쓰지 않으면 해결된다.
   • 배경 : dvi previewer, 즉 화면용 dvi 해석기는 구시대의 유물이다. 우선 dvi란 것 자체가 특정 기계를 위한 출력 포맷이 아니며, 따라서 화면 디스플레이라는 제한된 장치에서 dvi의 모든 속성을 모두 표시할 수 없다. 화면 디스플레이는 최종 출력물을 먼저 만들고 이것을 화면용 그림으로 변환하여 보여주는 것이 이론적으로나 실제적으로나 최선이다.(이것이 pdf viewer가 하는 일이다.) dvi는 최종 출력물이 아니며, 아직 해석되지 않은 잠정적 출력 형식에 불과하므로, 이것을 화면용으로 직접 번역하려 하는 것은 이론적으로 무리. 그러자면 dviware가 포스트스크립트, pdf, 그림포맷 등 다양한 special들을 모두 해석하는 말 그대로 만능 프린팅 드라이브를 내장해야 하는데, 그게 가능한 일이겠는가? 예전 dvi viewer들은 섬세한 그림 표현이나 special 표현들을 전부 사상하고, 오직 글자와 레이아웃을 거칠게 대강 보는 것으로 만족하던 시대에 쓰이던 것이다. dvi viewer에서 그림의 채도가 떨어진다든가 미세한 길이가 안 맞다든가를 따지는 현대의 사용자에게 거의 무의미. 그래도 최근까지 dvi viewer가 사용되었던 유일한 이유는 -src-specials를 이용한 에디터와의 연동 때문이었다고 생각한다. 그러나 synctex 기술에 의하여 source special inverse search가 대체되어 가는 지금 이마저도 그 의미가 사라졌다.
2. eps를 쓰지 않는다
   • eps는 자동 생성 자동 처리되는 포맷으로만 쓰여야 한다. 사용자가 자신의 그림을 eps로 변환하거나 준비할 필요가 없다. pdf export가 가능한 모든 프로그램에서 그림은 pdf로 출력하면 된다.
   • 배경 : eps는 구시대의 유물이다. 즉 dviware가 dvips밖에 없던 시절에 외부 그림을 포함하기 위하여 만들었던 것이다. 또는 다르게 말하면, postscript 인쇄기에게 그림을 전달하기 위해 사용하던 포맷이다. 지금 postscript 인쇄기들은 pdf를 잘 해석할 것이다. eps를 계속 유지하여야 할 이유가 없다. 게다가 대부분의 친숙한 그림 소프트웨어들이 eps를 잘 모르거나 잘못 처리한다. (물론 eps를 잘 다루는 그림처리기들도 있지만).
3. tfm 폰트를 만들기 위해 고민하지 않는다
   • 돌이켜보면, UHC 이외의 글꼴(트루타입)을 사용할 수 있게 되었을 때 얼마나 신기해했던가. 그 때가 언제였더라, 몇 년 된 것 같지도 않다.
   • 그리고 이제 폰트 문제는 (거의) 결정적으로 완전히 해결되었다. 폰트 패키지를 만들어 제공해야 했던 2006--2007의 불편함도 없어졌다, 고 나는 생각한다. (즉, 폰트 패키지를 제작하는 일은 이제 없을 것이라는 것임.)
   • 다만 이제, 다른 사람에게는 있는 폰트가 나한테 없어서 컴파일이 안 되는 소스가 점점 많아질 거라고 생각하니, 우울해진다.
     
     

1992년에 쓰여진 hlatex technical guide (최우형, 1992) 에 보면(유물보관 참고), 다음과 같은 구절이 있다.

1. 수학 모드에서 한글 사용 불가능
2. verbatim 환경에서 한글 사용 불가능
3. label 이름으로 한글 사용 불가능
4. 에러 메시지 해석의 어려움
   
   

그로부터 16년이 지난 현재까지, 이 과제가 어떻게 해결되어 왔는지 잠깐 요약한다. (1) 수학 모드에서 한글 사용 (2) verbatim 환경에서 한글 사용 (3) label 이름으로 한글 사용

• HLaTeX에서 label 이름으로 한글을 사용할 수 있었다.
• 그러나, hyperlink를 만들어야 하는 상황에서 한글 label 이름은 충돌을 빚음. 결국 HLaTeX의 한글 label 이름 기능은 별 쓸모가 없게 되어버리고 말았다.
• 현재까지 hyperlink도 보존하면서 label 이름으로 한글을 사용할 방법을 찾지 못했다.
• 그러나, XeLaTeX에서 이 문제가 해결되었다. 즉, 한글 매크로 레벨에서가 아니라 텍 엔진 레벨에서 문제가 해결된 셈.
  
  

(4) 에러메시지 해석의 어려움

• hLaTeXp는 한글 메시지를 보여주기 위한 별도의 TeX compiler를 만들었다. 그 후 한글LaTeX의 발전은 매크로 레벨에서 진행되었기 때문에 이 방식은 더 이상 계승되지 않았다.
• 초창기 hlatex 0.91과는 다른 상황이지만 (그 당시에는 전처리된 한글을 메시지로 보여줄 방법이 없었던 것이므로 현재와는 사정이 많이 다르다) 오늘날 이 문제는 매크로가 유니코드 UTF-8인데 윈도우즈 터미널(cmd)이 cp949이기 때문에 발생하는 어려움으로 남아 있다.
  • Linux나 Mac의 터미널에서는 utf-8을 보여주는 데 어려움이 없다.
  • Windows의 code page 65001은 utf-8을 처리하기는 하지만 메시지를 보여주는 용도로는 거의 쓸모가 없다. 게다가 파일 이름이 cp949이기 때문에 코드 페이지를 65001로 하면 한글 파일 이름을 쓰기 어려워진다.
• 이 문제의 편의성 때문에 유니코드가 아닌 euc-kr 또는 cp949로 돌아갈 수는 없는 것으로 생각된다.
• 현재 Windows에서 이 문제의 해결 방향은 TeXWorks와 같은 방법이 유일한 것이 아닐까? 어쨌든 TeXWorks는 에러 메시지를 잘 캡처해서 보여주는 것이다.
• 아니면, TeX 전용의 터미널을 만들어야 할까, 윈도우즈만을 위해서.