KTUGFaq

KTUG FAQ

로그인:
비밀번호:
가입
He is truly wise who gains wisdom from another's mishap.
FrontPage › MiKTeX/문제점

r1.13과 현재 버전의 차이점

@@ -1,4 +1,4 @@
== MiKTex MiKTeX 2.6 ==
1. pdfTeX 1.40.3을 채택하였으나, (영문자 사용자에게는 별 필요가 없고 우리에게는 필수적인) 트루타입 서브폰트 기능이 어떤 이유에서인지 제외되어 있는 듯하다. 즉, MiKTeX의 pdfTeX으로는 트루타입 서브폰트를 쓸 수 없다.
1. TDS 1.1을 따르지 않고 독자적인 TDS를 고수하고 있다. 그 결과 TeXLive 등과 texmf tree가 호환되지 않는다.
1. mptopdf와 같은 일부 프로그램이 표준 옵션으로 동작하지 않는다.



MiKTeX 2.6

  1. pdfTeX 1.40.3을 채택하였으나, (영문자 사용자에게는 별 필요가 없고 우리에게는 필수적인) 트루타입 서브폰트 기능이 어떤 이유에서인지 제외되어 있는 듯하다. 즉, MiKTeX의 pdfTeX으로는 트루타입 서브폰트를 쓸 수 없다.
  2. TDS 1.1을 따르지 않고 독자적인 TDS를 고수하고 있다. 그 결과 TeXLive 등과 texmf tree가 호환되지 않는다.
  3. mptopdf와 같은 일부 프로그램이 표준 옵션으로 동작하지 않는다.
  4. ebb로 pdf version 1.4 이상의 pdf 그림의 바운딩박스를 얻을 수 없다. (TeXLive win32는 이 문제가 해결되어 있음)
  5. 새로운 패키지를 설치할 때마다 (새로 도입된 기능으로) 자체 폰트캐시를 갱신한다. 이 과정이 너무 오래 걸리기 때문에 패키지 설치가 매우 지루한 과정으로 변했다. 그러므로 small miktex을 설치하여 필요할 때마다 패키지를 그때그때 온라인 설치하도록 하는 것은 비효율적인 방법이 되고 말았다.

MiKTeX 2.5

MiKTeX 2.5이 한글 환경 및 KTUG 한글 개발환경으로 적합하지 않다고 알려져 있다. 그 이유는

  1. MiKTeX 2.5는 내성적인 시스템이라서 자체 패키지 이외의 패키지를 설치하려면 상당한 설정의 변경 등을 감행해야 한다.
  2. MiKTeX 2.5의 바이너리들 중에 한글과 잘 맞지 않는 것이 많고, 최근 비약적으로 발전하고 있는 한글 처리의 실험적인 패키지들이 아예 실행조차 되지 않는 것도 있다. 그런데 MiKTeX은 개방적인 시스템이 아니라서 언제 새로운 바이너리가 추가되거나 갱신될지 알 수 없는 시스템이므로, 차라리 MiKTeX을 포기하는 것이 이 때문에 겪게 될 수많은 문제를 미연에 방지하는 것이 될 것이다. 예컨대, MiKTeX은 과연 ttf2tfm의 오메가 패치를 받아들일 계획이 있는가? MiKTeX의 패키지 매니저에서 CJK 패키지는 언제까지 이전 버전을 고수할 것인가? PdfTeX은 문제많은 1.30.6을 채택하였는데, 과연 1.40을 받아들이기나 할 것인가?... 등등...
  3. KTUG에서 권장하는 한글 환경은 Unicode/UTF-8을 이용하는 것이다. 그러나 MiKTeX은 BOM 처리에 지장이 많다(KC2006에서는 BOM이 문제가 되지 않는다).
  4. ConTeXt, XeTeX, JadeTeX, MetaPost, CWEB 등 한글 지원을 위하여 개발된 많은 새로운 솔루션을 적용하기가 난감하다(불가능하지 않은 것은 있겠지만).

MiKTeX은 개방적인 프로젝트가 아니다

대화모드

Karnes: MiKTeX 개발자의 개발성향이 우리 입장에서 개방적이지 않다. 아마도, MiKTeX은 한글 환경을 위해서 시스템을 재조성하는 등의 일은 결코 하지 않을 것이라고 예측하고 있습니다. DVIPDFMx의 "적절한" 버전이 받아들여지는 데 3년이 걸렸습니다. 이것은 TeXLive보다도 늦은 것이었습니다. 앞으로 무슨 일이 벌어질지 어떻게 알겠습니까?

WkPark: 이런 식으로 개방적이지 않은 프로젝트는 꽤 있습니다. 한글 사용자에게는 그다지 좋지 않은 정보군요 :( 그런 개방적이지 않은 프로젝트에 압력을 행사하는(?) 방법은 여러가지 있습니다.
  1. 계속 귀찮게 한다: [http]버그리포팅/[http]메일링리스트 활용 (인내가 필요)
  2. 관련된 다른 프로젝트에 제안한다. 예를 들어 TeXLive 혹은 [http]W32TeX에 반영되도록 노력합니다. 다른 프로젝트에 반영되었다는 것을 근거로 제시하여 MiKTeX프로젝트에 반영하도록 다시 노력합니다.
  3. fork한다: 예전에 MiKTeX-KTUG 프로젝트가 따로 운영되었듯이 MiKTeX 2.5에 대한 KTUG 프로젝트를 운영할 수도 있다. 그러나 단점은,
    1. 예전에 MiKTeX-KTUG 프로젝트가 중단되었던 이유(?)
      1. 컴파일러가 없어서 ? Please fixme
      2. 개발 인프라 부족
    2. 개발 외적인 부분에 신경을 많이 쓰기 어렵다. 현재 KTUG개발진에게는 W32TeX을 기반으로 한 KC2006이 더 낫다.
    3. 프로젝트를 fork하는 것보다 원 프로젝트에 반영하는 쪽이 언제나 더 낫다.

MiKTeX은 개방적인 시스템 아니다

MiKTeX 시스템 자체가 그다지 개방적이지 않다는 것입니다. MiKTeX에는 독립적으로 돌아가는 바이너리가 하나도 없습니다. *-miktex*.dll에 전적으로 의존적입니다. 어느 정도냐 하면, gs마저도 이 dll 없이는 동작하지 않습니다. --Karnes

MiKTeX-fy된거로군요... 예전부터 맘에 들지 않았던 부분.. 이런게 MiKTeX에서 개발된 것이 다른 TeX 배포에 포함되게 어려운 이유가 되는거죠 --WkPark


  • Q: Omega 패치를 받아주지 않는 이유는 무엇인가요?
  • Q: ttf2pk/ttf2tfm의 kpathsea가 제대로 링크 안된 이유는 버그 아닐까요?


예전부터 MiKTeX은 잠재적으로 일반 TeX배포판과 크게 차이나는 설정방법으로 인해, 기존 설명서를 무용지물이 되게 하고, 설명서를 다시 만들거나 해야하는 문제점이 있었습니다. 예전부터 MiKTeX의 이러한 비호환성이 큰 문제라고 생각했었습니다.

TDS도 잘 따르지 않고, 다른 TeX과는 다른 디렉토리 구성 등등이 점점 MiKTeX의 잠재적인 문제점을 부각시키는군요. 이제 MiKTeX을 버릴때가 되지 않았는지 하는 생각이 듭니다. --WkPark 2006-10-01



^
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2007-04-29 11:28:52
Processing time 0.0793 sec