Mein erstes Fazit

[NoSi]

Ich habe seit Erscheinen der TextMaker Beta sehr intensiv damit gearbeitet und sogar ein konkretes Projekt darin „riskiert“. Was jedoch keine Entscheidung aus Langeweile, sondern eine sehr praktische, wohlüberlegte, mit konkretem Hintergrund war.

Das habe ich zu keiner Zeit bereut – im Gegenteil: Für diese Art Texte werde ich verstärkt auf TextMaker zugreifen.

Allerdings sind wesentliche „Nervpunkte“ geblieben, die eine vollständige Ablösung anderer Produkte mit TextMaker weiterhin unmöglich bzw. „zu zeitaufwendig“ machen. Die waren/sind lt. Beta-Änderungsliste kein Bestandteil des geplanten Updates, weshalb es hier keine weitere Ausführung dazu gibt. Ich habe das in einem Blog-Beitrag zusammengefasst – falls es irgendwen interessiert.

[Gariniranus]

Interessanter Bericht!

"Das Adjektiv kompatibel hat seinen Ursprung im lateinischen Wort compati (mitfühlen). Im Deutschen wird es heute als ein Adjektiv für etwas verwendet, womit ausgedrückt werden soll, dass etwas in bestimmten Eigenschaften übereinstimmt. Weitere Synonyme sind „vereinbar“ oder „verträglich“."

https://neueswort.de/


https://forum.softmaker.de/viewtopic.ph ... ft#p115994

Problem.png (512 KiB) 1904 mal betrachtet

[Jossi]

Hallo NoSi, ich habe in dem verlinkten Blogbeitrag zum Thema Duplizieren von Objekten den Satz gefunden: „Wird das Duplikat ausgeschnitten, wird es als „Zeichen“ auf anderen Seiten eingefügt.“ TextMaker unterscheidet ziemlich strikt zwischen Text und Objekten, weshalb es auch einen Editmodus (zum Bearbeiten von Text) und einen Objektmodus (zum Bearbeiten von Objekten) gibt. Wenn man ein Objekt im Editmodus einfügt, wird es als Textbestandteil (Zeichen) behandelt. Um es als Objekt einzufügen, muss man vor dem Einfügen in den Objektmodus gehen. Das mag auf den ersten Blick verwirrend wirken, aber wenn man sich den Unterschied einmal klar gemacht hat, ist die separate Bearbeitung von Objekten im Objektmodus – für mich jedenfalls – eine Erleichterung. Jedenfalls war es einer der Gründe für meinen Wechsel von Word zu TextMaker, dass ich mich in Word ständig zwischen Text und Objekten verheddert hatte, weil es keine konsequente Trennung gab.
Natürlich hat dieses Prinzip auch Nachteile – zum Beispiel, dass man Text und Objekte nicht gemeinsam kopieren und einfügen kann, sondern immer zwei Kopiervorgänge (einmal im Edit- und einmal im Objektmodus) benötigt.

[NoSi]

"Das Adjektiv kompatibel hat seinen Ursprung im lateinischen Wort compati (mitfühlen).

Wenn ich morgens aus dem Haus zur Arbeit gehe, tue ich das, weil ich sowohl zu Hause als auch auf der Arbeit kompatibel zu den jeweiligen Anforderungen bin. Verändert sich auf dem Weg hin und her jedoch meine Augen-, Haar- oder Hautfarbe, werden mir Firma oder Partner ein Ultimatum stellen. Beide werden konstatieren, dass ich mit sich verändernden Grundeigenschaften für sie „nicht kompatibel genug“ bin.

Wohingegen es kein Kompatibilitätsproblem darstell, morgens mit einer anderen Laune als abends unterwegs zu sein, oder dass mir die Fleischklopse zu Hause besser schmecken als die in der Kantine salzarm vegan zubereiteten. Entscheidend für mich ist: Wir haben sowohl als auch Stühle, Tische und saubere Toiletten als gemeinsamen Nenner.

[NoSi]

Zusammengefasst: Unterschied Editmodus vs. Objektmodus

Programme sollen gern eigene Wege gehen – ansonsten gäbe es keine Programmvielfalt, die unterschiedliche Vorlieben bedient. Das ist wie bei Autos. Die haben sich trotz individuell z.T. großer Unterschiede dennoch so erfolgreich durchgesetzt, weil alle ein Lenkrad haben und das Bremspedal immer links, das Gaspedal immer rechts ist. Für den Unterschied Schalt- und Automatik-Getriebe gibts – wahlweise – ein Zusatzpedal in der Mitte, für weitere Features gibt's Knöpfe im Armaturenbrett oder auf dem Lenkrad.

