Es scheint also mit der Schriftart zusammen zu hängen (ist mit mehreren nachvollziehbar) und evtl. auch mit dem ausgewählten Drucker (hier: PDF-Printer; bei einem anderen Drucker auf demselben PC waren Block 1 und Block 2 beide zusammengeschoben, Block 3 und 4 hingegen nicht).
Die Ergebnisse des Canvas-Objekts sind Endgeräte-Abhängig. Abhängig davon, ob z.B. eine Schrift auf dem Endgerät verfügbar ist, wird diese Schrift im Canvas erzeugt oder es dem Endgerät überlassen. Da Arial (ersatweise Helv.) auf ansich JEDEM Endgerät verfügbar ist, wird diese Schriftausgabe auch erst dort passend erzeugt, während z.B. die Gill xxx von Canvas als Image erzeugt werden muß und auch als Image (Buchstabenweise) zum Endgerät gesendet wird.
Kann man das Problem irgendwie umgehen ohne dass man die Schriftart wechselt?
Ich persönlich sehe da garkein Problem, weil die Verwendung von MM_LOMETRIC nur bei ganz speziellen Endgeräten sinnvoll ist (Mir ist in 25 Jahren noch keins untergekommen, evtl. Stift/Gravur/3D-Plotter?). MM_LOMETRIC benutzt als Logik-Einheit 0,1 mm statt Pixel. Dazu muß dann Canvas aber die exakten Relationen des Endgerätes kennen (und entspr. umrechnen). Also sollte man die Verwendung MM_TEXT vs. MM_LOMETRIC (oder eines anderen Settings) von dem aktuell verwendeten Endgeräte-Treiber abhängig machen und nur umschalten, wenn dies das Endgerät
explizit benötigt.
In Deinem Fall berechnet Canvas bei Gill xxx den einzelnen Buchstaben selber noch korrekt, unterschlägt aber die Spationierungswerte (oder setzt die auf eine logische Einheit - was kaum zu erkennen ist) bzw. das Endgerät kann mit der auf den Buchstaben folgenden Spationierung in mm nichts anfangen.
Anmerkung zu PDF-Erzeugenen Tools: Die sind als Kontrolle kaum verwendbar, weil die die Schriften teils merkwürden verzerren. Nur die Startpunkte sind korrekt, die Versalhöhen weichen oft ab, die Laufweiten schriftabhängig teils auch.