KTUGFaq

KTUG FAQ

로그인:
비밀번호:
가입
Mistakes are oft the stepping stones to failure.
FrontPage › 매뉴얼프로젝트/대화
hoze매뉴얼프로젝트에 관한 대화와 건의, 질문과 답변을 위한 페이지입니다. 자유롭게 칭찬, 건의, 질문, 요구사항을 적으시면 됩니다. 새로 글쓰기 하시려면 다음과 같이 ----를 한 줄 쓴 다음 자신의 글을 페이지의 마지막에 덧붙이시면 됩니다.
----
매뉴얼 프로젝트 정말 조아요 ;) --[아무개]

목차

1 제안(hoze)
2 매뉴얼 프로젝트는 어떻게 만들어졌는가?
2.1 기본적인 요구사항
2.2 그 뒤로 새로 제기된 요구 사항
2.3 결론
3 대화
4 hozemanual.cls

1 제안(hoze)

시작을 하긴 했는데, 막상 시작하고 보니 '매뉴얼 프로젝트'가 언제 끝날지 아득해지는군요. 아, 매뉴얼 프로젝트란 이름은 제가 붙인 게 아니고 도은이아버님께서 지어주신 겁니다. 하여튼 각설하고, 두 가지를 제안하겠습니다. 제안이라기보다는 한 번 생각해 봐 주십시오.

첫번째는 제가 전혀 손댈 수 없는 부분에 대해서 누군가 저처럼 PDF로 만들어서 올려주시면 좋겠다는 것입니다. 이를테면, Emacs, WinEdt 또는 텍에서 그래픽 쪽, 그러니까 pstricks 같은 패키지요. metapost도 있어야겠네요. 그리고 리눅스나 유닉스 플랫폼에서의... 등등이요. 요즘 도은이아버님께서 직업이 무언지 의심스러울 정도로 위키 FAQ를 많이 추가해주셔서 저도 많은 도움을 받고 있습니다만, 아무래도 HTML보다는 PDF로 만들어진 것이 이해하기에 더 쉽고 또 문서도 더 구조적으로 만들 수 있지요. 사실 저처럼 만드는 방식은 시간이 좀 더 많이 걸립니다. 캡쳐를 뜨거나 그림을 그리거나 해서 집어넣는 과정이 좀 번잡하고 시간도 많이 걸리지만 이해하기에는 훨씬 좋지요. 제가 이런 방법을 쓰는 것은 당연히 제가 '매뉴얼 작가'이기 때문이죠. (Yudit는 혼자서 긁적거려 보니까 알겠던데, Emacs는 영~)

그리고 두번째는 우리말 쓰기 운동을 벌이자는 건데요. 단순히 우리말을 사랑하자는 그런 건 아니고요. 제 직업의 특성상 이 문제로 고민을 많이 하게 되는데, 가능하면 우리말을, 이왕이면 순우리말을 쓰는 게 좋다는 결론에 이르렀습니다. 도은이아버님께서도 갈무리, 글꼴 같은 좋은 표현을 사용하시는데, 좀 더 폭을 넓혀보자는 거지요. 나름대로 그럴만한 이유가 있습니다만, 사설이 길어질 테니 이에 대해서는 제가 달리 문서를 만들어 올리겠습니다.

2 매뉴얼 프로젝트는 어떻게 만들어졌는가?


한가지 hoze님께 부탁이 있는데요. TeX은 가장 좋은점은 자신이 정의한 명령이나 환경을 이용해서 글을 작성하고, 또한 쉽게 전체적인 layout를 바꿀수 있다는 것인데요. 이러한 자신에 맞는 명령이나 환경을 잘 할 수 있는 manual를 만들어 보실 생각은 없는지요? 아니면 지금 하고 있는 일이 다 그런일이라고 생각하지만요. 아무래도 TeX초보자인 저로써는 이렇게 손에 잡히게 해 줘야 좋지 않을까 생각하는데.... 이미 하고 있는데, 제가 못 찾은것은 아니지요?. --synapse