Sobald ein Objekt mit einem Anker einem Absatz zugeordnet ist, stellt das eine gewollte, schützenswerte kontextuelle Verbindung zwischen Text und Objekt dar. Diese muss bei allen Kopier- und Verschiebeoperationen respektiert werden, ansonsten wäre das Herstellen von Beziehungen zwischen Objekten und Text wie ein One-Night-Stand: Man hat eine Zeit lang ein bisschen Spaß miteinander, doch eine echte Beziehung ist es halt keine. So ein Typ bin ich nicht.

Zurück zum Auto: Wenn ich einen Kasten Limo in den Kofferraum stelle, fährt der ohne Murren mit mir nach Hause. Wenn ich erst das Auto in die Garage stelle und dann noch zurück muss, um den Limokasten zu holen, kann ich gleich mit dem Fahrrad fahren und den Limokasten auf's Lenkrad stellen.

[Gariniranus]

"Das Adjektiv kompatibel hat seinen Ursprung im lateinischen Wort compati (mitfühlen).

Wenn ich morgens aus dem Haus zur Arbeit gehe, tue ich das, weil ich sowohl zu Hause als auch auf der Arbeit kompatibel zu den jeweiligen Anforderungen bin. Verändert sich auf dem Weg hin und her jedoch meine Augen-, Haar- oder Hautfarbe, werden mir Firma oder Partner ein Ultimatum stellen. Beide werden konstatieren, dass ich mit sich verändernden Grundeigenschaften für sie „nicht kompatibel genug“ bin.

Wohingegen es kein Kompatibilitätsproblem darstell, morgens mit einer anderen Laune als abends unterwegs zu sein, oder dass mir die Fleischklopse zu Hause besser schmecken als die in der Kantine salzarm vegan zubereiteten. Entscheidend für mich ist: Wir haben sowohl als auch Stühle, Tische und saubere Toiletten als gemeinsamen Nenner.

[Jossi]

Sobald ein Objekt mit einem Anker einem Absatz zugeordnet ist, stellt das eine gewollte, schützenswerte kontextuelle Verbindung zwischen Text und Objekt dar. Diese muss bei allen Kopier- und Verschiebeoperationen respektiert werden, ansonsten wäre das Herstellen von Beziehungen zwischen Objekten und Text wie ein One-Night-Stand: Man hat eine Zeit lang ein bisschen Spaß miteinander, doch eine echte Beziehung ist es halt keine. So ein Typ bin ich nicht.

Grundsätzlich einverstanden, nur:
Ich füge auf Seite 1 meines Dokuments einen Grafikrahmen ein und verankere ihn an einem Textabsatz. In den Grafikeigenschaften kann ich einstellen: „Wenn das Objekt verschoben wird, den Anker am aktuellen Absatz verankert lassen“. Wird das Objekt jetzt verschoben, indem ich Text vor dem Absatz einfüge, an dem es verankert ist, dann passiert genau das, was Sie wünschen: Die Verbindung zwischen Text und Objekt bleibt erhalten, egal wohin der Absatz wandert.
Wenn ich hingegen eine Kopie des Objekts mache und diese Kopie auf einer anderen Seite einfüge, dann wird die Kopie am nächstgelegenen Absatz auf dieser Seite verankert. Das ist nun wiederum genau das, was ich mir wünsche; denn wenn ich ein Objekt auf, sagen wir, Seite 5 einfüge, dann ergäbe es, für mich jedenfalls, keinen Sinn, wenn dieses Objekt an einem Absatz auf Seite 1 verankert wäre.

Grundsätzlich ist es in TextMaker so, dass eine Verankerung eines Objekts an einem Absatz nicht seitenübergreifend funktioniert; d. h. Objekt und Absatz müssen sich immer auf derselben Seite befinden. Das halte ich für sinnvoll; ich möchte mir nicht vorstellen, was für ein Chaos beim Bearbeiten eines Dokuments entstünde, wenn darin befindliche Objekte an irgendwelchen weit entfernten Seiten verankert wären.

Beim Duplizieren ist es nicht anders: Befindet sich das duplizierte Objekt auf derselben Seite wie das ursprüngliche, ist es auch am selben Absatz verankert wie das Original. Es lässt sich daher auch nicht mit der Maus auf eine andere Seite verschieben. Wenn ich das will, muss ich in den Grafikeigenschaften des Objekts „Wenn das Objekt verschoben wird, den Anker zum nächstgelegenen Absatz verschieben“ einstellen.

[NoSi]

@Jossi:
Ich will keine „seitenübergreifenden Verankerungen“, ich will lediglich, dass einen Absatz, an dem ein Bild als Objekt verankert ist, genauso behandelt wird wie ein Bild, das dort als Zeichen-Objekt eingefügt wurde. Doch das wird von TM unterschieden, wofür es keine sinnvolle Erklärung gibt.

Grundsätzlich haben Grafiken bei TM immer einen Absatzbezug, sie sind „Bestandteil des Textes“:

