Canal de Renderizado

Entre OpenDocumentAsync y el PNG que llega al navegador hay dos etapas distintas: resolución del visor (qué motor carga el documento, decidido una vez por apertura) y procesamiento de página (qué ocurre con cada imagen de página en cada solicitud a DocImage.axd). Conocer ambas explica por qué un formato se representa de la manera que lo hace — y lo que realmente cambia DefaultRender.

Etapa 1 — Resolviendo el visor de formato

La fábrica asigna la extensión de archivo a un visor mediante el catálogo de formatos, con tres niveles de precedencia:

1. Primero los visores personalizados. Cualquier cosa que hayas registrado con DoconutOptions.RegisterViewer(extension, factory, defaultConfig?) prevalece sobre cualquier visor incorporado.
2. Visores de familia incorporados. El catálogo asigna cada extensión visible a una familia de visores — Word, Excel, PowerPoint, Pdf, Cad, Dgn, Image, Tiff, Psd, Email, Visio, Project, Xps, Epub, Txt, Html, Mht, Dcn — cada una con su propio adaptador de motor. Si un complemento con licencia aporta un visor para la misma extensión, el visor del complemento reemplaza al incorporado.
3. Formatos solo de complemento. Algunas extensiones no tienen ningún visor incorporado — DICOM (.dcm, .ima) existe solo a través del complemento DICOM. Abrir uno sin la capacidad requerida lanza:

LicenseException: This document type requires the 'Dicom' plugin license.

Una extensión que no tiene un visor asignado genera FormatNotSupportedException.

Después de la resolución, la configuración se establece: tu objeto de configuración explícito si lo pasaste, de lo contrario la configuración predeterminada del formato del catálogo. DocOptions.Password se copia en la configuración para documentos protegidos.

Etapa 1b — Modo de redirección (DefaultRender = false)

La mayoría de las configuraciones por formato exponen una bandera DefaultRender. Selecciona entre dos rutas fundamentalmente diferentes:

• DefaultRender = true — el documento se renderiza de forma nativa, directamente a imágenes de página.
• DefaultRender = false — el documento se convierte primero a un PDF en memoria, el motor fuente se libera y un visor de PDF toma el control. El PDF generado contiene texto real, por lo que la búsqueda de texto completo obtiene resaltados nativos exactos; la canalización activa AllowSearch y AllowCopy para el PDF redirigido, ya que la conversión es invisible para el usuario.

XPS y MHT, por defecto, usan la ruta de redirección. Una proyección a PDF brinda búsqueda nativa a formatos como HTML y Microsoft Project. Si el PDF resultante contiene imágenes sin capa de texto, esos píxeles no pueden ser buscados.

Usa el modo de redirección cuando necesites una proyección que permita búsqueda y que contenga texto — a costa de una conversión inicial cuando se abre el documento.

Etapa 2 — La canalización de imagen de página

Cada solicitud de página a DocImage.axd ejecuta una secuencia fija:

raw page PNG → watermark → rotate/flip → scale → annotation burn → PNG to the response

• Marca de agua — aplicada según el estado de la licencia (sin licencia, una licencia temporal o de suscripción expirada, un dominio inválido, una compilación fuera de las versiones de la licencia) y desde DocOptions.Watermark para tu propio texto. Un sitio con licencia sin marca de agua personalizada omite este paso.
• Rotar/voltear — el estado por página que el usuario establece en el widget (90°/180°/270°, volteos horizontales y verticales) se almacena en la sesión y se aplica a cada renderizado posterior de esa página.
• Escala — las miniaturas y niveles de zoom se producen escalando la página renderizada al tamaño solicitado.
• Quemado de anotaciones — las anotaciones guardadas se dibujan sobre el mapa de bits, de modo que las exportaciones y las imágenes de página las muestren.
• Codificación — el resultado se codifica como PNG y se escribe directamente en la respuesta.

Los errores dentro del manejador se devuelven como imágenes de error PNG (texto rojo sobre blanco) con estado 200, en lugar de páginas de error HTTP, para que el widget pueda mostrarlas en el área de la página.

Caché de páginas

BaseConfig.CachePages (predeterminado true) mantiene las imágenes de página renderizadas en memoria durante la vida de la sesión del documento, de modo que volver a visitar una página no la vuelve a renderizar. BaseConfig.ImageResolution (25–300 DPI, 0 = el valor predeterminado del formato) es el control principal de calidad y memoria; el valor predeterminado de cada formato se enumera en Configuraciones de Formato.

En un solo nodo, las sesiones y páginas en caché viven en la memoria del proceso de trabajo. Un reciclado del pool de aplicaciones — programado, o desencadenado por una edición de Web.config o un tiempo de inactividad — elimina cada sesión de documento abierto, y el widget entonces muestra Document session not found. Please re-open document. En modo distribuido (ver Sesiones y Seguridad), una sesión se reconstruye a partir del almacén compartido.

Dónde ajustar qué