Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Unnötige eingebettete Schriften entfernen, Codierung erhalten
364 views
Skip to first unread message
Tilmann Reh
Oct 20, 2015, 2:07:11 AM10/20/15
to
Guten Morgen,
ich bekomme immer wieder PDFs, bei denen unnötigerweise etliche
Schriften vollständig mit eingebettet sind - und die dadurch mehr als
zehnmal so groß sind wie sie sein müßten (einseitiger Text z.B. 175k
statt 16k).
Wenn ich diese Dateien mit PDFCreator "drucke", ohne die Schriften
einzubetten, ist der ganze Wasserkopf weg - aber dann werden im Dokument
anstelle der Umlaute irgendwelche anderen Zeichen angegeben - offenbar
verwenden die eingebetteten Schriften irgendwelche abweichenden
Zeichentabellen. :-(
In den Dokumenteigenschaften zeigt der Adobe Reader z.B. die Schriften
Arial und Arial Bold jeweils mit "Kodierung: Mitgeliefert", daneben aber
auch Arial Italic mit "Kodierung: Standard".
Gibt es eine (frei verfügbare) Möglichkeit, von den eingebetteten
Schriften nur die "unnötigen" Inhalte zu löschen oder die
"mitgelieferte" Codierung zu erhalten (oder auf "Standard" zu ändern")?
Ich weiß, daß das eigentlich an der Quelle am einfachsten behoben werden
könnte, aber darauf habe ich leider keinen Einfluß... :-(
Danke,
Tilmann
ich bekomme immer wieder PDFs, bei denen unnötigerweise etliche
Schriften vollständig mit eingebettet sind - und die dadurch mehr als
zehnmal so groß sind wie sie sein müßten (einseitiger Text z.B. 175k
statt 16k).
Wenn ich diese Dateien mit PDFCreator "drucke", ohne die Schriften
einzubetten, ist der ganze Wasserkopf weg - aber dann werden im Dokument
anstelle der Umlaute irgendwelche anderen Zeichen angegeben - offenbar
verwenden die eingebetteten Schriften irgendwelche abweichenden
Zeichentabellen. :-(
In den Dokumenteigenschaften zeigt der Adobe Reader z.B. die Schriften
Arial und Arial Bold jeweils mit "Kodierung: Mitgeliefert", daneben aber
auch Arial Italic mit "Kodierung: Standard".
Gibt es eine (frei verfügbare) Möglichkeit, von den eingebetteten
Schriften nur die "unnötigen" Inhalte zu löschen oder die
"mitgelieferte" Codierung zu erhalten (oder auf "Standard" zu ändern")?
Ich weiß, daß das eigentlich an der Quelle am einfachsten behoben werden
könnte, aber darauf habe ich leider keinen Einfluß... :-(
Danke,
Tilmann
tlvp
Oct 20, 2015, 3:06:43 PM10/20/15
to
angekommen ist ... :-) . Tschuess, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
Tilmann Reh
Oct 21, 2015, 2:00:42 AM10/21/15
to
tlvp schrieb:
> Anstatt mindestens froh zu sein dass es als Text und nicht als Grafik
> angekommen ist ... :-) . Tschuess, -- tlvp
Im Ernst: früher [tm] kamen diese Dokumente als Fax. Die PDFs aus
Fritz-Fax waren - trotz Vollgrafik - erheblich kleiner als die Bläh-PDFs
heute. (Und mit ca. 20k nur wenig größer als die geschrumpften PDFs.)
Ich bin trotzdem weiter an einer "optimalen" Lösung interessiert...
Tilmann
> Anstatt mindestens froh zu sein dass es als Text und nicht als Grafik
> angekommen ist ... :-) . Tschuess, -- tlvp
Fritz-Fax waren - trotz Vollgrafik - erheblich kleiner als die Bläh-PDFs
heute. (Und mit ca. 20k nur wenig größer als die geschrumpften PDFs.)
Ich bin trotzdem weiter an einer "optimalen" Lösung interessiert...
Tilmann
Wilfried
Oct 21, 2015, 8:37:34 AM10/21/15
to
Windows-System benutzt.
Hast Du mal PDF-XChange Editor ausprobiert?
Da gibt es einen Befehl
"Datei" "optimierte Kopie speichern"
und unter den Optionen gibt es
"Eingebettete Schriftarten entfernen" mit der Default-Einstellung, dass
nur die Standard-Schriftarten entfernt werden, die auf jedem System
vorhanden sein müssten, und - vielleicht für Dich interessant -:
"Schriftart-Teilmengen verschmelzen"
Eine Optimierung soll auch mit der Acrobat Vollversion (die ich nicht
habe und deshalb nicht ausprobieren kann) möglich sein, wenn man bei
"Speichern unter" den Dateityp "Adobe PDF Optimiert" (oder so ähnlich)
wählt.
Schließlich soll eine gewisse Optimierung auch mit Ghostscript möglich
sein, siehe
http://stackoverflow.com/questions/10450120/optimize-pdf-files-with-ghostscript-or-other
Zitat von vorgenannter Webseite:
gs \
-o output.pdf \
[...other options...] \
-dEmbedAllFonts=false \
-dSubsetFonts=true \
-dConvertCMYKImagesToRGB=true \
-dCompressFonts=true \
-c ".setpdfwrite <</AlwaysEmbed [ ]>> setdistillerparams" \
-c ".setpdfwrite <</NeverEmbed [/Courier /Courier-Bold /Courier-Oblique \
/Courier-BoldOblique /Helvetica /Helvetica-Bold /Helvetica-Oblique \
/Helvetica-BoldOblique /Times-Roman /Times-Bold /Times-Italic \
/Times-BoldItalic /Symbol /ZapfDingbats /Arial]>> setdistillerparams" \
-f input.pdf
Grüße
--
Wilfried Hennings
bitte in der Newsgruppe antworten, die Mailadresse ist ungültig
Tilmann Reh
Oct 22, 2015, 4:30:38 AM10/22/15
to
Wilfried schrieb:
> Aus den Header-Zeilen Deines Postings schließe ich dass Du ein
> Windows-System benutzt.
Richtig. Sorry, hätte ich erwähnen können.
> Hast Du mal PDF-XChange Editor ausprobiert?
> Da gibt es einen Befehl
> "Datei" "optimierte Kopie speichern"
> und unter den Optionen gibt es
> "Eingebettete Schriftarten entfernen" mit der Default-Einstellung, dass
> nur die Standard-Schriftarten entfernt werden, die auf jedem System
> vorhanden sein müssten, und - vielleicht für Dich interessant -:
> "Schriftart-Teilmengen verschmelzen"
Danke für den Hinweis - den hatte ich bisher noch nicht ausprobiert.
Allerdings:
- trotz ausdrücklicher Anweisung, die Schriften zu entfernen, sind sie
in der ausgegebenen Datei immer noch drin. :-(
- natürlich ist das "Optimieren" eine PRO-Funktion und damit nicht im
kostenlosen Funktionsumfang (OK, wenn sie wenigstens funktionieren
würde, könnte man trotzdem drüber nachdenken, das Programm ist ja
wenigstens nicht teuer).
Ich werde die vielleicht mal anmailen...
> Eine Optimierung soll auch mit der Acrobat Vollversion (die ich nicht
> habe und deshalb nicht ausprobieren kann) möglich sein, wenn man bei
> "Speichern unter" den Dateityp "Adobe PDF Optimiert" (oder so ähnlich)
> wählt.
Acrobat habe ich nicht - ist dafür auch etwas teuer...
> Schließlich soll eine gewisse Optimierung auch mit Ghostscript möglich
> sein, siehe
> http://stackoverflow.com/questions/10450120/optimize-pdf-files-with-ghostscript-or-other
Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
bricht dann ab.
Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
angegeben ist oder beide.
Lasse ich testhalber beide weg, läuft GS ohne Fehlermeldung durch und
bearbeitet laut Konsolenausgabe angeblich die eine Dokumentenseite, aber
ich finde anschließend nirgends die gewünschte Ausgabedatei (die ich
natürlich sicherheitshalber auch mit vollständigem Pfad angegeben habe).
Es ist zum fortlaufen. :-(
Danke trotzdem.
Tilmanm
> Aus den Header-Zeilen Deines Postings schließe ich dass Du ein
> Windows-System benutzt.
> Hast Du mal PDF-XChange Editor ausprobiert?
> Da gibt es einen Befehl
> "Datei" "optimierte Kopie speichern"
> und unter den Optionen gibt es
> "Eingebettete Schriftarten entfernen" mit der Default-Einstellung, dass
> nur die Standard-Schriftarten entfernt werden, die auf jedem System
> vorhanden sein müssten, und - vielleicht für Dich interessant -:
> "Schriftart-Teilmengen verschmelzen"
Allerdings:
- trotz ausdrücklicher Anweisung, die Schriften zu entfernen, sind sie
in der ausgegebenen Datei immer noch drin. :-(
- natürlich ist das "Optimieren" eine PRO-Funktion und damit nicht im
kostenlosen Funktionsumfang (OK, wenn sie wenigstens funktionieren
würde, könnte man trotzdem drüber nachdenken, das Programm ist ja
wenigstens nicht teuer).
Ich werde die vielleicht mal anmailen...
> Eine Optimierung soll auch mit der Acrobat Vollversion (die ich nicht
> habe und deshalb nicht ausprobieren kann) möglich sein, wenn man bei
> "Speichern unter" den Dateityp "Adobe PDF Optimiert" (oder so ähnlich)
> wählt.
> Schließlich soll eine gewisse Optimierung auch mit Ghostscript möglich
> sein, siehe
> http://stackoverflow.com/questions/10450120/optimize-pdf-files-with-ghostscript-or-other
zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
bricht dann ab.
Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
angegeben ist oder beide.
Lasse ich testhalber beide weg, läuft GS ohne Fehlermeldung durch und
bearbeitet laut Konsolenausgabe angeblich die eine Dokumentenseite, aber
ich finde anschließend nirgends die gewünschte Ausgabedatei (die ich
natürlich sicherheitshalber auch mit vollständigem Pfad angegeben habe).
Es ist zum fortlaufen. :-(
Danke trotzdem.
Tilmanm
Christian Zietz
Oct 23, 2015, 2:20:24 AM10/23/15
to
Tilmann Reh schrieb:
> Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
> zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
> bricht dann ab.
> Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
> angegeben ist oder beide.
Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
steht, eben nicht die anderen benötigten Optionen, insbesondere
-sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
*nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
der im Beispiel "[...other options...]" steht.
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
> Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
> zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
> bricht dann ab.
> Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
> angegeben ist oder beide.
steht, eben nicht die anderen benötigten Optionen, insbesondere
-sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
*nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
der im Beispiel "[...other options...]" steht.
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
Tilmann Reh
Oct 23, 2015, 3:09:40 AM10/23/15
to
Christian Zietz schrieb:
>> Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
>> zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
>> bricht dann ab.
>> Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
>> angegeben ist oder beide.
>
> Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
> steht, eben nicht die anderen benötigten Optionen, insbesondere
> -sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
> *nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
> der im Beispiel "[...other options...]" steht.
Ich ahnte nicht, daß eine an dieser Stelle zwingend notwendige Option
hier nicht genannt war - und dachte bei "other options" an Dinge, die
man "sonst noch so" hätte einstellen können.
Mit der Angabe von -sDEVICE=pdfwrite wird nun tatsächlich eine
Ausgabedatei erzeugt.
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
Reader als "Eingebettete Untergruppe", genau wie beim Original), obwohl
ich sie definitiv in der Never-Embed-Liste stehen habe. Allerdings
schrumpft die Datei von 174k auf 67k - die Größe ist aber bis aufs Byte
exakt gleich, egal ob die Arial-Schriften in der Never-Embed-Liste
stehen oder nicht...
dir:
> 20.10.2015 07:50 174.624 input.pdf
> 23.10.2015 08:40 67.926 output.pdf
pdffonts input.pdf:
> name type emb sub uni object ID
> ------------------------------------ ----------------- --- --- --- ---------
> AOEUOL+Arial CID TrueType yes yes yes 8 0
> IWUSEV+Arial,Bold CID TrueType yes yes yes 9 0
> RMHACJ+Arial,Italic CID TrueType yes yes yes 12 0
pdffonts output.pdf:
> name type emb sub uni object ID
> ------------------------------------ ----------------- --- --- --- ---------
> XMZYYF+Arial,Italic CID TrueType yes yes yes 22 0
> OWDJRV+Arial,Bold CID TrueType yes yes yes 18 0
> UHSVOA+Arial CID TrueType yes yes yes 14 0
Das ist wirklich alles merkwürdig. :-\
Tilmann
>> Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
>> zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
>> bricht dann ab.
>> Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
>> angegeben ist oder beide.
>
> Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
> steht, eben nicht die anderen benötigten Optionen, insbesondere
> -sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
> *nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
> der im Beispiel "[...other options...]" steht.
hier nicht genannt war - und dachte bei "other options" an Dinge, die
man "sonst noch so" hätte einstellen können.
Mit der Angabe von -sDEVICE=pdfwrite wird nun tatsächlich eine
Ausgabedatei erzeugt.
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
Reader als "Eingebettete Untergruppe", genau wie beim Original), obwohl
ich sie definitiv in der Never-Embed-Liste stehen habe. Allerdings
schrumpft die Datei von 174k auf 67k - die Größe ist aber bis aufs Byte
exakt gleich, egal ob die Arial-Schriften in der Never-Embed-Liste
stehen oder nicht...
dir:
> 20.10.2015 07:50 174.624 input.pdf
> 23.10.2015 08:40 67.926 output.pdf
pdffonts input.pdf:
> name type emb sub uni object ID
> ------------------------------------ ----------------- --- --- --- ---------
> AOEUOL+Arial CID TrueType yes yes yes 8 0
> IWUSEV+Arial,Bold CID TrueType yes yes yes 9 0
> RMHACJ+Arial,Italic CID TrueType yes yes yes 12 0
pdffonts output.pdf:
> name type emb sub uni object ID
> ------------------------------------ ----------------- --- --- --- ---------
> XMZYYF+Arial,Italic CID TrueType yes yes yes 22 0
> OWDJRV+Arial,Bold CID TrueType yes yes yes 18 0
> UHSVOA+Arial CID TrueType yes yes yes 14 0
Das ist wirklich alles merkwürdig. :-\
Tilmann
Tilmann Reh
Oct 23, 2015, 3:53:08 AM10/23/15
to
Christian Zietz schrieb:
>> Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
>> zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
>> bricht dann ab.
>> Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
>> angegeben ist oder beide.
>
> Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
> steht, eben nicht die anderen benötigten Optionen, insbesondere
> -sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
> *nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
> der im Beispiel "[...other options...]" steht.
Nachtrag: hier das aktuelle Batchfile:
> "c:\Program Files\gs\gs9.16\bin\gswin64c"^
> -o output.pdf^
> -sDEVICE=pdfwrite^
> -dEmbedAllFonts=false^
> -dSubsetFonts=true^
> -dConvertCMYKImagesToRGB=true^
> -dCompressFonts=true^
> -c ".setpdfwrite <</AlwaysEmbed [ ]>> setdistillerparams" ^
> -c ".setpdfwrite <</NeverEmbed [/Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique /Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique /Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic /Symbol /ZapfDingbats /Arial /Arial-Bold /Arial-Italic]>> setdistillerparams" ^
> -f input.pdf
Tilmann
>> Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
>> zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
>> bricht dann ab.
>> Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
>> angegeben ist oder beide.
>
> Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
> steht, eben nicht die anderen benötigten Optionen, insbesondere
> -sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
> *nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
> der im Beispiel "[...other options...]" steht.
> "c:\Program Files\gs\gs9.16\bin\gswin64c"^
> -o output.pdf^
> -sDEVICE=pdfwrite^
> -dEmbedAllFonts=false^
> -dSubsetFonts=true^
> -dConvertCMYKImagesToRGB=true^
> -dCompressFonts=true^
> -c ".setpdfwrite <</AlwaysEmbed [ ]>> setdistillerparams" ^
> -c ".setpdfwrite <</NeverEmbed [/Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique /Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique /Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic /Symbol /ZapfDingbats /Arial /Arial-Bold /Arial-Italic]>> setdistillerparams" ^
> -f input.pdf
Tilmann
Thomas Kaiser
Oct 23, 2015, 5:54:03 AM10/23/15
to
Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
Letzteres, dann deutet meine Frage jetzt evtl. schon auf die Problematik
-- Font-Subsetting, also Untergruppe nicht mit vollständigem sondern
benutzerdefiniertem Zeichenvorrat/-Encoding -- hin?
Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
vorher, weil die Glyphen-Zuordnung im Eimer ist.
Gruss,
Thomas
> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
> Reader als "Eingebettete Untergruppe", genau wie beim Original),
> obwohl ich sie definitiv in der Never-Embed-Liste stehen habe.
Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"? Falls
> Reader als "Eingebettete Untergruppe", genau wie beim Original),
> obwohl ich sie definitiv in der Never-Embed-Liste stehen habe.
Letzteres, dann deutet meine Frage jetzt evtl. schon auf die Problematik
-- Font-Subsetting, also Untergruppe nicht mit vollständigem sondern
benutzerdefiniertem Zeichenvorrat/-Encoding -- hin?
Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
vorher, weil die Glyphen-Zuordnung im Eimer ist.
Gruss,
Thomas
Tilmann Reh
Oct 23, 2015, 8:05:55 AM10/23/15
to
Thomas Kaiser schrieb:
> Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
>> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
>> Reader als "Eingebettete Untergruppe", genau wie beim Original),
>> obwohl ich sie definitiv in der Never-Embed-Liste stehen habe.
>
> Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
Das stand in dem Teil, den Du weggeschnitten hast...
Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
"Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
> Falls
> Letzteres, dann deutet meine Frage jetzt evtl. schon auf die Problematik
> -- Font-Subsetting, also Untergruppe nicht mit vollständigem sondern
> benutzerdefiniertem Zeichenvorrat/-Encoding -- hin?
>
> Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
> nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
> schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
> Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
> Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
> nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
> der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
> Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
> dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
> alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
> vorher, weil die Glyphen-Zuordnung im Eimer ist.
Näheres dazu hatte ich im OP geschrieben.
Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
oder Zuordnung. Nach dem vollständigen Entfernen der eingebetteten
Schriften ist der größte Teil des Textes einwandfrei, nur ein paar
Sonderzeichen und die Umlaute werden nicht mehr korrekt angezeigt -
stattdessen erscheinen irgendwelche anderen Zeichen.
Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
zurechtbiegen könnte - alternativ dürfen meinetwegen die paar nicht der
Standardcodierung entsprechenden Zeichen weiterhin als "eingebettete
Untergruppe" im Dokument bleiben. Aber eben nicht das ganze Alphabet in
drei verschiedenen Schriften.
Tilmann
> Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
>> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
>> Reader als "Eingebettete Untergruppe", genau wie beim Original),
>> obwohl ich sie definitiv in der Never-Embed-Liste stehen habe.
>
> Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
"Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
> Falls
> Letzteres, dann deutet meine Frage jetzt evtl. schon auf die Problematik
> -- Font-Subsetting, also Untergruppe nicht mit vollständigem sondern
> benutzerdefiniertem Zeichenvorrat/-Encoding -- hin?
>
> Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
> nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
> schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
> Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
> Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
> nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
> der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
> Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
> dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
> alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
> vorher, weil die Glyphen-Zuordnung im Eimer ist.
Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
oder Zuordnung. Nach dem vollständigen Entfernen der eingebetteten
Schriften ist der größte Teil des Textes einwandfrei, nur ein paar
Sonderzeichen und die Umlaute werden nicht mehr korrekt angezeigt -
stattdessen erscheinen irgendwelche anderen Zeichen.
Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
zurechtbiegen könnte - alternativ dürfen meinetwegen die paar nicht der
Standardcodierung entsprechenden Zeichen weiterhin als "eingebettete
Untergruppe" im Dokument bleiben. Aber eben nicht das ganze Alphabet in
drei verschiedenen Schriften.
Tilmann
Tilmann Reh
Oct 23, 2015, 8:50:45 AM10/23/15
to
Thomas Kaiser schrieb:
> Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
> nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
> schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
> Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
> Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
> nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
> der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
> Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
> dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
> alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
> vorher, weil die Glyphen-Zuordnung im Eimer ist.
Nachtrag:
ein solches fremdes Bläh-PDF zeigt im Adobe Reader unter Schriften:
Arial (Eingebettete Untergruppe)
Typ: TrueType (CID)
Kodierung: Identity-H
Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
nicht den tatsächlich benutzten.
Bei der mittels PDFCreator erzeugten kompakten Version ohne jede
eingebettete Schriften (aber mit kaputten Umlauten und Sonderzeichen) steht:
Arial
Typ: TrueType
Kodierung: Mitgeliefert
Originalschrift: ArialMT
Originalschrifttyp: TrueType
Ein von mir selbst mit pdfFactory erstelltes PDF ohne eingebettete
Schriften (völlig anderes Dokument natürlich) zeigt dagegen:
Arial
Typ: TrueType
Kodierung: Ansi
Originalschrift: ArialMT
Originalschrifttyp: TrueType
Es hat den Anschein, als ob das "Mitliefern" der Codierung der
eigentliche Knackpunkt ist bzw. dabei etwas schiefläuft.
Tilmann
> Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
> nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
> schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
> Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
> Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
> nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
> der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
> Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
> dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
> alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
> vorher, weil die Glyphen-Zuordnung im Eimer ist.
ein solches fremdes Bläh-PDF zeigt im Adobe Reader unter Schriften:
Arial (Eingebettete Untergruppe)
Typ: TrueType (CID)
Kodierung: Identity-H
Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
nicht den tatsächlich benutzten.
Bei der mittels PDFCreator erzeugten kompakten Version ohne jede
eingebettete Schriften (aber mit kaputten Umlauten und Sonderzeichen) steht:
Arial
Typ: TrueType
Kodierung: Mitgeliefert
Originalschrift: ArialMT
Originalschrifttyp: TrueType
Ein von mir selbst mit pdfFactory erstelltes PDF ohne eingebettete
Schriften (völlig anderes Dokument natürlich) zeigt dagegen:
Arial
Typ: TrueType
Kodierung: Ansi
Originalschrift: ArialMT
Originalschrifttyp: TrueType
Es hat den Anschein, als ob das "Mitliefern" der Codierung der
eigentliche Knackpunkt ist bzw. dabei etwas schiefläuft.
Tilmann
Thomas Kaiser
Oct 23, 2015, 9:55:32 AM10/23/15
to
Tilmann Reh schrieb in <news:n0d7n1$8c5$1...@dont-email.me>
nicht der Schriftname, der im PDF verwendet wurde.
> Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
> "Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
Und jetzt? Der Reader kennt halt auch die Konvention mancher PDF-
Erzeuger, wie die Font-Subsets benennen und zeigt nicht den
Originalnamen sondern den Namen des Fonts, auf dem das Subset basiert,
an.
> Näheres dazu hatte ich im OP geschrieben.
Na, dann.
> Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
> oder Zuordnung.
"Speziell"? Wie schon versucht zu erläutern gibt es diverse Standard-
Encodings und bei Untergruppen in jedem Fall Custom Encoding. Ich
verstehe ja nach wie vor nicht, warum Du so ein Gewese mit der Herkunft
der PDFs machst. Poste doch mal die Ausgabe von pdfinfo.exe -- aktuell
vermute ich stark, dass es bei Producer "Mac OS X ... Quartz PDFContext"
stehen dürfte (Font-Untergruppen, Truetype/CID und Unicode, wo's nur
irgend geht -- das riecht zumindest nach Apple)
> Nach dem vollständigen Entfernen der eingebetteten Schriften ist der
> größte Teil des Textes einwandfrei, nur ein paar Sonderzeichen und die
> Umlaute werden nicht mehr korrekt angezeigt - stattdessen erscheinen
> irgendwelche anderen Zeichen.
Ja mei, das klappt natürlich nicht, einen Zeichenvorrat, der in Unicode
beschrieben ist, als WinAnsi zu interpretieren.
> Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
> zurechtbiegen könnte
Die ist Standard. Weil weder Windows noch dort gebräuchliche und sehr
beschränkte Gammel-Encodings wie das dort übliche ANSI (basiert AFAIK
auf ANSI 1252) sind die _einzigen_ Standards. Es gibt durchaus zeit-
gemäße wie die auf Unicode basierenden.
Gruss,
Thomas
> Thomas Kaiser schrieb:
>
>> Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
>>> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut
>>> Adobe Reader als "Eingebettete Untergruppe", genau wie beim
>>> Original), obwohl ich sie definitiv in der Never-Embed-Liste stehen
>>> habe.
>>
>> Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
>
> Das stand in dem Teil, den Du weggeschnitten hast...
Ach ja, Dein "Nachtrag" mit der Kommandozeile. Da stand halt "Arial" und
>
>> Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
>>> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut
>>> Adobe Reader als "Eingebettete Untergruppe", genau wie beim
>>> Original), obwohl ich sie definitiv in der Never-Embed-Liste stehen
>>> habe.
>>
>> Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
>
> Das stand in dem Teil, den Du weggeschnitten hast...
nicht der Schriftname, der im PDF verwendet wurde.
> Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
> "Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
Erzeuger, wie die Font-Subsets benennen und zeigt nicht den
Originalnamen sondern den Namen des Fonts, auf dem das Subset basiert,
an.
> Näheres dazu hatte ich im OP geschrieben.
> Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
> oder Zuordnung.
Encodings und bei Untergruppen in jedem Fall Custom Encoding. Ich
verstehe ja nach wie vor nicht, warum Du so ein Gewese mit der Herkunft
der PDFs machst. Poste doch mal die Ausgabe von pdfinfo.exe -- aktuell
vermute ich stark, dass es bei Producer "Mac OS X ... Quartz PDFContext"
stehen dürfte (Font-Untergruppen, Truetype/CID und Unicode, wo's nur
irgend geht -- das riecht zumindest nach Apple)
> Nach dem vollständigen Entfernen der eingebetteten Schriften ist der
> größte Teil des Textes einwandfrei, nur ein paar Sonderzeichen und die
> Umlaute werden nicht mehr korrekt angezeigt - stattdessen erscheinen
> irgendwelche anderen Zeichen.
beschrieben ist, als WinAnsi zu interpretieren.
> Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
> zurechtbiegen könnte
beschränkte Gammel-Encodings wie das dort übliche ANSI (basiert AFAIK
auf ANSI 1252) sind die _einzigen_ Standards. Es gibt durchaus zeit-
gemäße wie die auf Unicode basierenden.
Gruss,
Thomas
Thomas Kaiser
Oct 23, 2015, 10:07:30 AM10/23/15
to
Tilmann Reh schrieb in <news:n0dab4$ju9$1...@dont-email.me>
dort das PDF geöffnet, bist in die Preflight-Funktion rein und dort
schön versteckt in den PDF-Objektbrowser? Oder wie kommst Du auf die
Idee, GS hätte an den Schriften rumgemacht? Bzw. woher willst Du wissen,
_was konkret_ im PDF jetzt weniger Platz verbraucht?
Ich würde ja eher zu MuPDF <http://mupdf.com/docs/> greifen. Zumindest
haben mir das mal Artifex-Leute nahegelegt, dass dessen Engine
verlustfreier PDF optimieren könne. Mittels mutool [1]
mutool -s -g -g -g
kriegt man PDFs schön klein ohne sie kaputt zu machen. Aber grad weder
Zeit noch Lust, bzgl. Font-Handling zu gucken.
Gruss,
Thomas
[1] https://www.mankier.com/1/mutool
> Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
> Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
> nicht den tatsächlich benutzten.
Aha, d.h. Du hast jetzt auf einmal doch Acrobat Pro auf dem Rechner,
> Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
> nicht den tatsächlich benutzten.
dort das PDF geöffnet, bist in die Preflight-Funktion rein und dort
schön versteckt in den PDF-Objektbrowser? Oder wie kommst Du auf die
Idee, GS hätte an den Schriften rumgemacht? Bzw. woher willst Du wissen,
_was konkret_ im PDF jetzt weniger Platz verbraucht?
Ich würde ja eher zu MuPDF <http://mupdf.com/docs/> greifen. Zumindest
haben mir das mal Artifex-Leute nahegelegt, dass dessen Engine
verlustfreier PDF optimieren könne. Mittels mutool [1]
mutool -s -g -g -g
kriegt man PDFs schön klein ohne sie kaputt zu machen. Aber grad weder
Zeit noch Lust, bzgl. Font-Handling zu gucken.
Gruss,
Thomas
[1] https://www.mankier.com/1/mutool
Tilmann Reh
Oct 23, 2015, 10:23:10 AM10/23/15
to
Thomas Kaiser schrieb:
> Tilmann Reh schrieb in <news:n0dab4$ju9$1...@dont-email.me>
>> Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
>> Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
>> nicht den tatsächlich benutzten.
>
> Aha, d.h. Du hast jetzt auf einmal doch Acrobat Pro auf dem Rechner,
> dort das PDF geöffnet, bist in die Preflight-Funktion rein und dort
> schön versteckt in den PDF-Objektbrowser? Oder wie kommst Du auf die
> Idee, GS hätte an den Schriften rumgemacht? Bzw. woher willst Du wissen,
> _was konkret_ im PDF jetzt weniger Platz verbraucht?
Nein, ich habe nach wie vor kein Acrobat Pro.
Aber der PDF-XChange-Editor kann mir - auch wenn er die Schriften nicht
aus dem Dokument 'rauskriegt - zumindest anzeigen, was wieviel
Speicherplatz belegt.
Und da sehe ich dann, daß in dem von GS auf 67k geschrumpften PDF eben
nur noch 51k für Schriften belegt sind, gegenüber 154k für Schriften im
Original.
Ich gehe davon aus, daß das Original einfach den /kompletten/
Schriftsatz mit massenhaft ungenutzten Zeichen/Glyphen enthält.
> Ich würde ja eher zu MuPDF <http://mupdf.com/docs/> greifen. Zumindest
> haben mir das mal Artifex-Leute nahegelegt, dass dessen Engine
> verlustfreier PDF optimieren könne. Mittels mutool [1]
>
> mutool -s -g -g -g
>
> kriegt man PDFs schön klein ohne sie kaputt zu machen. Aber grad weder
> Zeit noch Lust, bzgl. Font-Handling zu gucken.
Ich kanns ja mal ausprobieren...
Danke,
Tilmann
> Tilmann Reh schrieb in <news:n0dab4$ju9$1...@dont-email.me>
>> Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
>> Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
>> nicht den tatsächlich benutzten.
>
> Aha, d.h. Du hast jetzt auf einmal doch Acrobat Pro auf dem Rechner,
> dort das PDF geöffnet, bist in die Preflight-Funktion rein und dort
> schön versteckt in den PDF-Objektbrowser? Oder wie kommst Du auf die
> Idee, GS hätte an den Schriften rumgemacht? Bzw. woher willst Du wissen,
> _was konkret_ im PDF jetzt weniger Platz verbraucht?
Aber der PDF-XChange-Editor kann mir - auch wenn er die Schriften nicht
aus dem Dokument 'rauskriegt - zumindest anzeigen, was wieviel
Speicherplatz belegt.
Und da sehe ich dann, daß in dem von GS auf 67k geschrumpften PDF eben
nur noch 51k für Schriften belegt sind, gegenüber 154k für Schriften im
Original.
Ich gehe davon aus, daß das Original einfach den /kompletten/
Schriftsatz mit massenhaft ungenutzten Zeichen/Glyphen enthält.
> Ich würde ja eher zu MuPDF <http://mupdf.com/docs/> greifen. Zumindest
> haben mir das mal Artifex-Leute nahegelegt, dass dessen Engine
> verlustfreier PDF optimieren könne. Mittels mutool [1]
>
> mutool -s -g -g -g
>
> kriegt man PDFs schön klein ohne sie kaputt zu machen. Aber grad weder
> Zeit noch Lust, bzgl. Font-Handling zu gucken.
Danke,
Tilmann
Tilmann Reh
Oct 23, 2015, 10:34:34 AM10/23/15
to
Thomas Kaiser schrieb:
>>> Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
>>>> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut
>>>> Adobe Reader als "Eingebettete Untergruppe", genau wie beim
>>>> Original), obwohl ich sie definitiv in der Never-Embed-Liste stehen
>>>> habe.
>>>
>>> Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
>>
>> Das stand in dem Teil, den Du weggeschnitten hast...
>
> Ach ja, Dein "Nachtrag" mit der Kommandozeile. Da stand halt "Arial" und
> nicht der Schriftname, der im PDF verwendet wurde.
Ich hatte Deine Frage anders verstanden und nicht auf meine
>>> Tilmann Reh schrieb in <news:n0cmbj$djm$1...@dont-email.me>
>>>> ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut
>>>> Adobe Reader als "Eingebettete Untergruppe", genau wie beim
>>>> Original), obwohl ich sie definitiv in der Never-Embed-Liste stehen
>>>> habe.
>>>
>>> Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
>>
>> Das stand in dem Teil, den Du weggeschnitten hast...
>
> Ach ja, Dein "Nachtrag" mit der Kommandozeile. Da stand halt "Arial" und
> nicht der Schriftname, der im PDF verwendet wurde.
Kommandozeile bezogen.
Also müßte ich zum Entfernen konkret "AOEUOL+Arial" in der
Never-Embed-Liste für GS angeben? (Gibt es einklich dafür keine
Wildcards? Also so, daß einfach *alles* entfernt wird?)
>> Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
>> "Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
>
> Und jetzt? Der Reader kennt halt auch die Konvention mancher PDF-
> Erzeuger, wie die Font-Subsets benennen und zeigt nicht den
> Originalnamen sondern den Namen des Fonts, auf dem das Subset basiert,
> an.
dort eben "Arial" und halte das (offenbar fälschlicherweise...) für
"Arial". :-\
>> Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
>> oder Zuordnung.
>
> "Speziell"? Wie schon versucht zu erläutern gibt es diverse Standard-
> Encodings und bei Untergruppen in jedem Fall Custom Encoding. Ich
> verstehe ja nach wie vor nicht, warum Du so ein Gewese mit der Herkunft
> der PDFs machst. Poste doch mal die Ausgabe von pdfinfo.exe -- aktuell
> vermute ich stark, dass es bei Producer "Mac OS X ... Quartz PDFContext"
> stehen dürfte (Font-Untergruppen, Truetype/CID und Unicode, wo's nur
> irgend geht -- das riecht zumindest nach Apple)
> Author: Quadira BV
> Creator: FormPipe Software, LaserNet Output Management 6.5.11.release
> Producer: FormPipe Software, LaserNet Output Management 6.5.11.release
> CreationDate: 10/20/15 05:11:02
> ModDate: 10/20/15 07:50:09
> Tagged: no
> Form: none
> Pages: 1
> Encrypted: no
> Page size: 595.276 x 841.89 pts (A4)
> File size: 174624 bytes
> Optimized: yes
> PDF version: 1.4
>> Nach dem vollständigen Entfernen der eingebetteten Schriften ist der
>> größte Teil des Textes einwandfrei, nur ein paar Sonderzeichen und die
>> Umlaute werden nicht mehr korrekt angezeigt - stattdessen erscheinen
>> irgendwelche anderen Zeichen.
>
> Ja mei, das klappt natürlich nicht, einen Zeichenvorrat, der in Unicode
> beschrieben ist, als WinAnsi zu interpretieren.
a) die Codierung entsprechend anpassen, oder
b) nur die nicht dem Standard (von mir aus ASCII) entsprechenden Zeichen
eben behalten könne.
(Alles, was es schon im ASCII gibt, wird offenbar auch nach stumpfer
Entfernung der Schriften noch richtig angezeigt.)
>> Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
>> zurechtbiegen könnte
>
> Die ist Standard. Weil weder Windows noch dort gebräuchliche und sehr
> beschränkte Gammel-Encodings wie das dort übliche ANSI (basiert AFAIK
> auf ANSI 1252) sind die _einzigen_ Standards. Es gibt durchaus zeit-
> gemäße wie die auf Unicode basierenden.
Standard. Und ansonsten ist es mirauch egal, ob die Zeichen im PDF jetzt
nach ANSI oder Unicode zugeordnet werden... Es muß halt nur stimmen. :-)
Tilmann
Thomas Kaiser
Oct 23, 2015, 10:50:47 AM10/23/15
to
Tilmann Reh schrieb in <news:n0dgdp$enh$1...@dont-email.me>
im PDF ein anderes ist, als das, was Dein PDF-Schrumpfer dann am Ende
reinschreibt.
Mal anders gefragt und weil Du Faksimile bereits erwähntest. Wenn Du
auch damit zufrieden wärst, das Ganze als ultrakleines Bilddokument
weiterzuverwenden (wozu auch immer), würde ich eher in die Richtung
"Inhalt rendern und mit Maximalkompression als nur ein Bild enthaltenes
PDF aufbewahren" denken. Wozu dann überhaupt noch PDF als Container?
Weil PDF JBIG2 kann. JBIG2 ist hocheffizient für monochrome Bildobjekte
(zigmal effizienter als die bei Fax übliche CCITT Group 4 Kompression)
aber wenn man's übertreibt kann man auch prima auf die Fresse damit
fliegen:
http://heise.de/-1930941
Gruss,
Thomas
> Ich halte ANSI durchaus für einen (zumindest nicht un-) üblichen
> Standard. Und ansonsten ist es mirauch egal, ob die Zeichen im PDF
> jetzt nach ANSI oder Unicode zugeordnet werden... Es muß halt nur
> stimmen. :-)
Klar, nur es wird halt unter Garantie nicht stimmen, wenn das Encoding
> Standard. Und ansonsten ist es mirauch egal, ob die Zeichen im PDF
> jetzt nach ANSI oder Unicode zugeordnet werden... Es muß halt nur
> stimmen. :-)
im PDF ein anderes ist, als das, was Dein PDF-Schrumpfer dann am Ende
reinschreibt.
Mal anders gefragt und weil Du Faksimile bereits erwähntest. Wenn Du
auch damit zufrieden wärst, das Ganze als ultrakleines Bilddokument
weiterzuverwenden (wozu auch immer), würde ich eher in die Richtung
"Inhalt rendern und mit Maximalkompression als nur ein Bild enthaltenes
PDF aufbewahren" denken. Wozu dann überhaupt noch PDF als Container?
Weil PDF JBIG2 kann. JBIG2 ist hocheffizient für monochrome Bildobjekte
(zigmal effizienter als die bei Fax übliche CCITT Group 4 Kompression)
aber wenn man's übertreibt kann man auch prima auf die Fresse damit
fliegen:
http://heise.de/-1930941
Gruss,
Thomas
0 new messages