웹사이트도 인쇄할 수 있어야 한다
Websites Should Be Printable
블로그 글을 인쇄해 읽는 것을 좋아하는 개발자 Brennen Puth가 자신의 웹사이트를 인쇄용으로 최적화한 경험을 공유한다. @media print 규칙으로 헤더를 숨기고, 글꼴 크기를 12pt로 조정하고, 링크 색을 검정으로 바꾸는 등 CSS 몇 줄로 인쇄 품질을 개선했다. 그는 인쇄를 신경 쓰는 사이트가 드물고 시간이 들지만, 텍스트 중심 사이트라면 독자가 선호하는 매체로 콘텐츠를 경험하게 하는 작은 친절이 가치 있다고 말한다.
좋은 소프트웨어로 가는 길은 소프트웨어 엔지니어가 사용자에게 베푸는 친절로 포장되어 있다.
HN 토론
132- beej71
좋은 HTML 구조로 인쇄가 잘 되게 하는 것, 그리고 내비게이션 요소 등을 숨기는 것에는 찬성합니다만, 인쇄 버전에서 기본 폰트 크기나 폰트를 바꾸는 것에는 그다지 찬성하지 않습니다.
방금 아무데도 폰트 크기를 지정하지 않은 간단한 사이트를 만들었는데, 친구가 모바일에서 폰트가 너무 작다고 불평하더군요. 저해상도 화면인지 감지해서 폰트 크기를 키워야 할까요?
많은 사이트가 정확히 그렇게 한다는 걸 알지만, 저는 그게 잘못됐다고 생각합니다. 사용자는 자신의 플랫폼에서 기본 폰트 크기를 조절합니다. 만약 사용자가 이미 키워놨다면, 제가 또 키우는 꼴이 되잖아요?
사용자가 기본 인쇄 폰트 크기를 줄여놨는데 제가 또 줄이면 어떡하고요?
그런 건 전적으로 사용자에게 맡기는 게 최선이라고 생각합니다.
- pidgeon_lover
웹사이트는 인쇄 가능해야 한다는 데 동의합니다. 저는 RSS와 eInk 디스플레이(킨들, 그리고 여유가 되면 PC 모니터)를 좋아하는데, 인쇄 가능한 웹사이트는 종이 같은 디스플레이에서 그것들을 사용하기 쉽게 해줄 겁니다.
저는 수년간 PrintFriendly [1] 브라우저 확장 프로그램을 사용해 왔는데(인쇄 불가능한 웹사이트를 인쇄하기 위해), 점점 나빠져서 대안을 찾다가 The Printliminator [2](Hartija 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
- armcat
정중히 반대합니다. 팀 버너스 리의 원래 의도[1]는 문서와 정보를 찾아가는 탐색 가능한 방법을 만드는 것이었습니다. 인쇄가 아니었죠. 오늘날 우리가 겪는 모든 문제는 탐색 가능한 개념과 인쇄 가능한 개념을 흐려놓은 데서 비롯됩니다. 웹사이트는 의도된 정보를 쉽게 탐색하고 전달하기 위한 단순하고 깔끔한 공간이어야 합니다. 인쇄에는 LaTeX와 다른 마크업 방식이 있으며 그것들이 인쇄에 완벽합니다.
- swiftcoder
웃기게도, 이 특정 웹사이트에서 CMD-P를 누르면 4페이지가 나옵니다: 첫 페이지는 80%가 비어 있고, 두 번째 페이지는 꽤 괜찮고, 세 번째 페이지는 왼쪽에 얇은 띠로 CSS 코드 샘플만 들어 있고, 마지막 페이지는 다시 대부분 빈 공간입니다...
저도 비슷한 걸 시도했지만, 이력서[1] 서식을 맞추기 위해서만 했습니다. 많은 고용주가 PDF로 제출하라고 요구하거든요.
- lopsotronic
브라우저 벤더들과 이야기해서 CSS L3 PMM[1] 스펙을 넣도록 하세요. 그 스펙은 초안 상태로... 어디 보자... 오, 이런, 벌써 20년째네요.
CSS PMM이 브라우저에 들어가는 순간 - 밀리초 단위로 - PDF 생태계는 사라질 겁니다[2].
그건 그렇고, 핵심으로 돌아가면, HTML을 페이지 기반 UX로 제한하기에는 너무 늦었습니다. "브라우저"가 우리가 예전에 클라이언트-서버 컴퓨팅이라 부르던 것과 일종의 적시 소프트웨어 개발을 위한 다소 형편없는 샌드박스가 된 지도 적어도 10년은 됐습니다. 하지만 소프트웨어, 소프트웨어 작성이라는 것은 문서에서 사용하는 자연어와 정반대입니다. 그래서 우리는 하나를 "형식" 언어라 부르고 다른 하나를 "자연" 언어라 부르죠. 이 둘의 인터페이스, 즉 둘을 같은 것으로 만들려는 시도는 끝없이 풍요로운 고통의 뿔이 넘치는 곳입니다.
조건문과 트랜스클루드[3] 같은 복잡한 마크업 구조가 자연어, 즉 문서와 부딪히는 모습에서 이를 볼 수 있습니다. 이것이 지금까지 만들어진 모든 WYSIWYG "종이 같은" XML 편집기가 끔찍하게 형편없는 큰 이유입니다. 개발자들이 모두 바보라서가 아닙니다 - 저는 많은 개발자를 알고 있고, 그들은 제가 아는 가장 똑똑하고 약삭빠른 개발자들 중 일부입니다 - 개념적으로 실행 불가능한 작업을 떠맡기 때문입니다.
[1] Paged Media Module
[2] 뭐, 고급 인쇄 제작, 광택 인쇄, 임원용 백서를 제외한 모든 곳에서요. 하지만 그곳에서조차 그들은 [...]
- jillesvangurp
인쇄와 관련된 CSS 문제를 디버깅하는 것은 꽤 골치 아플 수 있습니다. 풀스택 페이지에서 동적 콘텐츠에 인쇄 옵션을 추가하는 것은 기술적으로 그렇게 어렵지 않습니다. 하지만 제대로 보이게 하는 것은 좀 까다로울 수 있죠. 인쇄된 후 어떻게 보일지 신경 쓰지 않으면 쉽습니다. 하지만 신경 쓴다면 실제로 약간의 고려가 필요합니다.
저는 CSS와 JavaScript만으로 라벨 프린터용 라벨을 생성하는 애플리케이션으로 몇 가지 커스텀 작업을 해봤습니다. 그렇게 어렵지는 않습니다. 하지만 네이티브 인쇄 대화상자와 브라우저별 인쇄 대화상자(및 인쇄 미리보기)의 차이, 네이티브 프린터 설정 및 크기 조정 옵션과의 기능 상호작용, 브라우저가 인쇄 문서에 바닥글을 추가하는 문제, 레이아웃 문제, 페이지 크기, 여백 등과 관련된 온갖 이상한 점을 다뤄야 합니다.
이걸 다루면서 느낀 일반적인 생각은 브라우저 개발자들이 인쇄용 CSS를 일반 CSS보다 훨씬 덜 검토한다는 것입니다.
할 수 있는 꼼수 중 하나는 인쇄 전용 DOM 트리를 생성하는 것입니다. DOM 트리의 루트를 그것으로 교체하고, 인쇄를 트리거한 다음, 원래 DOM 트리(풀스택 애플리케이션과 나머지 전부)를 다시 복원하는 것이죠. 그렇게 해야 한다는 게 매우 꼼수처럼 보입니다. 하지만 어느 정도 작동하고 하기에 충분히 간단합니다. 그리고 장점은 나머지 애플리케이션(아마 인쇄를 전혀 고려하지 않을 것)을 방정식에서 빼내어 인쇄 레이아웃을 방해하지 않게 한다는 것입니다. 개념적으로, 당신을 [...]
- bigblind
솔직히 말하면, 이건 제 우선순위 목록에서 꽤 낮은 항목인 것 같습니다. 시간이 제한적이라면 화면 UX와 접근성에 훨씬 더 집중하고 싶습니다. 특정 맥락에서는 인쇄 가능하게 만드는 것이 의미가 있고, 티켓, 인보이스 등에 대해 사이트들이 하는 PDF 생성의 상당 부분을 실제로 대체할 수 있다고 생각합니다.
- pmlnr
오, 와, 정말 순진한 print.css네요.
미디어 크기를 조정해 모든 공간을 차지하지 않게 한다든지, 특정 요소가 나뉘지 않게 막는다든지, 필요할 때 줄바꿈한다든지, 링크를 인쇄한다든지(원문 그대로) 등이 빠져 있습니다.
후자는 제가 링크를 인라인 링크 대신 각주로 옮긴 이유이기도 합니다 - 읽기 흐름이 끊기는 것도 막기 위해서죠.
그리고 페이지 카운터를 추가하는 것은 사실상 불가능합니다.
어쨌든 좋은 아이디어라고 생각하지만, 주로 보관 목적입니다: 정말로 보관용 사본을 원한다면 인쇄해야 하니까요.