패키지를 만드는 방법에 대한 설명은 The LaTeX Companion이나 A Guide to LaTeX에도 일부 나옵니다. 저는 처음에 이해하기도 어려운데다가 하다보니 Plain TeX까지 건드려야 할 필요성을 느끼지 못해 아직 깊이 공부하지는 않았습니다. 스타일을 만드는 방법에 대해서는 제가 어떤 새로운 기능의 패키지를 만들 능력도 없고 필요도 없고, 다만 제가 필요로 하는 서식 정도였으니, 제가 모색했던 방법에 대해 간략하게 설명 드리겠습니다.

2.1 기본적인 요구사항


제가 원했던 기본적인 요구 사항은 다음과 같았습니다.

  1. 그림을 왼쪽에 집어넣고 캡션을 달고 오른쪽에 설명문을 넣는다.
  2. 설명문은 enumerate와 itemize가 가능해야 한다.

(1) 일단은 그림과 설명문은 minipage나 parbox 안에다 넣으면 되겠다 싶었지요. 여기에서 첫번째 문제는 그림의 크기를 획일적으로 정할 수 없으므로 minipage나 parbox의 크기를 .sty에서 정해놓을 수 없다는 것이었습니다. 그래서 그림의 크기를 재서 왼쪽 상자의 크기를 정하고 linewidth 에서 그 길이를 뺀 나머지를 오른쪽 상자의 크기로 정하기로 했습니다. 그림에 대해서는 제가 참 할 말이 많은데, 지금 결론은 scale 조정을 하지 않고 애시당초 본문 넓이를 감안하여 만드는 게 최선이라는 것입니다. 기술적으로나 질로 보나 그렇게 하는 게 좋습니다. 그래도 혹시 몰라서 scale 조정을 일괄적으로 할 수 있게 해줬고 width 조정도 할 수 있게 확장할 생각입니다. 예기치 못한 경우를 대비하기 위한 것이지 결코 그런 장치를 쓸 생각은 없습니다.

(2) 두번째 문제는 그림과 설명문이 나란히 정렬되지 않는다는 것입니다. 몇 번의 시행착오 끝에 겨우 해법을 찾아냈습니다.

(3) 세번째 문제는 저는 Float가 되길 원하지 않았습니다. 가급적 그림을 삽입한 그 자리에 붙어 있길 바랬습니다. 제가 만드는 문서는 산업용 매뉴얼이니까요. 이 문제는 float 환경을 쓰지 않으면 되고, 또 상자 안에 그림을 집어넣으니까 float환경을 쓸 수도 없으므로 문제가 되지 않습니다. 하지만 float 환경을 쓰지 않으면 caption을 달 수가 없으므로 곤란합니다. 그래서 ccaption 패키지를 이용했습니다. 그래도 여전히 문제는 있습니다. caption이 한 줄일 때는 가운데 정렬하면 되지만, 두 줄일 때는 가운데 정렬을 할 수가 없습니다. 그보다 한 줄이 될지 두 줄이 될지도 알 수 없습니다. 그래서 할 수 없이 makecaption 명령문에 손을 댔습니다.

