Estilos de impresión para documentación que no te avergüencen

Cómo es una “buena impresión” (y qué se niega a hacer)

La salida de impresión es el crítico más exigente que conocerás. Elimina la interactividad, reduce tu lienzo a dimensiones fijas y castiga cualquier cosa que dependa de estados hover, posicionamiento fijo o de que el usuario “simplemente despliegue un poco la página”.
El objetivo no es hacer que el papel parezca tu sitio web. El objetivo es hacer que el papel se comporte como papel: predecible, escaneable, legible y sin basura de UI.

Una buena hoja de estilo de impresión hace cuatro cosas bien:

• Reduce el ruido: oculta la navegación, campos de búsqueda, “posts relacionados” y cualquier cosa que huela a métricas de engagement.
• Mejora la legibilidad: tamaños de fuente sensatos, márgenes, interlineado y contraste.
• Respeta la estructura: los encabezados no quedan colgando al final de una página; el código no se recorta; las tablas no explotan.
• Preserva el significado: los enlaces muestran destinos; las figuras tienen leyendas; el código se envuelve sin mentir.

Opinión: si tu documentación es relevante operativamente (runbooks, guías de incidentes, procedimientos de cumplimiento), la impresión no es un “lujo”. Es parte de tu historia de disponibilidad.

Broma #1: el CSS de impresión es como las copias de seguridad: todo el mundo dice que las tiene hasta que intenta restaurarlas.

Una cosa más: “amigable para imprimir” no significa “una columna única de texto diminuto”. Puedes usar espacio en blanco. El papel no cobra por píxel.

Hechos interesantes y contexto histórico

Trata estos puntos como restricciones, no como trivia. Las restricciones son donde empieza la buena ingeniería.

Principios clave: la impresión es un producto aparte

1) Empieza por el contenido, no por la maquetación

Al imprimir, el contenido se convierte en la interfaz. El “sistema de diseño” debería desaparecer en su mayor parte. Eso significa que tu hoja de estilo de impresión debe construirse alrededor de HTML semántico:
los encabezados son encabezados, las listas son listas, el código es código, las tablas son tablas. Si tu sitio es sopa de divs, la impresión te castigará por tus pecados. No es personal. Es física.

2) Elimina todo lo que cambie estado

Encabezados pegajosos, acordeones, pestañas, tooltips por hover, banners de cookies—estos son patrones de UI con estado. La impresión es sin estado. Si tu documento impreso depende de hacer clic en “Expandir”, has entregado un runbook que requiere electricidad y optimismo.

3) Haz que el artefacto impreso sea autónomo

Las páginas impresas pierden el contexto de tu dominio. El lector puede no saber el nombre del sitio, el título de la página o la fecha de última actualización. Incluye suficiente metadatos en el área de contenido—título, versión opcional y quizá un pie de página pequeño—pero no reconstruyas todo el encabezado.

4) Optimiza para dos audiencias: humanos y auditorías

Los humanos quieren texto legible, código envuelto y sin páginas desperdiciadas. Las auditorías quieren artefactos estables. Si tu salida de impresión cambia cada vez que un enlace de la navegación cambia, estás creando fricción sin beneficio.

Una idea útil parafraseada de John Allspaw: la estabilidad proviene de diseñar sistemas que asumen que fallos ocurrirán, y luego reducir el radio de impacto cuando lo hacen.

Maquetación legible: tipografía, márgenes y estructura

Márgenes: elige números aburridos

Usa márgenes @page en pulgadas o milímetros y mantenlos conservadores. Las impresoras tienen áreas no imprimibles; los PDFs no, pero los usuarios imprimen PDFs en impresoras con áreas no imprimibles.
Si tu contenido toca el borde, se recortará. No “podría”. Se recortará.

Haz: @page { margin: 0.6in; }. No hagas: margin: 0 y esperes que la impresora sea moderna y benévola.

Tamaños de fuente: la impresión no es retina

Para el texto del cuerpo, 10.5–12pt suele ser lo correcto. Para documentación técnica densa, 11pt es un buen valor por defecto. Para código, 8.5–10pt dependiendo de la longitud de línea. En el momento que reduzcas más para “encajar más”, tus lectores empiezan a ojear en vez de leer.

