[GastForen Programme Print/Bildbearbeitung Adobe InDesign XML mit Indesgin Unterscheidung Harter und Weicher Return

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Print/Bildbearbeitung - Photos, Layout, Design
Themen
Beiträge
Moderatoren
Letzter Beitrag

XML mit Indesgin Unterscheidung Harter und Weicher Return

pitcare
Beiträge gesamt: 67

30. Jan 2008, 14:40
Beitrag # 1 von 13
Bewertung:
(20615 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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
X

XML mit Indesgin Unterscheidung Harter und Weicher Return

Be.eM
Beiträge gesamt: 3356

30. Jan 2008, 15:21
Beitrag # 2 von 13
Beitrag ID: #334162
Bewertung:
(20602 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#334145]

XML mit Indesgin Unterscheidung Harter und Weicher Return

pitcare
Beiträge gesamt: 67

30. Jan 2008, 15:35
Beitrag # 3 von 13
Beitrag ID: #334166
Bewertung:
(20594 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Mensch Bernd,

das ist ja der Hammer, es funzt einwandfrei!

Herzlichen Dank!

Gruß
Stefan


als Antwort auf: [#334162]

XML mit Indesgin Unterscheidung Harter und Weicher Return

silo
Beiträge gesamt: 29

17. Jul 2008, 18:39
Beitrag # 4 von 13
Beitrag ID: #359267
Bewertung:
(20388 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#334162]

XML mit Indesgin Unterscheidung Harter und Weicher Return

henkel_1111
Beiträge gesamt: 3

17. Jul 2008, 18:55
Beitrag # 5 von 13
Beitrag ID: #359273
Bewertung:
(20375 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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 :-)


als Antwort auf: [#359267]
(Dieser Beitrag wurde von henkel_1111 am 17. Jul 2008, 19:03 geändert)

XML mit Indesgin Unterscheidung Harter und Weicher Return

Be.eM
Beiträge gesamt: 3356

17. Jul 2008, 19:09
Beitrag # 6 von 13
Beitrag ID: #359277
Bewertung:
(20367 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359267]

XML mit Indesgin Unterscheidung Harter und Weicher Return

Be.eM
Beiträge gesamt: 3356

17. Jul 2008, 19:22
Beitrag # 7 von 13
Beitrag ID: #359281
Bewertung:
(20361 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359273]
Anhang:
ndash.jpg (61.4 KB)

XML mit Indesgin Unterscheidung Harter und Weicher Return

robertfranz
Beiträge gesamt: 32

18. Jul 2008, 16:58
Beitrag # 8 von 13
Beitrag ID: #359444
Bewertung:
(20278 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359281]

XML mit Indesgin Unterscheidung Harter und Weicher Return

Be.eM
Beiträge gesamt: 3356

18. Jul 2008, 17:30
Beitrag # 9 von 13
Beitrag ID: #359446
Bewertung:
(20270 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359444]

XML mit Indesgin Unterscheidung Harter und Weicher Return

robertfranz
Beiträge gesamt: 32

18. Jul 2008, 19:31
Beitrag # 10 von 13
Beitrag ID: #359463
Bewertung:
(20245 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359446]

XML mit Indesgin Unterscheidung Harter und Weicher Return

Be.eM
Beiträge gesamt: 3356

19. Jul 2008, 13:12
Beitrag # 11 von 13
Beitrag ID: #359504
Bewertung:
(20214 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359463]

XML mit Indesgin Unterscheidung Harter und Weicher Return

silo
Beiträge gesamt: 29

21. Jul 2008, 16:47
Beitrag # 12 von 13
Beitrag ID: #359699
Bewertung:
(20134 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.


als Antwort auf: [#359444]

XML mit Indesgin Unterscheidung Harter und Weicher Return

robertfranz
Beiträge gesamt: 32

22. Jul 2008, 10:31
Beitrag # 13 von 13
Beitrag ID: #359799
Bewertung:
(20089 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#359699]
(Dieser Beitrag wurde von robertfranz am 22. Jul 2008, 10:33 geändert)
X

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
18.06.2024

Online
Dienstag, 18. Juni 2024, 10.00 - 10.30 Uhr

Webinar

In diesen beiden kostenlose Webinaren erfahren Sie, wie Sie mit Hilfe von Enfocus Griffin und dem Impressed Workflow Server Ihren LFP-Workflows optimieren können. 18.06.2024: So optimieren Sie Ihre Prozesse mit Enfocus Griffin 02.07.2024: So sparen Sie Zeit und Geld mit Impressed Workflow Server in der LFP-Edition Griffin: Griffin ist das leistungsstarke Kraftpaket für das automatische Nesting im Großformatdruck. Dank eines ausgeklügelten, KI-basierten Nesting-Algorithmus können Sie mit Griffin Vorlagen schnell und effizient vernutzen – und das klappt auch mit unregelmäßigen Formen perfekt. Das spart Ihnen unzählige Stunden, die Sie bisher mit dem manuellen Nesting und Ausschießen verbracht haben. Einige wichtige Funktionen ≡ Anlage von Beschnittzugaben ≡ Automatische Erzeugung der Schnittkontur ≡ Erstellung von Strichcodes, Textmarkierungen und Registrierungen IWS LFP Edition: Komplizierte, kleinteilige Aufträge; alles sehr speziell; seit Jahren bewährte Prozesse – da können wir nichts standardisieren und automatisieren! Das sagen viele Großformatdrucker – aber stimmt das wirklich, ist dem tatsächlich so? Mit dem IWS LFP Edition automatisieren Sie Ihre Produktion von der Übernahme der Daten aus dem ERP-System bis zur Erzeugung der verschachtelten Druckform und der Übergabe an den RIP. Phoenix Core ist eine hochentwickelte KI-Technologie für die Planung und das Nesting von Druckerzeugnissen. Anders als herkömmliche Ausschießlösungen arbeitet Phoenix nicht auf Basis von Vorlagen, sondern erzeugt entsprechend der Maschinen- und Produktionsanforderungen druckfertige Layouts „on-the-fly“.

kostenlos

Ja

Organisator: Impressed GmbH

https://www.impressed.de/schulung.php?c=sDetail&sid=328

So optimieren Sie Ihren LFP-Workflow
Veranstaltungen
02.07.2024

Online
Dienstag, 02. Juli 2024, 10.00 - 10.30 Uhr

Webinar

In diesen beiden kostenlose Webinaren erfahren Sie, wie Sie mit Hilfe von Enfocus Griffin und dem Impressed Workflow Server Ihren LFP-Workflows optimieren können. 18.06.2024: So optimieren Sie Ihre Prozesse mit Enfocus Griffin 02.07.2024: So sparen Sie Zeit und Geld mit Impressed Workflow Server in der LFP-Edition Griffin: Griffin ist das leistungsstarke Kraftpaket für das automatische Nesting im Großformatdruck. Dank eines ausgeklügelten, KI-basierten Nesting-Algorithmus können Sie mit Griffin Vorlagen schnell und effizient vernutzen – und das klappt auch mit unregelmäßigen Formen perfekt. Das spart Ihnen unzählige Stunden, die Sie bisher mit dem manuellen Nesting und Ausschießen verbracht haben. Einige wichtige Funktionen ≡ Anlage von Beschnittzugaben ≡ Automatische Erzeugung der Schnittkontur ≡ Erstellung von Strichcodes, Textmarkierungen und Registrierungen IWS LFP Edition: Komplizierte, kleinteilige Aufträge; alles sehr speziell; seit Jahren bewährte Prozesse – da können wir nichts standardisieren und automatisieren! Das sagen viele Großformatdrucker – aber stimmt das wirklich, ist dem tatsächlich so? Mit dem IWS LFP Edition automatisieren Sie Ihre Produktion von der Übernahme der Daten aus dem ERP-System bis zur Erzeugung der verschachtelten Druckform und der Übergabe an den RIP. Phoenix Core ist eine hochentwickelte KI-Technologie für die Planung und das Nesting von Druckerzeugnissen. Anders als herkömmliche Ausschießlösungen arbeitet Phoenix nicht auf Basis von Vorlagen, sondern erzeugt entsprechend der Maschinen- und Produktionsanforderungen druckfertige Layouts „on-the-fly“.

kostenlos

Ja

Organisator: Impressed GmbH

Kontaktinformation: E-Mailschulungen AT impressed DOT de

https://www.impressed.de/schulung.php?c=sDetail&sid=328

So optimieren Sie Ihren LFP-Workflow