Wenn man ein Profildokument mit einem Richtextitem mittels NotesDXLExporter exportiert, und anschließend -vollkommen unmanipuliert- mittels NotesDXLImporter wieder importiert, dann verliert das Richtextitem sämtliche Fonts. Das gesamte Item wird in einer der "Default"- Fonts (Default Mono, Default Serif, Default Sans Serif) angezeigt, es sieht so aus, als wäre diese irgendwie aus dem ersten Font im Item abgeleitet.
Siehe Bild: Vorher links, nachher rechts. Schriftart im Bild rechts: Default Monospace
Das exakt identische Richtextitem als Dokument exportiert und importiert zeigt dieses Verhalten nicht.
Das Problem lässt sich in allen Client- Versionen von 9 - 12.0.1 Beta2 nachvollziehen.
Ich habe mal eine Testdatenbank angelegt. Die beiden hier angehängten txt- Files sind umbenannte XML- Files, die als Export aus der Test- Datenbank entstanden sind: Einmal das Dokument, einmal das Profil.
Man kann sich die Dokumente anschauen (das Profil über "Edit Profile"- Aktion): Alles OK.
Nutzt man die beiden Agenten, um die DXL- Files zu importieren (Pfade anpassen), dann sieht man: Das Dokument ist danach immer noch OK, das Profildokument ist kaputt...
Hilft wohl nur ein Ticket bei HCL, oder was meint ihr?
Es gab einen
sehr sehr ähnlichen Bug schonmal in Notes 4, allerdings beim direkten manipulieren von Richtextitems mittels CopyToDocument oder RichtextItem.AppendRichtextItem. Der Workaround für diesen ($Fonts- Item kopieren) funktioniert aber hier nicht (weil kein $Fonts item im Export auftaucht)
Hintergrund: ich verwende XML- Operationen um Platzhalter in einem Richtextfeld zu ersetzen, und dazu verwende ich ein Profil als "Zwischenspeicher"... und dabei geht die Schriftart verloren...
Thema: NotesDXLImporter "verliert" Font bei Profildokumenten... (Gelesen 1877 mal)