Longitud de línea: la tiranía de los 100 caracteres

Los papeles y PDFs no hacen scroll. Mantén los párrafos legibles: evita líneas súper anchas usando márgenes, no max-widths en píxeles. En impresión, una “anchura completa” ya está limitada. Déjalo respirar.

Contraste: elimina la estética gris sobre gris

Los estilos de impresión deben forzar alto contraste. A muchas empresas les encanta el texto gris claro sobre fondos grises ligeramente distintos.
Luego alguien lo imprime en una impresora económica y tu caja de “nota” se vuelve un fantasma invisible. En impresión, si es importante, es negro.

Encabezados: no los dejes colgando

Usa break-after: avoid (y el antiguo fallback page-break-after: avoid) en encabezados. También protege el primer párrafo después de un encabezado usando un contenedor, o al menos evita que el encabezado quede al fondo de una página sin contenido.

Regla de opinión: si un H2 imprime como la última línea en una página, tu hoja de estilo de impresión está fallando en su único trabajo.

Ocultar navegación, chrome y basura de UI

Oculta por clase, no por esperanza

Necesitas selectores explícitos para los elementos que no deben imprimirse. Crea una clase utilitaria como .no-print y aplícala a:
barras de navegación, pies con texto legal, barras laterales, botones “editar esta página”, widgets de compartir, secciones de comentarios y banners de cookies.

Prefiere “display: none” en impresión

Para impresión, display: none es tu amigo. No uses trucos de opacidad. No uses posicionamiento fuera de pantalla. Algunos motores de impresión aún calculan la maquetación para elementos ocultos pero no nulos, y obtendrás espacios en blanco misteriosos.

Los elementos fijos y sticky se comen páginas

Un encabezado fijo de 72px se convierte en un impuesto recurrente en cada página impresa si el navegador decide renderizarlo en cada una. Así es como transformas un runbook de 10 páginas en uno de 17 y haces llorar a la impresora de la oficina.

Broma #2: Nada dice “empresa” como imprimir una guía de 40 páginas donde 12 páginas son solo el encabezado pegajoso.

Enlaces, referencias y la “realidad en papel”

Haz visibles los destinos de los enlaces

En papel, “haz clic aquí” es arte performativo. Los estilos de impresión deben añadir la URL después de los enlaces externos. El patrón clásico:
a[href^="http"]:after { content: " (" attr(href) ")"; }

No hagas esto para enlaces internos con hash ni para mailto a menos que quieras ruido. Puedes apuntar selectivamente protocolos externos.

Pero no dejes que las URLs destruyan la maquetación

Algunas URLs son largas y algunos sistemas generan cadenas de consulta heroicas. Necesitas envoltura:
word-break: break-word y overflow-wrap: anywhere pueden ayudar. Para impresión, la meta es “lo suficientemente legible para reescribirla”, no “preservar la cadena exacta en una línea”.

Enlaces ancla y TOCs

Un TOC en pantalla es útil; un TOC impreso es opcional. Si lo imprimes, asegúrate de que no ocupe la mitad de la primera página. Si tus docs son largos, un TOC corto puede ayudar—pero considera una “vista de impresión” que reordene el contenido en lugar de volcar el TOC del sitio sin cambios.

Bloques de código: envoltura, desbordamiento, fidelidad al copiar

La dura verdad: al código no le gusta el papel

Las salidas de terminal y los bloques de código nacieron para desplazarse horizontalmente. El papel se niega. Tus opciones son:

• Envolver líneas y aceptar que la fidelidad al copiar/pegar no es la prioridad en papel.
• No envolver, pero entonces debes asegurar que el contenido no se recorte (a menudo imposible).
• Proveer una variante segura para impresión (recomendado): envolver por defecto, pero permitir que líneas críticas de comandos se rompan manualmente con caracteres de continuación o saltos explícitos en la fuente.

Envuelve bloques pre en impresión

Para impresión, usa white-space: pre-wrap en pre y code. Añade word-break: break-word. Esto evita recortes y caracteres faltantes.

