FirmenLogo
Home

Layout

3D-Druck

Reprofilme
  Tipps&Tricks
  FAQ
  EPS-FAQ
  Meinungen

Grafik/DTP

Leiterplatten

Hardware

Software

Bildarchiv

Preisliste

Links

Impressum

Spezielles zu EPS und anderen Formaten

PostScript-Feinheiten

PostScript ist nicht immer „gutes“ PostScript

Nicht jedes PostScript-File lässt sich auf Anhieb fehlerlos belichten. Manche Programme schreiben hier schon ordentlichen Schrott rein. Auch wenn die einen oder anderen modernen PostScript-Interpreter – wie etwa „GhostScript“ – damit klar kommen, so haben Belichtungsmaschinen und so mancher Importfilter in andere Programmen damit Probleme.

So ein Problem stellen etwa Linienstücke mit der Länge Null als Ersatz für einen gefüllten Vollkreis dar. Normalerweise ist so eine Linie überhaupt nicht sichtbar. Da in PS die Linienenden mit einem Halbkreis gerundet werden können, gingen die Entwickler davon aus, dass zwei Halbkreise am Punkt Null (einer um 180° gedreht) einen Vollkreis ergeben. Nur das geht eben nicht mit jedem PS-Interpreter. Manche erwarten eine gewisse Mindestlinienlänge. Oft wird dann nur ein Halbkreis gezeichnet. Mittlerweile kennen wir die diversen Programm-Outputs ganz gut und korrigieren den Code daraufhin schon automatisch. So mancher Konverter für das eine oder andere „Problemchen“ musste geschrieben werden.

Da ist z.B. so ein Codestück:

; 200 Lw N 989 1733 M 989 1733 I : 0.5 -0.5 +S K

oder etwas verständlicher, weil teilweise ausgeschrieben:

grestore 200 linewidth newpath 989 1733 moveto 989 1733 lineto gsave ...

Bild links: falsch. Bild rechts: richtig.

Die Koordinaten des „M=Moveto“ und des „I=Lineto“-Anteils treten auf der Stelle. Resultat ist, ein Linienstück mit Länge Null. Zusätzlich ist nicht optimal, dass für jedes einzelne Linienstück um skaliert wird. Das geht einfacher, ist aber ein andere Baustelle.

Oder eine andere Stelle:

O N 519 1274 M 519 1274 I : 0.297 -0.297 +S K 

Der Buchstabe „O“ für „eofill“ am Anfang steht für ein Füllargument des letzten Objektes in der letzten Zeile. Zumindest ist das für die Lesbarkeit des Codes nicht gut – aber was solls.

Wenn man solche Codestücke sucht, geht es auch noch verzwickter: Die gesuchten Argumente stehen nicht immer am selben Platz. Und auch hier die unseligen Extra-Skalierungen für die Linien!

1 0 scol O 0 0 scol N 519 1274 M 519 1274 I : 0.297 -0.297 +S K

Eine weiteres Problem in vielen PS-Generatoren ist, dass ein einfacher Vollkreis – der in PS richtigerweise mit dem Befehl „arc“ für absolute Koordinaten, oder „arcn“ für relative Koordinaten beschrieben würde – durch eine Vierquadranten-Bezierkurve ersetzt wird. Bezierkurven sind vielseitig, aber nicht als Ersatz für einen schon eingebauten PS-Befehl gedacht. Wenn etwa ein Importfilter durch eine Beschränkung der Rechengenauigkeit – das Original-PS arbeitet nur mit Single-Genauigkeit – des aufrufenden Programms die Kontrollpunkte der Kurven nicht richtig umsetzt, kommt alles Andere als der gewünschte Originalkreis raus. Besonders bei kleinen Strukturen im mm-Bereich fällt das auf, da hier schon mal weit „hinterm Komma“ gerechnet werden müsste.

Zumindest macht das den Code länger und schlechter. Das war ursprünglich mal ein Kreis:

141.73228 212.59843 moveto
165.15128 212.59843 184.25197 193.49773 184.25197 170.07874 c
184.25197 146.65975 165.15128 127.55906 141.73228 127.55906 c
118.31329 127.55906 99.21260 146.65975 99.21260 170.07874 c
99.21260 193.49773 118.31329 212.59843 141.73228 212.59843 c

Der sich in PS einfacher so beschreiben ließe:

141.732268 170.07874 42.519694 0 360 arc [stroke oder fill]

Dann gibt es da noch eine Unsitte beim Füllen von großen Flächen. Für PS ist nichts leichter als das: Eine Flächenbeschreibung aus beliebigen (allerdings einer beschränkte Anzahl, etwa 1500) Polygonen und Objekten einfach mit „fill“ oder „eofill“ zu füllen. Oder so wie es manche Programme machen: Einfach eine schwarze Fläche zeichnen und dann mit Weiß draufzeichnen. In PS geht das ja und es ist einfach optimal. Aber einige Programme füllen Flächen in alter HPGL-Manier, aus einer Unzahl von mehr oder weniger feinen Linien. Das geht zwar auch, aber es dauert oft extrem lange und ist problembehaftet, wenn die Linien nicht überlappen oder zu fein werden.

Zum Schluss noch: Eines meiner Lieblinge ein ganz spezielles Programm (4- bis 5-stellige Kaufsumme ;-), gibt alle einfachen zu füllenden Strukturen – auch eine schlichtes Rechteck oder einen Kreis – in einer schier endlosen Kette von zu füllenden Mini-Dreiecken aus. Das mag zwar theoretisch und mathematisch richtig und auch für 3D-Funktionen nötig sein, aber für Belichtungszwecke ist das Mist. Denn viele PS-Interpreter und sogar moderne Programme über ihre Importfunktionen stürzen bei dieser MByte-Koordinatenflut regelrecht ab. Davon abgesehen werden damit Rundungen niemals wirklich rund, da alles mit Geradenstücken nachempfunden wird.

Beispiele: Das erste Bild zeigt die Flächen mit Dreiecken nachempfunden. Das Zweite, den daraus resultierenden PostScript-Output mit 2400 dpi und das Dritte zeigt es, so wie es sein sollte, mit richtigem PostScript und Circle-Befehlen.
(Die Bilder sind zum Betrachten mit höherer Auflösung eingebunden wie hier abgebildet.)

Diese Probleme tauchen m.E. auf, weil offenbar immer die gleichen fehlerhaften oder zumindest suboptimalen Programmbausteine für das Schreiben der PS-Dateien verwendet werden. Hier wird nur festgestellt, das es sowohl guten, wie weniger guten PS-Code gibt, mit dem man sich rumschlagen muss.

In diesem Zusammenhang ein großes Lob an die Entwickler von Target, Eagle und KiCad, die sich die Mühe gemacht haben, selbst einen PostScript-Generator zu integrieren, der gut belichtbaren und auch schlanken Code erzeugt.

Fazit: Es ist nicht immer einfach PS zu belichten!