\newsavebox{\tempbox}
\renewcommand{\@makecaption}[2]{
 \vspace{\abovecaptionskip}
 \sbox{\tempbox}{#1 #2}
 \ifthenelse{\lengthtest{\wd\tempbox > \linewidth}}
 {\begin{Lentry}{#1}\capfont
  \item[#1] #2
  \end{Lentry}}
 {\centering \capfont #1~ #2}
 \vspace{\belowcaptionskip}
}

(4) 그 다음은 설명문에 itemize나 enumerate를 쓸 때 들여쓰기나 줄 간격 등을 좁혀주거나 없애줘야 했습니다. 그래서 boxitemize, boxenumerate라는 걸 만들어줬습니다.

(5) 그림 대신 표가 들어가는 경우도 별도로 만들어줬습니다.

(6) 표 안에 들어가는 itemize와 enumerate는 boxitemize와 boxenumerate에 앞뒤 간격을 더 좁혀주는 방법으로 처리했습니다.

(7) 이제까지 만들어진 것은 모두 변수로 처리해서 언제든 그 길이나 간격을 조절할 수 있게 했습니다.

2.2 그 뒤로 새로 제기된 요구 사항


그 뒤로 새로 제기된 요구 사항은

  1. 영어를 쓸 경우와 한국어를 쓸 경우를 달리 해야 한다.
  2. 표지를 쉽게 만들어야 하며, 표지는 인쇄용으로 별도로 만들어질 수 있게 해야 한다.

산업용 매뉴얼 표지에는 많은 정보가 들어갑니다. 연락처, 모델명, 제품명, 브랜드명, 개정일 등등. 현재 두 가지 형태의 표지를 만들어 두었는데, 시간이 흐르면 좀 더 추가되겠지요. stdmanual.sty를 제외하면 나머지는 모두 typography적 문제라는 걸 알게 되었습니다. 전문가가 아니므로 늘 자신이 없었고, 그래서 가급적 기본값을 그대로 쓰면서 늘 변경이 용이하도록 했습니다.

그리고 제가 LaTeX 가이드를 만들면서 텍 코드를 표기할 필요가 있었는데 대부분 lshort-kr에서 베꼈습니다.

2.3 결론


결론은 이렇습니다.

  1. 일단 자신이 원하는 양식이 무엇인지 결정한다.
  2. 자신의 해법이 가져올 문제와 그 양식이 가져올 문제를 예측하고 거기에 대한 대비책을 세운다.
  3. .sty와 그 파일의 설명문을 참조하여 베낀다.

만들수록 코딩상의 기술적 문제라기보다 기획의 문제임을 절감하게 됩니다. 어떤 문장에 대해 textbf를 쓸 것인지, textsf를 쓸 것인지도 참 고민을 많이 하게 되는데, 핵심은 어떻게 하면 일관성 있게 쓸 수 있는 구조로 만드느냐이죠.

도움이 되길 바랍니다.

우선 매우 감사드립니다. 제가 혹시 말을 할때 무래하지 않았나 싶기도 하군요. 감사합니다.^^ --synapse

3 대화

좋은 매뉴얼 감사합니다. --Karnes 이거 정말 재밌네요. :D --Progress 호재님의 결과물이 상당히 기대됩니다. 기쁜 마음으로 기다립니다. --berise


Uploads:SLM368_A5.pdf 매뉴얼 스타일을 적용하여 만든 문서입니다.

Uploads:SLM368tex.zip 소스입니다. 위의 설명서만으로도 충분할 것 같은데... 아무튼 일단 올려드립니다.

허접한 사람은 어제나 소스에 목이 마릅니다. 감사합니다. :) --hermian


위의 스타일을 만들기까지 과정을 글로 써보실 생각은 없으신지요? 정말 재밌을 거 같은데요.. ;) 환경이나 명령의 정의 방식을 발견하는 과정에 대한 경험담이 다른 분들에게도 도움이 될 것이고, 명령/환경 자체에 대한 해설도 될 것으로... --Karnes
제가 밟은 과정이 독특할 것 같지는 않은데, 혹 도움이 된다면 그리 하겠습니다. --hoze


저도 매뉴얼 스타일을 한번 구경해 보았는데, 이렇게 그림이 많이 들어가는 문서의 경우에는 최근 업데이트된 DVIPDFMx-20030813 버전 (MiKTeX-KTUG 2.3 에 포함) 을 사용하면 PDF 의 크기를 꽤 줄일 수 있습니다. 이 버전의 특징은 같은 그림이 중복해서 들어갈 경우 단 한번만 임베드한다는 것입니다. 제가 manualstyle.pdf (837KB) 를 다시 만들어보니 627KB 가 되는군요. 아무튼 고생 많이 하셨습니다. --ChoF


제안: hoze님께서 이 페이지를 깔끔하게 유지하시려는 뜻은 알겠습니다만, 대화는 또 대화 나름대로 raison d'etre가 있는 것이고 이 프로젝트에 대한 칭찬, 건의, 피드백이 가능한 공간이 있어야 할 듯합니다. 이전의 대화들을 포함해서 ?매뉴얼프로젝트/대화 정도의 페이지를 만들 것을 제안합니다. --Karnes
흠~ 그런가요? 저는 대화를 일회성이라고 생각해서, 그럼 수고우시더라도, 아직 남아 있다면, 이전으로 돌이켜주시겠습니까? DeleteMe가 있는 경우에만 지우도록 하면 되겠죠? --hoze


추석은 잘 보내셨는지요? 계속되는 작업, 흥미롭게 보고 있습니다. 쌓이고 쌓여 KTUG 대표 문서가 될 때까지... :) --Progress

폰트 전반에 대해 설명서를 만들려고 공부하고 있는데 어렵네요.


(추가요청!) 안녕하세요~ 으흐흐 HOZE의 매뉴얼을 너무나도 좋아하는 어설픈 텍 사용자 입니당~ 표에 대한 매뉴얼 말인데요~ 행 넓이 조절하는 부분에서 행 마다 높이를 달리하는 방법도 추가 되면 좋을 같아요 제가 알려 드리고 싶지만...전 몰라욧 흑 ㅜㅜ renewcommand를 사용하는 건 전체 행 높이를 달리하는 거자나요 알고 계시면 그거두 추가 해 주세욤 네~*^^* 앗차~ 글구용 EPS 만들기의 젤 마지막 페이지에 "end{figure}"가 빠져써요~홍홍 V^^;
--teeming

고맙습니다. \end{figure}를 집어넣겠습니다. 그런데 행마다 높이를 달리한다는 말씀은 잘 이해하지 못하겠습니다. 어차피 내용이 늘어나면 행 높이도 늘어나니까 그건 내용이 결정할 문제 아니겠습니까?



좋은 메뉴얼 잘 보았습니다. EPS.PDF에 오타/제안 사항이 있습니다.

- 1.1 EPS 만들기 에서 3가지 방식을 요약하고 있는데 실제 본문에서는 4가지 방법을 소개 하고 있습니다. 포토샵에 대한 요약도 들어가면 좋겠습니다.

- 1.1.1절 3번째줄에서 conver.exe는 convert.exe겠지요? 본문 예제에서 보듯이..

- 1.1.1절은 ImageMagick를 이용해서 EPS를 만드는 것인데 본문 예제에는 정작 EPS 파일 만드는 예제가 없습니다. 물론 확장자만 바꾸면 되긴 하지만.

- 제가 알기론 convert a.gif a.eps로 하면 파일 사이즈가 10배 이상 증가하는 걸로 알고 있습니다.

ImageMagick은 Level 2 PS 압축을 지원하는데 convert a.gif eps2:a.eps를 하면 파일 사이즈가 많이 줄어 듭니다. 단 이 경우 바이너리 EPS가 만들어 집니다. 이 경우 텍에 잘 포함되고 인쇄도 문제가 없는지 알고 싶습니다.

즐거운 하루 되세요..

데이지웹


말씀하신 대로 모두 고치겠습니다. gif나 jpg를 convert를 이용해서 eps로 바꾸었을 때 파일 크기가 수십 배 이상 늘어나는 문제가 골치거리였는데, eps2 옵션을 이용하니까 크기가 현저히 줄어드네요. 그렇게 만든 eps를 삽입해서 PDF까지 만들었는데 별 문제 없어 보입니다. 이 내용도 추가하도록 하겠습니다. 고맙습니다.


새로 올리신 "길잡이들"을 재미나게 보았습니다. (제 이름에 꽤 자주 나오는군요.. ;) ) 아무튼지, 각 문서에 대한 간단한 (주관적이라도 상관없지 않겠습니까?) 소개가 있었으면 좋겠습니다. --Karnes