No uses white-space: normal para código. Eso colapsa espacios y corromperá ejemplos de código. Quieres envoltura, no re-tokenización.

Preserva prompts y señales

Si tus docs incluyen comandos, conserva los prompts consistentes. En impresión, los prompts ayudan a los humanos a distinguir lo tecleado de la salida.
Pero no hagas los prompts enormes ni estilizados como insignias de fondo que no se imprimirán.

Color y resaltado de sintaxis

Muchas canalizaciones de impresión eliminan fondos. El resaltado de sintaxis también puede perder contraste. En impresión, prefiere lo simple:
texto negro, borde ligero, quizás un fondo gris claro si toleras que desaparezca.
El código debe ser legible sin color.

No permitas que los bloques de código se dividan a la mitad de una línea si puedes evitarlo

Usa break-inside: avoid en pre. No es perfecto en todos los motores, pero reduce los peores casos.
Para salidas largas, la división es inevitable—asegura que tus comandos muestren contexto y puntos de reentrada.

Tablas, diagramas e imágenes sin lágrimas

Tablas: o encajan o rediseña

Las tablas anchas son la fuente número uno de basura en impresión. Si tu tabla es más ancha que una página, tienes tres opciones:

• Hacer la tabla más estrecha rediseñando el contenido (mejor a largo plazo).
• Permitir que la tabla envuelva celdas agresivamente (a veces bien para prosa, terrible para IDs).
• Imprimir la tabla en apaisado (difícil en impresión desde navegador; viable en generación dedicada de PDF).

No intentes “escalar” toda la página para encajar la tabla. Eso produce texto diminuto y humanos enfadados.

Imágenes: elimina las decorativas, conserva las informativas

Las imágenes decorativas no deberían imprimirse. Las imágenes informativas deben imprimirse con resolución suficiente para seguir siendo legibles. Ajusta:
img { max-width: 100%; height: auto; }

Si dependes de diagramas codificados por color, añade etiquetas. Las impresoras no están obligadas a reproducir tu paleta de marca. A menudo reproducen “el gris que resulte hoy”.

SVG y filtros

Los filtros SVG complejos pueden desencadenar rasterización. Cuando eso ocurre, el texto se vuelve borroso e no seleccionable en el PDF.
Si tus docs incrustan diagramas SVG con filtros de blur/sombra, considera un SVG alternativo para modo impresión sin filtros.

Saltos de página, huérfanas, viudas y evitar cortes incómodos

Usa propiedades modernas de salto, mantén los viejos fallbacks

Prefiere break-before, break-after y break-inside. Añade los viejos page-break-* para compatibilidad.
Los navegadores varían, pero estas propiedades son tu mejor opción para controlar la paginación.

Protege encabezados, listas cortas y definiciones

Un encabezado al fondo de una página es un fallo clásico. También lo es una lista de dos ítems partida entre páginas. Aplica:

• h2, h3 { break-after: avoid; }
• pre, table, blockquote { break-inside: avoid; }
• li { break-inside: avoid; } (úsalo con cuidado; las listas enormes forzarán espacios incómodos)

Huérfanas y viudas: siguen valiendo la pena

orphans y widows no se aplican perfectamente en todas partes, pero ayudan. Defínelos en párrafos y elementos de lista.
No estás intentando maquetar una novela. Intentas evitar la “línea solitaria varada en la página siguiente”.

Imprimir a PDF en pipelines: reproducibilidad y deriva

En muchas organizaciones, “imprimir” realmente significa “generar un PDF para distribución”. Eso está bien—hasta que forma parte de un flujo de cumplimiento, un artefacto de release o un paquete de soporte.
Entonces descubres que tu salida PDF cambia porque el navegador sin cabeza se actualizó, una webfont no cargó o una regla CSS fue eliminada por el tree-shaking.

Fija tu motor de renderizado

Si generas PDFs en CI, fija la versión de Chromium (o la etiqueta del contenedor) y trátalo como cualquier otra dependencia.
“latest” sin fijar es cómo obtienes un reflujo sorpresa el día antes de una auditoría.

Deshabilita dependencias inestables

