Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Mozilla arbeitet bei Firefox an integrierter PDF-Unterstützung

Wie ein Entwickler von Mozilla in seinem Blog berichtet, arbeitet man an einer Integration von PDF in Firefox. Bisher ist das Betrachten von PDF-Dokumenten in Firefox nur über Plugins möglich. Mit seiner in Firefox integrierten PDF-Unterstützung will Mozilla aber nun neue Wege gehen, denn im Gegensatz zu anderen Lösung wie bei WebKit wird in Firefox die Darstellung der PDF-Dokumente als umgewandeltes HTML5 erfolgen. Mozilla hofft, damit besser von der optimierten Browser-Engine und deren Sicherheitskonzept zu profitieren sowie ein konsistentes Nutzererlebnis schaffen zu können. Die Entwicklung an dem zugrundeliegenden "PDF.js" wurde vor rund einem Monat begonnen und könnte nach Einschätzung des Entwicklers in drei Monaten in einer ersten brauchbaren Version zur Verfügung stehen. Zunächst wird "PDF.js" aber für interessierte Anwender nur als Firefox-Plugin zum Download angeboten. Langfristig soll die Lösung jedoch bei Firefox mitgeliefert werden.

Weiterführende Links:

Kommentare

imushroom20.06.11 12:03
Kommt dann in Version 6
0
violenCe20.06.11 12:12
und die kommt nächste woche
0
idolum@mac20.06.11 12:17
Finde ich nicht gut. PDF soll absolut identisch aussehen, und das ist bei einer Umwandlung nicht gegeben.
0
wolf2
wolf220.06.11 12:25
bläst ihn nur weiter auf!
dann kommt dann wieder ein ableger, und dann wieder einer.
raunzen, mosern, sumpern, sudern, was uns bleibt.
0
lenn1
lenn120.06.11 12:49
Ich versteh den Sinn nicht. Warum muss man das umwandeln? Das PDF ist doch gut, so wie es ist.
0
Sagrido
Sagrido20.06.11 13:09
Eben - und Safari beherrscht das auch ohne Plugin (aber nur, weil PDF in Mac OS X integriert ist)
Ich habe immer gehofft, dass Apple die entsprechenden Frameworks mal mit ins Windows Safari portiert, damit dieser dort auch schnell und ordentlich PDFs darstellen kann. (Reader lahmt einfach nur)
0
sierkb20.06.11 13:12
Wo steht da in den Original-Quellen irgendwas von Umwandeln? Mir scheint, sb hat den Original-Text nicht ganz verstanden. Da wird nix umgewandelt. PDFs werden, so wie sie sind, nativ gerendert. Nur dass der Renderer eben kein C-Programm ist, sondern JavaScript in Verbindung mit HTML5 und SVG. Und dass man in Zukunft sogar vorhat, dieses Rendering evtl. sogar via OpenGL von der GPU durchführen zu lassen statt von der CPU. Und was die heutigen JavaScript-Compiler der Browser inzwischen an Geschwindigkeit zugelegt haben und man das dann auch noch steigern kann, indem man Berechnungen in die GPU auslagert, das dürfte allgemein bekannt sein. Solcher Code steht dann C-Code performancemäßig in nichts mehr nach.
0
Quickmix
Quickmix20.06.11 13:14
Top!
0
sierkb20.06.11 13:17
Sagrido:
Eben - und Safari beherrscht das auch ohne Plugin (aber nur, weil PDF in Mac OS X integriert ist)

Safari nutzt dafür das MacOSX PDFKit Framework. Genauso macht's seit längerem bereits ebenfalls diese Firefox-Erweiterung: PDF Plugin for Firefox on Mac OS X , Projektseite dazu bei Google Code: . Die nutzt dasselbe PDFKit Framework von MacOSX wie auch Safari. Leider hat sich er ursprüngl. Entwickler von diesem Projekt etwas zurückgezogen, und dieses Add-On funktioniert bislang nur im 32-bit-Modus von Firefox und nicht im 64-bit-Modus, der aber standardmäßig seit Firefox 4 benutzt wird.
0
Steppenwolf
Steppenwolf20.06.11 13:26
Mozilla, bitte macht das so komfortabel wie in Chrome.
0
Gerhard Uhlhorn20.06.11 13:28
Eigentlich können fast alle richtigen Mac-OS-X-Programme PDFs anzeigen, denn sie erben es vom Betriebsystem. So kann man auch PDFs in Pages, Numbers, iDVD, iMovie, iWeb usw. platzieren, und der Vektorcharakter des PDFs bleibt voll erhalten. So kann ich z.B. eine Webseite, die ich mit iWeb erzeugt habe, beliebig vergrößern, ohne dass das platzierte PFD-Logo pixelig wird. Leider kann das aber nur Safari (Mac) anzeigen.