갈수록 날림으로 만들다 보니 제 성의가 좀 떨어지는 듯합니다. 그런데 최근에 느낀 건데, 전에 말씀하셨듯 텍 자체가 빠르게 발전하기 때문에, 매뉴얼의 내용이, 치명적이지 않은 정도에서, 일부 맞지 않거나 혹은 패키지들끼리 상충하지 않나 합니다. 그래서 좀 더 세심하게 살펴 보고, 시험해 봐야 올바른 문서를 만들 수 있겠다는 생각이 들었습니다. 제가 만든 문서들에 대해 지적을 해주신 분들의 말씀을 따라 수정을 하려다 보니 그런 생각이 들었습니다. 그래서 갱신이 좀 지연되고 있습니다. 제가 아직도 잘못 이해하고 있는 부분이 많아서 그럴 수도 있습니다. 길잡이 목록에서 소개를 달지 않은 이유는 꼼꼼히 읽어본 문서가 별로 없기 때문입니다. 예전에는 마음이 급해서 주마간산으로 보았는데, 결과적으로 보면 처음에 시간이 걸리더라도 꼼꼼히 보는 것이 시간을 훨씬 더 아낄 수 있다는 것도 알게 되었습니다. 물론 처음에는 꼼꼼히 읽어도 이해하지 못하는 부분이 많습니다. 다시 한 번 읽어본 후 소개를 달도록 하겠습니다. 그러고 보니 우리말로 된 길잡이들은 거의 다 도은이아버님께서 만드셨거나 제작에 참여하셨네요. 다시 한 번 감사와 경의를 표합니다.