Las webfonts pueden fallar. Las imágenes remotas pueden fallar. Los scripts externos pueden fallar. Para impresión/PDF, usa activos locales o incluye CSS crítico inline.
El artefacto de impresión no debería depender de cinco CDNs y un resolvedor DNS que tengan un buen día.

Diseña para paginación determinista

Pequeñas diferencias de maquetación pueden cambiar saltos de página, lo que lo cambia todo (por ejemplo, números de página referenciados en SOPs).
Si necesitas paginación determinista, considera generar PDFs desde la fuente usando una cadena de herramientas de medios paginados o aplica CSS estable y fuentes fijadas.

Tareas prácticas: comandos, salidas, decisiones

El estilo de impresión falla de dos formas: tu CSS está mal, o tu pipeline te miente sobre lo que se está imprimiendo.
Aquí hay tareas reales que uso para depurar la salida de impresión como un SRE: verificar entradas, observar comportamiento y decidir qué cambiar.

Tarea 1: Confirma qué CSS se despliega realmente

cr0x@server:~$ curl -sS -D- https://docs.example.internal/article/runbook.html -o /tmp/runbook.html
HTTP/2 200
content-type: text/html; charset=utf-8
etag: "9b3b2e9a"
cache-control: max-age=300

Qué significa la salida: Has obtenido el HTML renderizado y las cabeceras de respuesta. ETag y caché indican si podrías estar viendo contenido obsoleto.

Decisión: Si la caché es agresiva, límpiala o evítala antes de culpar al CSS.

Tarea 2: Extrae las hojas de estilo enlazadas (chequeo rápido)

cr0x@server:~$ grep -Eo 'href="[^"]+\.css[^"]*"' /tmp/runbook.html | head
href="/assets/site.css"
href="/assets/print.css"

Qué significa la salida: La página incluye un CSS específico para impresión, no solo CSS de pantalla.

Decisión: Si no hay CSS de impresión, crea uno. Si existe, descárgalo y verifica que sea el desplegado.

Tarea 3: Obtén el CSS de impresión y verifica que contenga reglas de impresión

cr0x@server:~$ curl -sS https://docs.example.internal/assets/print.css | sed -n '1,80p'
@media print {
  .site-nav, .sidebar, .cookie-banner { display: none !important; }
  pre { white-space: pre-wrap; word-break: break-word; }
}

Qué significa la salida: Hay un bloque @media print y está haciendo lo básico.

Decisión: Si faltan reglas de impresión o el bloque está vacío, dependes del CSS de pantalla. Para de inmediato y arregla eso primero.

Tarea 4: Detecta un accidental “print: none” en el contenido principal

cr0x@server:~$ rg -n "display:\s*none" /tmp/runbook.html /tmp/print.css
/tmp/print.css:2:  .site-nav, .sidebar, .cookie-banner { display: none !important; }

Qué significa la salida: Solo la UI está oculta. Bien.

Decisión: Si encuentras main, article o tu contenedor de contenido oculto, corrige los selectores (a menudo una regla demasiado amplia como div o *).

Tarea 5: Genera un PDF con Chromium sin cabeza para reproducir problemas

cr0x@server:~$ chromium --headless --disable-gpu --print-to-pdf=/tmp/runbook.pdf https://docs.example.internal/article/runbook.html
[1229/102312.184556:INFO:headless_shell.cc(659)] Written to file /tmp/runbook.pdf.

Qué significa la salida: Ahora tienes un artefacto PDF reproducible desde un motor conocido.

Decisión: Si el PDF difiere de “Imprimir…” en Chrome de escritorio, probablemente tienes deriva de entorno (fuentes, DPI o diferentes versiones de Chromium).

Tarea 6: Comprueba si el PDF es texto o imágenes rasterizadas

cr0x@server:~$ pdftotext /tmp/runbook.pdf - | head
Runbook: Storage Failover
Last updated: 2025-12-01

1. Preconditions
...

Qué significa la salida: La extracción de texto funciona; el PDF es mayormente texto real.

Decisión: Si la extracción no devuelve nada o muestra basura, tu pipeline podría estar rasterizando. Reduce efectos visuales y comprueba fuentes/SVG que se incrusten.