• Wenn ein Bild „als Zeichen“ im Absatz liegt und ich wandle es in ein Objekt um, bekommt das Objekt eine Position relativ zur Seite statt zum Absatz zugewiesen. „Als Zeichen“ war es ein Absatzobjekt, jetzt „sieht es nur so aus“.
  Allerdings wird es mit dieser Formatierung kein Objekt „dieser“ Seite, sondern es ist ein Objekt des Absatzes, der es relativ zur Seite, auf der er sich befindet, anzeigt. Das ist bei großen, raumfüllenden Grafiken sinnvoll.
  Kleine, umflossenen Grafiken (ist ebenfalls der Standard) im Absatz liegen bei einem Seitenwechsel allerdings „irgendwo“ – was ich mit einer Verankerung am Absatz verhindern kann.
  Unabhängig von Änderungen des Textflusses werden Bilder mit den Positionsangaben relativ zum Absatz bewegt – auch über Seitenumbrüche hinweg.

Allerdings betrachtet TM Grafik-Objekte bei Blockfunktionen im Editmodus unterschiedlich.

• Ist das Bild „als Zeichen-Objekt“ eingefügt, klappt das Ausschneiden → Einfügen problemlos: Das Bild wird im Absatz mitbewegt.
• Ist das Bild „als verankertes Objekt“ im Absatz eingefügt, wird es nach dem Ausschneiden an den vorangegangenen Absatz gehängt — statt als Bestandteil des Absatzes bewegt zu werden.
  Dabei ist es völlig egal, ob der Anker „anm nächstgelegenen“ oder „am aktuellen“ Absatz verankert ist: Die Eigenschaft wird kommentarlos an den Vorgänger übernommen. Allerdings hatten Bild und Absatz bis dahin keinerlei Kontext – der wird einfach hergestellt.

Besonders fatal wird es, wenn mehrere Absätze mit mehreren Objekten mit Blockfunktionen ausgeschnitten und an anderer Stelle eingefügt werden sollen. In der Animation sind alle Bilder „am aktuellen Absatz“ verankert – die sind mit Hervorhebungen („fett“) markiert, auf der Nächsten Seite gibt es reichlich Text zum „nachfließen“. Und jetzt stellen wir uns mal vor, das ist ein langes Dokument, bei dem ich das öfter machen muss, und da sind keine rot markierten Absätze drin:

imagekiller.gif (962.76 KiB) 1850 mal betrachtet

Wer es selbst versuchen will, kann das mit dem anhängenden Demo-Dokument ausprobieren. Worin der Unterschied besteht, wird offensichtlich, wenn die Objekte per Rechtsklick in „eingebettete Objekte“ umgewandelt werden. Terminus beachten: Das sind per definitionem ebenfalls Objekte. Werden die anschließend ausgeschnitten … → selbst ausprobieren.

[Jossi]

In zwei Punkten sind wir uns, denke ich, einig:

1. TextMaker ist nicht in der Lage, Text und Objekte (Grafikrahmen, Textrahmen usw.) gemeinsam (in einem Arbeitsgang) zu kopieren oder zu verschieben.
Das liegt daran, dass, wie ich schon schrieb, die Textebene und die Objektebene in TextMaker strikt getrennt sind. Text wird auf der Textebene bearbeitet, Objekte auf der Objektebene, beides zusammen geht nicht. Ich kann immer nur auf einer der beiden Ebenen arbeiten. (Die sogenannten „eingebetteten Objekte“ heißen zwar so, sind aber eigentlich keine. Sie liegen auf der Textebene und werden in jeder Hinsicht genau so behandelt wie ein Buchstabe des Textes. Dadurch können sie zwar gemeinsam mit dem Text ausgeschnitten, kopiert und eingefügt werden, dafür haben sie aber zahlreiche andere Nachteile: nicht frei positionierbar, keine feste Position auf der Seite möglich, automatische Zeilenhöhen werden verändert und so weiter. Es ist daher in fast jedem Fall günstiger, mit echten Objekten (Grafikrahmen) zu arbeiten.) Der Befehl „In eingebettetes Objekt umwandeln“ bedeutet eigentlich so viel wie „in Textelement umwandeln und auf die Textebene verschieben".
Es trifft daher auch nicht zu, dass Objekte in TextMaker immer einen Absatzbezug hätten und Bestandteil des Textes wären. Wenn ich in den Grafikeigenschaften eines Objekts „Fest auf Seite“ und „Relativ zu Seite“ einstelle, gibt es keinerlei Bezug zu irgendeinem Text. Ich kann die Objekte ebenso gut auf einer völlig leeren Seite positionieren und bearbeiten.

