Etwa so:
Eine Erklärung fand ich schließlich darin, wie im Draw Modul entschieden wird, ob durch ein Vektorobjekt ein Pixel betroffen ist oder nicht. Entscheidend ist der Begriff des Boundary Pixels.
Eine Line mit definierter Breite wird intern zu einem Rechteck, das dann mit der Linienfarbe gefüllt wird (nennt sich "Flattening"). Anhand der Winding-Rule wird jedes Pixel, dessen Mitte innerhalb des Pfades liegt als "innen" mit Farbe gefüllt. In den PRM wird das als "Interior" oder als "Exterior" bezeichnet.
Das war der einfache Fall.
Dann gibt es Pixel, dessen Mitte zwar "außerhalb" liegt, der Pfad aber doch durch das Pixel verläuft. Ob solche Pixel gefüllt sind, kann mit einer weiteren, speziellen Regel entschieden werden: es wird untersucht, ob der Pfad eine in das Pixel eingeschriebene Raute quert oder nicht. Wenn ja, ist es ein Rand-Pixel, das gefüllt wird. Die PRM bezeichnen das als "Boundary" bzw. "Non-Boundary".
Das ist ein Boundary Pixel.
Der Pfad geht durch die Boundary-Raute.
Und das ein Non-Boundary Pixel.
Der Pfad geht zwar durch das Pixel, liegt jedoch komplett außerhalb der Boundary-Raute.
Nun sind wir gewappnet, um den feinen Unterschied zu erkennen, der zu dem fehlenden Eck-Pixel führt:
Liegt die Ecke im Non-Boundary Bereich, wird das Pixel wird nicht gefüllt.
Liegt die Ecke im Boundary Bereich, oder geht der Pfad durch den Boundary Bereich, wird das Pixel gefüllt.
Oder so:
Weshalb fällt sowas kaum auf?
Zuerst mal bemerken wir dase fehlende Pixel nur dann, wenn die Pfade parallel zum Pixelraster laufen, also genau senkrecht oder waagrecht.
Dann liegt die Wahrscheinlichkeit, daß das Eck-Pixel als als Non-Boundary eingestuft wird, bei 1 zu 8. Also eher gelegentlich.
Schließlich hängt es vom Programm ab, wie es die Sützpunkte der Pfade positioniert. Die Position des Mauszeigers zeigt immer auf ein Pixel. Um genauer zu arbeiten, müssen wir zoomen. Solange wir nicht in hohen Zoom-Stufen arbeiten, können wir im Programm die Stützpunkte der Pfade auch nur in dem groben Raster des Bildschirms positionieren.
Die Pfadkoordinaten sind in sog. Draw-Units definiert. Dabei gilt:
1 Draw-Unit = 1/256 OS-Unit
1 OS-Unit = 1/180 inch
In den üblichen Bildschirm-Modes ist ein Pixel 2 x 2 OS-Units groß, also 1/90 inch (90 dpi).
Nun ist mir klar: die Draw Datei, bei der mir das erstmals aufgefallen ist, wurde programmatisch aus Meßdaten erzeugt. Der generierte Pfad ist viel feiner aufgelöst als für die Bildschirmdarstellung nötig. Möchte ich das vermeiden, muß ich halt großzügig runden.
Übrigens, wenn wir eine Pfad "zu Fuß" per SWI plotten, können wir exakt definieren, ob Boundary-Pixel gezeichnet werden oder nicht. Über das UI von !Draw haben wir darauf keinen Einfluß.
Zum Abschluß nochmal ein Beispiel, erstellt bei Zoom 8:1, Grid-Lock/Auto-Adjust:
Linienlänge 1440 Draw-Units, Linienbreite 320 Draw-Units, jeweils um 720 Draw-Units verschoben. Darstellung in !Draw bei 1:1 Zoom.
Die Linienbreite ist übers UI mit 0.5 angegenben. Die Einheit ist dort der typografische Punkt (=1/72 inch, somit 0,5 pt = 320 Draw-Units).
Die Information über Boundary/Non-Boundary stehen so detailiert nicht in den PRM, sondern habe ich hier gefunden:
http://wss.co.uk/pinknoise/Docs/Arc/Draw/DrawModule.html
Leider ist dort nicht vermerkt, wie alt das Dokument ist. Für mich sieht es nach einer sehr frühen Version der Beschreibung des Draw Moduls aus.