KTUGFaq

KTUG FAQ

로그인:
비밀번호:
가입
You recoil from the crude; you tend naturally toward the exquisite.
FrontPage › ScientificWorkPlace

목차

1 소개
2 스크린샷
3 한글 처리
4 Q&A
5 관련 링크

1 소개


ScientificWorkPlaceTeX의 윈도우용 GUI이다. Unix나 Linux 환경에서 사용할 수 있는 LyX과는 달리 상업용이고 가격도 꽤 비싸다. (보통 줄여서 SWP라고 하기도 한다.)

  1. 장점
    1. 워드프로세서를 이용하듯 손쉽게 문서를 작성해서 TeX의 미려한 출판 결과를 얻을 수 있다("shell"이라고 하는 미리 정의된 템플릿을 이용해 손쉽게 문서를 작성할 수 있다).
    2. 수식 연산 프로그램인 Maple과 연동해서 수식 계산을 할 수 있다(ScientificWorkPlace만 가능. ScientificWord는 문서 편집만 가능).

  2. 단점
    1. 가격이 비싸다. (ScientificWorkPlace 4.0의 경우 아카데믹 라이센스로도 $600이 넘는다. :( )
    2. 한글을 포함한 국제어 환경에 적합하지 않다.
      • 한글의 경우 IME를 통한 입력이 가능하나 ScientificWorkPlace 내부적으로는 개별 글자를 UniCode로 입력한다. 따라서 compiler를 MiKTeX으로 정해줄 경우 한글 처리를 위해서는 $${\Omega}\mbox{mega}$$ 또는 이를 바탕한 Lambda를 이용해야 할 것이라고 추측된다.
      • 조금 번거롭기는 하지만 입력만을 GUI 환경인 SWP를 이용하고 컴파일은 다른 TeX 시스템을 이용하는 방법이 있다. 한글 처리를 참조하라.

2 스크린샷


3 한글 처리


SWP로 한글 입력이 가능하긴 하지만 위의 스크린샷에서 보듯 생성된 TeX 파일은 한글을 특수한 명령어와 UniCode 형식으로 기록한다. (Mathematica도 이와 비슷한 문제를 갖고 있다. libiconv 참조.) 이 TeX 파일을 HLaTeX으로 컴파일하려면 다음과 같은 식으로 처리해 준다.

  • ActivePerllibiconv, GnuWin32:libintl을 설치한다. (PATH 변수를 올바로 세팅해야 한다.) (아래 첨부된 .exe를 쓸 경우 이 과정이 필요하지 않다.)
  • SWP로 생성된 TeX 소스 파일 내의 한글을 UTF-8으로 변경시켜 주는 펄 스크립트(Uploads:swp_filter.pl (by WkPark))를 PATH가 걸려 있는 적절한 곳에 놓는다.
  • DOS 프롬프트 상에서 입력 파일이 있는 위치로 간 후 다음과 같은 명령을 한다.
c:\>  swp_filter[.pl] input.tex | iconv -f UTF-8 -t EUC-KR > output.tex
(옛날에는 HLaTeX을 써야 했기 때문에 위와 같이 EUC-KR로 바꿔줘야 했다. 그러나 요즘은 유니코드를 쓰니까 다음처럼 하면 된다. \usepackage{kotex}을 추가하는 것은 사용자의 몫이다.)
# swp_filter <input.tex >output.tex
(input.texoutput.tex은 적절한 이름으로 바꿀 것.)
  • output.tex을 컴파일한다.
  • 샘플 파일 Uploads:no-smok.tex


  • 더 쉬운 방법도 있을 듯 하군요 -- WkPark 2003-04-10 04:05:44
    WinEdt에서 바로 처리할 수 있는 방법을 아직도 연구 중입니다. ^^;; 매크로 파일로 만들어서 끼워 넣어야 할 텐데 WinEdt 매크로를 만들기가 생각보다 쉽지 않군요. 시간 없다는 핑계로 미루고 있습니다만... ^^a -- 모꼬지 2019-10-15 08:14:20

    4 Q&A


    Q: ScientificWorkPlace가 굉장히 비싸다는 얘기에는 좀 실망했지만 일단 저를 혹하게 하는 것은 TrueType font를 쓴다는 것입니다. 그런데 또 출력물이 미려함이 떨어진다고 하니까 헷갈리네요. 이제까지 레이텍을 하는 것 중에 아쉬운 것은 단 한 가지입니다. 글꼴 크기와 장평에 대해 좀 더 자유로웠으면 하는 것입니다. 이미 이 문제에 대해서 어느 정도 논의가 있었고 \small, \large 등의 명령어에 담긴 기본적인 제약의 의미에 대해서도 이해하고 있다고 생각합니다. 그래도 가장 기본적인 트루타입 글꼴은 좀 더 자유롭게 쓸 수 있었으면 좋겠습니다. ScientificWorkPlace가 그런 편의를 제공해줄 수 있다면 좋겠습니다. 그런 장점을 제공하는 대신 LaTeX2e와 문법이 현격히 다르거나 패키지 이용에 제약이 많다거나 하면 곤란하겠죠. 정리하자면, 저의 질문은 'ScientificWorkPlaceMiKTeX과 설치법과 사용법이 거의 동일하면서 트루타입 폰트를 자유롭게 사용할 수 있는가'입니다. - hoze

    Q: 안녕하세요, 모꼬지님? 저도 궁금합니다. 위에서 말씀하시길... 내부적으로 TrueType font를 쓰는 TrueTeX으로 컴파일하고 보여주는지라 출력물의 미려함이 많이 떨어지긴 합니다. 쩝... :( ... 라고 하셨는데 아마 Type 1 서체에 비해서 미려함이 많이 떨어지는 것을 지적하신 것이라 짐작합니다. 그리고, 일단 한글지원에 관한 사항도 perl을 이용하여 한번 변환을 더 거쳐야 하므로 불편한 점이 없다고는 할 수 없습니다. 그리고, tcilatex.tex을 이용하지 않고 plain 모드(?)로 저장할 수 있다는 것도 언급하셨는데, 역시 한글을 이용할 때에는 필터를 이용하여 변환을 거쳐야 하는 것이지요? 또 한글 트루타입폰트도 TrueTeX으로 직접 사용할 수 있는지 궁금합니다. --Progress

    A: 안녕하세요? 그동안 장문의 질문들이 올라와 있었네요. ^^ 일단 제가 폰트 관련해서는 아는 게 거의 없어서 그냥 추측성 글들밖에 쓸 수 없는 것을 양해해 주시기 바랍니다. 아마도 박원규(WkPark)님이나 신정식님 같은 분들이 관심을 가지고 보신다면 정확한 판단을 내리실 수 있겠죠. ^^;; 일단 정리해서 말씀 드리면 다음과 같습니다.

    • SWP는 기본적인 문법은 LaTeX동일합니다. 단지 필요에 따라 정의한 매크로들을 하나의 파일로 묶어서 input을 합니다. 파일을 저장할 때 'save as portable LaTeX document'로 하면 매크로들을 본래의 LaTeX 명령어로 바꿔서 저장합니다. 따라서 호환성에는 별다른 문제가 없어 보입니다.

    • 다른 편집기로 작성한 LaTeX 문서도 \def 같은 非LaTeX 명령어만 없다면 잘 읽습니다. (단지 확장자를 좀 가립니다. 예를 들어 '.*' 형식의 임의의 텍스트 문서는 문서 열기나 import를 할 때 파일 형식 옵션에 있지도 않습니다. -_-;; )

    • SWP에서 사용할 수 있는 패키지는 컴파일을 할 TeX Engine을 SWP의 default인 TrueTeX을 쓸 것이냐 아니면 MiKTeX을 쓸 것이냐에 따라 달라집니다. (이것은 SWP 내부에서 세팅해 줄 수 있습니다. 단, Yap을 dvi previewer로 설정하는 것이 조금 문제가 있어 보입니다. SWP 4.0, MiKTeX-KTUG 2.2에서.) SWP의 default인 TrueTeX은 SWP의 하위 디렉토리에 깔립니다만 딸려 나오는 패키지(sty 파일들과 fd 파일들)들은 별로 많지 않습니다.

    • SWP가 트루타잎을 쓰는 방식은 (TrueTeX의 방식인) CM 폰트나 extended CM 폰트를 '.ttf' 파일로 변환해서 사용하는 방식입니다. TrueTeX의 ttf를 이용한 TeX 컴파일에 관해서는 TrueTeX official web site인 http://www.truetex.com을 참고해야 할 듯 싶습니다. FixMe 하지만 제 생각은 KTUG에서 그동안 논의되어 온 MiKTeX에서 ttf를 이용하기와 크게 다를 것 같지 않습니다. TrueTeX의 방식도 폰트들을 ttf로 변환시킨 뒤 적절한 폰트맵을 적용시키는 것일 테니까요. 결국 SWP에서 ttf를 쓰려면 MiKTeX에서 ttf를 쓰는 것과 같은 작업을 해 줘야 할 것 같다는 생각입니다. 그럴 바에는 SWP에서 문서의 컴파일 엔진을 MiKTeX-KTUG으로 셋업해 주는 게 낫겠죠. 그런 방식이 MiKTeX의 좀더 다양한 패키지들을 쓸 수 있는 방식이 아닐까 생각합니다만...

    • 미려함이 떨어진다는 것은 CM을 ttf로 만드는 과정에서 약간의 품질 저하가 있지 않았나 하는 추측에서 비롯됩니다. 예를 들면 SWP로 만든 문서를 컴파일해서 보면 분수의 가운데 막대기가 약간 두껍고 울퉁불퉁하게 나오거든요. 같은 문서를 MiKTeX으로 컴파일하면 깨끗하게 나오는데 말입니다. 종이로 프린트해서 보면 그 부분이 약간 질이 떨어지는 것 같아 보입니다. 뭐 순전히 개인적인 입맛의 문제일 수도 있겠지요. ^^

    • 참고로 TrueTeX에서도 유니코드 ttf를 이용한 멀티바이트 문서의 컴파일이 가능한 것 같습니다. (기술적인 부분은 저도 쥐약입니다. ^^;; ) 단지 문제는 SWP가 멀티바이트 문자를 화면에 display할 때는 아무 문제가 없는데 문서를 일단 저장할 때는 꼭 \U{b8f0b2bfc1f6}와 같은 식으로 쓸데없는 태그를 붙인다는 겁니다. 저장하는 과정에서 그냥 ASCII로 변환해 버리는 것 같습니다. 아직은 SWP가 i18n의 개념이 전혀 없는 것 같습니다. Proprietary software라서 제작한 측에서 이 문제를 고치지 않는 한 어쩔 수 없을 것 같군요.

    • 그동안 SWP를 쓰면서 느낀 점은 일단 영어로 LaTeX 문서를 편하게 작성하기엔 좋은 프로그램이라는 겁니다. 이곳저곳 세심하게 신경 쓴 부분도 있고 나름대로 유연성도 있는 프로그램입니다. 단지 라이브러리를 구닥따리를 써서 만든 것인지 Windows XP와는 약간 안 맞고 좀 경직적인 것 같습니다. i18n에 좀더 신경쓰고 사용자가 취향에 맞게 설정해서 쓸 수 있도록 해준다면 윈도우에서 쓰기에 더할 나위없이 좋은 프로그램이 될 거라 생각됩니다. 아, 물론 가격도 내려야겠지요. ^^;;;

    • 다음에 좀더 확실하고 개선된 내용으로 소개할 수 있었으면 좋겠군요. ^^;; -- 모꼬지 2019-10-15 08:14:20

    Q: CM을 굳이 TTF로 바꿀 필요가 있을까요? 제가 알고 싶었던 것은 굴림, 돋움, 바탕 같은 윈도우 글꼴을 자유롭게 쓸 수 있느냐 하는 것이었는데요. -이호재(hoze)

    A: TrueTeX이 CM을 TTF로 바꾼 이유는 Windows라는 특정 플랫폼에 TeX의 폰트를 맞춘 것으로 생각됩니다. 그리고 자체 내장된 TrueTeX으로 문서를 compile하면 latex.dll이라는 라이브러리로 필터링을 해서 dvi 파일을 만들어 내는데 이렇게 만들어지는 dvi 파일을 Yap에서 읽으면 몇몇 글자가 깨지는 걸로 봐서 아마도 이 dvi 파일이 TrueTeX의 dvi previewer에서만 읽어내는 코드를 갖고 있는 것 같습니다. 제 생각엔 이 때 TTF를 이용하지 않나 싶습니다만... TrueTeX 웹사이트의 설명을 보면 Uses any TrueType ANSI font라고 되어 있습니다. FixMe 그렇다면 폰트맵만 제대로 맞춰준다면 굴림이나 돋움 같은 윈도우 글꼴을 TrueTeX 레벨에서 쓰는 건 문제가 없지 않을까요? (AnswerMe 그런데 TrueType ANSI font라는 게 무얼 말하는 겁니까?) 문제는 위에서 언급했다시피 SWP 자체가 파일 저장을 할 때 ASCII 형식으로 변환시켜서 한다는 것입니다. 이것은 제작사에서 프로그램 자체를 고치지 않는 한 해킹하기가 힘들지 않을까 싶습니다만... 결국 별로 도움이 못 되는 답변이 되고 마는군요. -_-a -- 모꼬지 2019-10-15 08:14:20


    5 관련 링크


    [http]Scientific Word/Workplace tips
  • tcilatex.tex (Old version): [http]tcilatex.tex
  • tcilatex.tex (DAvB version): [http]tcilatex.tex
  • 제작사 홈페이지: [http]MacKichan Software



  • ^
    Valid XHTML 1.0! Valid CSS! powered by MoniWiki
    last modified 2009-11-30 23:32:14
    Processing time 0.0697 sec