Änderungen mit Anmerkungen - Diskussion zur Entwicklung

Wir wollen jetzt massiv an diesen Teil gehen, daher hier die wichtige Frage, damit wir nicht in die falsche Richtung entwickeln:

Insbesondere für die Zusammenarbeit mit Lektoren wollen wir die Möglichkeit von Änderungsverfolgungen mit Kommentaren einbauen / erweitern.

Dafür brauchen wir “Feedback”.

Mit welchen MS Word-Versionen arbeitet Ihr Autoren mit Euren Lektoren zusammen?

Welche Funktionalität der Änderungsverfolgung ist dabei vonnöten - einstufig (alter Zustand <-> neuer Zustand umschaltbar reicht?) oder mehrstufig?

Kommentare direkt daran gekoppelt?

Und was Euch sonst so zu diesem Thema einfällt - bitte hier fleißig “mitentwickeln”! :slight_smile:

Dank und Gruß

Ulli

Also, bei mir arbeitet der Korrektor mit Word 2003. Ideal wäre es, wenn ich meine Datei als rtf abspeichern könnte, diese dann mit Word-Änderungen verfolgen bearbeitet werden kann und ich diese neue rtf oder doc-Datei dann mit Papyrus öffnen kann und sehen würde, was geändert ist. Bislang ist es so, dass ich die Änderung nur im Endergebnis sehe und auch nicht markiert. Idealerweise würde ich gerne einen Button haben “Änderung annehmen” oder eben ablehnen. Und noch ein Problem habe ich bislang mit rtfs, allerdings noch in der 13er Version ausprobiert: Meine Notizzettel erscheinen am Anfang des Absatzes der Verankerung als einfacher Text und sind später nur noch brutal zu löschen. Könnten die vielleicht per Export als Word-Kommentare erscheinen? Oder geht das schon und ich mach bloß was falsch.

Liebe Grüße

Regina

Hallo Ulli,

die Zusammenarbeit mit dem Lektorat zu erleichtern finde ich klasse! Nun zu deiner Frage: das Lektorat erfolgt bei mir über Word 2003. Perfekt wäre hier also eine möglichst reibungslose Zusammenarbeit mit Word. Im Prinzip finde ich die Funktionalität von Word auch ganz ausgeklügelt, d. h.

  • Vorgenommene Änderungen werden direkt im Text oder am Textrand kenntlich gemacht (ein Umschalten zwischen alt und neu reicht meines Erachtens nicht! das wird eine ziemliche hin- und herschalterei - sowohl bei mehreren kleineren Änderungen, als auch bei längeren Textpassagen, bei denen man gerne die 2 versionen zum direkten vergleich gegenüberstehen hat.) orignal und korrektur sollten mit einem blick zu erfassen sein.

  • Die Möglichkeit, die Änderungen “inline” oder als “Sprechblase” am Seitenrand anzeigen zu lassen finde ich sehr gelungen. Ersteres zeigt rasch kleine Änderungen im Text, letzteres belässt den Lesefluss des Originaltextes.

  • mit einem “Click” kann ich die Änderung annehmen, ablehnen oder zur nächsten Änderung springen (gerade letzteres spart viel Zeit und erleichtert das “Korrekturlesen” der Korrektur)

  • verschiedene Bearbeiter: finde ich eine gute Sache, wäre aber meines Erachtens nicht zwingend notwendig.

  • Die Möglichkeit, Änderungen zu kommentieren wird gern genutzt, vor allem bei inhaltlichen Korrekturen.

  • Praktisch: Die Markups zu filtern: Sollen nur Einfügungen und Löschungen, nur Kommentare oder nur bestimmte Bearbeiter gezeigt werden?!

  • Formatierungsmöglichkeit für die Überarbeitung: Vor allem, ob eine Löschung im Text als Durchgestrichen oder “Weggelassen” eingezeigt werden sollen nutze ich gerne.

  • Recht unübersichtlich finde ich bei Word, wenn zu viel angezeigt wird. Werden zum Beispiel an einem Absatz mehrere Änderungen (Löschung, Verschiebung, Ersetzung, Ergänzung) vorgenommen, dann kann rasch ein Wirrwarr entstehen. Hier würde mir völig ausreichen, dass der gesamte Satz einfach als “neu” markiert ist und die alte Version daneben/darunter/im Bearbeitungsfenster liegt. GENIAL wäre es natürlich (jetzt kommen die nachträglichen Weihnachtswünsche), wenn man definieren könnte, dass zum Beispiel ab 2 Korrekturen im Satz/Absatz, immer der ganze Satz/Absatz als neue Version vorliegt und nicht jedes Komma einzelnd aufgelistet wird. Das würden gerade bei punktuell größeren Eingriffen in den Text, die Arbeit erleichtern.