안녕하세요. texmanual project에 대해서 많은 정보와 도움을 얻고 있습니다. 한가지 여쭈어볼 말이 있어서 이렇게 글을 씁니다. TeX를 공부하다 보니, \def\a#1{\def\b#1{...}}과 \def\a#1{\def\b##1{...}}에 궁금한것이 있어서 이렇게 여쭈어 봅니다. 두번째의 것은 a 매크로의 parameter를 b매크로 에서 사용한다는 뜻이라는 것은 알겠는데, 그렇다면 첫번째것에서 \b#1의 의미는 무엇인가요? a라는 매크로와 관계없이 b라는 매크로도 하나의 parameter를 가진다는 의미일까요? 이렇게 쓰인다고 해도 어떻게 쓸모가 있을까요? 손에 잡히지 않으면 무엇이든지 잘 모르는 바보가 질문드립니다. 감사합니다.--synapse

에~ 헤^^ 저도 아직 Plain TeX은 모릅니다. 그리고 올려주신 코드가 완전한 형태가 아니라서 더 더욱 뭔지 모르겠는데요. 쩝, 죄송함다. 저는 제가 만드는 새로운 서식도 Plain TeX은 가급적 건드리지 않고 LaTeX을 주로 재정의하거나 조합해서 만듭니다. 구태여 Plain TeX까지 건드릴 필요도 없구요.
어찌되어던 감사합니다.--synapse

제가 답변해도 되는 거라면, 간단히 말씀드리겠습니다. 인자 치환이 어떻게 되는지만 잠깐 생각해보시면, 다음과 같은 정의, 예컨대
\def\a#1{\def\b#1{#1}}
로 정의한 상태에서
\a!
명령을 주면
\a! => \def\b!{!}
와 같이 확장되겠지요. 이리 되면 \b라는 새로운 명령을 부르는 셈이 됩니다.(부정확한 부분을 수정하였습니다) 반면, 예를 들어
\def\a#1{\def\b##1{##1#1}}
와 같이 정의한 상태에서 마찬가지로 \a! 명령은
\a! => \def\b#1{#1!}
와 같이 확장될 것입니다. 말씀하신대로, ##1이 주어진 매크로의 인자로 사용되려면
\def\a#1{\def\b##1{\bf##1}%
 \b#1}
