Hallo Schwarm-Intelligenz ich hab hier einen völlig skurrilen Fall den es aus meinem Verständnis heraus eigentlich gar nicht geben kann.
Ich wandle eine Adobe Schrift in der neuesten InDesign Version in Pfade um. Es handelt sich um einen Zweizeiler. In Pfaden schaut der Logo Schriftzug fetter aus. Ich dachte erst es handelt sich um einen Darstellungsfehler. Zoome rein auf ma. Tatsächlich, Font ist exakt gleich geblieben. Mache einen Test: Legt man die Schriften übereinander also die Version der Pfade und die offene sind Sie Deckungsgleich - siehe Bilder.
Aber weit gefehlt - denn wenn das Ganze ausgedruckt wird ist die Pfad Version so dick wie im Darstellungsehler 🤣, obwohl das technisch ja gar nicht möglich sein kann - da deckungsgleich in der Maximalansicht. Bin echt überfragt was da los ist, da mir das in den letzen 20 Jahren noch nicht untergekommen ist, denke ich mir, es hat was mit Adobe-Fonts zu tun…?!
Wer kennt das Rätsels Lösung?
ps. Da ich den Schriftzug für eine Markenentwicklung brauche ist es kein Lösungsansatz nicht umzuwandeln, wer weiß ob der Front auch in Zukunft von Adobe gehostet wird etc. - Bin schon sehr neugierig auf die Erklärungen oder sogar Lösungen! 😅

Das ist leider ein uraltes Problem, am besten zu sehen an I und l in z.B. einem Logo. Diese beiden Buchstaben werden gern dicker dargestellt und – wenn das Ausgabegerät blöd genug ist – auch dicker wiedergegeben. Du könntest probieren, mit einem pdf statt Vektoren zu hantieren, möglicherweise verhindert das im Ausdruck den Darstellungsfehler.

Verhält es sich mit einer Umwandlung in Pfade in Illustrator genauso?

Das hat mit verschiedenen Rasterern für Fonts und Vektoren zu tun, d.h. die Umrechnung von Vektoren in (am Bildschirm oder unter Umständen auch Office-Druck) sichtbaren Pixeln / Rasterpunkten funktioniert anders, je nachdem ob die Ausgangsdaten ein Font oder eine Vektorform ist.

D.h. die Form wird in Pixel umgewandelt, und weil Pixel ganzzahlig sind und sich nur in der Helligkeit unterscheiden können, muss irgendwie entschieden werden, wie so eine Vektorform "als Mosaik" abgebildet werden soll – da gibt es verschiedene Ansätze mit Vor- und Nachteilen.

Schriften werden/wurden oft so gerastert, dass das möglichst effizient (schnell) geht und dann wird – je nach Rasterbibliothek und Intention – noch gewichtet, ob man dabei möglichst geometrische Exaktheit haben will, oder möglichst uniforme und scharfe Buchstaben die aber leicht von der eigentlichen Form abweichen – beides zugleich geht nicht. Übliche Rasterer sind Apples Quartz, Microsofts GDI, Cleartype und heute hauptsächliche Direct2D, Adobes eigener systemübergreifender Fontrasterer für CreativeSuite und Acrobat, und dann noch verschiedenes auf Linux/Android, ...

Allgemeine Vektorformen (wie umgewandelte Buchstaben) sind für "Normaluser" seltener im Einsatz, und da wird zwischen den Systemen nicht so sehr unterschieden oder anders optimiert / priorisiert – insbesondere geht es da vor allem um exakte Darstellung, weil ja nicht viele Buchstaben in Serie immer exakt gleich aussehen müssen. D.h. sobald du vom Font in Vektoren umwandelst, ändert sich in der Regel die Methode wie gerastert wird, und das sieht man am Bildschirm sogleich.

Das ist aber nur ein Effekt, der am Bildschirm sichtbar ist – am Ende betrachtest du ja da IMMER ein Pixelbild des Vektors.  Im Druck solltest du diesen Effekt nicht sehen, wenn der Druckertreiber / RIP bis zur Erzeung des Druckrasters auf der Platte in Vektoren arbeitet. Das ist bei allen echten Postscript/PDF-Druckern der Fall, also bei teuren Bürodruckern und professionellen Dienstleistern – bei Bürodruckern, die nur vorgeben Postscript zu können, oder gar nicht damit arbeiten wird oft vorher ein Pixelbild gerastert, und das dann gedruckt --> da können Fonts und Vektoren wieder unterschiedlich behandelt werden und man sieht das.

 

