Hallo zusammen,

vielleicht weiss von Euch jemand weiter, ich überlege ob es nicht die Möglichkeit gibt, einer XML-Datei für Indesgin schon mitzugeben, welche Returns hart oder weich sein sollen. Bislang behelf ich mir mit dem Trick das ich mir ein Zeichen in die XML-Datei einsetze das ich später im Layout durch ein weiches Return ersetze.
Aber 15000 Ersetzungen zu machen, das legt meinen Indesgin für fast 20min lahm, im normalen Editor macht er das in 3 min :-)

Wahrscheinlich gibt es hierfür keine passende Lösung, falls doch wäre jedoch genial....

Gruß
Stefan

Antwort auf [ pitcare ]

Wahrscheinlich gibt es hierfür keine passende Lösung, falls doch wäre jedoch genial....

Du kannst beide Returns der XML mitgeben:


 für einen "Soft Return" (Zeilenumbruch)


 für einen "Hard Return (Absatzende)

Ich habe es gerade ausprobiert, hier werden diese Zeichen in InDesign korrekt interpretiert.

Grüße,
Bernd
---------------
cave fenestras!

Mensch Bernd,

das ist ja der Hammer, es funzt einwandfrei!

Herzlichen Dank!

Gruß
Stefan

Antwort auf [ Be.eM ]


 für einen "Soft Return" (Zeilenumbruch)

 für einen "Hard Return (Absatzende)

Ich kenne den 
eigentlich unter dem Namen "Harter Zeilenumbruch". Hier ist die deutsche Benennung etwas schwammig, da semantisch gesehen "Soft Return" möglicherweise mehr sinn macht.

Das 2028 Unicodezeichen heißt "LINE SEPARATOR" http://www.fileformat.info/.../char/2028/index.htm. Machmal lese ich auch "Forced Line Break". Beide beschrieben die semantik dieses Zeichens besser.

http://www.hilfdirselbst.ch/...ht_P50969.html#50969
Hier wird das Problem der Benennung auch angesprochen und in meinen Augen erklärt Framer das absolut korrekt.



Tip: Unter folgendem Link eine Tabelle mit InDesign-Zeichen herunterladen, in der solche Inforamtionen enthalten sind.
http://www.absatzsetzer.de/...zeichen-in-indesign/
Aber Achtung: Es sind leider Fehler enthalten sind. Und zwar genau das angesprochene LINE SEPARATOR-Zeichen (es ist nicht 202f sondern 2028)!



Viele Grüße
Silo

hallo,

nun habe ich doch noch eine weitere frage :-))

bei meinem import html > xml > id cs3 ersetze ich z.b. den – durch – (unicode). dieses zeichen kennt indesign aber wieder nicht und macht ein rotes quadrat!

gem. deinem link auf absatzsetzer.de wäre unicode 2013 richtig. das kenn ich aber anders...

- gibt es eine offizielle aufstellung, welche zeichen indesign kann?
- kann man automatisiert das dokument durchsuchen und eine fehlerdatei ausgeben lassen, auf welchen seiten welches zeichen nicht erkannt wurde?
- am besten diese gleich durch passende zeichen ersetzen lassen?

sorry, bin noch frisch in indesign :-)

Antwort auf [ silo ]

Ich kenne den 
eigentlich unter dem Namen …

Hallo Silo,

da hast du Recht, so richtig eindeutig habe ich das möglicherweise nicht formuliert. Ehrlich gesagt auch nicht so genau darüber nachgedacht, da es mir so selbstverständlich erschien.

Der "Forced Line Break" ist wohl richtiger, und da Zwang üblicherweise eine harte Sache ist, somit ein "Hard Return". Andererseits kriege ich das dann im täglichen Faultier-Sprachgebrauch irgendwie nicht mehr sauber getrennt vom Absatzende, welches dann ein "LF+CR" = "Line Feed + Carriage Return" = "Mega-Ultra-Hard-Return" wäre… ;-)

In spitzfindiger Weise müsste dann aber die Erzwingung eines Umbruches mittels Trennunterdrückung für ein Wort ein halbweicher Umbruch sein? Härter als das Textrahmenende, aber weicher als der Forced Line Break?

Im Ernst: Danke für den Hinweis auf die sprachliche Unsauberkeit :-)
Bernd
---------------
cave fenestras!

