Category: Solaris

Seitdem MS Word die Option anbietet Dateien auch als .pdf Datei zu speichern, treten vermehrt Anzeigeprobleme zu Tage. Um genau zu sein: Auf Plattformen, welche die typischen MS Fonts – Arial und Times New Roman nicht installiert haben.

So ergibt sich in diesen Fällen aus einem einfachen Text, der in der Schriftart Arial geschrieben wurde, ein ziemlich anderes Erscheinungsbild auf dem Adobe Reader unter Linux oder Solaris

Der Grund dafür ist, dass die Speichern unter.. Funktion von MS Word diese Schriftarten nicht einbettet, sondern nur darauf referenziert. Das Anzeigeprogramm muss dann eine Ersetzungstabelle anwenden, bei der die Originalschriftart durch eine – möglichst ähnliche – ersetzt wird. Das dies mit Adobe Sans MM nicht unbedingt gelingt, dürfte bei der obigen Darstellung klar sichtbar sein.

Wir reden übrigens von Einsparung von 50kB. Das ist marginal, vor allem angesichts der Tatsache, dass gerade Microsoft eher als Ressourcenfresser bekannt ist.

Der Grund liegt eher darin, dass die Tradition sich der Interoperabilität zu verschließen, auch heutzutage weitergeführt wird. Glücklicherweise lässt sich das Einbinden der Schriften erzwingen wenn man in den Optionen des Speichern unter.. Dialog den Modus ISO 19005 – PDF/A anwählt. Dieser Standard zur Langzeitarchivierung von pdf Dateien schreibt das Einbetten der Schriften vor.

Unter Mac OS X tritt das Problem nicht auf. Der Grund hierfür ist, dass zwar die Original Truetype Schriftart Arial auch nicht installiert ist, aber sehr wohl die Type 1 Schriftart ArialMT, die Zeichenkompatibel zu der originalen Arial Schriftart ist.

Interessanterweise tritt das Phänomen wirklich nur mit den klassichen MS Fonts auf. Ist der Text mit einem von den neueren, von Microsoft progragierten, Fonts, wie Calibri formatiert wird die Schriftart eingebetten. Zumindest alle Gylphen (Zeichen) die im Text vorkommen, daher Embedded Subset.

Im Bereich Messen, Steuern, Sensorik gibt immer noch die serielle Schnittstelle den Ton an.

Dumm nur, dass dieses Randpublikum kaum noch durch Hardwarehersteller bedient wird. Bei Laptops gibt es nur noch selten eine serielle Schnittstelle, bei Desktops teilweise auch nicht – oder zumindest wird kein D-Sub Stecker mehr von aussen zum UART (Serieller Baustein) des Mainboards verbaut.

Die Funktionalität muss daher durch andere Schnittstellen geführt werden und kaum etwas eignet sich schlechter als der Universal Serial Bus. Fast alle USB->Serial Kabel können höchstens ein paar Bytes über die Leitung kriegen. Sobald Timing oder Duplex-Verkehr gefragt ist, sind diese Kabel mit Chipsätzen von Prolific (ganz schlecht) oder FTDI überfordert.

Abhilfe schafft ein Transfer über den PCI Bus, bspw. mit einer ExpressCard.

Die DeLock 66217 ExpressCard34 arbeitet genauso so gut wie die interne Schnittstelle meines Desktop Rechners.
Die Karte benutzt die PCI-Express Verbindung der ExpressCard. In Ihr arbeitet ein Oxford Semiconductor Chip kompatibel zu 16C950 UART

Der Linux Treiber heißt 8250_pci, der aber die Kartenerkennung für diesen Chip erst seit Kernel 2.6.28 besitzt:

Vendor 1415 (Oxford Semiconductor Ltd.)

device c138

Mein openSUSE 11.0 System konnte daher nichts mit der Karte anfangen, erst ein Upgrade auf openSUSE 11.2 brachte das ganze ohne weiteres Eingreifen zum Laufen (8250_pci ist dort statisch in den Kernel einkompiliert und erfordert daher nicht die Kerneleinstellung CONFIG_EMBEDDED, siehe:
http://cateee.net/lkddb/web-lkddb/SERIAL_8250_PCI.html
Dass die Karte, die PCI Verbindung zum ExpressCard Slot benutzt sieht man schon an lspci, welcher den IRQ18 für den UART benutzt.

Die Karte hätte es übrigens in gleicher Bauform auch ein bischen billiger über die USB 2.0 Schnittstelle gegeben – DeLock 66211
Sehr wahrscheinlich mit allen gleiben Defiziten, wie die USB->Serial Kabel…