Noch was kommt dazu: Schriften sind heute nicht mehr so selten mit (quadratischen) Truetype-Kurven gespeichert, nicht mit (kubischen) Bezier-Postscript-Kurven. Beim Umwandeln in Vektoren in z.B. Illustrator wird dann die Kurve wieder in Postscript-Kurven umgerechnet, d.h. sie verändert sich wenn nicht optisch sichtbar dann doch mathematisch signifikant, und selbst wenn der selbe Rasterer drüber liefe, könnte das Ergebnis ein sichtbar anderes Pixelbild sein.

Wenn es sich nur um diese aus zwei Worten bestehende Wortmarke handelt, würde ich den Schriftzug einfach in gewünschter Stärke als Vektorgrafik nachbauen. Das ist nicht schwer, dauert nur ein bisschen. Aber bei einem Logo lohnt sich der Aufwand, die Nutzung ist ja in der Regel auf Langfristigkeit angelegt. 

Hallo und vielen Dank für die Inputs. Eine schlüssige Erklärung war für mich noch nicht dabei.

Auch bei einer Umwandlung im Illustrator kommt es zu diesem Fehler. Aus meiner Sicht ist das ein Bug in diesem Font. Wer es versuchen möchte zu replizieren, "

Mr Eaves Mod OT" Bold von Adobe Font.

Der Drucker ist ein OKI C9650 - der macht bestimmt nicht das Problem, der Druckt nur das, was ich auch sehe in der 100% Ansicht.

Es macht einfach keinen Sinn, dass es zu Abweichungen in der 100% Ansicht versus der 4000% Ansicht kommt - das kann eigentlich gar nicht sein… 

Ich habe den Verdacht, dass der Outline Pfad in der Umwandlung addiert wird. 
Danke trotzdem für den Input, werde mir Workarrounds anschauen - Hauptsache, dass ist nicht das neue Normal 😉

Das ist nicht neu, den Bug (oder ist’s ein feature?) gibt es seit Jahrzehnten.

vor 41 Minuten schrieb RAFF:

Eine schlüssige Erklärung war für mich noch nicht dabei.

Sebastian hat es doch korrekt, schlüssig und erschöpfend hier erklärt. Es wird nichts »addiert«. Es ist die unumgängliche Rasterung von mathematischer Kurven-Beschreibung zu Druck- oder Bildschirmpixeln, die sich gegebenenfalls anders verhält. Und der Drucker macht sehr wohl einen Unterschied. Man wird das Problem gerade bei einem Office-Drucker finden, weniger zum Beispiel im Offsetdruck. 

Hallo Ralf, die Erklärung von Sebastian mach für mich keinen Sinn, da ich in der 4000% Ansicht das exakt gleiche Ergebnis sehe.
Seine Erklärung wäre für mich sehr schlüssig, wenn die Umwandlung die Daten verändern würde… Wie kann es sein, dass etwas bei 4000% deckungsgleich ist - und bei 100% Ansicht nicht - macht das Sinn??

Also bei tritt der das erste mal auf in den letzen 2,5 Jahrzehnten…

Ich habe es so verstanden: Nicht die »Daten« (= Formen) verändern sich, sondern die »Übersetzung« in Pixel, die Monitor und Drucker nach der Umwandlung vornehmen.

Ich werde es herunterbrennen auf den kleinsten Fehler, der auch mein größtes Missverständnis darstellt:

Wandle ich einen Schriftzug - Mr Eaves Mod OT / Bold von Adobe Font in Pfade um, so sehe ich weder im Illustrator in der Pfadansicht, noch im Indesign bei 4000% einen unterschied!

Zoome ich heraus, sehe ich einen Unterschied, sowohl im Illustrator in der regulären Ansicht, wie auch im Indesign.

Frage: Wie kann etwas identisch aussehen bei hohem Zoom Faktor und dem übereinanderlegen der Daten, und beim heraus Zoomen die Optik ändern.