Freu mich schon auf die neue Version!

VG aus Potsdam!

MW

Sehr guter Ansatz. Zunächst einmal stimme ich in allem meinen Vorrednern zu. Auch ich kenne Word 2003 als momentanen Standard.

Wichtig finde ich die Unterscheidung der Korrekturart nach Farbe als mögliche Voreinstellung; z. B.: Löschen = rot, Hinzufügen = Blau, Formattierung = grün.

Wer mit mehreren Korrektoren arbeitet, wird sicher die farbliche Zuordnung nach Autor beforzugen - daher ist wohl beides sinnvoll.

Schön wäre es, wenn ich als Leser, der die Korrektur erhält, einstellen könnte, ob nach Korrekturart oder nach Autor farblich markiert wird.

Ich weiß nicht, ob ihr in Papyrus die Sprechblasen realisieren könnt oder wollt. Wichtig fände, ich die Umschaltung hin zu den klassischen Kommentaren, denn die Sprechblasen sind bei kleinen Monitoren (Netbook) unpraktisch, weil die Ansicht notgedrungen verkleinert wird; also wenn ja, dann wie in Word umschaltbar. Zweiter Schwachpunkt: Bei mehreren längeren Kommentaren auf einer Seite wird das Ganze mit den Sprechblasen unübersichtlich bzw. nicht mehr darstellbar.

Ganz wichtig: Falls es so etwas wie Sprechblasen gäbe, sollte man einstellen können, dass nur die Kommentare als Sprechblasen erscheinen - sonst wird das sehr unübersichtlich.

eine möglichkeit wäre vielleicht auch, statt sprechblasen, die korrekturen/originale in einem textstellenabhängigen fenster zu zeigen (vgl. korrekturlesen … nur dann etwas größer bzw. unter dem hauptfenster, wie z. b. die kommentare bei der gliederung)

VG

MW

Eine Alternative wäre genauso gut. Sprechblasen müssen nicht sein, wenn es eine andere Lösung gibt - ist nur bislang das Übliche bei Word und mittlerweile bei OpenOffice (3.0); somit eine Art Diskussionsgrundlage.

Das würde mir so auch gefallen!

Angenehm wäre es, eine Datei (RTF, DOC, DOCX, etc. ) zu exportieren. Der Lektor könnte dann seine Änderungen in der Textverarbeitung seiner Wahl durchführen.

Danach wird das Ergebnis des Lektors (RTF, DOC, DOCX, etc.) wieder mit dem Originalpapyrusdokument (PAP, PDF.PAP)zusammengeführt, wobei die Änderungen (Löschungen, Ergänzungen, Ersetzungen und Kommentare) geeignet im Originalpapyrusdokument markiert werden. Dies hat den Vorteil, dass sich im Gegensatz zum sonst notwendigen Konvertieren aufgrund dieser Systematik keine Formatierungsfehler o. a. einschleichen können und Querverweise und Papyrusspezialfunktionen 1:1 erhalten bleiben. Nur das so ergänzte Originalpapyrusdokument bleibt erhalten, der Import vom Lektor könnte gelöscht werden (oder als verbundenes Dokument verknüpft werden).

