Conocen un componente Delphi puro para Ver PDF (Sin usar AcroPDF) ?
 

Hola a todos,

Alguno conoce un componente que permita visualizar un archivo PDF en un formulario Delphi y que no esté basado en AcroPDF ?

Lo deseable es que no sea un Active X de paga, sino un OpenSource ?

He buscado tanto en el foro como con Google y nada. Uno que otro que potencialmente servirían son pagos.

Alguién quizás se pregunte porque no quiero la solución standard basada en AcroPDF. La respuesta puede resultarle bastante util así que les comento lo siguiente :

1. En general no necesito visualizar cualquier archivo, sino archivos generados por mi aplicación

2. Esos archivos son generados originalmente en QuickReport.

3. Como deben enviarse a terceros por correo, el reporte Quick Report debo convertirlo a PDF

4. El archivo PDF resultante lo debe visualizar el usuario a fin de verificar que la conversión fué correcta

5. Con AcroPDF, en general eso se logra bien; pero, no en todos los equipos hay compatibilidad y, peor todavía, según leí en algunos hilos del foro, las versiones recientes es casi seguro que sean incompatibles (Y los usuarios las necesitarían para ver archivos fuera de mi aplicación)

Por eso es que quiero una solución que sea estable entre diferentes versiones de Windows y que, en el peor de los casos, si hay problemas, pueda revisar por mi mismo

Como por ahora es solo una mejora menor (es más previsión a largo plazo), la idea es que, dentro de lo posible, sea un componente OpenSource

Muchos saludos

Si tú creas el pdf con quickreport, no tienes que preocuparte de nada más. Que cada usuario tenga instalado el visor de pdf que quiera o le guste más.

Gracias; pero...
 

Hola Casimiro,

Muchas gracias por interesarte; pero, me temo que no has entendido el problema.

Voy a ampliar detalles :

La idea es que el archivo se visualice dentro de un formulario Delphi; entre cosas porque en ese formulario, en la cabecera, van campos de captura de datos para enviar el archivo por correo.

Si el archivo se dejara afuera para ser abierto con cualquier visor de PDF, no habría problema y tú comentario sería correcto. Sin embargo, hacer eso es un perdida de calidad respecto a como se está haciendo ahora, ya que para el usuario es más incómodo conmutar entre mi aplicación y el visor PDF, comparado con tener a ambos en la misma ventana, que es lo que hacemos hoy con AcroPDF.

No tiene presentación que desmejoremos la experiencia del usuario. Y el problema es que, según lo dicho en otros hilos del foro, si se instalan versiones recientes de AcroPDF, es muy probable que no sean compatibles con mi aplicación, ya que es de 32 bits.

Migrar a 64 bits, si bien en algún momento será obligatorio, es también un costo enorme, dado el tamaño de las aplicaciones.

Tal migración no se justifica tan solo por un detalle menor como ese y, puesto que mis aplicativos, salvo uno que otro caso de poca importancia como el que estoy planteando, corren igual de bien desde Windows 2000 (que ya no existe) hasta por lo menos Windows 8, por ahora no hay nada que oblique a migrar en el mediano plazo. De hecho, no creo que antes de 3 o 4 años nos veamos obligados a migrar.

Muchos saludos

Las primeras versiones (usé la 1.2) de WPTools eran freeware, pero era muy trabajoso crear los documentos. De todas formas, yo tampoco veo el problema. Si estás creando el documento a partir de un componente de reportes, podrías usar ese componente para visualizar y generar el PDF más tarde, cuando el usuario haya introducido la información que le pides.

solo de pago gnostice

Tambièn se puede; pero ...
 

Hola DopeRider,

Gracias por colaborar. Si, como lo planteas también se puede; pero, una vez más desmejoramos el sistema ya que es más incómodo digitar todo primero y luego ir a ver que es lo que se va a enviar. En especial porque algo de lo que digitan los usuarios pueden ser comentarios al reporte y obviamente es mejor hacerlos viéndolo ahí mismo.

