UnBatang.otf.zip (2.61 MB)

• about pdfcomment, Karnes/2008-12#21
• pdfcomment vs. pdfmarginpar

  pdfcomment\	pdfmarginpar
  pdftex, xetex	pdftex only
  easy	easier

AdobeReader only.

• pdf: pdflayertest.pdf (673.94 KB)
• src: pdflayertest.zip (351.28 KB)

• pdf: todonotestest.pdf (53.05 KB)
• src: todonotestest.tex (2.4 KB)
  
  
• 만약 비정상적인 pdf가 만들어지는 경우, shadow 옵션을 끄거나, oblivoir/pdflatex으로 컴파일하세요.
  
  

최근 올라오는 질문 중 압도적인 비중을 차지하는 것은 대략 다음과 같이 정리할 수 있는 것이다.

특히 첫번째 것은 "KC2008에 뭔가 문제가 있는 것 아닌가요?"라는 뉘앙스를 띠고 있고, 실제로 어떤 블로거께서 "KC2008은 호환성에 문제가 있어서 MiKTeX으로 돌아갔다"고 적어두신 것을 보았다.

일단 위의 두 가지 문제는 본질적으로 동일한 것이다. 즉, 두번째 질문은

• 그림을 eps로 준비했으며
• Yap으로 볼 때는 그림이 보였으나
• WinEdt의 pdf 변환(아마도 pdflatex 컴파일 버튼일 듯) 버튼을 눌러보았더니 그림이 안 나온다

는 상황일 것이며, 첫번째 질문은

• MiKTeX에서는... 이라 한 것은 WinEdt의 latex 버튼으로 컴파일했을 때의 일이고
• KC2008에서는... 이라 한 것은 F6 버튼을 눌렀을 때의 일로서,
• eps로 준비한 그림이 하나는 보이는데 다른 하나는 안 보이는

이런 상황일 것이다. 요약하면,

• 그림이 eps라는 것,
• MiKTeX / WinEdt / Yap 에서 "잘 된다"는 것이 latex 컴파일한 결과이며
• KC2008 / pdf변환에서 "안 된다"는 것은 pdflatex 컴파일한 결과일 뿐이고,
• pdflatex은 eps 그림을 처리하지 않는다는

아주 단순한 일이 처음사용자를 당황하게 만들고 있다고 생각한다.

이 문제에 대한 답변 전략은 그냥 "eps를 쓰지 말고 pdf로 그림을 준비하세요."인데, 이게 또 순조롭게 잘 되지 않는 경우가 많다. 그럴 경우를 몇 가지 조사해보았는데,

1. 소스 자체에 꼭 그림의 확장명까지 모두 써둔다는 점. 그러니 pdf로 이걸 바꾸려면 얼마나 피곤한 노릇이겠는가.
2. 시대에 맞지 않은 클래스 파일인 경우가 있다는 점. 이런 것은 pdflatex으로 컴파일하는 상황을 아예 고려하지 않고 있다. 따라서 이런 경우는 pdflatex로 컴파일하면 안 된다는 것을 지적해야 할 것이다.
3. 그림을 입력하기 위해서 \includegraphics를 쓰는 분들은 거의 이런 문제를 겪지 않는다는 점. \epsfig 와 같은 옛날식 명령을 굳이 쓰고 있거나, 심지어 \epsfig를 이용하여 개인화한 명령 \ef 같은 걸로 그림을 삽입하고 있는 소스들에서 주로 발생하는 문제라는 것.

즉, 답변자의 상상과는 달리 "그림을 pdf로 바꾼다고 해결되는 문제가 아니"라는 것이다.

여기까지 와서, KC2008의 소위 "호환성" 문제를 살펴보자. KC2008이 호환성이 없다고 주장하게 되는 근본 원인이

1. 이전까지 잘 컴파일되던 게 잘 안 된다

는 데 있는 것 아니겠는가. 그 이유는,

1. KC2008의 default 편집기의 default 컴파일 명령이 pdflatex이라는

이 점 한 가지이다. 대부분의 처음 사용자는 pdflatex이니 latex이니 dvipdfmx니 해도 그게 뭔지 모르고 알려고 하지도 않을 것이다. 안내 문서의 F6을 누르라는 말은 들어보았으나 Alt-F6은 무엇이며 Ctrl-F6은 왜 필요한지 상상하기 힘들다는 것.

요컨대, 이제

1. "F6 대신 Alt-F6을 눌러보세요"라고 답변하는 것이 더 낫지 않을까?
2. 그림을 pdf로 준비하고 \includegraphics 명령을 쓰도록 유도하는 것은 정녕 불가능하단 말인가.