Tarea 7: Inspecciona fuentes incrustadas (fuentes faltantes causan reflow)

cr0x@server:~$ pdffonts /tmp/runbook.pdf | head
name                                 type              encoding         emb sub uni object ID
AAAAAA+Inter-Regular                  TrueType          WinAnsi          yes yes yes      12  0
AAAAAA+Inter-SemiBold                 TrueType          WinAnsi          yes yes yes      13  0

Qué significa la salida: Las fuentes están incrustadas y subseteadas. Eso es bueno para portabilidad y métricas estables.

Decisión: Si las fuentes no están incrustadas, espera deriva de maquetación entre máquinas. Incrusta o usa fuentes del sistema en modo impresión.

Tarea 8: Comprueba el número de páginas y detecta regresiones de páginas en blanco

cr0x@server:~$ pdfinfo /tmp/runbook.pdf | egrep 'Pages|Page size'
Pages:           14
Page size:       612 x 792 pts (letter)

Qué significa la salida: Tienes 14 páginas en tamaño Letter. Esa es una métrica base estable para seguir en CI.

Decisión: Si las páginas de repente aumentan (por ejemplo, de 14 a 19), sospecha elementos fijos/pegajosos, saltos de página forzados o un cambio de fuente.

Tarea 9: Valida que las líneas largas de código se envuelvan (no se recorten)

cr0x@server:~$ pdftotext /tmp/runbook.pdf - | rg -n "cr0x@server:~\$" | head
42:cr0x@server:~$ zpool status -v pool0
77:cr0x@server:~$ journalctl -u nginx --since "1 hour ago"

Qué significa la salida: Los comandos aparecen en el texto extraído, lo que implica que no se recortaron al borde de la página.

Decisión: Si falta texto extraído para comandos largos, revisa el envolvimiento de pre y los márgenes.

Tarea 10: Confirma que se aplica el medio print (depuración desde CSS)

cr0x@server:~$ node -e 'const fs=require("fs"); const css=fs.readFileSync("/tmp/print.css","utf8"); console.log(/@media\s+print/.test(css)?"has print media":"missing print media");'
has print media

Qué significa la salida: Tu CSS incluye reglas para media print.

Decisión: Si falta, tu bundler podría estar eliminándolas. Arregla la configuración del pipeline de build.

Tarea 11: Identifica elementos “dependientes de fondo” no imprimibles