이렇게 정의하고 이제 \a{para} 명령이 어떻게 동작할지 생각해보자면
 \a{para} => \def\b#1{\bf#1}\b{para}
          => \bf para
이런 식으로 치환될 것을 생각해볼 수 있습니다. --Karnes
이제 와서야 보았습니다. 정말 감사드립니다. karnes님...꾸벅, 꾸벅(절하는 것입니다) 그런데요.
\def\a#1{\def\b#1{#1}}
로 정의한 상태에서
\a!
명령을 주면 이라고 하셨는데, a!이라는 명령어는 존재하지 않는것 아닌가요? 이것을 a{!}라고 주어야 하는것 아닌가라는 생각이 드는것 같습니다. 그 저 이렇게 생각이 드는 것 같습니다. 제 생각의 어디가 틀린지 알려주세요. 그리고 TeX은 왜 이렇게 해서 명령어에 대해서 확장을 하나요? 이러한 내용이 나온 TeX의 책에 대해서 소개를 좀 해 주시면 안될까요? 거듭 감사합니다.

PlainTeX에서는 명령어를 정의하고 인자를 parsing하는 규칙이 있습니다. 그 가운데 하나에 따르면, 모든 명령은 문자 아닌 것이 오면 끝난다는 것입니다. 위의 예 \a!에서 !는 문자아닌 것이므로, 명령어는 \a(이것은 정말로 예일 뿐입니다)까지이고, 그 다음에 오는 !는 앞의 명령의 인자로 해석됩니다. 처음에 \def\a#1과 같이 정의하였기 때문입니다. 그러므로 PlainTeX의 문법으로는 \a!\a{!}과 동일하다고 할 수 있습니다. 물론 \a{para}의 경우에는 명시적으로 {para}를 묶어주지 않으면 안되겠지요. 한가지 재미난 예를 더 들어보자면, 예컨대 \def\mycommand#1#2{...}로 정의된 명령에 대해서 \mycommand32라고 부르면, 이것이 \mycommand{3}{2}로 읽어질 것이겠지요. 이런 것이 좀 혼란스러워서 LaTeX에서는 명시적으로 인자를 {}로 묶도록 권장하고 있습니다. 아무튼지 이런 부분이 정말로 궁금하시다면 The TeXBook부터 보시는 것이 좋을 듯합니다. 위의 예도 그 책을 참조하여 제시한 것입니다. --Karnes

a{!}는 예로서 말씀해주신 듯합니다. --hoze
DeleteMe 이 뒤에 길게 써주신 것은 대화에 두기는 아까운 내용이라서 제가 위쪽으로 옮기고 제목을 붙였습니다. --Karnes



메뉴얼 프로젝트 스타일을 이용해 보고 싶은데 초보자라서 컴파일조차 못해보고 있습니다. ㅜㅜ .sty 화일이 없다고 나와서 인터넷에서 찾아다가 해당폴더에 넣고 컴파일을 해보았는데, 결국 ! LaTeX Error: \subcapfont undefined. 라는 에러메시지가 나와서 포기했습니다. 저같은 초보자를 위해서 좀더 눈높이에 맞는 설명을 부탁드립니다. --robotdm

갑자기 여러(?) 분이 찾으시니 좀 당황스럽습니다. 앞서도 말씀드렸지만, 참고용으로 올린 것이기 때문에 아직 다른 분들이 사용하시기에 불편이 적지 않을 것입니다. hoze매뉴얼프로젝트에서 최근에 올린 것을 다시 내려받아 해보시길 바랍니다. 한글 제목 설정이나 여백 설정은 나름대로 바꾸고 싶어하실 것이므로 stdmanual.sty만 써도 문제가 없어야 할 텐데, 솔직히 자신은 없습니다. 함께 개선해나가길 바랍니다. 저에게 메일로 소스와 에러를 알려주시기 바랍니다. 연락처는 hoze매뉴얼프로젝트에 있습니다.

