요약
글 중심의 웹사이트라면 인쇄해도 읽기 좋도록 인쇄용 CSS를 갖춰야 합니다.
컴퓨터과학 전공 졸업을 앞둔 개발자 브레넌 푸스의 글입니다. 요즘 논문을 종이로 뽑아 메모하며 읽는 그는 자기 블로그 글도 종이로 읽을 수 있게 하고 싶었습니다.
왜 중요한가
- 화면에서 멀쩡한 사이트도 인쇄 결과는 따로 손봐야 한다는 점을 자기 블로그로 보여 줍니다.
- 독자가 원하는 매체로 읽게 해 주는 것도 개발자가 사용자에게 베풀 수 있는 배려라고 봤습니다.
- 단순한 사이트라면 오전 한나절 정도의 작업으로 충분했다고 밝혔습니다.
핵심 내용
- 처음 Ctrl-P로 인쇄해 보니 글자가 두 단계쯤 컸고, 파란 링크는 흑백에서 흐린 회색이 됐습니다.
@media print(인쇄할 때만 적용되는 CSS 규칙)로 본문은 12pt, 제목은 13~16pt로 고정하고 링크는 검은색으로 맞췄습니다.- 인쇄에서 숨길 요소와 인쇄에만 보일 요소를 클래스로 나눠, 헤더는 빼고 작성자 표기는 넣었습니다.
- 코드 블록이 페이지 경계에서 잘리지 않게 하는 방법은 찾지 못해 독자에게 해법을 물었습니다.
- HN과 lobste.rs에서 지적을 받은 뒤 스타일시트를 크게 단순하게 고쳤다고 덧붙였습니다.
HN 반응
- 글꼴 크기는 사이트가 정하지 말고 사용자 설정에 맡겨야 한다는 접근성 지적과, 기본값은 사이트가 잘 골라 줘야 한다는 반론이 맞섰습니다.
- Chrome과 Firefox는 인쇄하면 줄이 페이지 경계에서 잘린다는 불만이 이어졌고, 정작 이 글도 인쇄하면 빈 페이지가 많이 생긴다는 지적이 나왔습니다.
모든 웹사이트가 인쇄 가능해야 한다고는 생각하지 않아요.
하이퍼텍스트는 인쇄 가능해야죠.
하이퍼미디어는 상호작용이 아주 풍부해야 하고요.
HTML 구조를 잘 잡아서 인쇄가 깔끔하게 되게 하자는 데도, 내비게이션 요소 같은 걸 숨기자는 데도 동의합니다. 하지만 인쇄용 버전에서 기본 글꼴 크기나 글꼴을 바꾸자는 데는 그다지 동의하기 어렵습니다.
얼마 전에 글꼴 크기를 어디에서도 지정하지 않은 간단한 사이트를 만들었는데, 친구가 모바일에서 글자가 너무 작다고 불평하더군요. 그렇다고 해상도가 낮은 화면을 감지해서 글꼴 크기를 키워야 할까요?
그렇게 하는 사이트가 많다는 건 알지만, 저는 그게 옳지 않다고 생각합니다. 기본 글꼴 크기는 사용자가 자기 플랫폼에서 직접 정하는 것입니다. 이미 글꼴을 키워 둔 사용자라면요? 거기에 제가 또 키우는 셈이 됩니다.
반대로 인쇄 기본 글꼴 크기를 줄여 둔 사용자한테 제가 또 줄여 버리면 어떻게 됩니까?
이런 건 전적으로 사용자에게 맡기는 것이 최선이라고 생각합니다.
맞습니다. 접근성의 기본 중의 기본이죠.
이에 대해 제가 받아들일 만한 반론은 하나뿐입니다. 사용자들이 글꼴 설정이 있다는 사실을 모른다는 점입니다. 하지만 제대로 된 해법은 모든 웹사이트가 저마다 글꼴 조절 기능을 넣는 게 아니라, 브라우저가 그 설정을 더 쉽게 찾아 쓰도록 만드는 것입니다.
누구나 자기 기기에 대해 뭔가는 배워 두는 게 좋겠지만, 사용자에게 내놓는 기본값은 좋은 값이어야 한다고 생각합니다.
선을 어디에 그을지는 어려울 수 있지만, 기본 글꼴은 대부분의 사람이 읽을 수 있을 만큼 대비가 분명해야 하는 건 맞지 않나요? 사용자는 기기의 많은 기본값을 바꿀 수 있지만, 좋은 경험을 하려고 굳이 설정을 바꿔야 해서는 안 됩니다. 우리는 이미 웹사이트를 많이 커스터마이징하고 있기도 하고요.
인쇄 버전의 목적에 따라 다르겠지만, 사람들은 화면에서 보기 좋게 하려고 글꼴과 스타일을 고르는 데 많은 시간을 씁니다. 저는 이 글이 인쇄용 스타일시트에도 그만큼 공을 들이라는 뜻이라고 받아들였습니다.
그래서 저는 max-width를 안 씁니다. 웹사이트가 그걸 쓰면 짜증이 나요. 창 크기는 사용자가 정하는 건데요.
웹사이트는 인쇄할 수 있어야 한다는 데 동의합니다. 저는 RSS와 전자잉크 디스플레이(킨들, 그리고 여유가 생기면 PC 모니터도)를 좋아하는데, 인쇄 가능한 웹사이트라면 종이 같은 디스플레이에서 쓰기도 더 쉬울 겁니다.
저는 PrintFriendly [1] 브라우저 확장 프로그램을 몇 년째 써 왔습니다(인쇄가 안 되는 웹사이트를 인쇄하려고요). 그런데 갈수록 나빠져서 대안을 찾다가 먼저 The Printliminator [2](Haartija CSS 프레임워크 [3]를 씁니다)를 써 봤고, 지금은 CopyAsMarkdown [4](Pandoc과 함께)와 WebToEpub [5]에 정착했습니다.
[1] https://www.printfriendly.com/ [2] https://github.com/CSS-Tricks/The-Printliminator [3] https://github.com/vladocar/Hartija---CSS-Print-Framework [4] https://github.com/yorkxin/copy-as-markdown/ [5] https://github.com/dteviot/WebToEpub
브라우저가 화면에, 그것도 온갖 크기의 화면에 보여 줄 수 있다면 프린터로도 출력할 수 있어야 합니다. 완벽한 충실도로요. 그렇지 않다는 게 정말 짜증 납니다.
제 추측으로는 이렇게 엉망인 이유가 크롬 팀이 인쇄 기능에 관심이 없기 때문입니다(적어도 충분하지는 않아요). 파이어폭스는 조금 낫습니다. 하지만 인터넷 익스플로러 시절 이후로는 제대로 된 인쇄를 본 적이 없습니다.
가장 짜증 나는 사례는 웹사이트 이용약관입니다. PDF로 인쇄하면 줄 한가운데가 잘리는 곳에서 페이지가 넘어갑니다.
이게 문제라는 것 자체가 말이 안 되고, 아주 오래전부터 그래 왔죠.
저는 가르치는 일을 많이 하는데, 여러 이유로 웹페이지와 URL에 더해 글을 PDF로도 공유합니다. 저는 이런 문제를 피해 가는 법을 알지만, 글을 인쇄해야 할 이유는 많은데 일반 사람들은 어떻게 하라는 걸까요? 아니, 긴 문서 한가운데에 잘린 곳이 파묻혀 있는데 그걸 한참 지나서야 알아챌 때도 있다니까요...
네, 저도 파이어폭스와 크롬에서 제일 짜증 나는 게 바로 그겁니다. 화면에서는 똑같은 페이지가 완벽하게 렌더링되는데도 인쇄 명령은 거의 항상 완전히 쓰레기를 내놓습니다.
이유는 모르겠지만 비발디 브라우저에서는 인쇄가 훨씬 잘 됩니다. 파이어폭스와 크롬에서 깨지는 페이지도 비발디에서는 제대로 나오는 경우가 많습니다. 게다가 인쇄 속도도 몇 배는 빠릅니다. 그래서 평소에는 파이어폭스로 브라우징하지만 페이지를 저장하고 싶을 때는 비발디로 다시 열어 거기서 인쇄할 때가 많습니다. 안타깝게도 비발디조차 항상 완벽하지는 않습니다.
브라우저에서 인쇄 명령이 제대로 동작하지 않는 건 정말 짜증 나는 일입니다. 요즘은 그게 웹페이지를 저장하는 유일하게 믿을 만한 방법이기 때문입니다. "저장" 명령으로 페이지를 저장하는 건 거의 안 통합니다. 특히 저장한 페이지를 오프라인에서 읽으려 하면 더 그렇습니다. 화면에 보이는 내용을 스크립트로 생성하는 페이지가 너무 많은데, 그런 스크립트는 오프라인이나 로컬 파일 안에서는 동작하지 않는 경우가 많기 때문입니다.
이용약관 같은 법률 문서는 일부러 인쇄하기, 복사해서 붙여넣기, 그 밖의 어떤 조작이든 어렵게 만들기로 악명이 높습니다.
클릭해서 들어가 보면 가장 불편한 팝업, 모달 대화상자, 이런 목적으로 남용되는 중간 삽입 창 속에 그 글이 쑤셔 넣어져 있는 경우가 많습니다. 게다가 참을 수 없을 만큼 장황합니다.
저는 이른바 "법적 계약"이라는 것의 본문을 저장해 두려고 자주 시도합니다. "PDF로 인쇄"에 밀어 넣어 보지만 실패합니다. 그러면 Google Keep에 복사해서 붙여넣어 보는데, Keep에는 글자 수 제한이 있어서 이것도 실패합니다. 그래서 결국 Google Docs에 욱여넣는데, 내용을 제대로 옮기려면 복사, 붙여넣기, 스크롤, 스크롤, 스크롤을 열다섯 번쯤 반복해야 하는 일이 흔합니다.
나중에 쓸모가 있을 수 있습니다. 예를 들어 개인정보 보호나 법무 부서의 연락처가 들어 있는 경우가 많고, 이용약관 끝부분에 수신 거부 방법이 슬그머니 적혀 있기도 합니다. 불만 처리 절차의 단계가 문서화되어 있을 수도 있습니다. 고객이 불만을 접수할 때 그쪽이 정한 절차를 따르지 않고 그쪽 정책대로 진행하지 않으면, 그쪽에는 도와줄 의무가 전혀 없습니다. 그러니 어떤 서비스든 진지하게 쓰고 있거나 그 서비스에 큰돈이 걸려 있다면, 어떤 수단을 써서라도 그 약관을 붙여넣든 인쇄하든 해 두시길 권합니다.
물론 그쪽은 변덕에 따라 사용자에게 거의 알리지도 않고 약관을 바꿀 테고, 그러면 게임이 처음부터 다시 시작됩니다. 이상한 게임이죠. 어쩌면 가장 현명한 수는 아예 하지 않는 것일지도 모르겠습니다.
정중하게 반대합니다. 팀 버너스리가 원래 의도한 것은 [1] 문서와 정보를 찾아다닐 수 있는 길을 만드는 것이었지, 인쇄가 아니었습니다. 오늘날 우리가 겪는 문제는 전부 "탐색"과 "인쇄"라는 두 개념을 뒤섞어 버린 데서 나옵니다. 웹사이트는 의도한 정보를 쉽게 탐색하고 전달할 수 있는, 단순하고 깔끔한 공간이면 충분합니다. 인쇄에는 그 목적에 딱 맞는 LaTeX와 여러 마크업 방식이 있고요.
[1] https://info.cern.ch/hypertext/WWW/TheProject.html
저도 정중하게 반대합니다. 팀 버너스리의 의견이 이 문제와 대체 무슨 상관입니까? 웹페이지를 읽기 좋은 인쇄물로 뽑고 싶은 때 LaTeX가 무슨 소용입니까?
정말 좋은 지적이네요! 브라우저가 HTML뿐 아니라 LaTeX로 쓴 페이지도 받아 준다면 웹이 훨씬 보기 좋아질 거예요.
어쨌든 TeX는 종이에 고품질로 인쇄하자고 만든 거잖아요.
브라우저는 이미 PDF를 받아 줍니다. TeX 파일은 이식성이 없고요.
브라우저에 버그가 아직도 모자란 것처럼, 이제 TeX까지 넣자고요?
크누스 선생님이 걸어 둔 버그 현상금은 지금까지 가장 오래 이어진 현상금이잖아요!
무슨 면에서 이식성이 없다는 겁니까?
개발 머신을 통째로 들고 다니지 않는 한 쓸 수 없다는 면에서요.
맞습니다. 그래서 브라우저가 장치에 독립적인 출력을 처리해야 하는 겁니다.
MathML이요?
제 컴퓨터의 TeX 배포판(mactex)은 4기가바이트쯤 됩니다. "웹 브라우저에 같이 넣을" 만한 크기는 절대 아니죠.
글쎄요, 저는 은퇴해서 앞으로 30년 넘게 일하지 않고 싶은데, 원한다고 다 얻는 건 아닌가 봐요 :(
WWW의 원래 설계는 그가 만든 때부터 오늘날까지 열두 번쯤 모습이 바뀌었습니다. 저도 모든 혁신이 마음에 들지는 않지만, 오늘날 우리가 당연하게 여기는 것 가운데 HTML1로는 불가능했던 게 많습니다. 뱅킹 앱이 그렇죠.
그러니 이제 존재하지도 않는 것을 두고 따지는 건 별 의미가 없다고 생각합니다.
뱅킹 앱은 "웹사이트"가 아닙니다. 우연히 같은 기술로 인터페이스를 보여 줄 뿐이고, 웹사이트와 웹 앱 사이에는 큰 차이가 있습니다.
이 구분은 중요합니다. 사람들이 이 둘을 심하게 혼동해서 웹 앱이 웹사이트 같기를 기대하고, 반대로 HTML과 CSS로 충분한 웹사이트를 웹 애플리케이션을 만들 때 쓰는 기술로 구현해 JS로 인터넷 회선을 잔뜩 부풀리기 때문입니다.
큰 차이가 있긴 하죠. 하나는 "website"라고 쓰고 다른 하나는 "web app"이라고 쓰니까요.
그 밖에 그 구분은 순전히 임의적입니다. 기술 스택도 같고, 전달 방식도 같고, 클라이언트 쪽에서 보여 주는 도구도 같습니다.
가장 큰 문제는 우리가 모바일 우선 설계로 넘어갔고, 거기에 백엔드와 프런트엔드 기능이 끔찍하게 갈라졌다는 점입니다. 요즘 많은 사이트에서 소스 보기를 눌러 보면, 페이지는 실제로 HTML을 페이지에 집어넣는 자바스크립트를 호출하는 뼈대에 불과합니다. 사이트가 하는 일을 숨기려는 것이라기보다는, 웹 개발자들이 HTML 쓰기를 두려워해서 그걸 자바스크립트 프레임워크의 프레임워크에 떠넘기는 겁니다.
웃기게도 이 사이트에서 CMD-P를 누르면 4쪽이 나옵니다. 첫 쪽은 80%가 빈 쪽이고, 둘째 쪽은 꽤 괜찮고, 셋째 쪽에는 CSS 코드 샘플이 왼쪽에 가느다란 띠로만 나오고, 마지막 쪽도 거의 빈 공간입니다...
저도 비슷한 걸 시도해 봤는데, 이력서1를 꾸미려는 용도뿐이었습니다. 많은 고용주가 PDF로 제출하라고 하니까요.
이제 이런 문제를 많이 고쳤습니다. 아이러니하게도 스크린샷을 넣은 뒤에 인쇄 결과를 확인하는 걸 잊어서 이것저것 다 망가졌었네요.
저도 똑같이 나옵니다. "My accidental pnmp forkbomb" 스크린샷의 높이 때문에 둘째 쪽으로 넘어가 버리는 것 같습니다.
HTML/CSS를 인쇄 매체로 쓸 때 좋은 점 하나는, 페이지 나눔을 해석하는 방식이 브라우저마다 다른 것 같다는 겁니다. 게다가 CSS로 특정 페이지 나눔을 막을 수는 있어도, img 태그 같은 요소 안에서 페이지 나눔을 강제할 수는 없습니다.