cr0x@server:~$ rg -n "background-color|color:\s*#(7|8|9|a|b|c|d|e|f){3,6}" /tmp/print.css | head
14:  .callout { border-left: 4px solid #333; background-color: #f6f6f6; }

Qué significa la salida: Estás usando color de fondo para callouts. Está bien, pero no dejes que cargue el significado.

Decisión: Añade bordes, etiquetas o tipografía para que el callout siga siendo obvio cuando los fondos no se impriman.

Tarea 12: Comprueba saltos de página forzados que crean páginas en blanco

cr0x@server:~$ rg -n "page-break-before|page-break-after|break-before|break-after" /tmp/print.css
22:  h1 { break-before: page; }

Qué significa la salida: Algo fuerza un salto de página antes de h1. Eso puede crear una primera página en blanco en algunos motores.

Decisión: Elimínalo o aplícalo con alcance estricto (por ejemplo, solo en un modo “paquete de impresión”). Mide el recuento de páginas otra vez.

Tarea 13: Verifica que los elementos nav/sidebar realmente desaparezcan en el PDF impreso

cr0x@server:~$ pdftotext /tmp/runbook.pdf - | rg -n "Search|Sign in|Subscribe|Cookie" | head

Qué significa la salida: No hay frases obvias de UI en el artefacto impreso.

Decisión: Si aparece texto de UI, tus selectores no coinciden con el DOM en producción. Añade clases estables (.site-nav, .cookie-banner) y evita CSS frágil como cadenas nav > ul > li.

Tarea 14: Confirma que la misma maquetación se renderiza en A4 y Letter (comprobación de deriva por tamaño de página)

cr0x@server:~$ chromium --headless --disable-gpu --print-to-pdf=/tmp/runbook-a4.pdf --virtual-time-budget=10000 --run-all-compositor-stages-before-draw https://docs.example.internal/article/runbook.html
[1229/102409.918211:INFO:headless_shell.cc(659)] Written to file /tmp/runbook-a4.pdf.

Qué significa la salida: Tienes un PDF adicional para comparar. (El control de tamaño de página de Chromium es limitado; muchos equipos usan herramientas separadas para A4/Letter.)

Decisión: Si A4 vs Letter produce contenido recortado, aumenta márgenes y deja de usar anchos fijos.

Tarea 15: Atrapa regresiones de CSS en CI fijando un presupuesto de recuento de páginas

cr0x@server:~$ pdfinfo /tmp/runbook.pdf | awk -F': *' '/Pages/ {print $2}'
14

Qué significa la salida: Un único número que puedes comparar entre builds.

Decisión: Si el recuento de páginas cambia inesperadamente tras un cambio de CSS, trátalo como una regresión e inspecciona el diff, no solo el HTML.

Guion rápido de diagnóstico

Cuando la salida de impresión está mal, no empieces por “retocar CSS hasta que se vea mejor.”
Así es como obtienes una hoja de estilo de impresión de mil líneas en la que nadie confía.
Diagnostica como un operador: comprueba las pocas cosas que suelen romperse primero.

Primero: ¿se aplica la hoja de estilo de impresión?

• Abre la vista previa de impresión y verifica que la nav/barralateral desaparezca.
• Si no, tu @media print no está cargando, está siendo eliminada o tus selectores no coinciden con el DOM.

Segundo: ¿estás luchando contra posicionamiento fijo/pegajoso?

• Síntomas: encabezados repetidos, espacios desperdiciados, contenido desplazado hacia abajo, explosión en el número de páginas.
• Arreglo: en impresión, pon contenedores fijos/pegajosos en position: static y oculta el chrome redundante.

Tercero: ¿los bloques de código se recortan o envuelven mal?

• Síntomas: caracteres faltantes en el borde derecho, comandos truncados o un solo bloque de código de cinco páginas con palabras rotas.
• Arreglo: pre { white-space: pre-wrap; word-break: break-word; } y asegúrate de que los márgenes no sean cero.

Cuarto: ¿los enlaces son significativos en papel?

• Síntomas: “haz clic aquí” por todas partes, referencias que no se pueden seguir.
• Arreglo: añade URLs externas con attr(href); evita hacerlo para anclas internas.

Quinto: ¿los saltos de página sabotean la legibilidad?

• Síntomas: encabezados solos al fondo de la página; tablas partidas; ítems de lista separados de sus viñetas.
• Arreglo: break-inside: avoid en bloques; break-after: avoid en encabezados; ajusta orphans/widows.

Consejo operativo: captura un PDF “conocido bueno” y haz diff cada vez que cambies CSS. Los humanos son malos detectando reflows sutiles en la vista previa de impresión.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: las páginas impresas incluyen nav, búsqueda y banner de cookies

Causa raíz: no hay hoja de estilo de impresión, o los selectores apuntan a una estructura DOM antigua que cambió durante un rediseño.

Solución: introduce clases estables (.site-nav, .cookie-banner, .sidebar) y escóndelas en @media print usando display: none !important.

2) Síntoma: enormes áreas en blanco, especialmente en la parte superior de cada página

Causa raíz: encabezado fijo/pegajoso permanece en impresión; el navegador lo repite por página o reserva su espacio.

Solución: en impresión, pon el contenedor del encabezado en position: static !important o escóndelo por completo. Mueve metadatos esenciales al cuerpo del artículo.

3) Síntoma: código o tablas se cortan por la derecha

Causa raíz: white-space: pre sin envoltura, más márgenes insuficientes o anchos fijos.

Solución: usa pre-wrap para impresión y elimina anchos fijos. Aumenta ligeramente los márgenes de @page.

4) Síntoma: el código se envuelve pero queda ilegible “ensalada de palabras”

Causa raíz: usar white-space: normal o una separación agresiva que rompe tokens.

Solución: mantén white-space: pre-wrap y prefiere word-break: break-word. Evita la separación silábica para bloques de código.