Gibt es eigentlich irgendwo einen PDF-HTML5-Konverter?
0
sierkb20.06.11 13:45
Steppenwolf:

Chrome hat einen lizenzierten kommerziellen Foxit-Reader an Bord. Chromium hat aus dem Grund keinen PDF-Reader. Wegen der Lizenzierung bzw. wegen Closed-Source.
0
gritsch20.06.11 14:10
klingt doch sehr intressant das PDF.js
0
sierkb20.06.11 14:17
Gerhard Uhlhorn:
Gibt es eigentlich irgendwo einen PDF-HTML5-Konverter?

Also bezüglich PDF HTML gibt's seit Jahren bereits gleich mehrere Möglichkeiten und Tools (z.B. pdftohtml ), die in der praktischen Anwendung da draußen auch schon gut Verwendung gefunden haben. Ebenso in Gegenrichtung (HTML PDF, z.B. mittels XSL-FO bzw. Apache FOP u.ä. Technologien). Bzgl. PDF HTML5 stößt man via Google-Suche u.a. auf das hier , , da gibt es aber bestimmt noch mehr Lösungen, Möglichkeiten und Wege.
0
Steppenwolf
Steppenwolf20.06.11 14:36
Wie macht man hier eigentlich diesen Zitierpfeil?

@sierkb:
Das wusste ich nicht. Na dann muss es wohl oder übel mit der HMTL5 Methode gehen.
0
flashjo20.06.11 14:37
hmm … wenn die das ordentlich hinbekommen pdf's zu HTML5 zu wandeln und diese Technologie auch von anderen Browserherstellern übernommen wird …
ojee … dann werden alle Print-Leute zu Webdesignern.
0
uwe_aus_messel20.06.11 14:48
@Steppenwolf: ganz einfach: zweimal '-' und einmal '>' ergibt
0
Gerhard Uhlhorn20.06.11 14:49
Steppenwolf: 2 x @ ohne Leerzeichen dazwischen, oder - und > direkt hintereinander.
0
Gerhard Uhlhorn20.06.11 14:53
sirkb: Danke.
0
0x0020.06.11 16:03
Und was die heutigen JavaScript-Compiler der Browser inzwischen an Geschwindigkeit zugelegt haben und man das dann auch noch steigern kann, indem man Berechnungen in die GPU auslagert, das dürfte allgemein bekannt sein.
Solcher Code steht dann C-Code performancemäßig in nichts mehr nach.

Die heutigen JavaScript Compiler sind rasend schnell geworden, im Vergleich zu frueher, da hast du absolut Recht. Ich wuerde dir allerdings dennoch bezueglich deiner letzten Aussage, dass JavaScript Code dadurch kompiliertem C in nichts mehr nachsteht widersprechen. Dem ist nicht so und dem wird m.E. auch womoeglich nie so sein. Auch, wenn dies irgendwann in ferner Zukunft nur noch von akademischer Bedeutung sein mag, so sind wir davon noch ein ganzes Stuck entfernt. Ja, es gibt tolle und interessante Projekte, wie das kleine Linux im Browser, welches du kuerzlich hier irgendwo verlinktest, doch auch das ist letztendlich nur vorbeifliessender Text und ein paar simple GNU Tools im Hintergrund welche im Grunde auch nichts anderes sind, bzw. produzieren. Interessant waere es zu sehen wie soetwas mit ein paar mehr Tools augestattet multiple Aufgaben und idealerweise Berechnungen zur selben Zeit erledigen und im Vergleich zum nativen Kernel performieren wuerde.

Auch interessant waere ein grafisches Projekt, etwas wie IceWM im Browser. Doch fuer diese Dinge fehlt es m.E. nicht unbedingt an Performance von JavaScript sondern an Frameworks, die fuer solche nativ-aehnlichen Anwendungen ausgelegt sind. Momentan duerfte es doch eher ein Krampf sein komplexe GUIs mit wiederverwendbaren Elementen in JavaScript zu realisieren. Aber das ist nicht das Thema...

Bei grafischen Anwendungen, vor allem im Zusammenhang mit Animationen ist vielleicht heutzutage auch nicht mehr so sehr die Performanz des JavaScript Compilers der Flaschenhals, sondern womoeglich die Rendering Engine der Browser.

