Das Notes Forum
HCL Notes / Domino / Diverses => Entwicklung => Thema gestartet von: Tode am 26.11.21 - 08:19:21
-
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 (https://atnotes.de/index.php?topic=24703.0) 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...
-
Hallo Tode,
ich denke auch dass Du da ein Ticket anlegen musst.
Machst Du das am Client und benötigst eigentlich nur die Möglichkeit, ein temporäres Dokument via DXL anzulegen und anschließend wieder zu löschen? In dieser Konstellation nutze ich für eine ähnliche Funktion die lokale cache.ndk als temporäre Datenbank, das klappt ganz gut.
Viele Grüße
-Werner
-
Danke für das Feedback. Ja, es ist am Client... insofern wäre die cache.ndk eine gute Möglichkeit, werde das mal testen... Danke für den Hinweis