Hallo zusammen, ich wollte ein paar alte Bedienungsanleitungen wegwerfen - schließlich gibt es ja viele davon als PDF vom Hersteller, und auf dem PC sind sie aufgrund der schieren Anzahl besser zu finden als im Aktenschrank. Etliche Dateien sind allerdings riesig (12 MB für 2 Seiten schwarz-weiß): https://meters.uni-trend.com/download/ut210d-user-manual/ Okay - an der Passermarken kann man erkennen, dass die Datei mal für die Druckvorstufe gedacht war. Aber was ist daran so riesig? Und kann man das mit Hausmitteln kleiner bekommen? (Wenn ich die Papier-Version auf den Scanner lege, habe ich ca. 140 kB)
:
Bearbeitet durch User
Walter T. schrieb: > Etliche Dateien sind allerdings riesig (12 MB für 2 Seiten > schwarz-weiß): Wohl von Stümpern gescannt.
Walter T. schrieb: > (Wenn ich die Papier-Version auf den Scanner lege, habe ich ca. 140 kB) Als komprimierte Pixelgrafik mit begrenzter Auflösung Walter T. schrieb: > Aber was ist daran so riesig? Die Schriftarten sind eingebettet und Grafiken sind Vektorgrafiken. Diese Datei ist im Prinzip der Druck-Master in entsprechender Qualität. Walter T. schrieb: > Und kann man > das mit Hausmitteln kleiner bekommen? Gibt Online- und Offline-Tools, um PDF-Dateien zu komprimieren. Empfehlungen kann ich dir allerdings nicht aussprechen. H. H. schrieb: > Wohl von Stümpern gescannt. Gar nicht gescannt, sondern einfach unkomprimiert. Dadurch sind immerhin auch kleine Texte und Grafiken gut lesbar.
:
Bearbeitet durch User
Unwahrscheinlich. Das kommt irgendwo aus der Druckvorstufe. Der Scan eines fertig geschnittenen Dokuments sähe anders aus.
Moin, evtl. mit Ghostscript - so ausm Kopp raus - muss nicht exakt stimmen:
1 | gs -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=kleines.pdf grosses.pdf |
Gruss WK
Walter T. schrieb: > Und kann man das mit Hausmitteln kleiner bekommen? https://tools.pdf24.org/en/compress-pdf-v2
Walter T. schrieb: > Unwahrscheinlich. Das kommt irgendwo aus der Druckvorstufe. > > Der Scan eines fertig geschnittenen Dokuments sähe anders aus. Dann haben die wohl das dort übliche TIFF einfach ins PDF eingedost.
Sebastian R. schrieb: > Die Schriftarten sind eingebettet und Grafiken sind Vektorgrafiken. > Diese Datei ist im Prinzip der Druck-Master in entsprechender Qualität. Und warum soll daß dann 12MB ergeben? Solch riesige Dateien gibt eigentlich nur, wenn das im pdf einfach eingebettet gescannte Images von Papieroriginalen sind. Nix Vector, keine Schriften, keine Texte, nur ein TIFF o.ä. Oliver
Oliver S. schrieb: > Solch riesige Dateien gibt eigentlich nur, wenn das im pdf einfach > eingebettet gescannte Images von Papieroriginalen sind. Nix Vector, > keine Schriften, keine Texte, nur ein TIFF o.ä. Es sind keine Images. Das Dokument ist frei verfügbar. Du darfst gerne deine forensische Analyse dazu vorstellen.
Walter T. schrieb: > Okay - an der Passermarken kann man erkennen, dass die Datei mal für die > Druckvorstufe gedacht war. Aber was ist daran so riesig? Die Pixelgrafiken in Deinem PDF: Diagramme, Logos, Fotografien und so weiter. Monitore haben üblicherweise zwischen 72 und 100 dpi (dots per inch), in der Druckvorstufe sind 300 dpi üblich. Bei einer sechzehnfachen Menge an Rohdaten hilft auch die beste Komprimierung leider nur teilweise.
Walter T. schrieb: > Unwahrscheinlich. Das kommt irgendwo aus der Druckvorstufe. > Der Scan eines fertig geschnittenen Dokuments sähe anders aus. Die Antwort bezog sich natürlich auf eine Antwort davor, von Hinz. Es geht sogar noch extremer. Bedienungsanleitung für ein Fotostativ mit 113 MB. https://downloads.rollei.com/download/stativ-c5i/ Selbst wenn für jede Seite alle Schriftsätze und Farbtabellen eingebettet wären, würde das nicht die Größe erklären.
Mit Adobe Acrobat z.B. kann man die Größe reduzieren. Dann schrumpfen sie gewaltig. Ob das PDF24 auch kann habe ich noch nicht getestet.
Adobe Acrobat 9 habe ich schon probiert. Mit "gescannte Datei optimieren" wird alles grob gerastert, mit "Dateigröße verringern" wird das Dokument sogar größer. In die PDF-Container wird irgendetwas eingebettet sein, was die Größe erklärt. Das zu finden fehlt mir aber Werkzeug und Know-How. Bei PDF24 kommt übrigens ungefähr die gleiche Größe heraus, wie wenn man im Abcrobat auf einem PDF-Drucker ausdruckt.
:
Bearbeitet durch User
Sebastian R. schrieb: > Das Dokument ist frei verfügbar. Du darfst gerne > deine forensische Analyse dazu vorstellen. Enthält TIFF mit 2400dpi, und wurde von der Corel PDF Engine Ver. 14 verpackt. Stümper halt.
Dergute W. schrieb: > Moin, > > evtl. mit Ghostscript - so ausm Kopp raus - muss nicht exakt stimmen: > >
1 | gs -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=kleines.pdf |
2 | > grosses.pdf |
> > Gruss > WK Das wäre mein script:
1 | #!/bin/bash
|
2 | |
3 | gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=true -dColorImageDownsampleType=/Bicubic -dColorImageResolution=300 -dGrayImageDownsampleType=/Bicubic -dGrayImageResolution=300 -dMonoImageDownsampleType=/Bicubic -dMonoImageResolution=300 -sOutputFile="${1%.*}.compressed.pdf" "$1"; |
die 300dpi sind gewollt recht hoch... gerade bei /prepress könnte man weiter sparen. damit kommen aber schöne PDFs raus die eine erträgliche größe haben. Update... von 11,9MB wirds damit 3,7MB Groß... da ginge sicher noch viel mehr - mit dem preset ist das aber selbst beim zoom am pc noch scharf... und das ist mir bei dem script wichtig. 73
:
Bearbeitet durch User
Walter T. schrieb: > Adobe Acrobat 9 habe ich schon probiert. > > Mit "gescannte Datei optimieren" wird alles grob gerastert, mit > "Dateigröße verringern" wird das Dokument sogar größer. Mit Acrobat PDF Drucker in ein File drucken - schwarzweiss und 150 DPI einstellen - reduziert die Grösse auf 2.2 MB.
Sieh an. Es sind keine Schriften eingebettet. Es sind viele, viele Kurven. Ein Bitmap ist auch eingebettet. Mal sehen, ob ich das isoliert bekomme. Ich korrigiere: Es ist Arial eingebettet. Wird aber nur für die Kopfzeile genutzt. Das ganze Ding ist eine sehr feine Vektorgrafik.
:
Bearbeitet durch User
Danke, das hatte ich schon gefunden. Es geht mir mehr um die Problemursache als um die Anleitung selbst. Wie ich ja schon im Eröffnungsbeitrag schrieb: Die Anleitung habe ich jetzt einfach gescannt und mit 140 kB achiviert.
Walter T. schrieb: > s sind keine Schriften eingebettet. Doch. Eine. Für die Seitenheader P/N: 110401105246X MAY.2018 REV. 1 Das ist auch der gesamte Text, der in dem pdf steckt. Dazu dann noch 9 kleine png-Images mit in paar kB. Der ganze Rest sind Images, die im Background stecken. Oliver
Walter T. schrieb: > Etliche Dateien sind allerdings riesig (12 MB für 2 Seiten > schwarz-weiß): Schrecklich, das sind ja 9 Disketten! Oder heutzutage ungefähr 0,0000004 Festplatten.
H. H. schrieb: > Enthält TIFF mit 2400dpi, und wurde von der Corel PDF Engine Ver. 14 > verpackt. Das größte Pixel-Bild hat 56x32 Pixel. Das macht den Helmut nicht fett.
> Sieh an. Es sind keine Schriften eingebettet.
Doch. ArialMT ohne Subsetting. Komprimiert 19384 Bytes.
Es ist auch noch ein ICC-Profil mit komprimiert 225508 Bytes drin.
Ein T. schrieb: > Die Pixelgrafiken in Deinem PDF: Diagramme, Logos, Fotografien und so > weiter. Monitore haben üblicherweise zwischen 72 und 100 dpi (dots per > inch), in der Druckvorstufe sind 300 dpi üblich. Bei einer > sechzehnfachen Menge an Rohdaten hilft auch die beste Komprimierung > leider nur teilweise. Die Größe von mit geeignetem Verfahren komprimierten (echten) Bilder wächst etwa linear mit der Auflösung, nicht quadratisch.
Und dann sind da auch noch private Daten von Adobe Illustrator (page-piece dictionaries) drin. Bin zu faul, das aufzusummieren.
Wie liest Du das aus? Gibt es Werkzeuge, um PDF-Dateien als die Container zu betrachten, die sie sind?
Werkzeug: gibt es, z.B. https://docs.apryse.com/cli/guides/pdf-cosedit (das habe ich seit vielen Jahren nicht mehr verwendet, keine Ahnung, was daraus geworden ist). Zum "Warum so riesig": Vermutlich wurde das Dokument von Papier gescannt und dann mit Adobe Illustrator in Vektorgrafik verwandelt.
Zino schrieb: > Ein T. schrieb: >> [...] Bei einer sechzehnfachen Menge an Rohdaten [...] > > Die Größe von mit geeignetem Verfahren komprimierten (echten) Bilder > wächst etwa linear mit der Auflösung, nicht quadratisch. ROHDATEN, Superhirn.
Ein T. schrieb: > Zino schrieb: >> Ein T. schrieb: >>> [...] Bei einer sechzehnfachen Menge an Rohdaten [...] >> >> Die Größe von mit geeignetem Verfahren komprimierten (echten) Bilder >> wächst etwa linear mit der Auflösung, nicht quadratisch. > > ROHDATEN, Superhirn. Danke für das Kompliment! Allein, Deine Ahnungslosigkeit schmälert meine Freude daran ein wenig.
Ein T. schrieb: > Walter T. schrieb: >> Okay - an der Passermarken kann man erkennen, dass die Datei mal für die >> Druckvorstufe gedacht war. Aber was ist daran so riesig? > > Die Pixelgrafiken in Deinem PDF: Diagramme, Logos, Fotografien und so > weiter. Die Pixelgrafiken in diesem PDF sind, wie schon erwähnt, völlig belanglos, das sind nur ein paar Bytes. > Monitore haben üblicherweise zwischen 72 und 100 dpi (dots per > inch), in der Druckvorstufe sind 300 dpi üblich. Bei einer > sechzehnfachen Menge an Rohdaten hilft auch die beste Komprimierung > leider nur teilweise. Falsch. Hier geht es um Schwarz-Weiß-Text und -Zeichnungen. Wenn man die mit RLE komprimiert, wächst die Größe bei einer Vervierfachung der Auflösung etwa um Faktor 4, nicht Faktor 16. Daß die Rohdaten die 16fache Größe haben, ist belanglos. Die Anzahl der Farbwechsel pro Scanline bleibt gleich, unabhängig von der Auflösung. Es werden nur ein paar Bits mehr für Kodierung der Run Lengths gebraucht, da die Zahlen größer werden.
Walter T. schrieb: > Aber was ist daran so riesig? Ihr trolligen Menschen. Zoom doch einfach mal in Figure 6 rein und zähle wie viele Linien die Aufschrift auf dem Batteriedeckel hat.
Zino schrieb: > Zum "Warum so riesig": Vermutlich wurde das Dokument von Papier gescannt > und dann mit Adobe Illustrator in Vektorgrafik verwandelt. Schwachsinnige Vermutung. Sowas würden nur Trottel annehmen.
Zino schrieb: > Ein T. schrieb: >> ROHDATEN, Superhirn. > > Danke für das Kompliment! Allein, Deine Ahnungslosigkeit schmälert meine > Freude daran ein wenig. Da hatte ich Dich offenbar noch überschätzt. Kommt nicht wieder vor.
Re D. schrieb: > Walter T. schrieb: >> Aber was ist daran so riesig? > > Ihr trolligen Menschen. Zoom doch einfach mal in Figure 6 rein und zähle > wie viele Linien die Aufschrift auf dem Batteriedeckel hat. Du hast "Vektorgrafik" nicht verstanden. Da kannst Du beliebig weit (im Rahmen der Fähigkeiten Deines PDF-Anschauers) rein-zoomen und es kommen immer neue Scanlines hinzu.
Re D. schrieb: > Zino schrieb: >> Zum "Warum so riesig": Vermutlich wurde das Dokument von Papier gescannt >> und dann mit Adobe Illustrator in Vektorgrafik verwandelt. > > Schwachsinnige Vermutung. Sowas würden nur Trottel annehmen. Na dann biete mal eine bessere Erklärung für die forensischen Befunde. Ich bin gespannt.
Es gibt in der Tat eine alternative Erklärung, nämlich die, daß derjenige, der das Dokument mit Adobe Illustrator erstellte, alle Glyphe in Pfade hat umwandeln lassen.
Zino schrieb: > rein-zoomen und es kommen immer neue Scanlines hinzu. Nein, offensichtlich hast du es nicht verstanden.
Zino schrieb: > Es gibt in der Tat eine alternative Erklärung, nämlich die, daß > derjenige, der das Dokument mit Adobe Illustrator erstellte, alle Glyphe > in Pfade hat umwandeln lassen Das Dokument ist nicht gescannt. Das Dokument enthält Verktorgeafiken, die aus einen CAD exportiert wurden.
> Warum sind PDF-Dateien für Anleitungen so riesig?
Das weiß niemand.
Re D. schrieb: > Zino schrieb: >> Es gibt in der Tat eine alternative Erklärung, nämlich die, daß >> derjenige, der das Dokument mit Adobe Illustrator erstellte, alle Glyphe >> in Pfade hat umwandeln lassen > > Das Dokument ist nicht gescannt. Das Dokument enthält Verktorgeafiken, > die aus einen CAD exportiert wurden. Georg M. schrieb: >> Warum sind PDF-Dateien für Anleitungen so riesig? > > Das weiß niemand. Sorry, aber das ist doch schon im Ausgangpost vom TO erklärt worden. Walter T. schrieb: > Okay - an der Passermarken kann man erkennen, dass die Datei mal für die > Druckvorstufe gedacht war. Aber was ist daran so riesig? Und kann man > das mit Hausmitteln kleiner bekommen? Rastergrafiken macht man eben mindestens so hoch aufgelöst, wie es der Drucker kann. Hausmittel... für ghostscript habe ich oben mein Script hergezeigt, mit dem ich meine Messprotokolle schrumpfe. Da kommen Prüfaufbauten vom Handy fotografiert ins PDF und Ghostscript schrumpft die Auflösung dann passend zur tatsächlichen Größe im PDF. 73
Angehängte Dateien:
-
RY.png
17 KB
Re D. schrieb: > Zino schrieb: >> rein-zoomen und es kommen immer neue Scanlines hinzu. > > Nein, offensichtlich hast du es nicht verstanden. Da habe ich Trottel dich mißverstanden. Ich hatte herausgelesen, daß du behauptest, die Anzahl der Linien sei unbegrenzt. Daher mußte ich davon ausgehen daß du mit "Linie" eine "Scanline" meinst. Ich habe hier Software, die beliebig tief zoomen kann und auch den zugehörigen Quellcode aus dem Content Stream anzeigen kann, daher könnte ich die Linien exakt zählen, wenn ich wollte. Das war wohl mal dreidimensional, siehe Ausschnittsvergrößerung.
:
Bearbeitet durch User
Zino schrieb: > alle Glyphe > in Pfade hat umwandeln lassen. Man kann in dem Dokument nämlich keinen Text auswählen.
von Walter T. schrieb: >Aber was ist daran so riesig? Und kann man >das mit Hausmitteln kleiner bekommen? Ich habe eben mal ein Test gemacht, eine eingescannte Textseite als GIF gespeichert 444,1 kB. Dann diese Datei mit LibreOffice in PDF exportiert, hat dann eine Größe von 458,0 kB. Ist also nicht viel größer geworden. Eine Grafik ist dann in PDF immer noch eine Grafik. Pixel belegen eben viel Platz. Man muß daraus mit einer OCR-Software einen Text machen, dann wird weniger Speicherplatz belegt.
Armin K. schrieb: > Man kann in dem Dokument nämlich keinen Text auswählen. Doch kann man. Mit Nitro kann man den sogar bearbeiten.
Beitrag #8007682 wurde vom Autor gelöscht.
Günter L. schrieb: > Ich habe eben mal ein Test gemacht, eine eingescannte > Textseite als GIF gespeichert 444,1 kB. Dann diese Datei > mit LibreOffice in PDF exportiert, hat dann eine Größe > von 458,0 kB. Schön, hat mir den Problem aber nichts zu tun. Günter L. schrieb: > Pixel belegen eben viel Platz. Noch mehr Platz brauche ich, wenn ich "jedes Pixel per Vektorgrafik" darstelle. > Man muß daraus mit einer > OCR-Software einen Text machen, dann wird weniger > Speicherplatz belegt. Bei OCR in einem PDF werden die erkannten Buchstaben hinter dir Grafik gelegt. Das Ergebnis ist eine größere Datei.
:
Bearbeitet durch User
Günter L. schrieb: > Man muß daraus mit einer > OCR-Software einen Text machen, dann wird weniger > Speicherplatz belegt. Im Internet findet man Zeitschriften als pdf, z.B. die c't. Das Heft 3/2026 hat als durchsuchbares pdf 16.1 Mb und steht parallel mit 165.5 Mb da, wo alles als Bild umgewandelt wurde. Re D. schrieb: >> Man muß daraus mit einer >> OCR-Software einen Text machen, dann wird weniger >> Speicherplatz belegt. > > Bei OCR in einem PDF werden die erkannten Buchstaben hinter dir Grafik > gelegt. Das Ergebnis ist eine größere Datei. Blödsinn oder maximal dann, wenn der Erzeuger des pdf zu dämlich ist.
Statt jpg ein Bitmap kann auch beachtliche Größen einnehmen. Es gibt viele Möglichkeiten, ein pdf aufzublähen. Man kann z.B. auch Bilder verschiedener Größe einbinden oder eindampfen, exotische Schriftarten mitliefern usw. ...
Re D. schrieb: > Bei OCR in einem PDF werden die erkannten Buchstaben hinter dir Grafik > gelegt. Das Ergebnis ist eine größere Datei. Bei einem Byte pro Zeichen explodiert die Dateigröße dann natürlich extrem. Oliver
So viel Hass und Mist hier. Unfassbar.
Ich finde die Frage durchaus berechtigt und ich habe auch keine gute
Erklärung dafür.
Es sind keine großen Bitmaps oder Schriften eingebettet.
Wenn ich das einfach als PDF drucke, kommt ein 3.8 MB PDF raus. Auch Fig
6 sieht danach im extrem gezoomten Vergleich absolut gleich aus.
Mein Verdacht, dass da nichts deflate komprimiert wurde, hat sich nicht
bestätigt.
Klar kommt das aus der Druckvostufe, da spielt das keine Rolle. Ja es
waren Stümper, die das so ins Netz gestellt haben. Aber die Frage
warum also "technisch warum" ist damit nicht beantwortet.
> Und dann sind da auch noch private Daten von Adobe Illustrator
(page-piece dictionaries) drin. Bin zu faul, das aufzusummieren.
Das wäre durchaus interessant, wie groß die sind...
edit Kann natürlich sein, dass alle Koordinaten im Original mit 20
Nachkommastellen gespeichert wurden und bei mir nach dem Druck nur noch
8 da sind... hinter den deflate streams ist doch reiner Text oder?
:
Bearbeitet durch User
Angehängte Dateien:
-
warMuster12GB.jpg
24 KB
Walter T. schrieb: > allerdings riesig (12 MB für 2 Seiten Habe diese Datei kurz getestet. Es waren wirklich 12 MB, die sich kaum durch 7z verkleinern ließen. Also bereits komprimierte Daten, erstellt mit Corel PDF Engine Version 14.0.0.701. Wahrscheinlich wirklich für Druck od. andere großflächige Messeanwendungen? Sorry, kleiner Tippfehler im Bild. MB!
:
Bearbeitet durch User
Manfred P. schrieb: > Blödsinn oder maximal dann, wenn der Erzeuger des pdf zu dämlich ist. Ach ja, dann nehme dich mal das Programm, das bei OCR den Bildinhalt entfernt und durch Text ersetzt. Wie sieht das dann aus bei Fehlerkennung? Ich glaube, da spricht ein Blinder von Farben.
Oliver S. schrieb: > Re D. schrieb: >> Bei OCR in einem PDF werden die erkannten Buchstaben hinter dir Grafik >> gelegt. Das Ergebnis ist eine größere Datei. > > Bei einem Byte pro Zeichen explodiert die Dateigröße dann natürlich > extrem. > Oliver Was an größer verstehst du nicht? Niemand außer dir spricht von explodieren. Und 1 Byte pro Zeichen ist ein bisschen wenig oder lebst du in der IT-Steinzeit?
Mathias M. schrieb: > Es sind keine großen Bitmaps oder Schriften eingebettet. Nein, es sind die aus CAD exportierten Vektordaten.
Angesichts von Terrabyte-Platten und DSL-Flatraten sind 12 MB doch Pinnuts! Mir sind große PDFs bei denen Details sichtbar sind lieber, als zu tode komprimierte Pixel-Matschhaufen. Old-Papa
Re D. schrieb: >> Bei einem Byte pro Zeichen explodiert die Dateigröße dann natürlich >> extrem. >> Oliver > > Was an größer verstehst du nicht? Hier in diesem Thread gehts um mehrer MB. Was interessiert da Kleimkram? Niemand außer dir spricht von > explodieren. Und 1 Byte pro Zeichen ist ein bisschen wenig oder lebst du > in der IT-Steinzeit? Mach mal eine statistische Analyse der Texte in englischsprachigen pdfs, um die es hier geht. Was meinst du wohl, was da als Durchschnittsbytegröße pro Zeichen rauskommt. UTF8 ist halt erst einmal ASCII, und die paar Sonderzeichen, die mehr als ein Byte brauchen, gehen in der Masse unter. Oliver
Oliver S. schrieb: > Hier in diesem Thread gehts um mehrer MB. Was interessiert da Kleimkram? > Niemand außer dir spricht von Gott schmeiß Hirn. Die Aussage war: Günter L. schrieb: > Man muß daraus mit einer > OCR-Software einen Text machen, dann wird weniger > Speicherplatz belegt. Diese Aussage ist einfach falsch. Und du reißt Sachen aus dem Zusammenhang und merkst es nicht.
Oliver S. schrieb: > UTF8 ist halt erst einmal ASCII, und die paar Sonderzeichen, die mehr > als ein Byte brauchen, gehen in der Masse unter. Die Aussage ist auch einfach falsch. Braucht man nicht Diskutieren. Die Ursache habe ich ganz oben erläutert, aber Oliver labert trotzdem weiter Quak.
An den TO: Besorge er sich eine Demo-Version von Adobe Acrobat Pro oder Callas PDF Toolbox. Damit kann man das PDF techisch bis ins Detail sezieren und du erfährst, warum das so groß ist. https://www.adobe.com/de/acrobat/free-trial-download.html https://hilfe.callassoftware.com PDF ist ein objektorienterter hierarchisch aufgebauter Container, der Fonts, ICC-Farbprofile, Texte, Vektor- und Pixelgrafik u.v.a enthalten kann. Meist sind übermäßig hoch aufgelöste oder verrauschte Pixelgrafiken der Übeltäter, wenn die Datei zu groß wird. Aber: PDF bettet Pixelgrafiken nicht einfach im Originalformat ein, sondern wandelt sie beim Import in einen eigenen Datenstrom mit ZIP- oder JPEG-Kompression um. Der "Kompressions-Erfolg" hängt in hohem Maße von der Entropie ab und die wird bei Bilden maßgeblich vom Rauschen beeinflusst. D.h. ein verrausches Bild lässt sich deutlich schlechter komprimieren als ein "glattes", was z.B. bei optimalen Lichtverhältnissen erstellt wurde ...
Re D. schrieb: > Oliver S. schrieb: >> UTF8 ist halt erst einmal ASCII, und die paar Sonderzeichen, die mehr >> als ein Byte brauchen, gehen in der Masse unter. > > Die Aussage ist auch einfach falsch. Braucht man nicht Diskutieren. > > Die Ursache habe ich ganz oben erläutert, aber Oliver labert trotzdem > weiter Quak. Nein, sie ist nicht (komplett) falsch. UTF-8 heisst so, weil die Standardzeichen mit 8 Bit codiert werden, wie bei ASCII. Lediglich den Sonderzeichen werden quasi "Umschaltcodes" vorangestellt. Dass sieht man z.B daran, dass wenn man mal Text in UTF-8-Codierung als ASCII öffnet, alle Zeichen, ausser den Sonderzeichen, ganz normal zu lesen sind. Anstelle der Sonderzeichen sieht man immer zwei "Kryptos", den Umschalt-Code und den Code für das eigentliche Zeichen, die im ASCII-Umfeld natürlich "befremdlich" aussehen ...
:
Bearbeitet durch User
Frank E. schrieb: > Nein, sie ist nicht (komplett) falsch. UTF-8 heisst so, weil die > Standardzeichen mit 8 Bit codiert werden, wie bei ASCII Es ist falsch, da in dem Dokument u.a. chinesische Zeichen sind. Was soll dieses schwachsinnige diskutieren? Dabei war fast im Tor? War er aber nicht! Ende.
Frank E. schrieb: > PDF bettet Pixelgrafiken Es geht im vorliegenden Fall aber nicht um Pixelgrafik, es geht um Vektorgrafik. Und die Vektorgrafik hat sehr viele Vektoren.
Oliver S. schrieb: > Mach mal eine statistische Analyse der Texte in englischsprachigen pdfs, > um die es hier geht. Was meinst du wohl, was da als > Durchschnittsbytegröße pro Zeichen rauskommt. UTF8 ist halt erst einmal > ASCII, und die paar Sonderzeichen, die mehr als ein Byte brauchen, gehen > in der Masse unter. Das Dokument, um das es hier geht, ist aber PDF 1.6, da kann UTF-8 gar nicht verwendet werden. Wohl aber UTF-16.
Frank E. schrieb: > Nein, sie ist nicht (komplett) falsch. UTF-8 heisst so, weil die > Standardzeichen mit 8 Bit codiert werden, wie bei ASCII. Lediglich den > Sonderzeichen werden quasi "Umschaltcodes" vorangestellt. Nein, in UTF-8 gibt es weder "Umschaltcodes" noch quasi solche. Shift-JIS hingegen hat Umschaltcodes (nicht nur quasi) und kann schon länger in PDF verwendet werden. Ist aber zugunsten von UTF-16 aus der Mode gekommen. UTF-8 geht seit PDF 2.0.
:
Bearbeitet durch User
Re D. schrieb: > Es geht im vorliegenden Fall aber nicht um Pixelgrafik, es geht um > Vektorgrafik. Und die Vektorgrafik hat sehr viele Vektoren. Hat sie das? Ich habe auf der Arbeit pdfs mit „sehr vielen“ Vektoren. Das sind umgewandelte 2D-CAD-Zeichnungen, wofür der Konverter halt Murks ist. Das „sehr viele“ erkennt man daran, daß der Bildaufbau im Acrobat Reader erkennbar lange dauert. Man kann dem Aufbau des Bildes Linie für Linie zuschauen. Die Datei des TO hat nur ein paar Vektoren. Oliver
Oliver S. schrieb: > Re D. schrieb: >> Es geht im vorliegenden Fall aber nicht um Pixelgrafik, es geht um >> Vektorgrafik. Und die Vektorgrafik hat sehr viele Vektoren. > > Hat sie das? Wenn ich mich recht erinniere (ich habe gerade keinen Zugriff aufs Werkzeug): allein die zweite Seite hat etwa 450000 Pfade, wobei jeder Pfad aus mehreren Vektoren und Bögen besteht. Vielleicht täuscht die Erinnerung und es sind "nur" 45000. Morgen kann ich genau nachschauen.
Oliver S. schrieb: > Die Datei des TO hat nur ein paar Vektoren. > Oliver Oh bitte, extrahiere doch mal den Datenstream und laber nicht rum. Wo die zu finden sind im pdf habe ich auch schon beschreiben. Hättest du es verstanden, hättest du nicht den dummen 2d Vergleich gebracht.
Natürlich trog mein Gedächtnis. Habe nachgezählt: Für beide Seiten zusammen 134671 l-Operatoren (lineto),184168 c-Operatoren (curveto) und 3223 re-Operatoren (Rechtecke). Dazu kommen möglicherweise ein paar lineto, die durch das Schließen der Pfade durch Fülloperatoren entstehen. Man kann übrigens recht einfach mit pdftk die Streams einer PDF-Datei dekomprimieren, dann kann man mit einem gewöhnlichen Texteditor nachsehen.
Günter L. schrieb: > Ich habe eben mal ein Test gemacht, eine eingescannte Textseite als GIF > gespeichert 444,1 kB. Dann diese Datei mit LibreOffice in PDF exportiert, > hat dann eine Größe von 458,0 kB. Ist also nicht viel größer geworden. Wenn man schon beim Einscannen solche banalen Fehler macht, weil man nicht weiß für was GIF-Dateien gedacht sind, oder welchen Platz die ggn. über TIFF oder PNG brauchen, dann kann man alles weitere von dir probierte unter den gleichen Status Bastelei durch Versuch und Irrung einstufen. Text als Bild in eine PDF- oder Word-Datei ist schon mal Nonsens hoch 5, wenn man sie nicht gleich mit OCR Texterkennung einscannt. Noch dazu scannt man das mit extra Einstellungen am Gerät auf sw/ws Text und nicht als Bild, bei ca. 450 kB Dateigröße für 1 Seite ohne Grafik war das welche Auflösung? Wenn man so eine Zeitschrift wie die c't mit über mehr als 50 Seiten so scannen würde, wären das schon ohne Bilder dann 25 MB. Den Test kannst du damit also vergessen, ich habe eine A4 TextSeite mit ca. 45 kB in png in ein OO-Writer-Dokument eingefügt als Bild, da war diese Datei dann ca 62 kB groß, durch Umwandeln oder Exportieren in ein pdf dann aber nur noch 35 kB. Ob das Sinn macht sei dahingestellt, man kann darin dann nicht mehr nach Wörtern suchen. Bilder kann man aber auch gleich über die Druckfunktion in ein PDF umwandeln, auch wenn das wieder wenig Sinn macht, wie man ja hier im Forum oft erkennt. Zum eigentlichen Thema wird die Original-PDF-Datei wohl nicht mal zum Beschauen gebracht?
:
Bearbeitet durch User
Nevs schrieb: > Wenn man schon beim Einscannen solche banalen Fehler macht, weil man > nicht weiß für was GIF-Dateien gedacht sind, oder welchen Platz die ggn. > über TIFF oder PNG brauchen Was ost das für ein Schwachsinn? GIF ist die logische Weiterentwicklung von PNG und TIFF kann alles und nichts sein. Nevs schrieb: > Text als Bild in eine PDF Ost das Ergebniss, was 99 % aller Geräte bei scan to pdf standardmäßig liefern. Nevs schrieb: > Wenn man so eine Zeitschrift wie die c't mit über mehr als 50 Seiten so > scannen würde, wären das schon ohne Bilder dann 25 MB. Oh Gott, das wäre ja riesig 😱😱😱 Nevs schrieb: > Den Test kannst du damit also vergessen, ich habe eine A4 TextSeite mit > ca. 45 kB in png Toll, du hast herausgefunden, das schwarz/weiß Bilder nur 1 Bit pro Pixel brauchen und dich super komprimieren lassen Nevs schrieb: > Noch dazu scannt man das mit extra Einstellungen am Gerät auf sw/ws Text > und nicht als Bild, Was wäre im Ergebnis der Unterschied, wenn man als sw-Bild scannen würde? Nevs schrieb: > Bilder kann man aber auch gleich über die Druckfunktion in ein PDF > umwandeln, Die richtige Formulierung wäre wohl ehr einbetten. Nevs schrieb: > Zum eigentlichen Thema wird die Original-PDF-Datei wohl nicht mal zum > Beschauen gebracht? Was?
Re D. schrieb: > Was ost das für ein Schwachsinn? GIF ist die logische Weiterentwicklung > von PNG und TIFF kann alles und nichts sein. Nein, GIF ist keine Weiterentwiclung von PNG. Schon gar keine logische. PNG entstand lange nach GIF. Ich werde mich nicht auf dein Niveau hinabbegeben und daher diese Gelegenheit nicht für eine Retourkutsche für eine deiner obigen Beleidungen benutzen.
PDF-Dateien. Ein Thema, bei dem die Emotionen hochkochen. Am Samstagabend.
von Nevs schrieb: >Text als Bild in eine PDF- oder Word-Datei ist schon mal Nonsens hoch 5, >wenn man sie nicht gleich mit OCR Texterkennung einscannt. Muß man nicht. Nicht jeder hat einen Scanner mit OCR wenn der schon etwas älter ist. Und wenn man keine OCR-Software auf seinen Computer hat, gibt es auch noch Online-OCR. https://www.onlineocr.net/de/ Eine Buchseite in GIF eingescannt, 436 kB. Dann mit OnlineOCR in TXT umgewandelt 5,6kB. Dann nachbearbeiten, ab und zu sind mal ein paar Buchstaben bei, die nicht richtig erkannt wurden. Dann nachbearbeiten mit LibreOffice, Schriftbild, Fettdruckzeilen, Kursiveschriftzeilen, daß macht ja OCR auch nicht. Ich weis nicht, ob es schon OCR-Software gibt, die sowas kann. Dann exportieren in PDF, 16,2kB. Vielleicht auch noch in ODT speichern, 24 kB. Also es ist möglich PDF-Dateien selber anzufertigen, die nicht riesig sind.
Günter L. schrieb: > Muß man nicht. Nicht jeder hat einen Scanner mit OCR Wieso lese ich immer OCR? Ich gehe doch davon aus, dass der Ersteller eines pdfs die Quellen als Text besitzt. Günter L. schrieb: > Also es ist möglich PDF-Dateien selber anzufertigen, > die nicht riesig sind. Wie immer: Nur, wenn der Ersteller seinen Job versteht und auf die Datenmenge achtet.
Zino schrieb: > Re D. schrieb: >> Was ost das für ein Schwachsinn? GIF ist die logische Weiterentwicklung >> von PNG und TIFF kann alles und nichts sein. > > Nein, GIF ist keine Weiterentwiclung von PNG. Schon gar keine logische. > PNG entstand lange nach GIF. Entschuldige, ich habe es falsch herum getippt. PNG ist die logische Weiterentwicklung von GIF.
Günter L. schrieb: > Eine Buchseite in GIF eingescannt, 436 kB. > Dann mit OnlineOCR in TXT umgewandelt 5,6kB. > Dann nachbearbeiten, ab und zu sind mal ein paar > Buchstaben bei, die nicht richtig erkannt wurden. > Dann nachbearbeiten mit LibreOffice, Schriftbild, > Fettdruckzeilen, Kursiveschriftzeilen, daß macht > ja OCR auch nicht. Wieviel € müsste ein MB Speicher kosten, dass sich der Aufwand für einen Westeuropäer lohnen könnte?
Günter L. schrieb: > Dann exportieren in PDF, 16,2kB. > Vielleicht auch noch in ODT speichern, 24 kB. > Also es ist möglich PDF-Dateien selber anzufertigen, > die nicht riesig sind. Warum nicht gleich abtippen? Geht bestimmt schneller.
Manfred P. schrieb: > Wie immer: Nur, wenn der Ersteller seinen Job versteht und auf die > Datenmenge achtet. Die wenigsten Ersteller von PDF werden umgekehrt proportional zur Datenmenge bezahlt. Das PDF wurde offensichtlich für den Austausch mit der Druckerei erzeugt und für Leute die den Druck verlegt haben online gestellt.
von Re D. schrieb: >Wieviel € müsste ein MB Speicher kosten, dass sich der Aufwand für einen >Westeuropäer lohnen könnte? Manchmal kommt man um den Aufwand nicht drum rum, auch wenn die MB noch so billig sind. Zum Beispiel wenn man mit ältere Mikrocontroller experimentiert und die Assemblerprogramme aus Zeitschriften braucht. Der Assembler kann mit GIF TIF und PNG nichts anfangen, der braucht TXT.
:
Bearbeitet durch User
Günter L. schrieb: > Zum Beispiel wenn > man mit ältere Mikrocontroller experimentiert und > die Assemblerprogramme aus Zeitschriften braucht. Der braucht ein minimal kleines pdf mit korrektem Satz von kursiv und fett? Ich glaube nicht. Da reicht es das PDF in Graustufen zu scannen und OCR drüber laufen zu lassen. Am besten macht das sicher die KI und nicht Writer oder Word.
Zino schrieb: > Shift-JIS hingegen hat Umschaltcodes (nicht nur quasi) und kann schon > länger in PDF verwendet werden. Ist aber zugunsten von UTF-16 aus der > Mode gekommen. UTF-8 geht seit PDF 2.0. Ich hab gerade mal geguckt, wie bei mir die Zeichen codiert werden... keine Ahnung wie, aber bei PDF1.5 wird bei mir nur 1 Byte pro (normalem) Zeichen verwendet. ä wird dagegen z.B. als \344 kodiert. War jetzt der Export von Inkscape (PDF 1.5). Scribus ... keine Ahnung. Ich finde den Text im (dekomprimierten) PDF nicht wieder. Der Drucken Dialog in Firefox speichert ASCII Buchstaben auch mit einem Byte (PDF 1.7). Weil Text eigentlich immer als FlateDecode stream gespeichert wird, sind real also durchaus <1 Byte pro Zeichen möglich. Wahrscheinlich sind es meistens aber dennoch mehr, weil noch viel drumherum mitgespeichert wird. Positionierung, Kerning und so. Nur in absoluten Trivialfällen konnte ich <=1 Byte pro extra Zeichen hinbekommen. Hans W. schrieb: > Das wäre mein script: > #!/bin/bash > gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite > -dCompatibilityLevel=1.7 -dPDFSETTINGS=/prepress -dEmbedAllFonts=true > -dSubsetFonts=true -dColorImageDownsampleType=/Bicubic > -dColorImageResolution=300 -dGrayImageDownsampleType=/Bicubic > -dGrayImageResolution=300 -dMonoImageDownsampleType=/Bicubic > -dMonoImageResolution=300 -sOutputFile="${1%.*}.compressed.pdf" "$1"; Das produziert bei mir ein ähnlich großes PDF (3.7MB) wie einfach als PDF drucken (3.6MB). Tatsächlich sind bei 10.000% Vergrößerung beim einfachen Drucken doch geringe Rundungsfehler sichtbar. Dein gs Befehl erzeugt ein PDF, das auch bei 10k% alle Linien noch exakt am gleichen Platz hat. Dennoch sind minimale Unterschiede im Antialiasing der Haarlinien sichtbar. Für mich ist die Frage immernoch nicht ganz beantwortet. Sind das jetzt 8MB praktisch unnütze Nachkommastellen oder woher kommt der Unterschied? edit Re D. schrieb: > Entschuldige, ich habe es falsch herum getippt. PNG ist die logische > Weiterentwicklung von GIF. Na ja auch nicht ganz. Animation fehlt (in den meisten Implementationen) und es gibt zwei konkurrierende Standards.
:
Bearbeitet durch User
Re D. schrieb: > Entschuldige, ich habe es falsch herum getippt. PNG ist die logische > Weiterentwicklung von GIF. Ahnungsloser Quark, Gif hat Fähigkeiten die PNG nicht hat, oder schon mal animierte Grafiken, also bewegte Bilder, als PNG gesehen? super Leuchte
Nevs schrieb: > Ahnungsloser Quark, Gif hat Fähigkeiten die PNG nicht hat, oder schon > mal animierte Grafiken, also bewegte Bilder, als PNG gesehen? super > Leuchte Na ja, es gibt durchaus APNG und MNG. APNG wird (entgegen meiner geradigen Aussage) inzwischen von 96% der Browser unterstützt.
Mathias M. schrieb: > es gibt durchaus APNG und MNG. APNG wird (entgegen meiner > geradigen Aussage) inzwischen von 96% der Browser unterstützt. Dann zeig mal bitte solche Bilddateien, die habe ich noch nirgends gesehen. Jpg wird nach pip in manchen Browsern geändert, die neuesten Bildformate sind webp, die können auch gif-Funktionen als bewegte Bildinhalte als wäre es ein Video.
Nevs schrieb: > Ahnungsloser Quark, Gif hat Fähigkeiten die PNG nicht hat, oder schon > mal animierte Grafiken, also bewegte Bilder, als PNG gesehen? super > Leuchte Du bist die Leuchte. Zu der Zeit als PNG entwickelt wurde, war es logisch für bewegte Bilder andere Formate zu nutzen. Du scheinst nicht zu wissen, dass sowohl PNG als auch GIF hauptsächlich Bilder darstellen. Und nach gleichen Prinzipien Arbeiten (Farbtabelle, verlustfreie Kompression arbeiten. Eigentor!
Mathias M. schrieb: > Na ja auch nicht ganz. Animation fehlt (in den meisten Implementationen) > und es gibt zwei konkurrierende Standards. Was meinst du mit zwei Standards? Animationen brauchte man zur Zeit von PNG nicht, das ist nur logisch dass es entfallen ist
Re D. schrieb: > Der braucht ein minimal kleines pdf mit korrektem Satz von kursiv und > fett? Ich glaube nicht. Da reicht es das PDF in Graustufen zu scannen > und OCR drüber laufen zu lassen. Am besten macht das sicher die KI und > nicht Writer oder Word. Was quasselst du eigentlich für einen Unsinn, ein pdf in einen µC reinladen? Das war es nun wonach man dich hier als unfähigen Troll einstufen kann.
Nevs schrieb: > Was quasselst du eigentlich für einen Unsinn, ein pdf in einen µC > reinladen? > Das war es nun wonach man dich hier als unfähigen Troll einstufen kann. Wie kommst du darauf, das jemand ein pdf in einen uC laden will? Steht für dich auf der TK-Pizza Folie entfernen?
Günter L. schrieb: > Eine Buchseite in GIF eingescannt, 436 kB. Mit tiff oder png hast du es nicht versucht, was dabei für Dateigrößen und Qualität dabei rumkommt? Bei Gif meckert doch schon Paint dass man das sich vorher überlegt > Beim Speichern in diesem Format kann es zum Verlust von Farbinformationen kommen < bei reinem Text eigentlich egal oder gar der Vorteil. Ich habe jetzt über Paint das PNG Text-Bild nach unter GIF gespeichert, da belegt es statt der 45 kB nun 68 kB, also kann es das nicht ganz sein. Das müsste man dann noch mal mit einem Scanner versuchen, das war aber glaube ich genau der Punkt warum man gif dafür nicht nimmt. Als Tiff Datei werden es auch wieder mehr, nämlich 58 kB.
Nevs schrieb: > Mit tiff oder png hast du es nicht versucht, was dabei für Dateigrößen > und Qualität dabei rumkommt? Qualität kommt das rum, was man vorher einstellt. Aber das blickst du scheinbar nicht. Es hat aber auch überhaupt nichts mit der ursprünglichen Fragestellung zu tun.
Nevs schrieb: > Dann zeig mal bitte solche Bilddateien, die habe ich noch nirgends > gesehen. Erster treffer: https://apng.onevcat.com/demo/ Selten sind die dennoch. > Jpg wird nach pip in manchen Browsern geändert, die neuesten Bildformate > sind webp, die können auch gif-Funktionen als bewegte Bildinhalte als > wäre es ein Video. webp ist lange nicht mehr das neueste. avif wird inzwischen von jedem Browser unterstützt. Jpeg-XL steht jetzt tatsächlich doch wieder vor der Tür. Re D. schrieb: > Was meinst du mit zwei Standards? Animationen brauchte man zur Zeit von > PNG nicht, das ist nur logisch dass es entfallen ist MNG wurde von der PNG Development group 2001 veröffentlicht, fand aber praktisch keinen Anklang. APNG wurde 2004 von Mozilla veröffentlicht und wird inzwischen in jedem Browser unterstützt.
Walter T. schrieb: > Wie ich ja schon im Eröffnungsbeitrag schrieb: Die Anleitung habe ich > jetzt einfach gescannt und mit 140 kB achiviert. Mal kurz überschlagen: Eine 1TB SSD kostet derzeit um 150 Euro. Macht 15ct pro GB. Durch das komprimieren von 12MB auf fast nix hast du also ca. 0,2ct gespart. Gratuliere.
:
Bearbeitet durch User
Die Größe von PDF-Dateien ist vor allem deshalb interessant, weil sie in die Ladezeit und Blätterdauer eingeht. Und in die Zeit, bis in einem Verzeichnis alle Thumbnails sichtbar sind; die einem helfen, die richtige Datei überhaupt zu finden.
:
Bearbeitet durch User
Walter T. schrieb: > Die Größe von PDF-Dateien ist vor allem deshalb interessant, weil sie in > die Ladezeit Eine bahnbrechende Entdeckung. Du solltest den Nobelpreis für Informatik bekommen! Walter T. schrieb: > Und in die Zeit, bis in einem Verzeichnis alle Thumbnails sichtbar sind; > die einem helfen, die richtige Datei überhaupt zu finden. Der PDFs nur mit Vorschaubildchen findet, dem ist wohl nicht mehr zu helfen.
Walter T. schrieb: > PDF-Dateien. Ein Thema, bei dem die Emotionen hochkochen. Am Samstagabend. Da war es aber erst Freitag, und noch dazu der 13.!Oder war bei dir schon Samstag? ;-)
Mathias M. schrieb: > Ich hab gerade mal geguckt, wie bei mir die Zeichen codiert werden... > keine Ahnung wie, aber bei PDF1.5 wird bei mir nur 1 Byte pro (normalem) > Zeichen verwendet. ä wird dagegen z.B. als \344 kodiert. War jetzt der > Export von Inkscape (PDF 1.5). 344 oktal für ä ist wahrscheinlich WinAnsiEncoding. Man kann aber in PDF fast beliebige Codierungen definieren, z.B. um naive Textextraktions-Software zu verwirren. Der Weg vom Zeichencode im Show String zum Glyphen in der Schrift ist ziemlich komplex.
Walter T. schrieb: > Die Größe von PDF-Dateien ist vor allem deshalb interessant, weil sie in > die Ladezeit und Blätterdauer eingeht. Dafür gibt es Linearized PDF. Damit kann z.B. die erste Seite angzeigt werden, bevor die ganze PDF-Datei heruntergeladen wurde. Auch sollte man es vermeiden, alle Objekte in einen einzigen großen Object Stream (einer für alle Seiten) zu packen. Das richtig zu machen, ist wichtiger als die reine Dateigröße.
Re D. schrieb: > Der PDFs nur mit Vorschaubildchen findet, dem ist wohl nicht mehr zu > helfen. Apropos Vorschaubildchen: Das Dokument, um das es hier geht, enthält RLE-komprimierte 8-Bit-Indexed-Vorschaubildchen, eines pro Seite. Die hatte ich bisher nicht explizit erwähnt, weil sie sehr klein sind (128x96 Pixel WIMRE). Die sind aber nur für Adobe Illustrator.
Mathias M. schrieb: > MNG wurde von der PNG Development group 2001 veröffentlicht, fand aber > praktisch keinen Anklang. APNG wurde 2004 von Mozilla veröffentlicht und > wird inzwischen in jedem Browser unterstützt. APNG ist seit ein paar Monaten offiziell in PNG drin. Zurück zum Thema: Hier noch zwei Werkzeuge zum Reinschauen in PDF: - PoDoFoBrowser - https://itextpdf.com/products/rups
Sebastian R. schrieb: > Gar nicht gescannt, sondern einfach unkomprimiert. Dadurch sind immerhin > auch kleine Texte und Grafiken gut lesbar. Wer sagt, dass ein verlustbehaftetes Kompressionsverfahren verwendet werden soll?
Bei einer Anleitung hatte ich gefühlte hundert Seiten an Warnhinweisen bevor die eigentliche Gerätebeschreibung und Bedienungsanleitung begann. Eine pdf kann sehr lange werden. Wenn bei einer Smartwatch die gedruckte Anleitung im Umfang eines Telefonbuches der Stadt München beigelegt werden müßte, jeder hier dem Gesetzgeber, der dies verlangt hätte, einen V....(gelöscht) zeigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.