Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
웹사이트의 인쇄 지원은 접근성 측면에서 중요하지만 구현이 복잡합니다. 글자 크기 제어는 사용자에게 맡기는 것이 좋으며, 완벽한 출력을 위해 별도의 DOM 트리를 만들어 사용하는 우회책을 제시합니다. 개발자는 브라우저와 프린터 특성을 고려하여 섬세하게 CSS를 다뤄야 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기HTML이 구조화된 문서여서 종이, 음성, 점자 단말기, 화면, 전자잉크 등으로 표현될 수 있다는 이상은 무척 아름답게 느껴짐. HTTP API에 원하는 콘텐츠 유형을 요청한다는 발상도 마찬가지로 매력적임.
다만 현실에서는 곁가지에 불과할 때도 있어, 인쇄 지원은 가치가 있을 때 해야 함. 인쇄하려는 이용자가 거의 없는 사이트도 있고 상당한 사이트도 있을 것임. 레이아웃을 더 확실하게 보장하는 PDF를 제공하는 곳도 많지만, 일부 웹사이트는 인쇄할 수 있어야 함.
인쇄하기 좋은 HTML 구조와 탐색 메뉴 숨기기에는 찬성하지만, 인쇄용 글꼴이나 기본 글자 크기를 바꾸는 것에는 회의적임. 글자 크기를 전혀 지정하지 않은 간단한 사이트를 만들었더니 친구가 모바일에서 글씨가 작다고 했는데, 저해상도 화면을 감지해 크기를 늘려야 하는 걸까?
사용자가 이미 기본 글자 크기를 키웠다면 사이트가 또 키우게 되고, 인쇄용 기본 크기를 줄였다면 사이트가 다시 줄일 수도 있음. 글자 크기는 전적으로 사용자에게 맡기는 편이 낫다고 봄.
사이트를 만든 쪽이 맞고, 모바일에서 글자 크기를 키우는 법을 몰랐던 친구 쪽이 잘못한 것임. 브라우저의 페이지 확대·축소 설정을 알려줄 기회이기도 함. 나는 반대로 글씨가 너무 큰 사이트가 많아서 자주 축소함.
다만 여러 열이 필요한 레이아웃이라면 글자 크기나 배율을 늘려도 잘 작동하지 않을 수 있음. 예를 들어 gcc.gnu.org는 큰 글씨를 선호하는 모바일 이용자가 보기 까다로움.
프로젝트 소스 코드를 인쇄해서 제출하라는 교수님이 있었는데, 아직도 그러시는 듯함. 요즘처럼 AI가 널리 쓰이는 시기에는 정말 골치 아프실 것 같음.
이것은 접근성의 기본임. 사용자가 글꼴 설정을 모른다는 반론은 받아들일 수 있지만, 올바른 해결책은 모든 사이트에 글꼴 조절 기능을 넣는 것이 아니라 브라우저에서 해당 설정을 더 쉽게 바꿀 수 있게 하는 것임.
인쇄용 CSS 디버깅은 꽤 번거로울 수 있음. 동적 콘텐츠에 인쇄 기능을 추가하는 것 자체는 어렵지 않지만, 출력 모양까지 제대로 맞추려면 신경 쓸 부분이 많음.
CSS와 JavaScript만으로 라벨 프린터용 라벨을 만드는 애플리케이션을 구현해 봤는데, 운영체제와 브라우저의 인쇄 대화상자·미리보기 차이, 프린터 설정과 배율의 상호작용, 브라우저가 붙이는 바닥글, 용지 크기와 여백 등 온갖 특이한 동작을 다뤄야 했음. 브라우저 개발자들이 일반 CSS보다 인쇄용 CSS를 덜 꼼꼼하게 살피는 듯함.
한 가지 우회책은 인쇄 전용 DOM 트리를 만들어 기존 루트와 교체하고, 인쇄한 뒤 원래 애플리케이션의 DOM을 복원하는 것임. 편법 같지만 구현이 단순하고, 인쇄를 고려하지 않은 나머지 애플리케이션이 출력 레이아웃에 간섭하지 못하게 해 줌. 아예 인쇄 API에 별도의 문서 트리와 CSS를 전달할 수 없는 이유가 궁금함. 하나의 DOM과 통합 CSS로 모든 것을 처리하기보다 관심사를 분리하는 편이 훨씬 간단함.
정중히 반대함. Tim Berners-Lee의 원래 목적은 문서와 정보를 탐색하는 수단을 만드는 것이었지 인쇄 수단을 만드는 것이 아니었음. 탐색과 인쇄라는 개념을 뒤섞은 것이 오늘날의 문제임. 웹사이트는 정보를 쉽게 탐색하고 전달하는 단순하고 깔끔한 공간이면 되고, 인쇄에는 LaTeX처럼 적합한 마크업 도구가 있음. https://info.cern.ch/hypertext/WWW/TheProject.html
Tim Berners-Lee의 생각이 여기서 무슨 상관인가? 웹페이지를 읽기 좋은 종이 사본으로 갖고 싶은데 LaTeX가 무슨 도움이 되는가?
비꼬려는 질문은 아닌데, 웹사이트 개발을 업으로 하지는 않는 것 아닌가? 이런 이상론은 일반적인 웹 개발 현실과 너무 멀어서, 점유율 0.7%인 IE 버전 지원보다도 더 동떨어져 보임.
WWW의 설계는 여러 차례 변해 왔음. 모든 변화가 마음에 드는 것은 아니지만, 은행 앱처럼 지금은 당연하게 여기는 기능 중에는 HTML1로 불가능했던 것이 많음. 더는 존재하지 않는 과거의 웹을 기준으로 논쟁하는 것은 별 의미가 없어 보임.
탐색과 인쇄를 뒤섞은 것이 아니라, 웹사이트를 JavaScript 지옥으로 만들어 원래 목적이 설계 단계부터 무너지게 한 것이 문제임.
정작 이 사이트에서 CMD-P를 누르면 4페이지가 나옴. 첫 페이지는 80%가 공백이고, 두 번째는 괜찮지만, 세 번째는 왼쪽의 가느다란 영역에 CSS 예제만 나오며 마지막 페이지도 대부분 비어 있음.
나도 비슷한 작업을 했지만, 많은 고용주가 PDF 제출을 요구해서 이력서 서식을 맞추는 용도로만 구현함. https://www.trist.am/resume/
어떤 브라우저를 쓰는가? 일부 브라우저에서는 인쇄용 미디어 쿼리 지원의 우선순위가 낮았음. 이해는 가지만 막상 필요해지면 곤란함.
솔직히 인쇄 지원의 우선순위는 낮게 잡을 것 같음. 시간이 한정돼 있다면 화면에서의 사용자 경험과 접근성에 더 집중하고 싶음. 다만 특정 용도에서는 인쇄 지원이 합리적이며, 티켓이나 청구서 등을 위해 사이트가 따로 구현하는 PDF 생성 기능을 상당 부분 대체할 수도 있음.
바로 그래서 나는 처음부터 기본적인 인쇄를 지원하도록 만듦. 사용자는 대체로 인쇄하는 법을 알기 때문에, PDF 다운로드 기능을 요구할 필요 자체가 사라지는 경우가 많음.
그래도 별도 PDF 기능이 필요하다면 구현 선택지가 넓어짐. 헤드리스 브라우저로 페이지를 인쇄하면 되므로 특정 PDF 생성 라이브러리가 처리할 수 있는 마크업에 얽매일 필요가 없을 수 있음. 요즘은 레이아웃 편법도 많이 줄어서 CSS를 조금만 손봐도 인쇄 결과가 괜찮은 경우가 많음.
이 문제는 이미 브라우저의 읽기 모드로 해결된 줄 알았음. Firefox의 "Reader View (F9)"와 Brave의 "Speedreader"는 부수적인 콘텐츠를 제거하고 본문 서식을 통일해 줌.
서로 다른 사이트 열 곳에서 열 페이지를 인쇄해도 같은 모양으로 출력할 수 있음. Chrome에도 비슷한 기능이 있는지는 모르지만, 있을 법함.
개인적으로 꼭 필요한 경우가 아니라면 인쇄는 자원 낭비라고 생각함.
인쇄에는 PDF로 저장하거나 EPUB·Kindle 같은 전자책 형식으로 변환해 여행 중 오프라인으로 읽는 것도 포함됨.
오래 보관하고 싶은 웹페이지는 PDF로 인쇄함. 몇 년 뒤 사이트가 사라지거나 URL이 바뀌어 북마크가 깨져도 다시 볼 수 있기 때문임.
낯선 쇼핑몰의 주문 확인 페이지나 은행의 청구서 납부 내역을 주로 저장하고, 미납했다는 연락을 받으면 PDF를 확인해 내 실수인지 살펴봄. 더 중요한 용도는 요리법 보관임. 매년 같은 칠면조 요리법 PDF를 종이로 출력하면, 조리 중 휴대전화나 컴퓨터를 만지며 더럽힐 걱정이 없음.
CVE 추세를 보면 종이 기록의 중요성은 오히려 커지고 있음. 인쇄물은 오래 보관할 수 있고 해킹할 수 없으며 컴퓨터 없이 읽을 수 있다는 고유한 장점이 있음. 나중에 다시 읽어도 내용이 그대로일 것이라고 확신할 수 있음.
그 논리라면 Barnes & Noble에 들어가는 것도 끔찍할 것임. Bitcoin이나 자동차가 끝없이 원을 도는 NASCAR부터 살펴보는 게 어떨까? 자원 낭비라고 할 만한 수많은 활동보다는 책과 원하는 내용을 종이로 보관하는 일을 택하겠음.
자원 낭비이긴 하지만, 인쇄 가능해야만 하는 경우도 있고 PDF도 유용함. 제대로 된 운영체제는 인쇄 대화상자에서 PDF를 만들 수 있음.
웹페이지 인쇄는 기본적으로 배경색과 배경 이미지를 제거한다는 문제가 있음. 내 사이트의 체스 도표는 배경색으로 격자무늬를 만들고 말은 컬러 웹폰트로 표시하는데, 배경 인쇄를 켜지 않으면 체스판이 전부 흰색으로 나옴.
우회하려면 폰트에 밝은 칸용 흰 배경 말과 어두운 칸용 유색 배경 말을 따로 넣어야 함. 웹페이지를 인쇄하는 일이 드물어서, 인쇄하는 사람이라면 배경 인쇄도 켤 것이라고 가정하고 있음. 이미지를 쓰지 않는 이유는 대역폭을 더 차지하고 다크 모드에 적합한 색상을 적용하기 어렵기 때문임.
이 용도라면 SVG가 잘 맞을 것 같음.
기본 설정일 뿐이므로, 인쇄할 때 "Print backgrounds"에 체크하면 간단히 해결됨.