El caso es que funcionalmente el sistema trabaja hoy en día de manera ideal. De lo que se trata es buscar una solución a un problema operativo que se ve venir, sin bajar la calidad de la parte funcional.

La pista de las WPTools parece buena. Según leí, el componente exacto que necesito es el WPViewPDF; pero, todos los sitios que encontré eran ya con la versión paga. Alguna idea de como conseguir esas primeras versiones ?

Muchos saludos

Se me olvidó aclarar ...
 

Hola de nuevo,

Al responder a DopeRider se me olvidó aclarar que el componente de generación no cuenta con interfase visual. El reporte se genera en QuickReport y por debajo se hace la eexportación a PDF.

La idea de visualizar la versión en PDF es, como lo expliqué al principio del hilo, para verificar que la exportación fué correcta

Muchos saludos

No se si entendí bien tu problema, pero yo lo que uso es el TWebBrowser para utilizarlo como visor de archivos, el webBrowser usará lo que la computadora tenga instalado para ver el archivo, no importa que tenga.

Dejo una imagen de un pequeño programa que hice a forma de muestra.

Saludos

PD, Bueno, pues no se puede adjuntar, ClubDelphi solo deja subir 976K de archivos adjuntos, tendrás que confiar en mis palabras :D

A lo mejor digo una tontería, pero si sólo hace falta visualizarlo, ¿Por qué no utilizas el componente TWebBrowser?. Se mostrará dentro del formulario Delphi un navegador que utilizará el plugin correspondiente para mostrar el pdf.

Y ahí está, sin usar más componentes extraños, y el cliente usará el navegador que tiene por defecto.

Mira por ejemplo este hilo del club

Saludos

No me expliqué bien. Tengo una versión antigua en alguna parte, pero no te va a servir para nada. Cuando usé aquello tenía que usarlo al estilo del GDI, o sea dibujando en un canvas. Creo que no te das cuenta de lo que eso significa: manejar contextos de dispositivo, medir el tamaño de la letra, ajustar manualmente las líneas... Si no se hubiese dado la circunstancia de que ese trabajo había que hacerlo de todas formas, por otras razones, la decisión hubiera sido comprar unos componentes que hicieran ellos el trabajo, no yo.

Hay un tipo de respuesta que no me gusta dar, porque siempre parece que estás enmendando la plana al que pregunta, que te aseguro que no es mi intención, pero en este caso cae por su propio peso y, después de veinte años bregando con clientes... pues mi modesta opinión es que no hay muchas vueltas que se le puedan dar. A un cliente se le dice: "mira, por cambios de Windows esto no se va a poder seguir haciendo igual, así que elige entre pagar un extra para incorporar los componentes o sintiéndolo mucho, tendrás que hacerlo manualmente".

Si se trata de un cliente, lo entenderá. Si no lo entiende, ¡no se trata de un cliente! sino de otra cosa. No sé si se me entiende :-) En fin, decidas lo que decidas, mucha suerte!

Gracias. Es otra alternativa; pero ...
 

Hola a todos,

Gracias a ElKurgan y DopeRider por plantear la posibilidad de TWebBroser.

Es otra alternativa a usar; pero, si entendí bien lo que leí en otros hilos del foro, es muy probable que tenga el mismo problema de AcroPDF. Por qué ?. Porque usa el plugin instalado en el equipo para la extensión PDF, o sea que normalmente usa el de Adobe.

Si la versión de TWebBrowser disponible es de 32 bits, como es mi caso, entonces según lo que comentaban los compañeros, lo más probable es que ya, o muy pronto, falle porque la explicación acerca de AcroPDF dada es que Adobe ha empezado a parar el soporte para 32 bits.

Más claramente, la tendencia actual es forzar a la gente a cambiar a plataformas de 64 bits; pero, mientras uno se mantega con los standares mínimos, los aplicativos de 32 bits corrren perfecto en las plataformas de 64 bits.

En mi caso, siempre he sido muy cuidadoso en eso. El caso PDF es una excepción, y tengo una que otra más; pero, son detalles de menor importancia.