2. Wenn ein Objekt relativ zu einem Textabsatz positioniert ist und dieser Absatz verschwindet danach (durch Löschen oder Ausschneiden), dann verliert das Objekt die Verbindung zu diesem Absatz und wird automatisch relativ zum nächstgelegenen Absatz positioniert.
Das ist die unmittelbare Konsequenz des unter 1. beschriebenen Umstands, dass Text und Objekte nicht gemeinsam bearbeitet werden können. Beim Ausschneiden müssten Text und Objekt zusammen in die Zwischenablage wandern, und das geht nicht. Ebenso enthält der ausgeschnittene Text keine Information darüber, dass und wo ein Objekt an ihn angebunden ist, so dass diese Anbindung nach dem Wiedereinfügen des Textes wiederhergestellt werden könnte. Die Information über die Positionierung „relativ zu Absatz“ ist im Objekt (genauer: dessen Eigenschaften) gespeichert, nicht im Text. Der einzige Workaround für dieses Problem ist daher, zuerst im Objektmodus die Grafikobjekte auszuschneiden und auf der neuen Seite einzufügen. Da der Absatz, an dem sie ursprünglich verankert waren, auf dieser Seite nicht existiert, wird beim Einfügen der Objekte ein passender Absatz ausgewählt (bzw. auf einer leeren Seite ein neuer leerer Absatz geschaffen), an dem sie verankert sind. Anschließend kann man im Editmodus den dazugehörigen Text ausschneiden, den Cursor auf der Zielseite in den entsprechenden Absatz setzen und den Text dort einfügen. Dann stimmt es wieder.

Ich gebe aber gerne zu, dass das in jedem Fall ein umständliches Verfahren ist und eine gemeinsame Bearbeitung von Text und Objekten wesentlich komfortabler wäre. Nur fürchte ich, dass die SoftMaker-Programmierer, um das zu implementieren, sehr tief in die Eingeweide des Programms hinuntersteigen müssten.

[NoSi]

Ich spreche nirgends davon, gleichzeitig Text und Grafik zu bearbeiten – das macht kein Text-Programm.

Ich spreche lediglich davon, dass der Kontext von Elementen behalten wird – das machen alle Textprogramme.
Bis auf die Kopier-Operationen verhält sich TM absolut identisch zu anderen Programmen und wird auch analog dazu bedient.

Was es umso verwunderlicher macht, dass es beim Kopieren am Standardverhalten von allen mir bekannten Mitbewerbern scheitert.

Es wird schlicht zu einem unbrauchbaren Text-Werkzeug, wenn für Umstrukturierungen absatzweise gearbeitet werden muss, damit Bildverknüpfungen jeweils wieder durch einen zweiten Kopierschritt restauriert werden können.


Die „Ebenentheorie“ ist ein schönes Bild – als Programmier würde ich mir diesen Aufwand allerdings sparen – allein schon aus Kompatibilitätsgründen (s.u.). Für verschiedene Objekte im Objektbaum werden unterschiedliche Editoren verwendet. Bild-Parameter als Text bearbeiten ist was für Freaks. Es gibt keine „strikte Trennung“, die Objekte hängen „im Text“ und werden relativ zu ihm bewegt – allerdings inkonsistent. Denn „relativ zur Seite“ ist – je nach Aktion!! – ziemlich absolut (Text davor einfügen, Bild auf Seite2 bleibt auf Seite 2) oder tatsächlich relativ (Seitenumbruch davor einfügen Bild wandert von Seite 2 auf Seite 3).

Es wäre ein erheblicher Aufwand, zwei „strikt getrennte Ebenen“ zu verwalten, damit am Absatz verankerte Bilder synchron mitfließen. Die Bearbeitung von Word-Dokumenten stelle ich mir unter diesen Bedingungen brutal aufwändig vor; das Format hat keine Trennung und ich kann es im Original DOCX-Format mit TM bearbeiten.

Oder in Kurzform: Hier sehe ich eine Baustelle, die dringend behoben werden sollte, damit konsistente Bearbeitung – auch im Kontext mit der beworbenen „Word-Kompatibilität“ – gewährleistet ist.

[Jossi]

Nur um Missverständnisse auszuschließen: Mit „gemeinsam bearbeiten“ meinte ich natürlich nicht Bildbearbeitung (obwohl TextMaker da auch einige Funktionen anbietet), sondern kopieren, einfügen und verschieben.

[NoSi]

Nur um Missverständnisse auszuschließen: Mit „gemeinsam bearbeiten“ meinte ich natürlich nicht Bildbearbeitung (obwohl TextMaker da auch einige Funktionen anbietet), sondern kopieren, einfügen und verschieben.

Genau davon spreche ich: GEMEINSAM kopieren – so wie das alle anderen Programme machen. Denn so, wie es ist, ist es ein klares k.o.-Kriterium für ernsthafte Verwendung im Dokumentationsbereich. Was bedauerlich ist, denn mit den übrigen „inneren Werten“ kann TM klar überzeugen.