mmaass
Beiträge: 88
4. Jan 2008, 17:28
Beitrag #56 von 63
Beitrag ID: #329243
Bewertung:
(4554 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
|
neue und alte Bugs – noch nicht in der Bugliste
|
|
Hallo Drienko,
danke für die Mitteilung. Aber es wundert mich schon etwas, muss ich sagen.
Zugegebenermaßen eine sehr bizarre "Funktion", beim Import von XPress-Tags bei geschlossener Index-Palette oder beim Kopieren/Einsetzen von Text (egal, ob die Palette sichtbar ist oder nicht) die Marken zu entfernen und sie andererseits beim Duplizieren oder Kopieren ganzer Rahmen mit Text bestehen zu lassen. Raffiniert!
Quark sieht es also nicht als Bug an, dass wichtige Tags beim Import als XPress-Tags oder beim Kopieren/Einsetzen verschwinden. Na dann ist ja alles gut. "Es kann nicht sein, was nicht sein darf."
Mal ehrlich: Quark sieht so einiges nicht als Fehler an, oder? Tauchen alle in diesem Thread oder an anderer Stelle genannten Fehler in einer offiziellen Fehler-Aufstellung von Quark auf. Sicher nicht.
Ich weiß nicht, wen Du gefragt hast, aber selbst wenn das die offizielle Ansicht von Herrn oder Frau Quark ist, ist und bleibt das - zumindest für mich und alle, die mit XPress-Tags und Indexmarken arbeiten - ein Fehler. Ein sehr schwerer dazu. Ein Fehler, den Quark - nach meinen Gesprächen und eMail-Austausch mit der Hotline und mit Quark-Mitarbeitern zudem durchaus als solchen ansieht.
Mal als Analogie: Wenn die Palette "Stilvorlagen" beim Import von XPress-Tags geschlossen ist, werden die Stilvorlagen (@MeineAbsatzStilvorlage: bzw. <@MeineZeichenStilvorlage>) trotzdem auch über den Markentext importiert. Wenn die Palette "Farben" beim Import geschlossen ist, wird eine im Markentext angegebene Farbe (<c"MeineFarbe">) selbstverständlich trotzdem interpretiert und nicht "silently ignored". Das Gleiche gilt selbstverständlich für Kopieren/Einsetzen.
Nur beim Import von Markentext, der mit Indexmarken (<XO>Wort<XC,"Wort","","","",0, 0,"">) versehen ist, fliegen die Tags sang- und klanglos raus, wenn die Palette "Index" nicht geöffnet ist? Ist sie geöffnet, werden sie interpretiert? Alles ohne Warnung oder Hinweis.
Wenn die Index-Palette geschlossen ist, sind die Indexmarken ja nicht weg. Sie sind vielleicht nicht durch die nicht-druckenden Klammern markiert und daher aktuell für den Layouter unsichtbar. Aber sie nicht weg. Da stimmst Du mir zu, oder? Wenn man indizierten Text dann als XPress-Tags sichert, sind sie aber in der Exportdatei nicht mehr drin. Das erscheint mir wenig sinnvoll und als eine sichere Methode, viel Arbeit zunichte zu machen.
Du verstehst, worauf ich hinaus will?
Wenn das nicht ein Fehler in der Import-/Export-Schnittstelle für XPress-Tags bzw. in der Index-Xtension ist, dann sollte es mich sehr wundern.
Was den Fehler beim Kopieren und Einsetzen von mit Index-Marken versehenem Text angeht (Index-Marken sind beim Einsetzen verschwunden) könnte man genauso argumentieren: Warum gehen Stilvorlagen nicht verloren, wenn Text ein Kopieren/Einsetzen durchläuft? Warum geht die Textfarbe beim Kopieren/Einsetzen nicht verloren? Warum gehen Textauszeichnungen oder gar die Schriftart, -schnitt und -größe nicht verloren? Warum geht dabei absolut nichts verloren - außer Index-Markierungen?
Wenn in einem Text ein oder mehrere Worte indiziert sind und ich möchte diesen Text auf einer anderen Seite der Publikation erneut verwenden - eventuell leicht modifiziert - dann ist es nicht unwahrscheinlich, dass auch diese Stelle später über den Index wiederfinden möchte. Wenn nicht, kann ich die Marken ja nach dem Einsetzen entfernen. Dass QuarkXPress sie aber ungefragt für mich rausschmeißt, finde ich weder wünschenswert noch logisch. Denn dann könnte man diese ungefragte "Hilfe" auch bei anderen Texteigenschaften - z.B. angewendeten Stilvorlagen - erwarten.
Und dann wäre da noch die interessante Frage, warum die Marken beim Kopieren und Einsetzen eines Textrahmens nicht verschwinden, sondern brav erhalten bleiben? Egal, ob die Palette "Index" sichtbar ist oder nicht. Dann sollte man das vielleicht als Fehler betrachten? Gleiches gilt für das Duplizieren eines Textrahmens: Die indizierten Stellen bleiben indiziert und werden dem Index brav als weitere Vorkommnisse hinzugefügt.
Es ist Dein Thread. Aber ich kann nicht nachvollziehen - Verlautbarungen von Quark hin oder her - warum dieses Verhalten beim Import von XPress-Tags richtig bzw. gar bewusst eingebaut sein soll. Die Erklärung, dass es "so programmiert" wurde, bedeutet nichts anderes als "es ist, wie es ist". Ganz offensichtlich wurde die Index-Xtension "so" programmiert, dass sich wie beschrieben verhält. Wäre das nicht so, gäbe es das beschriebene Verhalten nicht, weil sie dann nicht "so" programmiert wäre, sondern "anders".
Alle Bugs - aber auch alle erwümnschten Funktionen - sind zwangsläufig "so programmiert". Sonst wären sie ja nicht da.
Vor etwas mehr als 2 Jahren hatte ich bezüglich der Index-Funktionen übrigens eine ca. 10 eMails umfassende, sachliche Kommunikation mit einem Mitarbeiter von Quark. Ich hatte die Probleme detailliert beschrieben und Rückfragen dazu beantwortet. An keiner Stelle wurde ich darauf hingewiesen, dass dieses Verhalten im Zusammenhang mit dem Index so beabsichtigt ist. Hier ein Auszug aus der letzten, abschließenden dieser eMails:
Dear Michael,
Thanks for your valuable inputs.
Regarding your issues:
1. Index-tag is lost when text is copied/cut and pasted.
2. Index-tags are lost when XPress-tagged text is imported while the Index window is not open.
3. "Index" can still not be accessed via AppleScript.
[..]
I have forwarded your issues to the concerned department. They are looking into this.[..]
Thanks
[..]
Das Punkt 3 kein "Bug" sondern eine bitter fehlende Funktion ist, ist klar.
Kurz und gut: Dieses offensichtlichen Fehler aus der Liste der Bugs zu nehmen, halte ich für eine falsche Entscheidung. Aber es ist Deine Liste.
Ach so, noch etwas im gleichen Zusammenhang, das ich bisher nicht erwähnt hatte:
Versuch mal, Miniaturen, auf denen sich indizierter Text befindet, in ein anderes/neues Projekt zu ziehen. Auch hier hat Quark gewissenhaft dafür gesorgt, dass alle Index-Marken entfernt werden, ohne den User mit lästigen Warnungen oder Hinweisen zu konfrontieren. Sehr umsichtig, wenn mir diese sarkastische Anmerkung erlaubt ist. Da wäre ich dann gerne dabei, wenn die Publikation redigiert wird und dann vor der Neuauflage noch schnell der Index "aktualisiert" werden soll. Die Autoren werden sicher anerkennend vor sich hinmurmeln, wenn sie feststellen, dass Quark - bzw. der zu dem Zeitpunkt noch im Verlag angestellte zuständige Reinzeichner, der die Konvertierung zu verantworten hat - so zuvorkommend war, die komplette Entfernung des mühevoll erarbeiteten Index vorzunehmen.
Das hieße, eine saubere Konvertierung von XPress-6-Dateien zu XPress 7, in deren Verlauf ja unter anderem auch zu diesem Schritt (aus dem konvertierten 6er- per Miniaturen in ein echtes 7er-Dokument ziehen) geraten wird, ist ohne Totalverlust des Index nicht möglich. Eine Übernahme von Seiten aus Dokumenten mit indiziertem Text, die man z.B. zur Sicherheit, bei eventuell beschädigten Dokumenten oder aus anderen Gründen durchführt, sollte man sich also gut überlegen. Besonders wissenschaftliche Verlage werden sich meiner Meinung anschließen.
Da es in Quark immer noch keinerlei Funktionen gibt, die einem bei der automatischen Erstellung eines Index helfen (z.B. die automatische Aufnahme in den Index per Erkennung bestimmter Zeichenstilvorlagen, Artikelnummern-Strukturen, etc.), bleibt dann ja noch die mehrtägige manuelle Nacherstellung des Index. Außer: man braucht seinen Index nicht mehr. Fein.
Du glaubst wirklich, das ist eine "Funktion"? Dann wüsste ich schon mehrere "Bugs" in InDesign zu vermelden: Index-Marken bleiben beim Kopieren/Einsetzen erhalten, Index-Marken werden auch bei geschlossener Palette "Index" mit InDesign-Tagged-Text importiert und interpretiert ...
Adobe hat's nicht drauf. QuarkXPress ist halt einfach besser bzw. "so" programmiert. ;-)
Sieh Dir den Fall bitte noch einmal an und Du wirst Deine Entscheidung, das aus der Fehlerliste zu nehmen, vermutlich nicht beibehalten.
Vielen Dank für die Mühe
-----
[<··mmaass··>]
als Antwort auf: [#329205]
(Dieser Beitrag wurde von mmaass am 4. Jan 2008, 17:31 geändert)
|