Kontrolle via Print: Da sich die Darstellungsverhalten auch via Postscript Drucker replizieren lässt, schließe ich daraus, dass es sich tatsächlich nicht nur um einen Darstellungsfehler in der 100% Ansicht handeln kann…

Hoffe ich konnte das jetzt schlüssiger erklären?!

 

vor 8 Minuten schrieb RAFF:

Hoffe ich konnte das jetzt schlüssiger erklären?!

Wir haben die Beschreibung auf Anhieb verstanden, da wir das Problem seit langem kennen. Es scheitert nicht an der Beschreibung des Problems. Es scheitert daran, dass du die gelieferte Erklärung nicht annimmst und immer weiter »warum passiert das?« fragst. Es passiert aus den genannten Gründen. Wir können sie nur wiederholen. Dein Drucker und dein Bildschirm kann keine Vektoren ausgeben. Die Vektoren müssen gerastert werden und die zuständige Software (die Render Engine) rechnet gegebenenfalls etwas anders, wenn die Vektoren als Font oder als nativer Pfad vorliegen. Das ist die Erklärung. Mehr kann man nicht sagen. 

vor 1 Stunde schrieb RAFF:

Wie kann es sein, dass etwas bei 4000% deckungsgleich ist - und bei 100% Ansicht nicht - macht das Sinn?

Weil ein Vektor auf einem Pixel-Gerät nun mal nur annähernd wiedergegeben werden kann. Je größer die relative Länge der darzustellenden Vektoren, desto genauer.

Ein Beispiel, beide Male das identische Objekt. Die kleine Darstellung ist fast rund, obwohl das svg äußerst grob ist. Würde man noch weiter wegzoomen, wäre das O irgendwann äußerst scharf dargestellt.

Ob das in deinen Augen Sinn ergibt, steht auf einem anderen Blatt. Die technischen Rahmenbedingungen lassen es nicht anders zu.

 

Ich muss mal ein Lob loswerden: Sebastian Nagels ausführliche und stets verständliche Erklärungen lese ich immer mit Vergnügen (und Gewinn). 

vor 2 Stunden schrieb Ralf Herrmann:

Wir haben die Beschreibung auf Anhieb verstanden, da wir das Problem seit langem kennen. Es scheitert nicht an der Beschreibung des Problems. Es scheitert daran, dass du die gelieferte Erklärung nicht annimmst und immer weiter »warum passiert das?« fragst. Es passiert aus den genannten Gründen. Wir können sie nur wiederholen. Dein Drucker und dein Bildschirm kann keine Vektoren ausgeben. Die Vektoren müssen gerastert werden und die zuständige Software (die Render Engine) rechnet gegebenenfalls etwas anders, wenn die Vektoren als Font oder als nativer Pfad vorliegen. Das ist die Erklärung. Mehr kann man nicht sagen. 

ich wandle Vektoren in Vektoren um. Kein einziges mal in Pixel… Das ist Mathematik. 2+2 muss immer vier ergeben…

vor einer Stunde schrieb Diwarnai:

Weil ein Vektor auf einem Pixel-Gerät nun mal nur annähernd wiedergegeben werden kann. Je größer die relative Länge der darzustellenden Vektoren, desto genauer.

Ein Beispiel, beide Male das identische Objekt. Die kleine Darstellung ist fast rund, obwohl das svg äußerst grob ist. Würde man noch weiter wegzoomen, wäre das O irgendwann äußerst scharf dargestellt.

Ob das in deinen Augen Sinn ergibt, steht auf einem anderen Blatt. Die technischen Rahmenbedingungen lassen es nicht anders zu.

 

u See what you get… ich sehe aber immer das Idente, da die Daten auch identisch sind… auch beim einzoomen, eine perfekte mathemaische Kurve…

 

vor 3 Minuten schrieb RAFF:

ich wandle Vektoren in Vektoren um. Kein einziges mal in Pixel

Nein. Ein Monitor kann keine Vektoren darstellen, sondern nur Pixel.

und auch ein drucker kann keine vektoren darstellen sondern nur die pixel, die der renderer gerechnet hat. bei einem retina-display und einem guten drucker wirst du kaum was merken. bei miesem drucker und standard monitor auflösung sehr wohl.

