Markdown 파일: 관례를 따르는 일반 텍스트, 그리고 그 관례는 하나가 아닙니다

문제는 Markdown이 하나가 아니라는 점입니다. 2004년의 원래 구현은 정의하지 않은 경우를 아주 많이 남겨 두었고, 그래서 렌더러마다 이를 다르게 처리했습니다. CommonMark는 그런 모호함을 확정하기 위해 존재하며, GitHub Flavored Markdown은 그 위에 표, 작업 목록, 취소선을 더합니다. 이런 상황은 공식적으로도 인정되어 있습니다. 2016년 3월 RFC 7763에서 text/markdown이 미디어 유형으로 등록될 때 variant 매개변수가 포함되었는데, 파일이 Markdown이라고만 해서는 어떤 Markdown인지 알 수 없기 때문입니다. 이 사이트가 내보내는 것은 UTF-8의 text/markdown이며, 모든 방언이 합의하는 구문인 해시 제목, 빈 줄로 구분한 문단, 하이픈 글머리 기호, 가로줄만 사용합니다.

PDF를 Markdown으로 변환한다는 것은 PDF에 애초에 없던 구조를 만들어 낸다는 뜻입니다. PDF는 제목이 아니라 글자 크기를 기록하므로, 페이지의 글자 크기에 순위를 매겨 가장 큰 여섯 개를 여섯 단계의 제목 수준으로 삼습니다. 본문보다 크기만 큰 줄이라도 작성자가 제목으로 여겼는지와 상관없이 제목이 됩니다. 목록은 더 어렵습니다. PDF에는 목록이라는 구조가 전혀 없고 눈에 보이는 글머리 기호는 말 그대로 텍스트 속 문자 하나이므로, 목록을 살리는 유일한 방법은 그 문자를 알아보고 하이픈으로 바꿔 쓰는 것입니다. 번호 매긴 항목은 이런 도움이 필요 없습니다. "1. "과 "1) "은 이미 Markdown이고, 이미 목록을 뜻합니다.

텍스트 자체를 바꾸는 세부 사항 두 가지는 알아 둘 만합니다. 하이픈으로 끝나는 줄은 줄바꿈 때문에 끊긴 단어로 보고 하이픈 없이 다시 이어 붙입니다. 또 중국어나 일본어의 연속된 줄은 공백 없이 이어 붙이는데, 이 문자 체계는 원래 줄 사이에 공백을 넣지 않기 때문입니다. 페이지 사이는 가로줄로 구분하므로 13쪽 문서에는 가로줄이 12개 들어갑니다. PDF가 텍스트 레이어 없는 스캔본이라면, PDF 워드 변환에 쓰는 것과 같은 인식 모델이 먼저 사용자의 기기에서 페이지 이미지의 글자를 읽어냅니다.