Q&A 마당은 텍 관련 질문/답변을 위해 만들었습니다.
- 로그인 없이 자유롭게 글을 읽고 쓸 수 있는 철학은 처음과 같이 계속됩니다.
- 질문 전에 아래를 읽어 보세요. 좋은 질문이 좋은 답을 받을 수 있는 좋은 방법입니다.
- 질문에 맞는 제목을 붙이세요. 질문의 내용과 관련없는 "고수님", "긴급질문", "도와주세요"와 같은 제목은 답이 잘 올라오지 않습니다. 이 게시판에 올라오는 모든 글은 질문입니다. 굳이 [질문], [Q]를 적으실 필요도 없습니다.
- 내용을 충실히 적어 주시고, 같은 상황을 재현할 수 있는 최소한의 예제가 같이 있어야 합니다.
- 최소 예제는 "Minimal working example"을 읽어 보세요.
- 파일을 첨부하실 때에는 가능한 압축하여 파일 크기를 줄여서 올려주시길 바랍니다.
- 개인적으로 사용하신 글꼴이 들어 있는 경우, preparefont.sty에 관한 답변을 참조하세요.
- 스팸 글을 막기 위하여 짧은 시간 내에 다시 글이 등록되는 IP를 막거나, 광고 글을 막기 위하여 금지어로 .com, .net 등을 설정하고 있습니다. 다소간의 불편함이 있으시더라도 양해 바랍니다.
- 금지어에서 stackexchange, stackoverflow, ctan, overleaf, , github, google.com, gmail.com, .org, .io, sil.org, wiki.com, tistory.com등은 해제하였습니다.
- MathJax를 이용한 수식조판을 사용하실 수 있습니다. 여기를 참조하세요.
- 사용하는 편집기는 CKeditor입니다.
- 편집기에서 [enter]를 누르면 <p> 태그가 들어가고, 문단으로 생각하고 한 줄을 비웁니다.
- 글줄만 바꾸려면 [shift-enter]를 누르면 <BR> 태그가 들어가므로 용도에 맞게 나누어 쓸 수 있습니다.
- 수식를 문서내에 삽입하시려면 에디터를 툴바에서 [소스]를 눌러 HTML로 입력할 수 있게 바꾸신 후 <pre> </pre> tag를 사용하셔서 <pre> 여러 줄의 수식 </pre>처럼 입력하시면 좋습니다.
LaTeX 파일 공동 작업 문제
2012.09.04 09:12
안녕하세요,
보통 같은 소스를 가지고 여러명이 손질하게 되는 경우 어떻게 취합해서 통일된 문서를 만들어 내시는지 궁금합니다. MS Word의 경우는 문서의 공동 작업이 용이한데 LaTeX 문서는 그런 점에서 좀 아쉽네요. 텍스트 파일이니 그냥 diff를 이용할까 싶었는데 단어가 조금만 달라져도 문장 전체 혹은 문단 전체가 다르다고 나오는 바람에 별로 도움은 안되는 것 같고 현재는 latexdiff를 돌려서 차이를 확인한 후 일일이 수작업으로 선별해서 취합하고 있습니다. latexdiff가 많이 쓰는 클래스가 아닌 경우는 에러가 나는 경우도 있어서 안정적이진 않은 것 같구요. 고수님들 비결이 있으시면 좀 알려주시면 고맙겠습니다.
댓글 15
-
yihoze
2012.09.04 09:25
-
aeronova
2012.09.04 17:06
답글 감사합니다. 아무래도 뾰족한 수가 없군요. ㅎㅎ
-
샘처럼
2012.09.05 01:28
MS word를 예를 드셨기에, 갑자기 Karnes님의 blog에 있던 글이 생각나 URL을 가져옵니다.
http://blog.doeun.kr/146 : SubEthaEdit, xelatex mode
원하시던 답이 아닐 수도 있습니다. ^^ -
aeronova
2012.09.05 09:13
알려주신 내용은 "동시" 공동 편집이라 제가 고민하던 것과는 조금 차이가 있군요.
-
gromob
2012.09.05 07:32
죄송합니다만 Word를 어떻게 사용하시는지 잘 모릅니다.
얼핏 생각에
다른 분이 손 본 파일을 받으셨을 때 어떤 부분을 고쳤는지 알고 싶으신건가요?
워드는 두 파일 비교가 쉽습니까?(전혀 사용해 보지 않아서...)
혹시 그런 것이라면,
그리고 TeX에서도 고친 부분을 빨리 찾는 것이 목적이라면
그리고 diff 밖에 방법이 없다고 보이니까,
작업을 하실 때 이것을 염두에 두고 작업 방식을 정하시면 어떨까요?
즉 TeX에서 입력할 때 한 줄의 길이를 짧게 하시도록
정하고 모두 지키는 겁니다.
(전 세기 80년대에는 컴퓨터 처리 용량 제한 덕분에
한 줄에 글자를 많이 둘 수 없었습니다.
그래서 텍은 줄바꿈도 띄어쓰기 한 간으로
치는지도 모릅니다.)
처음에는 번거로워 보이실지 몰라도 여러 가지로
낫다고 생각되는 점이 있으실겁니다.
search 및 inverse search 시에도 한 문단을 몽땅
찾아주지 않아서 편하실 수 있고요.
저는 적어도 문장이 끝나면 줄을 바꿉니다.
-
aeronova
2012.09.05 09:11
제가 워드를 많이 쓰진 않지만 워드는 여러명이 손질한 기록이 코멘트 형식으로 보여져서 바뀐 내용을 합칠지 버릴지를 간단히 선택가능합니다. 공동 작업에 상당히 편리하더군요.
-
gromob
2012.09.05 07:55
예전에 써 본 기억이 있어서 찾아보니 mac에서 textwrangler라는 프로그램은 Find Differences라는 명령을 통해서 두 파일의 차이를 두 개의 창에서 보여주는데요.
차이있는 line을 회색으로 칠하고 (양쪽 모두), 거기서 서로 다른 단어는 색깔로 칠해줍니다 (양쪽 모두).
윈도우를 사용하신다고 해도 이런 프로그램은 당연히 많이 있을겁니다.
(프로그램 코딩하는 분들이 사용하는 것...)
-
gromob
2012.09.05 08:58
저도 이런 작업을 10여년 전부터 종종 하고있는데요.
전반적으로 고칠것이 정해진 (수정 명령이 있는) 경우가 아니라면
최종 수정은 chief editor 한 명이 하고 이에 대해서는 다른 저자들은
아무 이의를 달지 않도록 하고 작업합니다.
그래서 논의 후에 chief 마음대로 고치니까 수합후 수정을 검토할
필요가 없게됩니다.
그런 것이 아니라면 tex의 경우에 제가 고친다면 다음과 같이 합니다.
(원본)
... 이것을 보면 북송이 남송보다 기술개발에 능했다는 것을 알 수 있다. ...
(수정)
... 이것을 보면 북송이 남송보다 기술개발에
%능했다는
적극적이었다는
것을 알 수 있다. ...
이런 식으로 하던가 수정한 여러 사람을 구별할 수 있게 하려면
(수정)
... 이것을 보면 북송이 남송보다 기술개발에
%%gromob
%능했다는
적극적이었다는
것을 알 수 있다. ...
식으로 적어서 %%gromob 정도만 찾아보면 제가 고친 것을모두 쉽게 찾아볼 수 있게 합니다.여러 사람이 검토하는 파일이라면 수정하는 사람이 이정도성의는 보여야 뒷 일이 쉽게 돌아가겠지요. -
aeronova
2012.09.05 09:12
코멘트 방식으로 누가 뭘 고쳤는지 달아두는 것도 괜찮은 방법이군요. 조언 감사합니다.
-
aeronova
2012.09.05 09:17
-
샘처럼
2012.09.05 14:44
windows에서라면 Acroedit의 부속 유틸인 acrodiff가 비슷한 환경을 제공하여 줍니다. http://faq.ktug.or.kr/faq/AcroEdit 를 참조하세요. ^^
-
gromob
2012.09.05 20:44
아 이런 툴이 있었군요. 나중에 쓰게되면 꼭 기억했다가 시도해 봐야겠습니다.
여기서 곧바로 텍 컴파일하는 것은 쉬울지 잘 모르겠지만요...
알려주셔서 감사합니다.
ndh 님의 아래 커멘트도 감사합니다.
-
ndh
2012.09.05 16:11
subversion 관련해서 PracTeX 저널에 소개된 글이 있습니다.
http://tug.org/pracjourn/2007-3/kalderon-svnmulti/kalderon-svnmulti.pdf
좀더 간단한 협력작업에는 changes 패키지를 이용할 수 있습니다. 공동작업자들이 \added, \deleted, \replaced 명령을 일관되게 사용하기로 약속하면 될 거로 봅니다.
version 패키지는 comment 패키지를 이용해서 표시되거나 숨겨지는 부분을 일정한 환경으로 정의할 수 있게 합니다. 각 작업자에게 고유한 환경을 할당하면 그럭저럭 버전 콘트롤 비슷한 일을 할 수 있습니다.
diff와 merge 기능이 있는 에디터는 제법 많다고 봅니다. mac에서는 textmate가 꽤 좋다고 하는데 textwrangler에도 difference라는 기능이 있어서 diff-merge가 가능합니다.
-
마잇
2012.09.09 15:39
원하시는 기능은 git같은 버전 관리 시스템에서 모두 찾으실 수 있을 겁니다.
길지 않고 간단하게 소개 해보겠습니다. ^^
변경 이력 관리
어떤 내용을 왜, 무엇을 참조해서 썼는지 기록이나 메모를 남기는 용도로 쓰시면 편리합니다.
특정 파일이나 전체 파일의 변경 기록을 볼 수 있습니다.
이전 상태로 되돌리기
실수해서 파일을 삭제 했거나 잘못된 내용을 입력하고 저장했을 때 편리한 기능입니다. 이런 실수를 방지하기 위해서 간단하게 수작업으로 관리할 경우 원본을 놔두고 복사본에 변경사항을 적용해서 저장하거나 하는데 이런 과정이 계속 되면 계속 파일이 늘어나면서 관리하기가 힘들어 집니다. 폴더나 파일에 이름에 날짜 붙여서 관리해 보셨다면 공감하실 겁니다.
더군다나 수작업으로 해야하기 때문에 실수가 방생할 여지가 많습니다.
무엇보다도 병합 작업에 실수가 있었는데 이전 버전의 원본이 없을 경우 곤란한 상황이 생길 수 있는데 이럴 때 되돌리는 기능이 아주 좋습니다. 파일 하나만 되돌리던지 여러 파일들 전체를 되돌리던지 하는 기능을 신뢰성 있게 제공합니다. 직전이 아닌 특정 시점의 상태로 돌리는 것도 잘 됩니다.
편집기에서 지원되는 되돌리기(언두)기능을 폴더 전체 내용에 자유 자재로 구사한다고 생각하시면 됩니다.
다른 저자와의 작업 내용 병합
자동으로 병합할 수 있는 부분은 자동으로 해줍니다. 하지만 같은 부분을 편집해서 충돌이 나는 경우 직접 살펴본 후 선별적인 병합이 가능합니다. 이 단계에서 스크린샷으로 올려주신것과 같은 외부 merge tool과 연동하게 되면 편리 합니다.
자동으로 병합하지 않고 모든 변경 사항을 전부 직접 병합할 수도 있습니다.
팀원들도 같이 버전 관리를 사용한다면 어느 부분을 누가 언제 수정했는지 줄 단위로 쉽게 파악할 수 있습니다.
브랜치를 이용한 손쉬운 작업 상태 변경
챕터 1, 2, 3을 다 쓰고 챕터 4를 쓰고 있는데 외부적인 요인으로 전반적을 집필 내용을 수정해야 한다거나, 어느 날 아침 자고 일어나 보니 그동안 써놓은 게 다 맘에 안든다! 이런 상황을 가정해 보겠습니다.
지금까지 작업한 이력에 계속 이어나가면서 수정하는 것도 나쁜 방법은 아닙니다만 제 경험상 한 번 바뀐 것은 또 바뀔 확률이 높더군요. 싹 뜯어 고치고 수정해서 보여주면 "아 이것도 좀 아닌데요, 원래대로 갑시다.", "이렇게 말고 좀 다른식으로 해봅시다.". 이런 경우가 현실적으로 많더라는 거죠. 아니면 또 어느날인가 일어나 보니 스스로 다시 뜯어고치고 싶을 때도 있을지 모릅니다.
제 경험으로는 일단 한 번 바뀌면 두세번 바뀌는 건 흔한 일이더군요. ^^
이럴 때 브랜치를 사용하면 그 기능이 빛을 발합니다. 현재까지의 작업과 비교해 방향 자체가 달라져 버리는 경우, 현재까지 작업 이력은 별도로 놔두고 완전히 독립된 작업 상태로 전환해서 별도의 작업 이력을 시작할 수 있습니다.
현재 상황의 작업 이력을 건드려 어수선하게 하지 않고 별도의 임시 작업 공간을 만드신다고 보시면 됩니다. 여기서의 작업 이력도 모두 별도로 보관 됩니다.
브랜치간의 전환도 언제든 가능 합니다. 브랜치간의 내용을 통합하는것도 지원 합니다. 다른 저자와의 내용 병합이 바로 이 브랜치 병합 입니다.
현재 작업을 기반으로 '가지'를 친다는 의미로 브랜치라는 이름이 붙었다고 생각할 수 있습니다.
편리한 사용
프로그래밍하는 분들이 주로 사용하고 기능이 많기 때문에 복잡하고 어렵게 느껴질 수 있는데 원하는 만큼의 기능만 활용하면 간단 합니다.
- 단계별 작업 이력 저장
- 이전 작업 이력 중 원하는 시점으로 되돌리기
- 다른 작업자의 작업 내용을 자동 병합
- 현재 작업 상태와 별도로 작업 공간 생성
- 별도의 작업 공간에서 변경한 내용을 원래의 작업으로 병합
이정도 기능만 사용하셔도 대단히 편리 합니다. 저 개인적으로는 브랜치 기능을 이용한 다양한 작업 상태를 자유롭게 변경할 수 있는 점을 아주 좋아합니다.
가장 중요한 점!!!
기능이 좋고 많아도 결국 꿰어야 보배가 될텐데... 편리한 도구가 있어야 사용하기가 편하겠지요. 맥을 안써봐서 추천해드리기가 애매하네요. :)
오픈소스로 공개되어 있고 평이 좋은 것 같습니다.
- github for mac -
http://mac.github.com/
github라고 git에 기반한 일종의 호스팅 사이트인데 이 바닥에서는 최고로 쳐줍니다. github 서비스를 사용하기 편하게 특화된 것 같은데 기본적인 git의 기능도 지원하는 것 같습니다. 작업하시는 내용이 외부에 공개되는 안되는 것이라면 github에 저장소를 등록하시면 안됩니다. 비공개 저장소도 지원하기는 한데 유료 입니다.
- TextMate git bundle -
https://github.com/textmate/git.tmbundle#readme
texmate 번들인데 개발이 활발히 되는 것 같지 않습니다. textmate를 사용하시는 것 같으니 한 번 살펴보세요.
-
Progress
2012.09.09 22:43
좋은 글 잘 읽었습니다. 감사합니다.
SVN을 써 본 적이 있는데, 그다지 익숙해지지 않더라고요. 저자들이 몫을 나누어 맡고 전체적으로 보는 편집자를 두는 것이 가장 바람직하지 않을까 생각합니다. 처음에는 기술적인 문제만 염두에 두었지만 막상 해보니 문장 스타일이 다른 게 더 큰 문제이더군요.