vor 23 Minuten schrieb Diwarnai:

Nein. Ein Monitor kann keine Vektoren darstellen, sondern nur Pixel.

das ist mir schon klar. Die beiden Vektordaten sind identisch. Deckungsgleich...!

Vielleicht lässt sich ja noch was ergänzen zur unterschiedlichen "Darstellung" bei unterschiedlichen Zoomstufen:

Die Pixel von denen wir sprechen sind als Hardware im Bildschirm verbaut – du schaust am Bildschirm IMMER eine Pixel-Repräsentation deiner (Vektor- oder Pixel-)Inhalte an. Diese Pixel haben eine feste Größe und ändern sich beim Zoomen auch nicht (Hardware!), die Größe der Pixel ist abhängig von deinem Bildschirm. Du wandelst aktiv nichts in Pixel um, aber die Darstellung am Bildschirm ist eine in Pixel umgewandelte Version deiner Daten.

 

Wenn eine Kurve bei hohem Zoom (4000%) so groß dargestellt wird, dass sie den gesamten Bildschirm ausfüllt, dann stehen – z.B. an einem imac – 5120 x 2280 Pixel zur Verfügung um diese Kurve in Pixeln (Mosaiksteinchen) abzubilden. Das sind sehr viele, das Ergebnis der Pixelansicht wird sehr nahe an die mathamtische Kurve heran kommen die der Darstellung zugrunde liegt – aber auch nicht pefekt, es gibt im Bereich der Kurve eine Zone, in der der Rasterer entscheiden muss*, ob er einen Pixel schwarz oder weiß färbt (und mit Antialiasing: auch noch Grau als Kompromiss für "dazwischen").

Wenn du jetzt die Zoomstufe auf 100% änderst, wir die abzubildene Kurve effektiv "kleiner", sie füllt bei weitem nicht mehr den ganzen Bildschirm aus. Der Bildschirm hat aber immer noch die gleich großen Pixel zur Verfügung wie zuvor, um diese Kurve abzubilden – jetzt aber weniger davon, weil ja die Abbildung kleiner ist als zuvor, und die Pixel sind in Relation zur gesamten Kurve viel größer (40x größer). Mit so viel größeren Mosaiksteinen kannst du die Kurve nicht mehr so exakt abbilden wie zuvor – nach wie vor muss entschieden werden, ob ein Pixel am Bildschirm schwarz oder weiß wird – halbe Pixel gibt's nicht, man kann sich wieder nur mit Graustufen ein bisschen helfen. Das Ergebnis wird aber ein weniger exaktes sein als zuvor, und wieder muss entschieden werden, was von den verschiedenen Präferenzen in der Darstellung Priorität hat*, alles zusammen geht nicht.

* und da liegt der Hund begraben: für Schriftdarstellung wird anders entschieden, als für Kurvendarstellung. Das liegt darin begründet, dass es andere Ansprüche für diese Darstellung gibt – Tempo, Gleichförmigkeit, Schärfe, Exaktheit, Patente, Kompatiblitätsgründe, ..., ...

 

Für Drucker, insbesondere Laserdrucker im Büro, auch gute, ist das Problem das gleiche, nur dass sie keine quadratischen Pixel erzeugen, sondern, Druckerraster-Punkte. Aber auch da kann es (je nach Druckertreiber und Druckersprache) sein, dass eine Kurve aus einem Font anders gerastert wird wie die exakt selbe Kurve als "Grafik-Kurve".

Ein einfarbiger Offset-Druck (Schwarz, Sonderfarbe, ...) hat den Vorteil, dass der Belichter mit in der Regel 2400ppi belichtet, d.h. die Rasterpunkte sind da sehr sehr klein, man sieht da mit normalem Auge nichts mehr vom Raster, und eventuelle Unterschiede in der Rasterung verschwinden praktisch. Ich möchte fast wetten dass wenn du deine Schrift und deine in Pfade umgewandelte Schrift, wenn du sie schwarz oder in Sonderfarbe nebeneinander drucken lässt, auf dem Papier gleich aussehen werden. (weniger sicher bei 4C-Aufbau).