Kommentare als Erläuterungen, warum geändert wurden wären super. Auch die Idee bei mehr als x Änderungen den Satz (alte Version) nach Wunsch in einen Lektor-Notizzettel zu verschieben oder zu mumifizieren unterstütze ich.

Alternativ zum Anzeigen der Änderungen am Rand sollten sie hinter dem Text gelistet werden können:

  • Originalsatz

  • Änderung

  • Notiz, wer, wann geändert hat

  • Ggf. Kommentar, warum geändert wurde

Ich kommuniziere mit meinen Lektoren ausschließlich über RTF-Dokumente, weil ich seit Jahren kein WORD mehr einsetze, und kann daher sagen: Änderungsverfolgung per RTF funktioniert. (Auf meiner Seite benutze ich OpenOffice Writer, der (bislang! :smiley: ) beste WORD-Ersatz, was Änderungsverfolgung anbelangt.)

Grundsätzlich braucht man 3 Funktionen:

1. Lektorieren.

Das heißt meistens “Änderungen verfolgen” oder so, und gemeint ist, dass, wenn der Haken hier gesetzt ist, der aktuelle Text als fix betrachtet wird und alle Änderungen daran protokolliert werden: Hinzufügungen werden unterstrichen, Löschungen erscheinen durchgestrichen; außerdem werden Stellen, an denen sich etwa geändert hat (manchmal ist es ja nur ein gestrichenes Komma o.dgl.) durch einen Strich am Textrand angezeigt.

Ob das so aussehen muss? Früher, als man Manuskripte noch von Hand lektorierte, war gängige Praxis, die fraglichen Zeichen in der Zeile zu markieren (es gibt da ein ausgefeiltes Set von Korrekturzeichen; im DUDEN steht es noch abgedruckt) und den Änderungsvorschlag zusammen mit der Markierung an den Rand zu schreiben. Wenn jetzt “Sprechblasen” in Mode kommen, dann erinnert das ein bisschen an diese Praxis.

Auf der anderen Seite hatte auch diese althergebrachte Methode schon den Nachteil, dass es oft ziemlich gedrängt zugehen konnte: Denn änderungsbedürftige Stellen neigen dazu, sich zu ballen! Da war die etwas unübersichtlichere Darstellung, die WORD einst erfunden hat, durchaus flexibler.

2. Dokumente vergleichen.

Man gibt zu dem Dokument, das man gerade geladen hat (A), ein anderes Dokument an als “vergleiche mit” (B), und es entsteht ein Bild, das dem unter (1) entspricht: Alles aus A, was in B nicht vorhanden ist (also gelöscht), erscheint durchgestrichen; alles, was in B zusätzlich zu A vorhanden ist, erscheint als Einfügung.

Das ist eine trickreiche Funktion, denn das Programm muss erkennen, ab wann zwei Dokumente wieder identisch weitergehen: Das kann (oder konnte zumindest, als ich noch den Vergleich hatte) WORD besser als alle anderen. Problematisch wird es nämlich, wenn ein Stück Text durch ein anderes Stück Text (von anderer Länge) ersetzt wurde. In OpenOffice kam es manchmal vor, dass ab da der Rest des Dokuments erst mal gestrichen und dann wieder identisch ein gefügt angezeigt wurde!

3. Lektorat einarbeiten.

Man kriegt nun ein lektoriertes Dokument zurück (im Fall von Papyrus entweder ein DOC oder RTF) und hat die Aufgabe, alle Änderungsvorschläge durchzusehen und zu entscheiden: Ja, will ich so haben; Nein, soll so bleiben, wie es ursprünglich war; Weder-noch, ich schreibe das ganz anders.

Der letzte (häufige!) Fall erfordert, dass man so einen Durchgang durch die Änderungen unterbrechen und nachher wieder aufnehmen kann.

