KTUGFaq
![[http]](/wiki/imgs/http.png)
달라졌다기에는 뭣하지만 어쨌든 달라진 것.
- 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가 대체되어 가는 지금 이마저도 그 의미가 사라졌다.
- eps를 쓰지 않는다
- eps는 자동 생성 자동 처리되는 포맷으로만 쓰여야 한다. 사용자가 자신의 그림을 eps로 변환하거나 준비할 필요가 없다. pdf export가 가능한 모든 프로그램에서 그림은 pdf로 출력하면 된다.
- 배경 : eps는 구시대의 유물이다. 즉 dviware가 dvips밖에 없던 시절에 외부 그림을 포함하기 위하여 만들었던 것이다. 또는 다르게 말하면, postscript 인쇄기에게 그림을 전달하기 위해 사용하던 포맷이다. 지금 postscript 인쇄기들은 pdf를 잘 해석할 것이다. eps를 계속 유지하여야 할 이유가 없다. 게다가 대부분의 친숙한 그림 소프트웨어들이 eps를 잘 모르거나 잘못 처리한다. (물론 eps를 잘 다루는 그림처리기들도 있지만).
- tfm 폰트를 만들기 위해 고민하지 않는다
- 돌이켜보면, UHC 이외의 글꼴(트루타입)을 사용할 수 있게 되었을 때 얼마나 신기해했던가. 그 때가 언제였더라, 몇 년 된 것 같지도 않다.
- 그리고 이제 폰트 문제는 (거의) 결정적으로 완전히 해결되었다. 폰트 패키지를 만들어 제공해야 했던 2006--2007의 불편함도 없어졌다, 고 나는 생각한다. (즉, 폰트 패키지를 제작하는 일은 이제 없을 것이라는 것임.)
- 다만 이제, 다른 사람에게는 있는 폰트가 나한테 없어서 컴파일이 안 되는 소스가 점점 많아질 거라고 생각하니, 우울해진다.