Bezueglich des Auslagerns von Berechnungen auf die GPU kommen auch interessante Zeiten auf uns zu. Microsoft hat bereits angekuendigt, dass man einen solchen Schritt nicht unterstuetzen werde, da man Sicherheitsbedenken habe jeder moeglichen Webanwendung Zugriff auf die Hardware zu geben. Das geht den Herren dann doch ein wenig weit und man fuerchtet sich vor niemals zuvor erschlossenen Sicherheitsluecken. Beispielsweise in Treibern fuer Grafikkarten. Man mag von den Herren ja halten was man moechte, doch damit haben sie leider Recht. Das ist ein bisher nicht getesteter Bereich. Hinzu kommen noch andere Problematiken des Webs. So ist es doch nichts neues, dass beispielsweise Scareware sich ueber legitime Seiten verbreitet. Da wird einfach etwas in einem Werbebanner oder einem Bild untergeschoben. Und so kann man sich nicht sicher sein, wer oder was da eigentlich gerade etwas ausfuehren moechte und ob dort nicht etwas untergeschoben wurde. Von der Problematik, dass unbedarfte Anwender nicht unbedingt direkt zwischen vertrauenswuerdiger und boshafter Quelle unterscheiden koennen und dennoch direkt Zugriff ins System besteht einmal abgesehen.

Aber gut, da muss man wohl abwarten was die Zukunft bringt und welche Sicherheitsaspekte bei einer ersten Implementierung beruecksichtigt werden.
0
sierkb20.06.11 16:28
0x00:
Ich wuerde dir allerdings dennoch bezueglich deiner letzten Aussage, dass JavaScript Code dadurch kompiliertem C in nichts mehr nachsteht widersprechen.

Warum würdest Du? Mach's doch einfach und widersprich! Trau Dich!
Scherz beiseite: ich denke, die Entwickler bei Mozilla, Opera, Google, Apple und Microsoft, die sehen das inzwischen wohl ein wenig anders als Du, während sie über derzeitige und zukünftige Web-Applikationen und Apps aus der Cloud nachdenken und bei diesme Thema sehr geschäftig tun und entwickeln...
Ja, es gibt tolle und interessante Projekte

Ein weiteres interessantes Beispiel, das dieser Tage von sich reden macht:
geek.com: JavaScript decoder lets MP3s play in Firefox without Flash , jsmad - javascript mp3 decoder

In dem Ganzen ist durchaus Potential.
Bezueglich des Auslagerns von Berechnungen auf die GPU kommen auch interessante Zeiten auf uns zu. Microsoft hat bereits angekuendigt, dass man einen solchen Schritt nicht unterstuetzen werde, da man Sicherheitsbedenken habe jeder moeglichen Webanwendung Zugriff auf die Hardware zu geben.

Du solltest diese Äußerungen nicht allzu wörtlich nehmen, schließlich machen sie es auf andere Weise via ihrem eigenen Direct2D und Direct3D. Dass von Microsoft keine großen Lobreden bzgl. der zu ihnen in Konkurrenz stehenden WebGL/OpenGL-Technologie zu erwarten sind (egal, wie berechtigt oder unberechtigt, ein Teil der Kritik wird ja nicht nur von Microsoft alleine geäußert, sondern auch von anderen), dürfte auch klar sein. Allerdings sind die hinter WebGL und OpenGL stehenden Unternehmen (und das ist so quasi der ganze große Rest der etablierten großen Namen in der IT-Welt inklusive der Grafikkartenhersteller) alles keine Anfänger, die werden ihre Hausaufgaben schon recht gewissenhaft machen. Sollte es was zu verbessern geben, dann wird's halt eben verbessert, und fertig ist die Laube.
0
sierkb21.06.11 06:12
0x00:
[..]Microsoft hat bereits angekuendigt, dass man einen solchen Schritt nicht unterstuetzen werde, da man Sicherheitsbedenken habe jeder moeglichen Webanwendung Zugriff auf die Hardware zu geben.[..]

Und schon gibt's diesbzgl. nicht nur Widerspruch nicht nur aus der Ecke von Mozilla , sondern ausgerechnet auch noch aus den eigenen Reihen bei Microsoft und auch nicht von irgendwem:

The Register: Microsoft's WebGL claims bashed by own employee

Avi Bar-Zeev Blog (Microsoft): Why Microsoft and Internet Explorer need WebGL (and vice-versa)

Zu Avi Bar-Zeev:
([..]currently works at Microsoft as a Principal Architect, having helped pitch, design and prototype new products and experiences for Bing, Microsoft’s Startup Business Group, and XBox.)

Avi Bar-Zeev weiß also genau, worüber er spricht, er hat in dem Metier, um das es hier geht, also jahrelang Erfahrungen gesammelt auf diesem Gebiet. Innerhalb von Microsoft und außerhalb von Microsoft.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.