Auch sollte man nicht gezwungen sein, immer eine Entscheidung zu treffen, sondern auch sagen können: Überlege ich mir später, lass die Änderung einstweilen so stehen.

All unsere Überlegungen besitzen allerdings eine Grenze: Die Bearbeitung von doc- oder rtf-Dateien funktioniert schmerzfrei nur bei sehr einfachem Layout - hier im Forum geht es ja häufig um fiktionale Literatur. Da wird es kaum Probleme geben - ist ja meist reiner Text.

Im Sachbuchbereich wird die Sache wohl schwieriger werden, da Papyrus bekanntlich Word nicht verlustfrei im-/exportieren kann, wenn das Layout komplizierter ist. Auch wenn Bücher (zumeist) neu gesetzt werden, wünschen Verlage, dass Abbildungen und Tabellen schon an den Positionen eingefügt werden, an denen sie später erscheinen sollen. Wie gehen wir denn damit um?

Vielleicht schickt man die konvertierte Datei und eine pdf? Gerade habe ich einen Verlag, der ohnehin doc und pdf möchte. Besagter Verlag gibt sich aber auch mit Verweisen zufrieden, an denen die Position für die Abbildungen angezeigt werden. Dann wäre man ja wieder aus dem Schneider.

Zum Thema “Schwierigkeit des Textvergleichs”:

An und für sich ist ein Textvergleich algorithmisch recht einfach machbar. Man kann beispielsweise die “Longest Common Subsequence” (LCS) berechnen. Das zugrundeliegende Problem ist zwar NP-vollständig, es gibt jedoch viele praktikable Algorithmen dafür, auch sehr einfache. Das ist längst kein Elfenbeinturm-Thema mehr. Selbst das gute alte Unix-Programm “diff” verwendet diese Methode. Für ein Textverarbeitungsprogramm wie Papyrus ergeben sich dabei ein paar Besonderheiten:

  1. Textdokumente sind hierarchisch

Im Gegensatz zu einfachen Textdateien sind Textdokumente hierarchisch gegliedert: Es gibt Absätze, Überschriften usw. In einer Perfekten Welt würden die Dokumente hierarchisch verglichen werden. D. h. Wenn sich ein Absatz von einer Stelle eines Dokuments an eine völlig andere bewegt, wird er einfach “umgehängt”. Nichthierarchische Diff-Algorithmen kennen jedoch nur “Löschen” und “Einfügen” - kein “Bewegen”. Bei semantisch stark strukturierten Dokumenten (z. B. in Redaktionssystemen) macht ein solcher hierarchischer Vergleich durchaus Sinn. Die Firma in der ich arbeite hat so etwas entwickelt. Ich war selbst eine zeitlang mit dem Thema betraut; das ist schon eine ganz andere Klasse und äußerst schwierig zu lösen.

Für ein normales Textverarbeitungsprogramm wie “Papyrus” halte ich so etwas für übertrieben.

  1. Textdokumente enthalten Stilinformationen.

Nicht nur der Text an sich kann sich ändern, auch die Stilinformation. Wird aus einer Überschrift erster Ebene eine in zweiter Ebene? Oder ein Absatz wird zu einem “Zitat”? Auch diese Änderungen müssen erkannt werden.

Ich präferiere ebenfalls eine Lösung, bei der ein lektorierter Text wieder in das Hauptdokument “zurückgeführt” wird. Ich finde es ist ein fundamentales Problem bei Autor-Lektor Workflows mit unterschiedlichen Textverarbeitungssystemen. Was man als RTF herausgibt, bearbeitet jemand anderes mit einem völlig anderem Tool und gibt es wieder zurück; jedes mal gibt es kleine (unnötige) Verluste: Das Ergebnis gleicht dem ursprünglichen meist nicht mehr sehr. Wir haben es mit drei Dokumenten zu tun:

  1. Hauptdokument (Papyrus)

  2. Lektorenexport (z. B. rtf)

  3. Lektorierter Text (z. B. rtf)