5) Síntoma: el PDF tiene texto que no puedes seleccionar o se ve borroso

Causa raíz: rasterización por efectos CSS pesados, filtros SVG complejos o peculiaridades del motor de impresión.

Solución: elimina sombras/filtros en impresión, simplifica SVG y verifica con pdftotext que la extracción de texto funcione.

6) Síntoma: encabezados huérfanos, listas partidas de forma extraña

Causa raíz: falta de reglas de paginación; confiar en los valores por defecto del navegador; bloques de contenido no protegidos de cortes.

Solución: aplica break-after: avoid a encabezados y break-inside: avoid a bloques críticos. Usa widows/orphans como salvaguardas.

7) Síntoma: “Imprimir a PDF” difiere de “Imprimir” en escritorios

Causa raíz: diferentes versiones de Chromium, distintas fuentes instaladas, tamaños de página por defecto distintos o activos faltantes en modo headless.

Solución: fija versiones del motor de renderizado y incrusta fuentes (o usa fuentes del sistema). Genera PDFs en un contenedor controlado.

8) Síntoma: faltan diagramas o iconos en las páginas impresas

Causa raíz: activos bloqueados por CSP, restricciones cross-origin en modo headless o configuración del usuario “no imprimir fondos”.

Solución: no transmitas significado con imágenes de fondo; incrusta SVG críticos; asegúrate de que los diagramas sean verdaderos <img> o <svg> inline.

Listas de verificación / plan paso a paso

Paso a paso: construye una hoja de estilo de impresión que sobreviva en producción

1. Inventaría lo que debe imprimirse.

   Título, última actualización, encabezados, texto del cuerpo, bloques de código, tablas relevantes y un pie de página mínimo (opcional). Todo lo demás empieza como “no”.

2. Añade @media print con resets estrictos.

   Forza texto negro, elimina fondos y sombras, normaliza márgenes y establece un tamaño de fuente para impresión.

3. Oculta la UI con clases estables.

   Añade .no-print y aplícalo a nav/búsqueda/barra lateral/banner de cookies/widgets de compartir. Luego oculta esos selectores en impresión.

4. Arregla el posicionamiento.

   En impresión, los elementos fijos/pegajosos deben hacerse estáticos o desaparecer. Prueba el recuento de páginas antes y después.

5. Haz los enlaces utilizables.

   Añade destinos de URL externos. Evita añadirlos para anclas internas para reducir ruido.

6. Haz que el código se envuelva con seguridad.

   pre-wrap + break-word + bordes. Verifica que comandos largos no se recorten.

7. Controla saltos de página.

   Protege encabezados, tablas y bloques de código de dividirse. Añade valores por defecto de widows/orphans.

8. Prueba en A4 y Letter.

   Al menos una vez. Tu compañía global te lo agradecerá en silencio (la forma más alta de gratitud).

9. Automatiza la generación de PDF en CI.

   Fija la versión del navegador. Guarda un artefacto base. Alerta por diffs grandes (recuento de páginas + comprobaciones visuales).

10. Escribe una “prueba de aceptación de impresión”.

    Una pequeña lista: nav oculta, código envuelto, sin contenido recortado, enlaces muestran destinos, sin primera página en blanco.

Checklist rápido de aceptación de impresión (humano)

• La primera página empieza con el título, no con espacio vacío o una barra de navegación.
• No hay banner de cookies, ni cuadro de búsqueda, ni “suscríbete”, ni widget de chat.
• Los bloques de código se envuelven y siguen legibles; nada recortado por la derecha.
• Los encabezados no están separados de su primer párrafo.
• Los enlaces muestran a dónde llevan (al menos para referencias externas).
• Las tablas o encajan o tienen un comportamiento de envoltura aceptable.
• El documento imprime en A4 y Letter sin pérdidas críticas.

Checklist rápido de aceptación de impresión (CI)

• Generar PDF desde un navegador sin cabeza fijado.
• Extraer texto con pdftotext; fallar si está vacío.
• Registrar recuento de páginas con pdfinfo; alertar por cambios grandes.
• Opcionalmente escanear el texto extraído en busca de cadenas de UI (“Search”, “Cookie”, “Subscribe”).