Antwort auf [ henkel_1111 ]

gem. deinem link auf absatzsetzer.de wäre unicode 2013 richtig. das kenn ich aber anders...

Unicode 2013 ist auch richtig, siehe Screenshot...

Grüße,
Bernd
---------------
cave fenestras!

Bernd,
ich bin der, der die absatzsetzer-Liste gemacht hat, als Hilfsmittel, um nicht jedes Mal wieder neu auf die Suche gehen zu müssen...

<202F> für "Forced LineBreak" ist natürlich Quatsch, da das der Code für "Geschützten Leerraum mit fester Breite" ist, wie weiter unten in der Liste aufgeführt.

Was aber ist richtig? Mit XML hatte ich mich im Zusammenhang mit der Liste nicht befasst. Deine Angabe, den Code des "Line Separators" <2028> in die XML-Datei zu nehmen, kann ich auch nachvollziehen und bringt das richtige Ergebnis in InDesign. Wenn ich aber in InDesign schaue, welchen Unicode-Wert das "Forced LineBreak"-Zeichen hat, so bekomme ich <000A>, also das, was man auch als "Linefeed" kennt. Auch wenn ich mit GREP suche, finde ich mit \x{2028} nichts, mit \x{000A} aber besagtes Zeichen. Aber wenn ich andererseits &#x000A; in der XML-Datei habe, so bekomme ich einen Absatzumbruch (<000D> in InDesign. Da wird also konvertiert.

Ich denke, dass in der Liste das <000A> stehen sollte, und die Zeile "End of Line" sollte raus, weil das ja gar kein eigenes Zeichen ist. Ich kann lediglich in GREP nach dem Zeilenende suchen mit $, dann bekomme ich alle Zeilen, die mit <000D> oder <000A> enden.

Robert

Antwort auf [ robertfranz ]

Bernd,
ich bin der, der die absatzsetzer-Liste gemacht hat, als Hilfsmittel, um nicht jedes Mal wieder neu auf die Suche gehen zu müssen...

Robert,

und ich bin NICHT der, der deine Liste verlinkt oder die Fehler bemerkt hat (das war "silo") ;-)

Antwort auf [ robertfranz ]

Was aber ist richtig? Mit XML hatte ich mich im Zusammenhang mit der Liste nicht befasst. Deine Angabe, den Code des "Line Separators" <2028> in die XML-Datei zu nehmen, kann ich auch nachvollziehen und bringt das richtige Ergebnis in InDesign.

die "2028" ist die "unambiguous"-Version, d.h. eindeutige Version des LineBreaks, siehe z.B. http://unicode.e-workers.de/unicode3.php. Konsequenterweise müsste dann als ParagraphBreak auch die "2029" funktionieren, habe ich aber noch nicht ausprobiert.

Antwort auf [ robertfranz ]

Da wird also konvertiert.

Ja. Ich habe das allerdings auch noch nicht bis ins Detail untersucht, sondern war lediglich erstmal glücklich, hierfür funktionierende Zeichen gefunden zu haben. Ein bisschen blöd ist es allerdings, dass der InDesign-Export dann wieder auf dem basiert, was (wie von dir aufgelistet) in InDesign selbst verwendet wird. "2028/2029" taugt also nur für XML zu InDesign, umgekehrt nicht.

Grüße,
Bernd
---------------
cave fenestras!

Bernd,

entschuldige, dass ich Dich von der Seite angequatscht habe ;-).

Ja, <2029> = "Paragraph Separator" wird beim XML-Import ebenfalls akzeptiert und in <000D> umgesetzt.

Robert

Antwort auf [ robertfranz ]

Bernd,

entschuldige, dass ich Dich von der Seite angequatscht habe ;-).

Hallo Robert,

es ist völlig OK, mich hier von der Seite anzuquatschen. Ich wollte nur ein mögliches Missverständnis vermeiden :-)

Antwort auf [ robertfranz ]

Ja, <2029> = "Paragraph Separator" wird beim XML-Import ebenfalls akzeptiert und in <000D> umgesetzt.

Danke für die Info!

Schöne Grüße,
Bernd
---------------
cave fenestras!

Hallo Robert,
das ist sehr interessant.
Ich hab damit mal ein bisschen rumgespielt, und habe das ganze so verstanden.