DeleteMe install.zip이 다운로드 되지 않는데, 저만 그런 것인지요? --Progress
DeleteMe hoze 님의 typo를 제가 수정했습니다. --Karnes
DeleteMe 감사합니다. 그런데 UploadedFiles 에 가도 안 되던데... -_-... Progress
DeleteMe 저는 돼요... 이 페이지를 다시 Reload하신 다음에 다운로드해보시지요.... --Karnes

업로드 파일의 이름은 되도록 일반적이지 않은 것을 사용하시는 것이 좋지 않을까 합니다. install.zip은 너무 일반적이라 다른 분이 같은 이름의 파일을 업로드하면 덮어쓰게 됩니다.... 매뉴얼프로젝트의 업로드 파일은 hzm_ 으로 시작할 것을 제안합니다. --Karnes
네 앞으로는 hzm_을 붙이겠습니다. 지금 것은 Karnes님께서 고쳐주십시오.

4 hozemanual.cls

새로 시작하신 hozemanual.cls를 흥미롭게 보고 있습니다. 설명서까지는 아니더라도 간단한 예제를 하나 만들어주시면 무척 감사하겠습니다. --Karnes

구구절절이 설명할 필요는 없고 단지 hozemanual.cls로 만든 문서이면 되겠습니까? 작년에 올린 SLM368처럼요?
예. 그저 hozemanual.cls의 대부분의 기능을 사용한 문서이면 되리라고, 저는 생각합니다. 일종의 "뽄"으로 사용할 수도 있겠지요. --Karnes

Uploads:hozemanualclsSample.zip

이 파일은 현재 제가 만들고 있는 설명서입니다. 그림이 많이 들어가서 아직 완성이 되지 않았는데도 26 메가 바이트가 넘습니다. 그 중 한 章만 삽입해서 여기에 올립니다. 다 올리지 못하는 이유는 파일이 크기도 하지만 설명서도 보안 대상이기 때문입니다. --hoze
고맙습니다. cover.tex이 없다고 하는데요? --Karnes

돌려보시게요? cover.tex은 표지인데요. \frontcover와 \backcover 명령이 정의되어 있습니다. cover.tex이 있어도 어차피 그림이 없어서 돌리셔도 원하는 결과를 얻지 못할실 텐데요. 설마 fakemanual.cls를 이용하시려는 건 아니겠죠? :) --hoze


설치매뉴얼 좀 적어주세요 :D --2006-05-17 hermian
@texmf-hoze6518.zip (561.61 KB) 전 그냥 texmf 트리 하나 만들어서 쓰는데요. 그런데, 여기 참 오래만에 들어오는데, 제가 예전에 이런 문서들을 올렸나 싶습니다. 지금 보니까 텍으로 만든 게 아니라 잘 만든 워드 문서를 보는 것 같습니다. --hoze

예전에 어디선가 잠깐 본듯 한 문서가 있네요. PDF아주 좋습니다. 열심히 읽고 있는 중입니다. 감사 합니다. --hermian

hozemanual project에 대한 설명서(class에 대한 설명서)를 이전에 한번 본 기억이 있는것 같은데요. 이번에 hozemanual project를 폐기하면서 같이 폐기하셨나요? 있으면 다시 한번 올려주시면 감사하겠습니다. 일전에 말씀드린것 같이 한번 써볼려고요. 그런다고 해서 일일이 class화일을 읽기는 좀 어려워서요.. 감사합니다. --synapse

요 위의 texmf-hoze6518.zip을 풀면 doc/latex/hozemanucs/ 폴더에 hozemanucs.pdf가 있습니다. 워낙 자주 수정을 해서 마지막 버전과 설명서가 맞지 않을 겁니다. --hoze

^
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2007-01-16 14:23:55
Processing time 0.0899 sec