El cambio es un costo altísimo y la idea es asumirlo solo cuando ya se esté muy cerca de la inviabilidad de ejecutar aplicativos de 32 bits; para lo cual hemos pensado un colchón de seguridad en tiempo.

Muchos saludos

Hola rolandoj, realmente es un dolo de cabeza el tema, si cambias la versión del acrobat va a tronar y no te enteraras (reinstalacion, actualización, etc), te recomiendo para el preview usar el preview del componente de reportes y en un proceso posterior generar el PDF.

Saludos.

Buenas.

Yo uso http://www.cadetill.com/dcef-la-alte...a-twebbrowser/, (Chromium Embedded Framework).

Es un Chrome embebido y funciona bastante bien, sin depender del navegador instalado.

Hola,

¿Qué hay del proyecto PDF.js de Mozilla? Digo para usarlo en un componente "WebBrowser"...

Excelente opción. A veces la respuesta está en nuestras narices y ni aún así la vemos. Lo digo por mi, pues cotidianamente veo los pdfs en el navegador y no me había tomado la molestia de investigar quién me los estaba presentando.

¿Cómo va en el WebBrowser? ¿Lo has probado?

LineComment Saludos

Gracias a todo. Comentario corto
 

Hola todos,

Disculpen la demora. He estado ocupado con otro tema.

Ante todos gracias por las colaboraciones.

A más tardar mañana voy a empezar a investigar las últimas sugerencias.

Por ahora, quiero resaltar que el punto no es solo reemplazar la solución basada en AcroPDF. Por ello no es que el visor trabaje bien, sino las condiciones en que lo haga.

En el fondo de lo que se trata es de blindar el aplicativo para que el visor que se use de PDF no sea afectado por la versión de un software de terceros que esté instalado en el equipo donde se ejecuté, a fin de garantizar la misma experiencia de visualización del archivo.

Eso, porque lo que se desea visualizar son solo archivos generados por el mismo programa.

Por lo tanto, lo ideal es que el componente de visor a incrustar sea codificado en Delphi y que el código fuente esté disponible, claro está preferiblemente un código abierto. Además, y por supuesto, debe ser mínimo para plataforma de 32 bits ya que, como aclaré en una nota anterior, migrar a 64 bits es algo que no planeamos hacer sino cuando ya sea definitivamente inevitable.

Para claridad de esto último, caso de que alguién pregunte :

Eso es porque funcionalmente la serie XE no ha aportado hasta ahora absolutamente nada que nos signifique una mejora importante para nuestra necesidades. En cambio, la migración nos representa un esfuerzo muy grande en codificación, principalmente por el tema Unicode. Lo digo por experiencia, ya que hace como 7 años lo intentamos y después de casi dos meses de trabajo tuvimos que regresar a un Delphi anterior

Muchos saludos

Hola,

He hecho alguna prueba Román, pero, ahora mismo no recuerdo bien... creo que todo funcionaba más o menos como se espera.

Hola dec,

Pero, creo que funciona con node.js y el pdf debe residir en un servidor y no local. Al menos es lo que creo haber entendido de lo que dice en el sitio. Además de que menciona que el soporte para IE es limitado.

LineComment Saludos

En la empresa que trabajo se desarrollaron los sistemas con Delphi 2007, antes con Delphi 6 (me parece), ahora estamos migrando a XE6 todos los sistemas, por una simple razón "Requerimientos de aplicaciones móviles". Y estamos aprovechando para migrar de una vez todos los sistemas, ya hemos migrado dos de ellos con pocos problemas y muchos beneficios. Y lo mejor de todo, cumpliendo con las necesidades actuales de los clientes.

Quiero decir, si en tu compañía sólo tienen necesidades de VCL, pues no, puede ser que haya mas problemas que beneficios en el cambio, sobre todo si usas componente que no se han actualizado.

Saludos

Hola,

Hasta donde yo recuerdo en mis pruebas usé el archivo Javascript como haríamos con cualquier otro archivo Javascript...