Ein Vergleich von 2 und 3 ergibt, was man in 1 ändern muss.

Viele Grüße,

Jochen Schmidt

Ich probiere gerade die Kommentar- und Überarbeitungsfunktionen vom neuen Pages 9 aus iWorks aus. Die sind mit denen von Word identisch, nur deutlich einfacher und leichter zu handhaben. Man kann ohne Verluste der Überarbeitungen oder Kommentare hin- und herkonvertieren.

Meiner Meinung nach ist Word mit diesen Funktionen Maßstab und Standard. Im Gegensatz zu anderen Programmteilen haben sie das gut gemacht. Papyrus sollte sich also daran orientieren.

Ich zweifele allerdings stark daran, daß Papyrus Autor ähnlich kompatibel in beide Richtungen werden könnte. Schon das Stammseitenkonzept ist unverträglich mit dem Seitenlayout von Word. Nur mal ein Beispiel: Wenn Word auf einer Seite zweispaltig mit einspaltig mischt, kann Papyrus das unmöglich darstellen. Zweispaltige Texte von Word werden bei mir jedenfalls immer noch grundsätzlich einspaltig umgebrochen. Das mag für Erzählungen und Romane keine Rolle spielen, es verdeutlicht aber die Beschränkungen durch das Stammseitenkonzept von Papyrus. Das sicherlich andere Vorteile hat.

Also kompatibilität zum MS Office Überarbeitungsworkflow ist für mich eher zweitrangig. Ich fand den Ansatz immer schon ranzig. Leider macht in jeder andere - einschließlich Apple einfach 1 zu 1 nach. Das Problem ist, das dazu dasselbe Dokument abwechselnd in zwei unterschiedlichen Textverarbeitungssystemen bearbeitet wird. Nach meiner Erfahrung zerhaut das immer irgendwas. Mal davon abgesehen, dass der Output mancher Textverarbeitungsprogramme andere auch gerne mal abstürzen lässt. Ich befürchte leider, dass auch ein Hin-und-Her zwischen MS Office und Papyrus mit ständigen Problemen geplagt wäre.

Deshalb finde ich es besser, wenn man stattdessen als Autor sein (Papyrus) Dokument unverändert beibehält, ein RTF oder Worddokument als Lektorexport herausschreiben könnte und der Lektor einem das bearbeitete Dokument zurückschickt. Dieses Dokument kann ich dann per Programmfunktion in mein Papyrus-Dokument einpflegen. Ein Vorteil: Das Lektor-Exportdokument kann möglicherweise stark vereinfacht werden - es geht meistens ja nur um den Textinhalt nicht so sehr um Layout oder irgendwelche Spezialfeatures. Die Überarbeitungs und Kommentarfunktionen zwischen Lektorexport und lektoriertem Dokument dürfen von mir aus auch MS Office kompatibel sein. Papyrus liest dann die Kommentare und Änderungen heraus und stellt sie mir im Papyrus-Dokument zur Einarbeitung bereit.

Viele Grüße,

Jochen Schmidt

Die Erklärung dafür ist relativ einfach: Der Spaltensatz von Word ist ein Absatzattribut, das von Papyrus nicht unterstützt wird. Insofern ist die einspaltige Darstellung richtig.

Das würde auch meiner Meinung völlig genügen. Das Problem ist aber doch, die zugrundeliegenden Papyrusversionen 1:1 in RTF-Dokumente zu übertragen, so daß sie unter Word genauso aussehen. Das klappt ja jetzt schon nicht, ohne Kommentar und Überarbeitungsfunktionen.

