요약
글 중심의 웹사이트라면 인쇄해도 읽기 좋도록 인쇄용 CSS를 갖춰야 합니다.
컴퓨터과학 전공 졸업을 앞둔 개발자 브레넌 푸스의 글입니다. 요즘 논문을 종이로 뽑아 메모하며 읽는 그는 자기 블로그 글도 종이로 읽을 수 있게 하고 싶었습니다.
왜 중요한가
- 화면에서 멀쩡한 사이트도 인쇄 결과는 따로 손봐야 한다는 점을 자기 블로그로 보여 줍니다.
- 독자가 원하는 매체로 읽게 해 주는 것도 개발자가 사용자에게 베풀 수 있는 배려라고 봤습니다.
- 단순한 사이트라면 오전 한나절 정도의 작업으로 충분했다고 밝혔습니다.
핵심 내용
- 처음 Ctrl-P로 인쇄해 보니 글자가 두 단계쯤 컸고, 파란 링크는 흑백에서 흐린 회색이 됐습니다.
@media print(인쇄할 때만 적용되는 CSS 규칙)로 본문은 12pt, 제목은 13~16pt로 고정하고 링크는 검은색으로 맞췄습니다.- 인쇄에서 숨길 요소와 인쇄에만 보일 요소를 클래스로 나눠, 헤더는 빼고 작성자 표기는 넣었습니다.
- 코드 블록이 페이지 경계에서 잘리지 않게 하는 방법은 찾지 못해 독자에게 해법을 물었습니다.
- HN과 lobste.rs에서 지적을 받은 뒤 스타일시트를 크게 단순하게 고쳤다고 덧붙였습니다.
HN 반응
- 글꼴 크기는 사이트가 정하지 말고 사용자 설정에 맡겨야 한다는 접근성 지적과, 기본값은 사이트가 잘 골라 줘야 한다는 반론이 맞섰습니다.
- Chrome과 Firefox는 인쇄하면 줄이 페이지 경계에서 잘린다는 불만이 이어졌고, 정작 이 글도 인쇄하면 빈 페이지가 많이 생긴다는 지적이 나왔습니다.
HTML 구조를 잘 잡아서 인쇄가 깔끔하게 되게 하자는 데도, 내비게이션 요소 같은 걸 숨기자는 데도 동의합니다. 하지만 인쇄용 버전에서 기본 글꼴 크기나 글꼴을 바꾸자는 데는 그다지 동의하기 어렵습니다.
얼마 전에 글꼴 크기를 어디에서도 지정하지 않은 간단한 사이트를 만들었는데, 친구가 모바일에서 글자가 너무 작다고 불평하더군요. 그렇다고 해상도가 낮은 화면을 감지해서 글꼴 크기를 키워야 할까요?
그렇게 하는 사이트가 많다는 건 알지만, 저는 그게 옳지 않다고 생각합니다. 기본 글꼴 크기는 사용자가 자기 플랫폼에서 직접 정하는 것입니다. 이미 글꼴을 키워 둔 사용자라면요? 거기에 제가 또 키우는 셈이 됩니다.
반대로 인쇄 기본 글꼴 크기를 줄여 둔 사용자한테 제가 또 줄여 버리면 어떻게 됩니까?
이런 건 전적으로 사용자에게 맡기는 것이 최선이라고 생각합니다.
맞습니다. 접근성의 기본 중의 기본이죠.
이에 대해 제가 받아들일 만한 반론은 하나뿐입니다. 사용자들이 글꼴 설정이 있다는 사실을 모른다는 점입니다. 하지만 제대로 된 해법은 모든 웹사이트가 저마다 글꼴 조절 기능을 넣는 게 아니라, 브라우저가 그 설정을 더 쉽게 찾아 쓰도록 만드는 것입니다.
누구나 자기 기기에 대해 뭔가는 배워 두는 게 좋겠지만, 사용자에게 내놓는 기본값은 좋은 값이어야 한다고 생각합니다.
선을 어디에 그을지는 어려울 수 있지만, 기본 글꼴은 대부분의 사람이 읽을 수 있을 만큼 대비가 분명해야 하는 건 맞지 않나요? 사용자는 기기의 많은 기본값을 바꿀 수 있지만, 좋은 경험을 하려고 굳이 설정을 바꿔야 해서는 안 됩니다. 우리는 이미 웹사이트를 많이 커스터마이징하고 있기도 하고요.
인쇄 버전의 목적에 따라 다르겠지만, 사람들은 화면에서 보기 좋게 하려고 글꼴과 스타일을 고르는 데 많은 시간을 씁니다. 저는 이 글이 인쇄용 스타일시트에도 그만큼 공을 들이라는 뜻이라고 받아들였습니다.
예전에 교수님 한 분이 프로젝트 소스 코드를 출력해서 가져오라고 하셨어요. 보니까 아직도 그러시나 봐요. 요즘 같은 AI 시대에는 아마 미쳐 버리실 것 같아요.
와, 구문 강조 때문에 컬러 프린터로 뽑으라고도 하셨나요?
저는 거의 매일 프로그래밍을 하는데, vim 하이라이트 규칙에는 굵게, 기울임, 회색(주석용)만 넣어 둡니다.
그래도 제 코드를 읽는 데는 아무 문제가 없습니다.
수염이 충분히 길고 희면 구문 강조는 그때그때 알아서 되죠.
잘 가꾼 수염은 누군가 초자연적이라고 여길 만한 수많은 능력으로 가는 길이죠.
저희는 흑백 프린터밖에 없었어요. 컬러까지 사 주시진 않았을 것 같고요. 그리고 제 기억엔 출력할 때 돌리라고 하신 스크립트가 따로 있었어요. 그러니까 에디터에서 곧장 뽑은 건 아니었죠.
vim의
:hardcopy여, 안녕... :(malloc구현처럼 좀 어려운 C 코드를 짤 때는 코드를 출력해서 수업 사이 쉬는 시간에 펜으로 디버깅하는 방식을 가장 좋아했습니다.나중에야 깨달았는데, 에디터 안에 있으면 "딱 한 번만 더 고쳐서 돌려 보자"는 유혹에 자꾸 빠져서 오히려 시간이 더 걸릴 수 있었습니다. 종이로 보면 이미 써 둔 코드와 머릿속 모델을 맞춰 보고 제 가정을 다시 확인할 수밖에 없었고요.
재미있게도 제 동기 몇 명이 각자 프로젝트에서 이 습관을 따라 하기 시작했고, 나중에는 출력물을 서로 바꿔 보면서 작은 "디버깅" 모임까지 하게 됐습니다.
흥미롭네요. 저도 한동안 코드를 출력해서 디버깅했는데, 이유는 주로 형편 때문이었습니다. 컴퓨터가 없었고, 고등학교 컴퓨터는 하루에 쓸 수 있는 시간이 정해져 있었거든요. 첫 번째 버전도 종이에 짰습니다. 그래야 컴퓨터를 쓸 수 있는 짧은 시간에 코드를 후딱 입력하고 실제로 돌려 볼 수 있으니까요. 정신없던 시절이었지만 그 덕분에 프로그래밍 실력이 늘었다고 생각합니다. 집에 컴퓨터가 있지만 멀리 사는 친구와 저는 "그래프 생성기"라는 프로그램을 같이 짰는데, 수학 함수를 그려 주는 프로그램이었어요. 저는 제 몫을 종이에 짜서 친구에게 주고, 친구가 그걸 입력했죠 :) Turbo C++ IDE로 만들었는데, GUI 프로그램이 흔하지 않던 때라(적어도 고등학교 프로젝트로는요, 인도, 1999년) 한동안 우리가 꽤 인기를 끌었습니다. 와, 옛날 생각하니 정말 재미있네요!
2010년 버클리에서도 종이로 코딩할 일이 꽤 있었습니다. 일부 교수님은 종이로만 시험을 치르셨고, 중간고사를 처음으로 종이에 코딩해 보는 자리로 삼고 싶지는 않으니 미리 조금씩 연습했죠.
십대 때 TI-83용 프로그램을 종이에 스케치하던 기억도 나요. 일일이 입력한 다음 여러 군데를 고치는 게 귀찮았거든요.
웹사이트는 인쇄할 수 있어야 한다는 데 동의합니다. 저는 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로는 불가능했던 게 많습니다. 뱅킹 앱이 그렇죠.
그러니 이제 존재하지도 않는 것을 두고 따지는 건 별 의미가 없다고 생각합니다.