vor 51 Minuten schrieb RAFF:

Das ist Mathematik. 2+2 muss immer vier ergeben…

Jepp. Und genau das passiert auch, wenn die Darstellungsgröße groß genug ist und alles auf gerade Zahlen und Pixel fällt. Daher stimmt es ja bei 4000 % oder wenn du z. B. einen Buchstaben in 500 Punkt auf ein A4-Blatt druckst. Das Problem tritt aber auf, wenn nicht einfach mit Ganzzahlen und ganzen Pixeln gerechnet wird, also in kleinen Schriftgraden. Dann führen Berechnungen des Renderings mit unterschiedlichen Methoden zu leicht abweichenden Ergebnissen. Auch das ist Mathematik!

Ich sage es jetzt noch einmal ganz deutlich: Deine Software benutzt gegebenenfalls zwei(!) unterschiedliche Rechenmethoden um von Vektoren zur Rasterdarstellung zu kommen. Bei …

1. Vektoren, die in einen Font eingepackt sind
2. Vektoren, die direkt vorliegen (z.B. Illustrator-PostScript-Pfade)

Das hat auch alles seine Gründe, weil Fonts zum Beispiel mit einer Bildschirmoptimierung ausgestattet sein können, die zum Beispiel tanzende Grundlinien bei Überhängen (und viele andere Dinge) speziell behandelt. Daher muss die Software das Schrift-Rendering durch einen separaten Render-Algorithmus schicken, der für Schriften optimiert ist. Und so führen dann auch vermeintlich identische Vektorbeschreibungen zu unterschiedlichen Ergebnissen. Damit muss man sich einfach abfinden. Die Rasterung/Kantenglättung (und damit die Wirkung der Fettheit einer Schrift) werden immer von den konkreten Render-Engines abhängen. Innerhalb eines Programms, zwischen verschiedenen Programmen, Betriebssystemen, Druckern usw. 

vor 35 Minuten schrieb RAFF:

2+2 muss immer vier ergeben…

Richtig, aber 2.71 + 2.35 kann man so rechnen:

 

2.71 + 2.35 = 5.06  (wenn es exakt sein soll)

2.7 + 2.4 = 5.1 (wenn nur 1 Kommastelle erlaubt ist und gerundet wird)

3 + 2 = 5 (wenn gar keine Kommastelle erlaubt ist und gerundet wird)

2 + 2 = 4  (Kommastellen einfach weg – korrektes Runden kostet viel Zeit und Energie!)

 

Pixel heißt immer Ganzzahlen (Antialiasing mal ignoriert) ...
Wie man zu diesen Ganzzahlen kommt, ist dann die große Frage – wie genau muss es sein, wie genau kann es sein, wie viel Zeit hab ich dafür.

 

Wenn wir dann noch berücksichtigen, dass wir nicht immer bei Position 0 losrechnen (die Position einer Kurve in Bezug auf das unumgängliche Pixelraster), also nicht 0.00 + 2.71 + 2.35 rechnen können sondern z.B. bei 0.51 als Rechen-Position starten (was ja bei Schrift sehr gut sein kann, nicht jedes "a" fällt auf einen Pixel-Nullpunkt):

0.51 + 2.71 + 2.35 = 5.57

0.5 + 2.7 + 2.4 = 5.6  (nur 0.3 statt 0.4 Differenz wie zuvor!)

1 + 3 + 2 = 6  (selbe gerundete Summanden, anderer Startpunkt, sehr anderes Ergebnis!)

0 + 2 + 2 = 4  (und hier wieder das selbe Ergebnis wie zuvor!)

 

Ganzzahlen-Mathematik ist einfach ein großer Murks – aber bei Pixeln unumgänglich, die sind weiß oder schwarz ... die Entscheidung, wie gerechnet wird, ist aber abhängig von verschiedenen Dingen.

Ha, ich hab's wiedergefunden – wie das so läuft, mit Kurven zu Pixeln ...

 

Das Angebot steht noch: Montag wird geprüft (aber den Sch... mit Cleartype könnt ihr weglassen, ist veraltet)!

Bearbeitet (21. Januar 20251 J. von Sebastian Nagel)

Wow Sebastian, zack gut erklärt