Firefox: visor nativo de PDFFirefox soportará el estándar PDF de forma nativa, utilizando HTML 5 y Javascript, sin necesidad de plug-in. Mozilla está trabajando desde hace un mes en este proyecto de código abierto, que está alojado en GitHub.
Al igual que muchos antes que nosotros, nos preguntamos por qué nadie había puesto en marcha un lector de PDF en HTML5/JavaScript.
El proyecto se ha llevado a cabo de forma pública, aunque discreta. Han esperado a tener resueltas algunas de las características principales, como las fuentes Type1, gradientes, etc., antes de presentar pdf.js públicamente.
El soporte nativo del estándar PDF tiene grades ventajas:
- Se elimina la necesidad de utilizar software adicional, (como el plug-in de Adobe o cualquier otro).
- Un lector interno puede aprovechar determinadas características de la Web, (como cadenas de peticiones HTTP).
- Unificar el interfaz de usuario para manejar PDFs.
- Algunos lectores externos y plug-ins no soportan bien ciertas características importantes de los documentos PDF, (como los enlaces).
- Aumento de la seguridad, ya que HTML es inmune a problemas como los presentados por el sandbox de Google.
- En el código abierto es más fácil detectar y corregir problemas.
- Algunas de estas ventajas cobran especial sentido en los terminales móviles.
Os dejo el enlace a una página especialmente preparada para comprobar esta interesante funcionalidad. He probado que funciona con Firefox 4 y Google Crome 12. En Internet Explorer 9 y Opera 11.11, no. No tengo instalado Safari 5 en este equipo y no lo he podido verificar.
Vía | Andreas Gal blog
Web | Ver cómo funciona
Comentarios
Por fin! hace tiempo que faltaba esta característica ya que los plugins de terceros no son nada efectivos
¿ Se vendra un cambio en mozilla ? para sus proyectos usan Mercurial, no Git... al menos hasta ahora.
Parece un poco absurdo que implementen esta característica en html+javascript en lugar de hacerlo en c e integrarlo en el navegador.
interesante
Ten en cuenta que Javascript cada vez está más optimizado, que no es una operación que consuma muchos recursos y que así pueden utilizarse en cualquier otro navegador que soporte Javascript y HTML5.
¡Realmente es un proyecto magnífico!
No importa que tan optimizado esté, un código en lenguaje interpretado nunca será más eficiente que en lenguaje compilado.
-- editado por última vez a las 20:28
6 Comentario moderado
8Sin embargo llega un punto en que si vas a interpretar otro código que interpreta a otro y así sucesivamente SÍ es mas efectivo, productivamente hablando, programar en javascript y más existiendo los motores tan optimizados y rápidos como los que hay hoy en día.
Decir que programar en javascript "no es óptimo" es demasiado arriesgado. La productividad en este caso es del orden de "muchisimo más" que hacerlo, por ejemplo, en C.
Al fin y al cabo... los plugins están hechos en C y C++ y... bueno, no entran en la definición de "óptimos", ¿no?
Si sabes programar te aconsejo que eches un vistazo a node.js que funciona sobre V8, una pasada.
Un saludo.
-- editado por última vez a las 21:06
interesante
"Sin embargo llega un punto en que si vas a interpretar otro código que interpreta a otro y así sucesivamente SÍ es mas efectivo, productivamente hablando, programar en javascript y más existiendo los motores tan optimizados y rápidos como los que hay hoy en día."
- Si te digo la verdad, no entendí que quieres decir ahí.
"Decir que programar en javascript "no es óptimo" es demasiado arriesgado."
- No no, yo no he hablado de programar, he hablado del programa. No importa lo optimizado que esté el interpretador, compilar al vuelo no es más eficiente que ya compilado.
"La productividad en este caso es del orden de "muchisimo más" que hacerlo, por ejemplo, en C."
- Pero si hablamos de programar, la productividad no depende de la herramienta sino del dominio que tenga la persona sobre la herramienta.
Hay quienes son unos tigres haciéndo páginas en Dreamwever y hay quienes lo son hasta en un Notepad. Decir que Dreamwever es más productivo para todos es bastante peregrino. Sin mencionar que el tema iba sobre el resultado, no sobre su elaboración (es decir, que tendríamos que hablar de que las páginas en Dreamwever son mejores que las hechas a pulso).
"Al fin y al cabo... los plugins están hechos en C y C++ y... bueno, no entran en la definición de "óptimos", ¿no?"
- ¿Cómo saber si ya no son óptimos? Dejando eso de lado, no era cuestión de comparar dos códigos sólo por comparar compilado vs interpretado. Notar que hablo de hacer un código en lenguaje interpretado y hacer en lenguaje compilado. Si el plugin fulano no te parece óptimo sería interesante ver ese mismo plugin en javascript a para ver una redefición del concepto "no óptimo".
http://3.bp.blogspot.com/-g-9_2XIBs1g/TYCqnpZupQI/AAAAAAAAAjc/yTPr65YEfGA/s1600/results.png
En este gráfico se ve cómo javascript es ligeramente más rápido que C, no olvides que no es un lenguaje originalmente orientado a objetos.
No veo gran diferencia, la velocidad al interpretar no es tan mala, en cambio cargar una aplicación adicional si consume muchos más recursos y la diferencia en velocidad no es tanta. Espero que FF no sea el único en hacerlo.
Entonces ya está, si pones una gráfica aislada en la que no pone qué algoritmo ejecuta ni bajo qué condiciones, ni qué flags de optimización han puesto en la compilación ni nada de nada, está clarísimo que javascript es más rápido.
Al mismo algoritmo, cualquier lenguaje compilado es más rápido. Si comparas una implementación como la de node.js con otros algoritmos lo único que estás diciendo es que el algoritmo es muy bueno, no que javascript sea más rápido.
¿Y qué tiene que ver eso con la velocidad? En todo caso del desarrollo. A mi me encanta la POO, pero no aporta más velocidad que la programación imperativa por ejemplo. Y c++ sí que es orientado a objetos.
Con esto no quiero decir que sea un fallo hacer el lector de pdf en javascript porque creo que compensa mucho la portabilidad del proyecto. Además no es necesario cargar un plugin adicional en memoria, con lo que en eso también se gana tiempo.
He probado el ejemplo de la página del test ( http://onlinevillage.blogspot.com/2011/03/is-javascript-is-faster-than-c.html ) y en el programa en c hace 1981515 reallocs por cada ejecución, y todas son de ampliación con lo que conlleva movimiento de los elementos del array. Muy optimizado el programa no está.
En javascript no es equivalente porque usa el objeto Array, en vez de usar vectores y hacer manualmente los reallocs.
No es un ejemplo válido ya que no usa los mismos algoritmos. Además, en los comentarios hay uno que dice que en c++ ha hecho uno más rápido.
Me pregunto cómo vez eso ¿al ojo por ciento?.
La "aplicación adicional" con sus respectivos recursos siempre se va a cargar en algún momento, sólo que en un caso se carga ¿una vez? y ya compilado mientras que en el otro caso se cargará cada vez se requiera (eso supongo) más los recursos que pida para la interpretación.
Como vez todo era cuestión de subjetividad, de ver que hay "cosas de más" en un caso y ver que "no hay nada" en otro.
Cosa que viene estupenda, ante el monstruo devorador de memoria en que se ha convertido mi firefox.
pregunta: he estado probandolo y solamente me bota como imagen, es decir no me deja selecionar texto... eso lo veo como un gran freno o solo fue en mi maquina? alguein q pueda aclararlo??
En el post original explican que de momento no se puede seleccionar texto ni realizar búsquedas porque renderizan el PDF como una imagen en Canvas, pero están trabajando en un backend en SVG que sí permitirá estas funciones.
Interesante.
De hecho yo también me había hecho la misma pregunta =)
La verdad yo nunca me lo pregunté porque no imaginé siquiera que fuese posible. xD
Muy bien por Mozilla, ahora sí me sorprendieron, y es raro viniendo de ellos. Sinceramente me resulta muy extraño verlos innovar en vez de adoptar las innovaciones de alguien más.
¡Pero que cosas dices! O_O
En verdad crees que si Firefox hiciera esas cosas, ¿estaría en el lugar que se encuentra ahora?
Firefox se volvió popular simplemente por dos cosas: ser software libre y tener extensiones, pero nunca ha sido innovador, ese trabajo siempre le ha correspondido a otros como Opera y Chrome, mientras que Firefox tan solo se limita a ponerse al día con lo que ellos lanzan.
Totalmente de acuerdo , ahora o arriesga a innovar o muere. No todo es sobrevivir a base de personalizaciones de sus usuarios
Si las extensiones no son una "innovación", ¿entonces que son? (ahora a casi cualquier cosa le llaman innovación, no es de sorprenderse).
Seamos realistas, Chorome solo impuso la moda de que todo sea minimalista, los procesos separados por pestaña y su sandbox de hay en mas ya estaba presente casi todo. De Opera no lo niego, pero de Chorome lo dudo, las innovaciones seria de quien mantiene el motor y segun tengo entendido fue de un proyecto de KDE de donde salio Chorome.
Salu2
No sé si Firefox inventó las extensiones porque según yo ya estaban presentes antes en otros programas, pero aunque lo hubiera hecho, ese vino siendo su único punto fuerte durante la mayor parte de su historia.
Mozilla se confió en que su comunidad de extensiones supliría las deficiencias del navegador y lo mantuvo absurdamente básico por muchísimo tiempo. Solo recuerda cuánto tiempo tardaron en mostrar las pestañas por defecto y añadir el botón para abrir una nueva. ¡Fue hasta la versión 3.5 que salió en 2009! Para entonces todos los navegadores ya lo habían hecho; incluso IE llevaba nada menos que 4 años de ofrecer el dichoso botón.
Ahora que todos los navegadores implementaron las extensiones, Firefox perdió esa ventaja y tuvo que espabilar, pero aún así sigue sin añadir nada que no existiera antes en el mercado, simplemente que ahora se da más prisa en copiarlo.
En cuanto a Chrome, el minimalismo es cuestión de gustos, pero los procesos separados, la sandbox y especialmente las actualizaciones silenciosas son innovaciones muy importantes, ya no digamos que ha impulsado terriblemente el desarrollo de JavaScript con su cada vez más rápido intérprete V8. Los navegadores nunca se habían preocupado tanto por hacerse más rápidos hasta que llegó Chrome.
No es por joder a Mozilla, pero hablando con sinceridad, además de las extensiones y de este nuevo lector de PDF en HTML5/JavaScript no se me ocurre ninguna otra situación en donde hayan dado el primer paso en algo.
El primer navegador extensible fue... IE.
Sólo que en esa época a eso no se le llamaba "innovación" sino que se le llamaba por algún insulto o chiste.
La única diferencia es que esa extensibilidad no fue usada como juguete nuevo por pringaos y codemonkeys sino por unas cuantas aplicaciones y, como no, por gente no bien intencionada, que luego llenaban al navegador de menú, barras, botones, plugings, dlls, etc.
Recientemente esto último también le está pasando a Firefox y un empleado de Mozilla salió llorando diciendo que hacer esas cosas era sucio. Pensar que cuando le ocurría a IE lo gracioso y mal programado que era.
Ese proyecto está publicado en GitHub https://github.com/andreasgal/pdf.js cualquiera podrá implementarlo en su web :D
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect