Pdf.js: Soporte de formulario interactivo (AcroForm)

Este es un problema de meta para el seguimiento de la compatibilidad con formularios interactivos (AcroForm) de acuerdo con el Capítulo 8.6 de la referencia en PDF (https://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7. pdf # page = 671 & zoom = auto, -246,244).

En su lugar, podría ser una buena idea basar el trabajo en la última versión de la especificación PDF, en caso de que haya alguna diferencia: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/ pdfs / PDF32000_2008.pdf # G11.2110737.

Además, ¿quizás sea una buena idea agregar un elemento TODO "general" para garantizar una cobertura de prueba adecuada?

Se han abordado ambos elementos. ¡Gracias!

Creo que también vamos a tener que analizar el contenido del diccionario AcroForm , ya que de lo contrario no podemos, por ejemplo, cargar todos los recursos de fuentes necesarios.
Obviamente, no podemos usar fuentes personalizadas en la capa de visualización, pero deberíamos poder al menos inferir la familia de fuentes correcta (y cosas como, por ejemplo, negrita / cursiva) que debería usarse y pasar esa información a la capa de visualización.

Además, para imprimir formularios, es posible que podamos utilizar (o construir sobre) la funcionalidad appendToOperatorList ya existente, pero eso definitivamente requerirá que se hayan cargado los recursos de fuentes presentes en el diccionario AcroForm .

Otra cosa que probablemente deberíamos intentar admitir es usar el color de texto correcto en la capa de visualización (observe cómo en Adobe Reader el texto en los campos de formulario de f1040.pdf es azul). Esto probablemente se relaciona con un soporte de transmisión de Appearance mejor y más completo.

Finalmente, una pregunta general: ¿Seremos realmente capaces de admitir formularios de manera significativa, sin un soporte de scripts parcial (y bien depurado)?

Buenos puntos. Los acabo de agregar a la lista de elementos anterior. No creo que realmente necesitemos soporte de scripts, ya que los AcroForms generalmente solo requieren relleno e impresión. Los scripts AFAIK solo se utilizan para la interacción entre elementos, pero podemos implementar la funcionalidad más utilizada nosotros mismos (como resetear el formulario o acciones de botón para imprimirlo). Tendremos que ver qué tan ampliamente utilizada es dicha funcionalidad de script.

Manejar banderas: multilínea y solo lectura

Hay otras banderas que podríamos necesitar probar y apoyar también, un ejemplo es comb que controla el espacio entre los caracteres en un campo de entrada. Ese se usa realmente en la segunda página de f1040.pdf , consulte el campo "Número de identificación personal (PIN)".

Suena como una buena idea. Lo he agregado a la lista.

Probablemente también sería una buena idea ver si el código WidgetAnnotation que construye la propiedad fullName se puede limpiar o mejorar, consulte https://github.com/mozilla/pdf.js /blob/6c263c19946af23b723f148d9f05118971e18b36/src/core/annotation.js#L640 -L670.

Además, con respecto a WidgetAnnotation s, parece que diferentes tipos pueden tener diferentes requisitos para la entrada V en el diccionario de anotaciones, por lo que podría ser mejor buscar y validar data.fieldValue en _each_ subclase WidgetAnnotation específica.

El primer punto está ahora en la lista, para el que tengo algunas ideas. Me enteré del segundo punto en un parche que estoy finalizando actualmente para las anotaciones de widgets de elección, por lo que se abordará allí.

Hola @timvandermeij
¿Cuándo estará disponible esta funcionalidad? ¿Como puedo ayudar?

Actualmente estamos en el proceso de implementar esto, pero es una gran parte de la funcionalidad que llevará tiempo antes de que se complete. Las casillas marcadas arriba muestran qué elementos ya están implementados y para otras casillas ya hay solicitudes de extracción de trabajo en progreso, por lo que estamos en camino con esta funcionalidad. Siéntase libre de probarlo usando la rama master y estableciendo el parámetro renderInteractiveForms en true . Está deshabilitado de forma predeterminada porque aún no está listo.

Gracias Tim, ¿qué me puedes decir sobre las firmas digitales? Hay avances de acuerdo con este hilo de discusión https://github.com/mozilla/pdf.js/issues/1076

Esto fue informado por el usuario: soa-x abrió este problema el 13 de enero de 2012

Han pasado casi 5 años desde que se informó.

Incluso alguien ya ha realizado gran parte de la implementación.

viveksjain comentó el 22 de febrero
@complience Hola, tengo una prueba de concepto trabajando en https://github.com/viveksjain/pdf.js/tree/sig-verify-support. Puedes probarlo usando git clone --recursive https://github.com/viveksjain/pdf.js.git. Con un poco más de trabajo, debería estar listo para una solicitud de extracción en este repositorio, pero todavía no he tenido tiempo.

¿Sabe si estos trabajos se agregaron a versiones recientes de pdf.js?

Re: https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251692825

Las firmas en archivos PDF es un tema grande y complejo, que es algo ortogonal a la implementación del soporte básico de AcroForm (que es lo que _este_ problema en particular está rastreando).

El problema actual es solo un problema de seguimiento para la implementación de las características básicas de AcroForm, las firmas ya se rastrean en otros lugares (en el # 1076, que es donde se debe discutir esa característica).

@lexcorp No publique información no relacionada y / o haga preguntas aquí, ya que resta valor al propósito de este problema (que es realizar un seguimiento del soporte para las funciones básicas de AcroForm).
Además, ahora ha publicado básicamente la misma información en _tres_ problemas diferentes, ¡no envíe spam al rastreador de problemas de esta manera!

Hola @timvandermeij @Snuffleupagus ,
Realmente nos gusta su solución para agregar soporte para campos de AcroForm. Estamos planeando utilizar estas funciones en una aplicación que estamos desarrollando actualmente. Realmente agradeceríamos que nos proporcione una fecha tentativa en la que pueda agregar soporte para todo tipo de campos de formulario como casillas de verificación, etc. y exportar los datos completados a un archivo XFDF o cualquier otro formato. Gracias.

@anujgeek Como ya mencioné en https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251699579, este es un problema de _tracking_ y no es realmente un buen lugar para este tipo de discusión general y / o haciendo preguntas!

Queda una serie de tareas pendientes bastante difíciles de implementar, consulte la lista posiblemente incompleta anterior, por lo que _no_ es posible dar ningún tipo de estimación de cuándo, o incluso si, esta función se implementará por completo.

Además, tenga en cuenta que hasta ahora todo el trabajo ha sido realizado por los colaboradores, y dado que Mozilla está reemplazando PDF.js en Firefox (consulte https://wiki.mozilla.org/Mortar_Project), es muy probable que el soporte de formularios tarde un poco en completarse.

Este es un problema de seguimiento (consulte https://github.com/mozilla/pdf.js/issues/7613#issuecomment-251895091), por lo que este no es el lugar para discusiones o preguntas. Contáctenos en IRC en caso de preguntas o presente un problema por separado si encontró un error. Gracias.

_ (Estoy desbloqueando la conversación para permitir que los usuarios usen el botón de reacción para medir el interés por esta función, pero se eliminarán los comentarios irrelevantes). _

¡Hola juntos!

¿Cuál es el progreso con el relleno AcroForm?
El ejemplo usado https://www.irs.gov/pub/irs-pdf/f1040.pdf (y otros) todavía no funciona. ¿O no está configurado por defecto?
¿Se mencionó algo de JavaScript básico como establecer campos, campos claros, compatibilidad con el botón de envío?

Gracias.

@ Alex-DE-74 Lea detenidamente los comentarios anteriores, en particular https://github.com/mozilla/pdf.js/issues/7613#issuecomment -251895091 y https://github.com/mozilla/pdf. js / issues / 7613 # issuecomment -287907674 son relevantes.
Además, ya hizo estas preguntas en el n. ° 9261 (donde se proporcionaron las respuestas); Intentemos mantener este problema de seguimiento libre de ese tipo de discusión general.

@Snuffleupagus

Disculpe, pero para mí no es realmente rastreable a través de muchos temas, qué elemento tiene en qué etapa. Y las referencias cíclicas no son útiles en absoluto. Desde el punto de https://github.com/mozilla/pdf.js/projects/1 , está claro para mí, qué parte de AcroForms es compatible ahora (completamente) y qué está en el plan. Además, muchos temas abordan el renering / visualización, pero no hay palabras sobre la función interactiva llenar / verificar / seleccionar / enviar, etc. Entonces, por ejemplo, la parte de arriba "Widgets de texto" no tiene nada sobre "Escritura de texto". Entonces, si el "Diccionario AcroForm" no se analiza actualmente en absoluto, ¿cómo puede funcionar realmente bien?
Quizás sería útil para los "usuarios" ver una tabla simple en la que AcroForm se destaque con sus propiedades y un estado de soporte completo / particular / planificado enumerado. (¡¿Por qué esto se mostró en negrita = ?!)

PD: Es doloroso para mí, no soy un experto en JS / HTML5, pero hice muchas cosas en el otro sitio (creando PDF con C #) y también estoy familiarizado con otros lenguajes de programación. ¿Merece la pena intentar comprender el código actual para poder brindar un soporte más interactivo y ayudar a desarrollar este proyecto? ¿O llevará mucho tiempo comprender la arquitectura actual?

He eliminado el estilo atrevido para ti. Me gustaría enfatizar nuevamente que este no es el lugar para tal discusión; un canal como IRC sería más apropiado para que podamos dar alguna información de fondo. Completar / enviar / imprimir formularios está de hecho en la lista de casillas de verificación anterior, simplemente no se ha implementado todavía. La parte de "widgets de texto" trata sobre la representación de widgets de texto, lo que significa los campos de entrada en los que puede escribir. Eso está hecho; la parte que queda es almacenar los valores ingresados. Cualquiera es bienvenido para ayudar a implementar esto.

Por cierto: Chrome tampoco puede guardar archivos PDF con formularios, pero hay una solución. Los formularios se representan de forma predeterminada y se pueden imprimir e incluso se pueden imprimir como PDF de forma predeterminada, incluida la entrada del formulario.

Tal vez esto también sea aplicable para pdf.js y podamos utilizar el guardado de FF existente como PDF (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/saveAsPDF).

Estoy jugando con pdf.js tratando de imprimir los valores del campo de texto del formulario ingresado. Tengo una prueba de concepto rudimentaria en la que puedo representar los valores ingresados ​​en el PDF de impresión. Ahora quiero discutir mi enfoque y ver si a alguien se le ocurre uno mejor o más simple.

En mi enfoque, paso los valores ingresados ​​a la tarea del trabajador agregando un mapa a la tarea. Este mapa está actualmente lleno en el evento 'beforeprint'.
En el método 'getOperatorList' de 'TextWidgetAnnotation', leo el flujo del objeto y reemplazo el valor de texto antiguo del operador 'Tj' por el nuevo. Esto funciona, pero tiene muchos problemas. La primera es que falla si la secuencia no tiene un operador 'Tj' porque el campo no tiene valor. El segundo es que la ubicación de las alineaciones que no sean 'izquierda' será incorrecta.
Entonces, la siguiente idea es crear una secuencia completamente nueva calculando todos los valores por mí mismo. Esto supondrá mucho trabajo, así que primero quería hablar de este enfoque.
Ya puedo crear una nueva secuencia y mostrar los valores, pero nuevamente, existe el problema con los valores de compensación de la operación 'Td'. Profundicé un poco en el código y creo que necesito calcular la posición de desplazamiento X e Y teniendo en cuenta el ancho y la altura de la Cadena con la Fuente dada. Encontré FontDescriptor para una fuente incrustada, pero no para una fuente del sistema. Con el descriptor de fuente tengo el valor de ascenso y descenso de la fuente, con el que creo que puedo calcular el desplazamiento y El desplazamiento x será fijo para textos alineados a la izquierda, pero debe calcularse para textos centrados o alineados a la derecha . Creo que puedo hacer esto con la matriz de anchos de Font xRef, pero nuevamente, no existe tal para las fuentes del sistema. Entonces creo que tendría que usar un lienzo y el método meterText.

Entonces, como puede ver, hay mucho "pensamiento". Pero antes de intentar implementar y probar mi enfoque, me gustaría saber qué piensan los demás al respecto.

Hace algún tiempo tuvimos una discusión sobre cómo podríamos abordar esto. Consulte https://mozilla.logbot.info/pdfjs/20161219. La idea es tener dos listas de operadores diferentes: una para la interfaz de usuario y otra para imprimir. En el de imprimir, reemplazaríamos las operaciones basadas en el valor ingresado / seleccionado en el widget.

Creo que esto es algo más fácil de lo que estás describiendo, ya que dejamos que la lógica restante haga el trabajo pesado por nosotros; solo tenemos que proporcionar la lista de operadores correcta.

Este es un problema que tenemos que resolver en varios pequeños pasos. El primer paso es hacer que el código de anotación sea asíncrono, lo que hace @dmitryskey en # 9822. El siguiente paso sería analizar el diccionario de AcroForm para, por ejemplo, fuentes y analizar la entrada de apariencia predeterminada en el diccionario de anotaciones para toda la información de apariencia. Para esto, probablemente podamos usar el evaluador para obtener la información como una lista de operadores, lo que requería que el código de anotación fuera asíncrono. Luego, podemos crear las listas de operadores de impresión para cada tipo de anotación.

También pensé en crear la lista de operaciones por mí mismo, pero esto sería más complicado para mí que mi enfoque. Simplemente creo el flujo de objetos pdf con 'BMC ... EMC' y paso el flujo al evaluador, que genera la lista de operaciones.
Si creo la matriz de la lista de operaciones yo mismo, tendré los mismos problemas que al generar una nueva secuencia de objetos. Pero en mi humilde opinión, es más complicado crear la lista de favoritos que crear una cadena y convertirla en un flujo de objetos. Esto ya funciona en mi prueba de concepto.

Pensé que Opera / Chrome también están usando pdf.js, pero Opera puede imprimir y usar datos de formularios. Quizás haya algo. podemos reutilizar?

Usan PDFium, que es principalmente código C ++.

Hola a todos, la empresa para la que trabajo está empezando a aprovechar PDFJS y me han dicho que necesito que funcione "Almacenar valores ingresados ​​para cuando la página se destruye cuando no es visible". No estoy seguro de si este hilo es el lugar adecuado para discutirlo. @timvandermeij , parece que eres uno de los principales impulsores de este proyecto. ¿Hay alguna forma de que podamos ponernos en contacto con usted o con alguien de la comunidad que pueda ayudarlo? Tengo una estrategia para implementar esta función, pero quiero asegurarme de que lo que hago también se pueda incorporar a este repositorio. También estamos dispuestos a patrocinar o crear alguna recompensa de funciones, si eso ayudara a acelerar las cosas.

Si tiene ideas sobre cómo se debe hacer esto, es mejor abrir un tema por separado para discutirlo. La pregunta principal es qué hacer con los datos ingresados. ¿Renderizarlo en el lienzo al imprimir? ¿Ofrece una opción para descargar los valores en formato FDF? ¿Renderizar un nuevo archivo PDF con los valores completados? Etcétera. Depende de lo que el usuario esperaría y de lo que hagan otros lectores de PDF.

Cierre ya que el soporte de AcroForm ahora está hecho y habilitado. Los problemas restantes ahora se archivan en números individuales y se recopilan con la etiqueta 4-form-acroform ; ver https://github.com/mozilla/pdf.js/labels/4-form-acroform.