2004/08/25 19:15
TTPDFw에 대한 이야기.
오늘 업데이트하면서 지난 버전과의 날짜 간격을 보니 어느새 석달이 지나있었네요. 그동안에 이사도 하고, 새로운 일도 시작하고 하면서 신경쓸 틈이 없었다는 변명을 한다고 해도 꽤 긴 공백기간이 아니었나 싶은 생각이 들어요. 게다가 어느새 테터툴즈 본체도 업데이트한다고 하니 어지간히 게을렀구나 싶어요.
'고치자 고치자'하면서도 귀찮아서 뒹굴거리다가 오늘 버전을 3a로 올린 이유가 '스스로가 너무 불편해서'라는걸 생각해보면 과연 이걸 공개할 필요가 있었나 하는 생각이 들기도 해요. 오늘은 Mizar님[ http://mizar92.egloos.com/ - 지금은 옮겨졌어요. -]으로부터의 리포트 게시물들에 짤막짤막하게 답변을 해보면서 곧 발표될 테터툴즈 0.93에 대비해서 스스로도 조금 정리해보려고 해요.
폰트와 그림의 문제들.
꽤 고민한 문제인데, PDF파일에 기록할 때 HTML파일을 기초로 기록할 것인가, 아니면 데이터베이스에 기록된 텍스트 데이터를 기초로 기록할 것인가 하는 문제에요. 테터툴즈는 파일을 삽입하는 기능을 제외하고는 HTML태그를 데이터베이스에 직접 기록하고 있는데, 이것만 생각해본다면 HTML 데이터를 기초로 PDF파일에 기록하는 방식을 생각해볼 수 있어요.
그런데 테터툴즈는 그림파일만은 HTML이 아닌 전용 태그를 사용해서 이미지를 기록하고 있어요. 만약 BBCode처럼 이미지의 좌우정렬을 지원하지 않았다면 문제는 간단했겠지만 태터툴즈의 이미지 태그는 여러 가지 정렬 방법들을 지원하고 있기 때문에 이것들을 독립적으로 읽어 해석하는 과정을 거치기에는 귀찮은[!!] 점들이 있었어요. 그래서 태터툴즈의 전용 태그의 해석은 태터툴즈 본체에 맡기고 본체가 전용 이미지 태그를 HTML로 변환한 후의 데이터를 읽어 PDF파일로 변환하는 방법을 선택했어요. 그런데 테터툴즈는 그림파일을 정렬하기 위해 테이블을 사용하는데 이 테이블을 PDF파일에 재현하기 위해서는 그림파일의 좌표와 관련된 몇가지 연산을 해 주어야 하는데 FPDF[ http://www.fpdf.org/ ] 라이브러리의 기능을 완전히 습득하지 못한 상태에서 능숙하게 처리하지 못한 부분들이 많아요.
또, 프린터 드라이버를 사용하는 원래의 PDF파일과는 달리 프린터 드라이버의 도움을 전혀 받을 수 없는 웹에서는 몇가지 제한사항들이 있었어요. 먼저 PDF파일의 제작은 서버에서 수행되기 때문에 폰트를 서버에 설치해서 사용해야 하는데, 서버에서 폰트 파일을 열어 처리하는 방법은 자칫하면 호스팅 서버에서 쫓겨날 가능성을 가지고 있었어요. 사실 구현방법이 조금 까다로운 편이기도 해서 결국은 지금의 모습이 되었지요. 이 부분은 제가 좀더 공부해야 개선될 수 있을 것 같아요.
설정을 저장할 수 없는 문제.
테터툴즈의 개발자님께서 최초의 정식 버전 - 1.0 - 이 나오기 이전의 플러그인 정책으로 '테터툴즈 본체에 수정을 가하지 않는 범위 한에서의 배포를 허용한다.'를 제시하셨어요. 그도 그럴것이 함부로 내부를 수정했다가 다음 버전이 등장했을 때 수정되지 않은 이전 버전으로부터의 수정사항에는 대비할 수 있디만 수정된 이전 버전으로부터는 정상적인 업그레이드를 보증할 수 없어요. 때문에 테터툴즈 본체에 수정을 가하지 않으려고 하고 있고, 덕분에 TTPDFw는 관리자모드에 메뉴도 만들 수 없었지요.
헌데 설정을 저장하기 위해서는 쿠키와 데이터베이스 중의 하나를 선택해야 하는데, 설정은 생각보다 큼직한 데이터이고 여러 환경에 대비하도록 하기 위해서는 데이터베이스에 기록하는 쪽을 선택하는 것이 당연했어요. 그런데 TTPDFw를 위해 테터툴즈의 데이터베이스에 새로운 테이블을 생성한다는 것은 테터툴즈의 데이터베이스 백업 기능과 복구기능을 수정해야 한다는 것을 의미하고, 이런 이유로 데이터베이스를 사용할 수 없었어요. 때문에 사용자 설정을 저장하도록 만들 수 없었지요. 만일 데이터베이스를 자유롭게 사용할 수 있게 되면 이글루스에서처럼 PDF파일에 포함되는 게시물 하나하나까지 관리할 수 있게 될 텐데 말이지요.
하지만 데이터베이스를 사용하지 않고 하는 작업에는 한계가 있고, 앞으로 설정들이 더 늘어나게 되기 때문에 이제부터는 테터툴즈에 관계 없이 데이터베이스를 사용하려고 하고 있어요. 테터툴즈 0.93에 맞춰서 만들어질 TTPDFw의 다음 버전에서는 독립적인 데이터베이스를 사용하고, 얼마 동안은 테터툴즈와는 독립적으로 관리하게 될 거에요.
차례가 맨 뒤에 나오는 문제.
으하하. 이 문제는 간단해요. 그리고 가장 멍청한 이유에요. 이유는 페이지에 직접 서보기 전에는 글이 몇 페이지나 차지할 지 알 수 없기 때문이에요. 사실은 이렇게 글자와 그림이 몇 페이지 정도를 차지할 거라는 정보를 미리 계산해볼 수 있지만 시간이 최대 두배까지 오래 걸렸어요. 사용자의 PC에서 파일을 생성한다면 이정도는 무시해도 괜찮지만 파일이 웹서버에서 만들어지는 이상은 차례를 앞으로 가져오기 위해 그정도의 댓가를 치르는 것은 무모하지 않을까 하고 생각했어요.
그래서 지금은 한 페이지, 한 페이지를 만들어 가면서 이 정보를 기록해 맨 마지막에 차례를 나타내고 있어요. 나름대로는 월간지와 비슷하지 않을까 하고 위안을 삼고 있다고 해요. [...죄송합니다 ;ㅁ;] 이 부분은 앞으로 좋은 생각이 떠오르기 전에는 개선되지 않을 예정이에요. 다만 뒤에 나오는 차례를 표시하지 않는 옵션을 만들어둘 생각이에요.
설정이 그다지 자유롭지 못한 문제.
TTPDFw의 네번째 버전을 준비하면서 사용자의 스킨 기능을 준비하고 있었어요. 앞표지, 뒷표지, 그리고 본문에서 각 구성 요소들 - 제목, 날짜, 본문 등 - 의 위치를 자유롭게 설정하고, 표지에 배경을 넣을 수 있도록 해서 이것들을 스킨 같은 개념으로 디렉토리에 복사해 넣으면 이것들 중에서 선택할 수 있도록 하려고 계획했었어요.
이 부분은 순전히 제가 많은 시간을 투자하지 않았기 때문이에요. 처음에 예상하기로는 구현하는데 별 문제가 없으리라고 생각했는데 예상보다 생각해야 하는 사항들이 많아졌어요. 그래서 '시간이 없다.'는 핑계를 대고 버전 3a 같은 괴상한 버전이 나오게 된 거지요. [...]
그림의 해상도 문제는 지금은 그림을 페이지 사이즈에 맞게 강제로 리사이즈하는 부분이 적용되어 있기 때문인데, 그림이 너무 작으면 억지로 늘리다 보니 생긴 문제에요. 이 부분은 그림이 페이지보다 큰 경우와 그렇지 않은 경우를 나눠서 처리하면 수정할 수 있는 문제에요. 또 한가지 문제가 되는 부분은 그림 크기를 원래 크기보다 작게 해서 표현하는 경우인데, 이 게시물에 사용된 그림을 클릭하면 더 큰 그림이 뜨는 경우에요. 이 경우에도 그림이 어느정도 크기로 표시될지를 정확히 계산하는 부분을 구현하면 해결할 수 있는 문제에요. 제가 게으름을 피우지 않는다면 이 부분은 다음 버전에서 수정되지 않을까 싶어요.
-----
... 처음에 TTPDFw를 만들기 시작한 건 이글루스의 PDF파일 출력기능에 감동해서였어요. 첫 버전의 날짜를 보시면 아시겠지만 이글루스에서 PDF파일 베타 서비스를 시작하고 2~3일이 지나서였을 거에요. 짐작하셨겠지만 제가 필요해서 만들기 시작했고, 제가 필요한 한은 계속해서 만들어질 거에요. 역시 가장 중요한 문제는 '제가 필요로 하는 기능'이라는 부분이 아닐까 싶어요.
'고치자 고치자'하면서도 귀찮아서 뒹굴거리다가 오늘 버전을 3a로 올린 이유가 '스스로가 너무 불편해서'라는걸 생각해보면 과연 이걸 공개할 필요가 있었나 하는 생각이 들기도 해요. 오늘은 Mizar님[ http://mizar92.egloos.com/ - 지금은 옮겨졌어요. -]으로부터의 리포트 게시물들에 짤막짤막하게 답변을 해보면서 곧 발표될 테터툴즈 0.93에 대비해서 스스로도 조금 정리해보려고 해요.
폰트와 그림의 문제들.
아직 문제가 많아요.
그런데 테터툴즈는 그림파일만은 HTML이 아닌 전용 태그를 사용해서 이미지를 기록하고 있어요. 만약 BBCode처럼 이미지의 좌우정렬을 지원하지 않았다면 문제는 간단했겠지만 태터툴즈의 이미지 태그는 여러 가지 정렬 방법들을 지원하고 있기 때문에 이것들을 독립적으로 읽어 해석하는 과정을 거치기에는 귀찮은[!!] 점들이 있었어요. 그래서 태터툴즈의 전용 태그의 해석은 태터툴즈 본체에 맡기고 본체가 전용 이미지 태그를 HTML로 변환한 후의 데이터를 읽어 PDF파일로 변환하는 방법을 선택했어요. 그런데 테터툴즈는 그림파일을 정렬하기 위해 테이블을 사용하는데 이 테이블을 PDF파일에 재현하기 위해서는 그림파일의 좌표와 관련된 몇가지 연산을 해 주어야 하는데 FPDF[ http://www.fpdf.org/ ] 라이브러리의 기능을 완전히 습득하지 못한 상태에서 능숙하게 처리하지 못한 부분들이 많아요.
또, 프린터 드라이버를 사용하는 원래의 PDF파일과는 달리 프린터 드라이버의 도움을 전혀 받을 수 없는 웹에서는 몇가지 제한사항들이 있었어요. 먼저 PDF파일의 제작은 서버에서 수행되기 때문에 폰트를 서버에 설치해서 사용해야 하는데, 서버에서 폰트 파일을 열어 처리하는 방법은 자칫하면 호스팅 서버에서 쫓겨날 가능성을 가지고 있었어요. 사실 구현방법이 조금 까다로운 편이기도 해서 결국은 지금의 모습이 되었지요. 이 부분은 제가 좀더 공부해야 개선될 수 있을 것 같아요.
설정을 저장할 수 없는 문제.
테터툴즈의 개발자님께서 최초의 정식 버전 - 1.0 - 이 나오기 이전의 플러그인 정책으로 '테터툴즈 본체에 수정을 가하지 않는 범위 한에서의 배포를 허용한다.'를 제시하셨어요. 그도 그럴것이 함부로 내부를 수정했다가 다음 버전이 등장했을 때 수정되지 않은 이전 버전으로부터의 수정사항에는 대비할 수 있디만 수정된 이전 버전으로부터는 정상적인 업그레이드를 보증할 수 없어요. 때문에 테터툴즈 본체에 수정을 가하지 않으려고 하고 있고, 덕분에 TTPDFw는 관리자모드에 메뉴도 만들 수 없었지요.
헌데 설정을 저장하기 위해서는 쿠키와 데이터베이스 중의 하나를 선택해야 하는데, 설정은 생각보다 큼직한 데이터이고 여러 환경에 대비하도록 하기 위해서는 데이터베이스에 기록하는 쪽을 선택하는 것이 당연했어요. 그런데 TTPDFw를 위해 테터툴즈의 데이터베이스에 새로운 테이블을 생성한다는 것은 테터툴즈의 데이터베이스 백업 기능과 복구기능을 수정해야 한다는 것을 의미하고, 이런 이유로 데이터베이스를 사용할 수 없었어요. 때문에 사용자 설정을 저장하도록 만들 수 없었지요. 만일 데이터베이스를 자유롭게 사용할 수 있게 되면 이글루스에서처럼 PDF파일에 포함되는 게시물 하나하나까지 관리할 수 있게 될 텐데 말이지요.
하지만 데이터베이스를 사용하지 않고 하는 작업에는 한계가 있고, 앞으로 설정들이 더 늘어나게 되기 때문에 이제부터는 테터툴즈에 관계 없이 데이터베이스를 사용하려고 하고 있어요. 테터툴즈 0.93에 맞춰서 만들어질 TTPDFw의 다음 버전에서는 독립적인 데이터베이스를 사용하고, 얼마 동안은 테터툴즈와는 독립적으로 관리하게 될 거에요.
차례가 맨 뒤에 나오는 문제.
으하하. 이 문제는 간단해요. 그리고 가장 멍청한 이유에요. 이유는 페이지에 직접 서보기 전에는 글이 몇 페이지나 차지할 지 알 수 없기 때문이에요. 사실은 이렇게 글자와 그림이 몇 페이지 정도를 차지할 거라는 정보를 미리 계산해볼 수 있지만 시간이 최대 두배까지 오래 걸렸어요. 사용자의 PC에서 파일을 생성한다면 이정도는 무시해도 괜찮지만 파일이 웹서버에서 만들어지는 이상은 차례를 앞으로 가져오기 위해 그정도의 댓가를 치르는 것은 무모하지 않을까 하고 생각했어요.
그래서 지금은 한 페이지, 한 페이지를 만들어 가면서 이 정보를 기록해 맨 마지막에 차례를 나타내고 있어요. 나름대로는 월간지와 비슷하지 않을까 하고 위안을 삼고 있다고 해요. [...죄송합니다 ;ㅁ;] 이 부분은 앞으로 좋은 생각이 떠오르기 전에는 개선되지 않을 예정이에요. 다만 뒤에 나오는 차례를 표시하지 않는 옵션을 만들어둘 생각이에요.
설정이 그다지 자유롭지 못한 문제.
TTPDFw의 네번째 버전을 준비하면서 사용자의 스킨 기능을 준비하고 있었어요. 앞표지, 뒷표지, 그리고 본문에서 각 구성 요소들 - 제목, 날짜, 본문 등 - 의 위치를 자유롭게 설정하고, 표지에 배경을 넣을 수 있도록 해서 이것들을 스킨 같은 개념으로 디렉토리에 복사해 넣으면 이것들 중에서 선택할 수 있도록 하려고 계획했었어요.
이 부분은 순전히 제가 많은 시간을 투자하지 않았기 때문이에요. 처음에 예상하기로는 구현하는데 별 문제가 없으리라고 생각했는데 예상보다 생각해야 하는 사항들이 많아졌어요. 그래서 '시간이 없다.'는 핑계를 대고 버전 3a 같은 괴상한 버전이 나오게 된 거지요. [...]
그림의 해상도 문제는 지금은 그림을 페이지 사이즈에 맞게 강제로 리사이즈하는 부분이 적용되어 있기 때문인데, 그림이 너무 작으면 억지로 늘리다 보니 생긴 문제에요. 이 부분은 그림이 페이지보다 큰 경우와 그렇지 않은 경우를 나눠서 처리하면 수정할 수 있는 문제에요. 또 한가지 문제가 되는 부분은 그림 크기를 원래 크기보다 작게 해서 표현하는 경우인데, 이 게시물에 사용된 그림을 클릭하면 더 큰 그림이 뜨는 경우에요. 이 경우에도 그림이 어느정도 크기로 표시될지를 정확히 계산하는 부분을 구현하면 해결할 수 있는 문제에요. 제가 게으름을 피우지 않는다면 이 부분은 다음 버전에서 수정되지 않을까 싶어요.
-----
... 처음에 TTPDFw를 만들기 시작한 건 이글루스의 PDF파일 출력기능에 감동해서였어요. 첫 버전의 날짜를 보시면 아시겠지만 이글루스에서 PDF파일 베타 서비스를 시작하고 2~3일이 지나서였을 거에요. 짐작하셨겠지만 제가 필요해서 만들기 시작했고, 제가 필요한 한은 계속해서 만들어질 거에요. 역시 가장 중요한 문제는 '제가 필요로 하는 기능'이라는 부분이 아닐까 싶어요.
