프론트엔드

회사에서 올해부터 마크다운 에디터를 만들고 있다. WYSIWYG 와 마크다운 소스를 오가는 웹 에디터고, WAS 에 정적 자원으로 올려 납품하는 구조다. 기능 목록에 “PDF로 저장”이 있었는데 이번에 브라우저 인쇄에서만 사용했던 PDF 변환 기능을 서버 변환으로 옮기면서 알게된 점을 기록하고자 한다. 이번 글은 PDF 변환을 브라우저에서 서버로 옮기면서 스택 후보를 어떻게 검토했고, 어떤 규칙을 적용했는지 공유하기 위한 글이다. 시작하기 전, 용어 정리 헤드리스 브라우저(Headless Browser)는 화면 표시 없이 실행되는 웹 브라우저로, 렌더링 결과를 사람이 보는 화면이 아니라 프로그램이 받아 쓰도록 하는 기술을 뜻한다. 사이드카(Sidecar) 패턴은 주 애플리케이션 옆에 별 프로세스를 함께 띄워 부가 기능을 맡기고, 둘을 로컬 통신으로 잇는 배치 방식을 뜻한다. 브라우저 인쇄부터 확인하기 브라우저에서 PDF를 얻는 수단은 window.print() 를 호출하고 사용자가 인쇄 대상을 "PDF로 저장"을 고르는 방법 하나 뿐이다. 당연히 동작은 되지만 해당 기능을 "PDF 내보내기"라고 부르기는 애매했다. 내가 생각하는 PDF 내보내기는 아래 두 조건을 만족해야 한다. 메뉴를 누른 순간 작성 중인 문서가 PDF 파일로 다운로드된다. 중간에 사용자가 고를 것이 없다. 변환을 담당하는 별도 서버나 엔진이 있다. 파일 이름·용지·여백을 프로그램이 정하고, 성공과 실패를 호스트가 알 수 있다. 브라우저 인쇄는 둘 다 채우지 못한다. 파일 이름은 인쇄 대화상자가 정하고, 용지와 여백은 사용자가 마지막에 바꿀 수 있고, 사용자가 취소했는지는 코드가 알 수 없다. 그래서 브라우저 인쇄를 통한 PDF 저장은 PDF 내보내기가 아니라 참고 수단으로만 두기로 했다. 우선 마크다운을 PDF 로 바꾸는 데 무엇이 필요한지 분석해 보았다. 마크다운을 파싱해 문서 구조를 만든다 구조를 HTML/DOM 으로 렌더한다 스타일을 입혀 실제 모양을 만든다 (글꼴·색·간격·표 테두리)