InDesign hat eine bestimmte interne Darstellung für die Zeichen. Je nachdem mit welchem Format man Im-/ oder Exportiert, findet eine Konvertierung von der InDesign-internen Darstellung zu der Zielformat-Darstellung statt.

Beim Im-/Export nach XML/INX ist ein ForcedLineBreak das Unicodezeichen für den ForcedLineBreak (e280a8 im Hexeditor bzw. &#x2028; als HTML Entity). Ein Absatz (normales Return) enspricht übrigens dem angesprochenem 'PARAGRAPH SEPARATOR' (e280a9 im Hexeditor bzw. &#x2029; als HTML Entity).

Beim Im-/Export nach InDesignTaggedText ist ein ForcedLieBreak ein <000A> und der Absatz eine neue Zeile.

Beim Im-/Export nach RTF wird der ForcedLineBreak in ein \line und der Absatz in ein \par umgesetzt.

Als nächstes habe ich ein kleines Skript geschrieben das mit ein einem Textrahmen (dem ersten und einzigen Textrahmen in einem Dokument) Zeichen für Zeichen über die characters-Collection ausgibt.

Code

function textUnicode() { 
	var tf  =app.documents[0].textFrames[0]; 
	var erg = ""; 
	for(var i=0; i<tf.characters.count(); ++i) { 
		try { 
			erg += "Zeichen " + (i+1) + ": " + tf.characters[i].contents + "\t=ascii(" + tf.characters[.i].contents.charCodeAt(0) + ")\n"; 
		} 
		catch(error) { 
			erg += "Zeichen " + (i+1) + ": " + tf.characters[i].contents + "\t=ascii(-kein ASCII Wert-)\n"; 
		} 
	} 
	alert(erg); 
	 
} 

Bei dem ForcedLineBreak erhalte ich den Wert"1397124194" und das ist (schnell in der InDesign_Scription_Reference nachgeschaut) eine NestedStyleDelimiter-Enumeration mit dem Namen: NestedStyleDelimiters.forcedLineBreak.
Wohingeben normale Absätze als &#13; dargestellt werden.

Es scheint mir im Moment sehr undurchsichtig wie InDesign seine Zeichen intern selbst verwaltet.


Was deine Liste angeht müsste man bei diesem Zeichen differenzieren in welchem Zusammenhang man sich befindet, da unterschiedliche Umgebungen die Zeichen unterschiedlich kodieren.


Viele Grüße
Silo

PS.: Es ist mir im übrigen auf die schnelle nicht gelungen mit dem TaggedText-Format das <2028> zu importieren. Das endet in einer Fehlermeldung.

Hallo silo,
die Diskussion hier bewegt sich allmählich in Dimensionen, wo ich eigentlich nicht mehr mitreden kann. Ich sehe das Ganze mehr aus Anwender- als aus Entwicklersicht und so war meine Liste (http://www.absatzsetzer.de/downloads/Zeichen.pdf) ja auch gedacht.

Die fundiertesten Informationen (aus Sicht eines Javascript-Entwicklers) zu diesem Thema findet man übrigens bei Marc Autret (http://marcautret.free.fr/geek/indd) allerdings größtenteils auf Französisch. Er hat auch zwei Listen "Caractère spéciaux et assimilés" für CS2 und CS3 angelegt, die sehr hilfreich sein können.

Ich werde auf jeden Fall noch Fehler und Lücken in meiner Übersicht beheben. Um das Ganze aber nicht zu kompliziert werden zu lassen, werde ich für Spezialfälle einfach auf entsprechende Webseiten oder Foren verlinken, wo bei Interesse das Thema dann vertieft werden kann.

In diesem Zusammenhang bin ich jetzt noch auf eine Sache gestoßen, bei der vielleicht jemand weiterhelfen kannst: In der Text- und der GREP-Suche gibt es einerseits das Absatzende und unter Umbruchzeichen den Standardzeilenumbruch, (^p bzw. ^b) in beiden Fällen wird aber das Gleiche gefunden. Hat das etwas mit den unterschiedlich kodierten Zeilenumbrüchen in Mac und Windows und der Dateikompatiblität zu tun? Oder verstehe ich da etwas nicht?

Robert