am 09.03.2005, um 14:09:36 +0100 mailte David Seidel folgendes:

Hallo Andreas,

Am Mittwoch, 9. März 2005 14:04 schrieb Andreas Kretschmer:

...

Fals jemand daran interesse hat, via Google gefunden:

ftp://ftp.sys.net.pl/Linux/AdbeRdr70

Der Link scheint nicht ganz richtig zu sein. Unter ftp://ftp.sys.net.pl/Linux/ findet man allerdings eine Datei "AdbeRdr70_linux_enu.0.beta1.tar.bz2" die

ACK.

Andreas

Josef Spillner schrieb:

Jaja die x86-Fraktion... wer den KPDF von KDE 3.4 noch nicht kennt, sollte ihn kennenlernen, damit er/sie weiß, woran sich Adobe messen lassen muß. Gerade bei PDFs möchte ich es mir nicht vorschreiben lassen, welche Teile ich rauskopieren darf, während Adobe fleißig DRM reinbaut.

Von DRM sollte man im Zusammenhang mit dem Adobe Reader[1] eher nicht sprechen :-) Letzten Endes sind die Benutzerrechte einer PDF-Datei etwa auf dem Niveau netter Empfehlungen; wenn man einmal das Lesepasswort hat, kann man auch drucken, kopieren, montieren usw.

Alle Diskussionen in de.comp.pdf sagen eigentlich aus: wenn jemand etwas Betrachtbares (Lesbares) schützen will (warum auch immer), ist PDF in der jetzigen Version nicht das richtige Mittel. Vielleicht können wir heute abend etwas dazu sagen, ich habe ein paar Folien zu einem PDF-Werkzeug vorbereitet.

Bringst Du ein Notebook mit dem KPDF von KDE 3.4 mit, damit man mal einen Blick darauf werfen kann?

Es ist problematisch, wie weit die Ersteller eines PDF-Readers gehen dürfen. Das Format ist zwar relativ offen, aber proprietär. Und die Verwendung ist durch gewisse Bestimmungen beschränkt. Soweit mir bekannt ist, müssen PDF-lesende Programme zumindest das user- und das owner-Passwort respektieren. Dass man nach Angabe des User-Passworts de facto alles mit dem Dokument machen kann, ist uns klar, aber vielen Windows- und Mac-Usern nicht.

Diverse Passwortknackprogramme zähle ich jetzt mal nicht zu den PDF- Anwendungen :-)

Auf den CLT war ja auch der xpdf-Fork ein großes Thema: http://poppler.freedesktop.org/

Wobei mir nicht ganz klar ist, warum es zu diesem Fork kam. Hast Du da nähere Informationen?

Stefan

.

[1] Seit der Version 6 legt Adobe Wert darauf, dass dieses Produkt nicht mehr das Wort "Acrobat" im Namen führt (Abgrenzung zwischen dem Reader und dem lizenzkostenpflichtigen Adobe Acrobat).

Am Mittwoch, 9. März 2005 15:27 schrieb Stefan Lagotzki:

Bringst Du ein Notebook mit dem KPDF von KDE 3.4 mit, damit man mal einen Blick darauf werfen kann?

Ja. Bis dahin bin ich noch beschäftigt, 'mkfs.dos' für PPC ganzzumachen... denn die damalige Umwandlung meines USB-Stick nach ext3 ging recht gut, aber so manch einer kann dieses Format nicht lesen, so dass ich eigentlich mal ganz gern wieder vfat drauf hätte.

Soweit mir bekannt ist, müssen PDF-lesende Programme zumindest das user- und das owner-Passwort respektieren. Dass man nach Angabe des User-Passworts de facto alles mit dem Dokument machen kann, ist uns klar, aber vielen Windows- und Mac-Usern nicht.

Die Beschränkungen gelten *nur*, wenn auch Adobe-Beispielcode aus der Spec verwendet wird. Noch gilt hier kein DMCA, der es einem verbieten würde, beliebige Bits und Bytes zu interpretieren.

...

http://poppler.freedesktop.org/

Wobei mir nicht ganz klar ist, warum es zu diesem Fork kam. Hast Du da nähere Informationen?

Der Code wird an vielen Stellen verwendet, nicht nur in den Anzeigeprogrammen, auch in CUPS etc. Bei einem Sicherheitsproblem (und derer gab es etliche in letzter Zeit) müssen all diese Programme aktualisiert werden. Daher ist es logisch, den Code in eine dynamische Bibliothek umzuwandeln, gegen die alle Programme linken. Das wollter der xpdf-Autor aber irgendwie nicht...

Josef

Am Dienstag, 15. März 2005 15:52 schrieb Hilmar Preusse:

...

Der Code wird an vielen Stellen verwendet, nicht nur in den Anzeigeprogrammen, auch in CUPS etc.

tetex-bin

Ahja, stimmt :)

Goil! Ist das schon End-User Ready? Lohnt es sich, bei Debian einen RTP-bug einzukippen?

Naja, es müssen jetzt erstmal die Patches integriert werden, die die einzelnen Projekte bisher hatten, gerade die von KPDF sind noch nicht drin. Aber die bisherige Funktionalität von xpdf sollte es auf alle Fälle schon haben.

Interessant ist sicherlich die Nutzung von fontconfig, so dass die lokal verfügbaren Schriften besser genutzt werden können, sofern keine direkt in die Dokumente eingebunden wurden. Die bisherigen Testanwendungen (die entweder Gtk+/splash oder Cairo nutzen) sind aber noch nicht so berauschend. Also abwarten + Tee trinken, würd ich mal sagen. Evince (der neue GNOME-PDF-Betrachter) ist momentan wohl der einziger, der es schon verwendet.

Josef

Am Mittwoch, 9. März 2005 15:57 schrieb Sebastian Hegler:

Wenn wir schon beim Thema sind: hat jemand ne Glaskugel, aus der ersichtlich ist, wann KDE 3.4 in Debian Sarge aufschlägt?

Ich denke da im Moment offiziell erst der RC1 erschienen ist, vermutet meine Glaskugel, dass das ganz wohl noch zwei-drei Monate dauern wird.

Wenn ich betrachte wie lange es gedauert hat bis KDE 3.3.x im sarge war, dann ist diese Schätzung wohl eher optimistisch.

Aber ich bin kein "Insider" und meine Glaskugel auch nicht. :-)

David

Josef Spillner wrote:

Olá rapaz,

Oi!

Wenn du testing+1 = etch meinst, nunja, nach dem Release von Sarge, also vielleicht gegen Mitte des Jahres.

Also das übliche Debian-Spiel, "Wir kriegen Sarge noch dieses Jahr fertig! Ganz bestimmt!"

Ich will doch nur nen halbwegs vernünftigen PDF-Betrachter! Acroread5 kann zwar alles darstellen, hat aber keine Mausrad-Unterstützung, Acroread7 auch nicht, und das neue GUI ist gewöhnungsbedürftig. xpdf versaut nach wie vor einige Transparenz-Effekte, genau wie kpdf aus KDE3.3. Und mit kpdf läßt sich nicht drucken, mit blackbox als Windowmanager. :(

MfG Sebastian