Tres microhistorias corporativas desde la mina de impresión

Preguntas frecuentes

1) ¿Debería crear un archivo print.css separado o mantener reglas de impresión en la hoja de estilo principal?

Cualquiera funciona. Si generas PDFs en CI, prefiero incluir las reglas de impresión en el CSS principal para evitar problemas de orden de carga. Si mantienes un archivo separado, asegúrate de que cargue determinísticamente y lo suficientemente pronto para la impresión headless.

2) ¿Por qué la vista previa de impresión difiere entre Chrome y Firefox?

Diferentes motores de impresión, distintos valores por defecto y diferentes niveles de soporte para características de medios paginados. Usa la vista previa de impresión en ambos si tu audiencia es amplia y valida con una canalización headless si generas PDFs.

3) ¿Cómo evito que mi encabezado sticky se repita en cada página impresa?

En @media print, pon el contenedor sticky en position: static !important o escóndelo. También elimina padding/márgenes superiores que compensaban el encabezado en pantalla.

4) ¿Debo imprimir el pie de página del sitio con enlaces legales e iconos sociales?

No. Si necesitas texto legal, incluye un pie de página mínimo y relevante. Los iconos sociales en papel son solo una confesión de que nadie pensó esto bien.

5) ¿Cuál es la mejor manera de mostrar URLs en papel sin arruinar las páginas?

Añade URLs solo para enlaces externos y mantén la fuente más pequeña. Si las URLs son demasiado largas, permite que se envuelvan. No las añadas para anclas internas a menos que estés generando un informe formal con IDs de referencia.

6) Mis bloques de código se envuelven, pero la indentación queda extraña. ¿Qué hago?

El envolvimiento preserva espacios con pre-wrap, pero las líneas largas mostrarán visualmente una “sangría colgante”. Considera añadir CSS para un efecto de sangría colgante en impresión, o rompe manualmente comandos largos en la fuente con continuaciones de línea cuando sea apropiado.

7) ¿Puedo forzar impresión en apaisado para tablas anchas?

El soporte de navegador para orientación por página es inconsistente. Si debes hacerlo de forma fiable, usa una canalización controlada de generación de PDF que soporte plantillas de página y reglas de orientación, o rediseña la tabla para impresión.

8) ¿Por qué mis colores de fondo desaparecen en impresión?

Muchos navegadores desactivan la impresión de fondos por defecto para ahorrar tinta. No confíes en fondos para transmitir significado. Usa bordes, etiquetas y texto de alto contraste.

9) ¿Cómo evito que una tabla se divida entre páginas?

Aplica break-inside: avoid (y page-break-inside: avoid) a la tabla o a filas, pero sabe que tablas muy altas seguirán partiéndose. Para tablas críticas, considera convertirlas en secciones o en varias tablas más pequeñas.

10) Si solo puedo permitir una comprobación de impresión en CI, ¿qué debería probar automáticamente?

Genera un PDF con un navegador sin cabeza fijado, ejecuta pdftotext para confirmar que no está rasterizado, y registra el recuento de páginas para detectar regresiones.

Conclusión: pasos siguientes que puedes hacer esta semana

El estilo de impresión no es glamuroso. Precisamente por eso hiere a los equipos: nadie lo toca hasta que un cliente, auditor o ingeniero de guardia fuerza el tema.
La solución no es complicada, pero requiere tratar la salida de impresión como un artefacto real con pruebas reales.

1. Crea o limpia un bloque dedicado @media print que oculte la UI y normalice la tipografía.
2. Haz que los bloques de código se envuelvan en impresión y verifica que los comandos largos no se recorten.
3. Añade las URLs externas después del texto del enlace para que los lectores en papel puedan seguir las referencias.
4. Añade reglas básicas de paginación para proteger encabezados, código y tablas de cortes feos.
5. Si generas PDFs, fija la versión del navegador y añade una comprobación mínima en CI: generación de PDF + extracción de texto + seguimiento del recuento de páginas.

Haz esas cinco cosas y tus documentos impresos dejarán de ser una responsabilidad. No serán hermosos. Serán utilizables. Los sistemas de producción funcionan con lo utilizable.