Was nützt einem ein theoretischen “richtig”, wenn man die Dokumente nicht mit Papyrus öffnen kann, ohne das gesamte Layout zu zerstören? Bei Papyrus wird der Spaltensatz durch die Stammseite bestimmt, deswegen kann man auch nicht einfach auf einer Seite zwischen einspaltig und zweispaltig wechseln, wie bei der Konkurrenz, bei der man absatzweise wechseln kann.

Ich habe die größten Probleme, wenn ich ein Word- oder RTF-Dokument mit Papyrus öffne. Oder ein Papyrusdokument als RTF-Dokument oder Worddokument exportiere. Habe mir das bisher mit diesem Stammseitenkonzept erklärt, aber auch Attribute wie Silbentrennung und Sperrung werden von Word zu Papyrus nicht übernommen. Bilder oder Grafiken verschwinden meist komplett in beide Richtungen. Von daher bin ich sehr skeptisch, wenn es um die Übertragung zusätzlicher Funktionen geht. Und neidisch wenn ich sehe, wie gut Open-Office oder Pages das können. Vielleicht weil Open-Office MS-Word konzeptionell näher steht. Deswegen könnte ich auch nie damit arbeiten. Bei Pages sieht die Sache allerdings anders aus, das ist keine Wordkopie. Apple geht auch hier einen eigenen Weg, der die Möglichkeiten der Benutzer, Einfluß auf die Funktionen zu nehmen, sehr beschränkt.

Das ist ja gerade, was ich mit dem expliziten Lektorexport meine; der soll gar nicht unbedingt 1:1 nach RTF kommen. Natürlich wäre diese Funktion dann wohl nur für Autoren interessant, deren Lektoren ihre Werke rein inhaltlich bearbeiten. Wenn ich das richtig verstehe scheinen manche Forumsmitglieder hier ihren Lektoren quasi fast fertig layoutete Dokumente zuzuschicken. Da Frage ich mich: Wäre für diese Aufgabe nicht eher etwas wie InDesign+InCopy geeignet? Also DTP anstatt Textverarbeitungen wie MS Word, Pages oder Papyrus? Bitte nicht falsch verstehen - ich möchte hier niemanden “sein” Papyrus schlecht machen oder jemanden in die Wahl seiner Werkzeuge reinreden; für das genannte Feature wäre es jedoch interessant festzulegen wie denn nun der genaue Zweck einer solchen Funktion wäre. Ich bezweifle einfach, dass eine Lektorierungsfunktion inkl. DTP-Layout programmübergreifend realisierbar ist.

Grüße,

Jochen

Ich sehe den Nutzen darin, dass der gesamte Text gelesen und übernommen werden kann.

Eine Layout-Übernahme kann bei so unterschiedlichen Konzepten wie Stammseiten (papyrus) und mehrspaltigen Absätzen (Word) nicht erreicht werden. Eine gewisse Abhilfe könnte nur dann geschaffen werden, wenn papyrus eine Funktion für mehrspaltige Absätze bekäme.

Das Stammseitenkonzept von papyrus ist viel näher an der Musterseitenfunktion, wie sie z.B. in Indesign gibt. Eine Umwandlung von papyrus- in Indesign-Dokumente wäre deshalb wahrscheinlich nahezu verlustfrei möglich. Allerdings ist über das Indesign-Dokumentformat vermutlich noch viel weniger bekannt als über Word.

Die Probleme hat man manchmal schon, wenn man ein papyrus-Dokument als RTF exportiert und danach das RTF wieder mit papyrus öffnet. Je nach Komplexität erkennt man nicht viel wieder …

Stimmt. Selbst beim Wechsel von Papyrus Mac zu Papyrus Win gehen die eingebetteten Bilder verloren.

Machbar ist es sicherlich – aber nicht ganz trivial, weil auch solche Sachen wie Objektumfluss beachtet werden müssen.

… sofern die Bilder am Mac als QuickTime-Bild, PICT-Bild oder PDF eingebettet wurden. Bitmap-Bilder funktionieren ansonsten relativ problemlos.