[Frame-User-Talk] Verbreitung Framemaker strukturiert / CD Strukturiertes Arbeiten mit FrameMaker

64 views
Skip to first unread message

20i...@arcor.de

unread,
May 7, 2008, 7:13:49 AM5/7/08
to ta...@framemaker.de
hallo Listige,

a) Täuscht mich meine Wahrnehmumg oder ist der Anteil der Nutzer von Framemaker strukturiert (die hier mitlesen und mitschreiben) wirklich so gering?

b) "'Adobe FrameMaker 7.0: Strukturiertes Arbeiten mit FrameMaker'" auf CD von Markus Bollenbach:
Wer besitzt dieses Buch/die CD und kann etwas zum Nutz-/Mehrwert sagen? Wie anwenderfreundlich ist das Produkt? Praxisbeispiele vorhanden?
Es wird im pdf- bzw. html-Format vertrieben.

Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv
_______________________________________________
Talk mailing list
Ta...@framemaker.de
http://lists.framemaker.de/mailman/listinfo/talk

Karin Hoffmann

unread,
May 7, 2008, 7:24:55 AM5/7/08
to ta...@framemaker.de
Hallo anonymus,

> a) Täuscht mich meine Wahrnehmumg oder ist der Anteil der
> Nutzer von Framemaker strukturiert (die hier mitlesen und
> mitschreiben) wirklich so gering?

den Eindruck habe ich als ebenfalls strukturiert Arbeitende auch. Ich werde
auch sonst oft im Zusammenhang mit FrameMaker erstaunt gefragt: "Ach, Sie
arbeiten mit dem strukturierten FrameMaker?"



> b) "'Adobe FrameMaker 7.0: Strukturiertes Arbeiten mit
> FrameMaker'" auf CD von Markus Bollenbach:
> Wer besitzt dieses Buch/die CD und kann etwas zum
> Nutz-/Mehrwert sagen? Wie anwenderfreundlich ist das Produkt?
> Praxisbeispiele vorhanden?

Ich besitze das Produkt, bin aber leider nie dazu gekommen mich
ausführlicher damit auseinanderzusetzen.

Viele Grüße,

Mit freundlichen Grüßen/Best Regards

Karin Hoffmann
European Computer Telecoms AG
www.ect-telecoms.de

Ralf Löbelt

unread,
May 7, 2008, 1:49:55 PM5/7/08
to ta...@framemaker.de
Hallo UNBEKANNT!

Am 07.05.2008 um 13:13 schrieb 20i...@arcor.de:

hallo Listige,

a) Täuscht mich meine Wahrnehmumg oder ist der Anteil der Nutzer von Framemaker strukturiert (die hier mitlesen und mitschreiben) wirklich so gering?

hmm... vielleicht kommt das daher, dass weniger Probleme mit dem Strukturierten FrameMaker auftreten?
Nein, Scherz beiseite. Meiner Meinung nach macht "nur eine Strukturierung der Dokumente" alleine keinen großen Sinn. Ich glaube das wurde hier auch schon mal diskutiert. SGML/XML ist erst mal kein Selbstzweck. In den meisten Fällen wird es  einen anderen Grund geben für den Einsatz des FrameMakers geben als nur die Strukturierung. Allen voran natürlich die Weiterverarbeitung bzw. Verwaltung der strukturierten Informationen in einem xMS (mit x{C,D,T}).
Und dort wird meistens der Prozess einmal sauber aufgesetzt. Und dann gibt es halt tatsächlich weniger Probleme. Die Leute arbeiten produktiver und verbringen weniger Zeit in dieser Liste (weder zum Fragen noch zum Antworten, wie ich auch zu meiner Schande gestehen muss ;-)

b) "'Adobe FrameMaker 7.0: Strukturiertes Arbeiten mit FrameMaker'" auf CD von Markus Bollenbach:
Wer besitzt dieses Buch/die CD und kann etwas zum Nutz-/Mehrwert sagen? Wie anwenderfreundlich ist das Produkt? Praxisbeispiele vorhanden?
Es wird im pdf- bzw. html-Format vertrieben.

Ja, ich habe das Werk und sollte ev. mal mit Hr. Bollenbach über Provision sprechen. ;-)
Ist echt klasse gemacht, für viele etwas dabei. Neueinsteigern in den Strukturierten FrameMaker empfehle ich immer Kapitel 6, Arbeiten mit der STruktur.
SEHR EMPFEHLENSWERT.


Mit freundlichen Grüßen / Best regards / Salutations
Saludos  /  Με φιλικούς χαιρετισμούς  / 敬具 / 祝好


Ralf Löbelt

Thomas Böttiger

unread,
May 7, 2008, 1:54:15 PM5/7/08
to ta...@framemaker.de
Ähm.

On 07.05.2008, at 13:24, Karin Hoffmann wrote:

> den Eindruck habe ich als ebenfalls strukturiert Arbeitende auch.
> Ich werde
> auch sonst oft im Zusammenhang mit FrameMaker erstaunt gefragt:
> "Ach, Sie
> arbeiten mit dem strukturierten FrameMaker?"

Kann man denn auch mit nicht-strukturierte FM ordentlich arbeiten?
Meine Erinnerungen daran sind schon recht verblasst, aber FM
unstrukturiert ist wie Essen mit nur einem Stäbchen: es geht, aber es
nutzt das Potenzial nicht.
;-)


MfG
Thomas Böttiger

t_boe...@mac.com
http://www.readit-dtp.de
skypename: tboettiger

Thomas Reuter

unread,
May 7, 2008, 4:10:27 PM5/7/08
to ta...@framemaker.de
Lieber Thomas,

> Essen mit nur einem Stäbchen: es geht, aber es nutzt das Potenzial
> nicht.

ich glaub', ich muß bei Dir mal um Nachhilfe einkommen. Ich war bisher
mit dem unstrukturierten FrameMaker immer sehr zufrieden, hab' auch
nie was anderes gebraucht. Aber wie mein Schwiegervater immer sagte:
"Wenn man's gewöhnt ist, ist es auch in der Hölle schön."

Herzliche Grüße,
Thomas Reuter

Ralf Löbelt

unread,
May 7, 2008, 4:36:00 PM5/7/08
to ta...@framemaker.de
Bitte bitte bitte nicht übelnehmen.....!!!

Aber...

Am 07.05.2008 um 22:10 schrieb Thomas Reuter:
> ..." wie mein Schwiegervater immer sagte:


> "Wenn man's gewöhnt ist, ist es auch in der Hölle schön."

.... sagte er das augenzwinkernd entweder über seine Tochter oder
Ehefrau, in der Hoffnung Ihnen Mut zu machen?

In der Hoffnung, nicht aus der Liste gebannt oder als vogelfrei
erklärt, gesteinigt, gevierteilt, mit Word-Aufträgen oder Windows-
Nutzung bestraft zu werden,
verbleibe ich zutiefst demütig und einen schönen Abend wünschend,
Ralf Löbelt

Thomas Böttiger

unread,
May 7, 2008, 4:50:56 PM5/7/08
to ta...@framemaker.de
Hallo Thomas,

On 07.05.2008, at 22:10, Thomas Reuter wrote:

> Lieber Thomas,
>
>> Essen mit nur einem Stäbchen: es geht, aber es nutzt das Potenzial
>> nicht.
>
> ich glaub', ich muß bei Dir mal um Nachhilfe einkommen.

Beim Essen mit Stäbchen?
;-)
Nee, im ernst: es kommt natürlich drauf an, was du mit FM machst. Wenn
Du damit Kataloge aus einer datenbank produzierst, ist die
Strukturierung ziemlich unerheblich. Anders sieht es m.E. bei der
Bearbeitung umfangreicher technischer Dokumentationen aus: ich kann
wesentlich leichter konsistente Dokumente verfassen und -- bei
entsprechender EDD -- mich auf den inhalt konzentrieren statt auf die
Formatierung ("Jetzt kommt der nächste Handlungsschritt." statt "Wie
hieß das Format für den Absatz noch?").

Ich bin auch kein ausgesprochener Freund der ganzen XML/YML/ZML-
Schiene (siehe auch http://www.readit-dtp.de/subpage.php?artnum=92),
aber wenn ich schreibe, will ich nicht formatieren. Das lenkt mich ab.


MfG
Thomas Böttiger

thomas becker

unread,
May 8, 2008, 1:29:22 AM5/8/08
to ta...@framemaker.de
> aber wenn ich schreibe, will ich nicht formatieren. Das lenkt mich ab.

Hallo Thomas,

trotz der Gefahr mich fürchterlich zu outen möchte hier einhaken. Ich habe
keine wirkliche Vorstellung vom Unterschied zwischen strukturiert und
"normal". Mein FM jedenfalls hat ganz oben stehen: "(strukturiert)".
Deine Aussage wörtlich nehmend, müsste FM ja erkennen, was Du als nächstes
schreibst und das dann richtig formatieren.
Dass das nicht geht, ist mir klar. Wo liegt denn (zumindest in diesem Punkt)
der Struktur-Nutzen? Wenn ich ne Überschrift brauche, muss ich sie mir auch
"holen" oder kopieren... Musst Du das nicht?

ich bin gespannt und sende viele Grüße
Thomas

Thomas Böttiger

unread,
May 8, 2008, 1:52:01 AM5/8/08
to ta...@framemaker.de
Hallo Thomas,

On 08.05.2008, at 07:29, thomas becker wrote:

> Deine Aussage wörtlich nehmend, müsste FM ja erkennen, was Du als
> nächstes
> schreibst und das dann richtig formatieren.

schon irgendwie. Ich habe ein Dokument (strukturiert) und sage ihm:
"Du wirst eine Einleitung zu einem Kapitel in einer
Betriebsanleitung." Das mache ich, indem ich im Strukturbaum
"Einleitung" anklicke". Jetzt bietet mir FrameMaker automatisch
aufgrund der EDD an, entweder eine Notiz zu schreiben (falls ich die
Einleitung nur anlegen und später fertig stellen möchte) oder eine
Überschrift. Wenn ich "Überschrift" wähle, formatiert FM sie so, wie
eine Überschrift in einer Einleitung aussehen soll (möglicherweise als
Marginalie). Nach dem Einfügen des Elements Überschrift gibt FM an,
was als nächstes folgen darf (gemäß EDD): ein Absatz oder eine Grafik,
aber keine Tabelle. Wenn ich eine Tabelle einfügen will, muss ich
zuerst einen Absatz davor stellen. Falls Ich dann auch noch als
Attribut bestimmte Eigenschaften eingerichtet habe wie Zeilenumbruch
oder Sprache, kann ich diese auch steuern.
Natürlich weiß FM nicht, was ich in die Elemente reinschreibe, das ist
glücklicherweise mir überlassen. Aber ich muss mit beispielsweise
keine Gadanken darüber machen, welches Tabellenformat oder
Überschriftenformat in Einleitungen stehen soll.
Mit anderen Worten: Layout-technische Rahmenbedingungen, die ja in
technischen Dokumenten konsistent sein sollen, muss ich nicht mehr
berücksichtigen.

Am besten probierst Du es mal aus mit den mitgelieferten Templates. Es
gibt da einen Ordner mit strukturierten Vorlagen.


MfG
Thomas Böttiger

office

unread,
May 8, 2008, 3:53:37 AM5/8/08
to ta...@framemaker.de
Hallo Thomas,

danke für Deine ausführliche Beschreibung; jetzt ist es mir deutlich klarer!
Wenn ich das richtig verstehe, bedarf das zwar einer gründlichen
Vorbereitung, entlastet jedoch in der Anwendung.

Für mich als Dienstleister für verschiedenste Anwendungen und Kunden war es
bislang ausreichend das vorhergehende Dokument als Quasi-EDD zu verwenden.
Auch jonglierte ich schon mal mit Veränderungen in den Absatzformaten
(Abstand nach) um gewünschte Seitenanzahlen zu erreichen.

Werde mir mal den Ordner mit strukturierten Vorlagen ansehen.

Grüße,
Thomas

Thomas Böttiger

unread,
May 8, 2008, 4:22:35 AM5/8/08
to ta...@framemaker.de
Hallo Thomas

On 08.05.2008, at 09:53, office wrote:

> .
> Auch jonglierte ich schon mal mit Veränderungen in den Absatzformaten
> (Abstand nach) um gewünschte Seitenanzahlen zu erreichen.
>

Das Jonglieren ist eher eine Spielwiese für InDesign. Sollte man nicht
machen mit FM. Ich mache das auch mit Word, wenn die Dokumente nicht
zu lang sind, aber solche Sachen sind hochriskant. Vor allem, wenn man
später einen Formatabgleich macht und sich diese "irregulären" Formate
wieder rauswirft. Dann darf man ja wieder durch das ganze Buch
blättern auf der Suche nach den alten Einstellungen.
Ein Minenfeld...


MfG
Thomas Böttiger

thomas becker

unread,
May 8, 2008, 4:37:34 AM5/8/08
to ta...@framemaker.de
> Ein Minenfeld...
richtig und auch nicht. Bei wachsenden Dokumenten garantiert - Aber bei
"Einmaligen" kaum.

>Sollte man nicht machen mit FM

gelegentlich vielleicht schon. Zumindest wenn ich die möglichst kürzeste
Erstellungszeit im Auge behalte. Was soll ich anderes machen, wenn ich sonst
3 Füllseiten zusätzlich einbauen muss? (Abgesehen von Textreduktion, bei
Rückenstichheftung). Das Jonglieren fällt weder der Zielgruppe (Bediener
einer Maschine) noch dem Kunden auf. Das Ziel ist in diesem Fall erreicht.

Grüße, Thomas

Thomas Böttiger

unread,
May 8, 2008, 4:49:42 AM5/8/08
to ta...@framemaker.de
Hallo Thomas,

On 08.05.2008, at 10:37, thomas becker wrote:

>> Ein Minenfeld...
> richtig und auch nicht. Bei wachsenden Dokumenten garantiert - Aber
> bei
> "Einmaligen" kaum.
>
>> Sollte man nicht machen mit FM
> gelegentlich vielleicht schon. Zumindest wenn ich die möglichst
> kürzeste
> Erstellungszeit im Auge behalte. Was soll ich anderes machen, wenn
> ich sonst
> 3 Füllseiten zusätzlich einbauen muss? (Abgesehen von Textreduktion,
> bei
> Rückenstichheftung). Das Jonglieren fällt weder der Zielgruppe
> (Bediener
> einer Maschine) noch dem Kunden auf. Das Ziel ist in diesem Fall
> erreicht.

Klar, bei kurzfristigen Jobs ("Fire and forget") ist das auch kaum
notwendig. Problematisch wird es bei den ersten Änderungen.
Dann kann der Aufwand extrem werden.


MfG
Thomas Böttiger
______________________________
mail: t_boe...@mac.com
url: http://www.readit-dtp.de
tel.: 0177-245 666 8
skypename: tboettiger

USt-ID: DE207258158

20i...@arcor.de

unread,
May 8, 2008, 6:41:18 AM5/8/08
to ta...@framemaker.de

Hallo Thomas,

mit dem Jonglieren ist es bei FM strukturiert eigentlich vorbei. Man sollte Strukturverletzungen tunlichst vermeiden. Wenn Du später in andere Formate, z.B. Word, publizieren möchtest, kann es riesige Probleme geben.

Gruß
Ingo

> Für mich als Dienstleister für verschiedenste Anwendungen und
> Kunden war es bislang ausreichend das vorhergehende Dokument

> als Quasi-EDD zu verwenden. Auch jonglierte ich schon mal mit

> Veränderungen in den Absatzformaten (Abstand nach) um
> gewünschte Seitenanzahlen zu erreichen.
>

> Werde mir mal den Ordner mit strukturierten Vorlagen ansehen.
>
> Grüße,
> Thomas

------------------

hallo Ralf,

wieviel Provision bekommst Du, da Du es besonders lobst ;-) ?

Gruß
Ingo


> > b) "'Adobe FrameMaker 7.0: Strukturiertes Arbeiten mit FrameMaker'"
> > auf CD von Markus Bollenbach:
> > Wer besitzt dieses Buch/die CD und kann etwas zum Nutz-/Mehrwert
> > sagen? Wie anwenderfreundlich ist das Produkt? Praxisbeispiele
> > vorhanden?
> > Es wird im pdf- bzw. html-Format vertrieben.
>
>
> Ja, ich habe das Werk und sollte ev. mal mit Hr. Bollenbach über
> Provision sprechen. ;-)
> Ist echt klasse gemacht, für viele etwas dabei.
> Neueinsteigern in den
> Strukturierten FrameMaker empfehle ich immer Kapitel 6, Arbeiten mit
> der STruktur.
> SEHR EMPFEHLENSWERT.

Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv

Ralf Löbelt

unread,
May 8, 2008, 6:46:24 AM5/8/08
to ta...@framemaker.de
Keine,
aber das ist bei dem Preis glaub ich eh nicht interessant ;-)

Am 08.05.2008 um 12:41 schrieb 20i...@arcor.de:

wieviel Provision bekommst Du, da Du es besonders lobst ;-)  ?

Michael Müller-Hillebrand

unread,
May 8, 2008, 9:51:53 AM5/8/08
to ta...@framemaker.de
Am 08.05.2008 um 12:46 schrieb Ralf Löbelt:

> Keine,
> aber das ist bei dem Preis glaub ich eh nicht interessant ;-)


Der Hinweis auf den "Preis" trifft in gewissem Sinne auch auf die
ursprüngliche Frage zu:

* Wer es sich "leisten" kann, mit unstrukturierten Dokumenten zu
arbeiten, wird die höheren Anlaufkosten für strukturierte Dokumente
nicht investieren. "Sich leisten können" bedeutet hier, dass durch
diese Arbeitsweise keine kaufmännisch relevanten Nachteile entstehen.

* Wer zwar Probleme hat und vielleicht sogar weiß, dass diese
zumindest teilweise mit strukturierten Dokumenten (mit oder ohne CMS)
behebbar wären, aber unglücklicherweise in einem Umfeld arbeitet, bei
dem es *keine* kaufmännische Betrachtung der Arbeitszeiten gibt
(Kostenstelle "[der Mitarbeiter ist] eh da") und deshalb
Qualitätsmängel oder Verzögerungen in Kauf genommen werden, der/die
hat irgendwie Pech gehabt.

* Alle anderen prüfen, ob Ihnen die XML-basierte ("strukturierte")
Arbeitsweise Vorteile bringt. Kriterien, die dafür sprechen, sind:

+ Single-source Publishing (gleichzeitige Erstellung von Online-Medien),
+ Übersetzung mit TM-Systemen,
+ Produktvarianten aus einer Quelle beschreiben,
+ Wiederverwendung von identischen Textteilen,
+ häufiger Wechsel der Autoren,
+ keine Zeit für Einarbeitung neuer Autoren,
+ räumlich verstreut arbeitende Autoren in einem größeren Team,
+ zeitkritische Veröffentlichungstermine,
+
+
+

Haben Sie weitere Kriterien?

Im Übrigen glaube ich schon, dass die Nutzer strukturierter
Umgebungen tatsächlich weniger in Foren wie diesen präsent sind, da
durch diese Vorgehensweise (wenn es richtig gemacht ist!), der Fokus
weg vom Produkt (FrameMaker) hin zum Schreiben geht. FrameMaker ist
in solchen Fällen wirklich nur noch Editor oder PDF-Publisher.

Schöne Grüße,

- Michael Müller-Hillebrand

--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologien
Adobe Certified Expert, FrameMaker
Aktuelle Infos & Blog: <http://cap-studio.de/>
Tipp: <http://cap-studio.de/wp/index.php/2007/11/rss-feed-ie7/>

marentxml

unread,
May 9, 2008, 2:25:30 AM5/9/08
to ta...@framemaker.de
sali michael

> Haben Sie weitere Kriterien?


deine kritieren überzeugen bereits, trotzdem hab ich weitere wichtige
argumente für den einsatz von framemaker-xml:

+ qualitätssicherheit. währenddem man im unstrukturierten framemaker
letztlich beliebiges formatchaos anstellen kann, bedeutet das arbeiten
mit dem strukturierten framemaker, dass man die strukturelle qualität
eines dokumentes über dessen validierung 100%ig sicherstellen kann. je
nach dtd lässt sich so auch die inhaltliche qualität eine dokumentes
stark beeinflussen.

beispiele: symptombeschreibung vor hypothesen bzgl ursachen, dann erst
befundstellung, dann diagnose und dann reparaturprozess. oder
warnhinweis *vor* instruktionsschritt. oder jedes bild mit titel. oder
keine tabellen in listen. oder oder oder

+ werkzeugunabhängigkeit. es muss nicht mehr jedermann/-frau mit (dem
teuren) framemaker arbeiten, um inhalte beizusteuern. es können auch
billige und einfache xml editoren verwendet werden, die texte
schneller, einfacher und kostengünstiger in identischer dtd
beisteuern. in framemaker öffnen - und fertig. keine konvertierung.
kein aufwand.

+ nachhaltigkeit. legt man inhalte in xml an, so lassen sich viele
technologien anschliessen, deren nachhaltigkeit sichergestellt ist,
denn xml ist anerkannt und wird breit unterstützt. viele dms oder cms
systeme haben probleme mit framemaker fm dateien, nicht jedoch mit
xml. der aufbau von technologien rund um xml dokumente ist damit eine
nachhaltige investition.

+ standardisierung. xml ist seit den später 90er jahren standardisiert
und bietet aus diesem grund grosse sicherheiten bzgl zukunftsicherheit.

entscheidend für einen sorgenfreien einsatz von xml ist aus meiner
sicht aber sicherlich eine einfache dtd.

lieber gruss
frank

Michael Müller-Hillebrand

unread,
May 9, 2008, 3:10:26 AM5/9/08
to ta...@framemaker.de
Am 09.05.2008 um 08:25 schrieb marentxml:

> entscheidend für einen sorgenfreien einsatz von xml ist aus meiner
> sicht aber sicherlich eine einfache dtd.


Die kaufmännisch korrekte Vokabel wäre wohl "angemessene DTD", aber
das Ziel ist das gleiche. Wer hier zu viel will (klassisch: "Alles
was wir bisher publiziert haben, muss sich genauso auch mit XML
machen lassen."), schießt übers Ziel hinaus und gefährdet das Projekt.

Aber erst einmal muss man den XML-Weg gehen wollen, um dann mit
einem fähigen Partner über die angemessene/einfache DTD zu
entscheiden. Ich habe die Kriterien zusammengefasst unter

<http://cap-studio.de/wp/index.php/2008/05/gruende-fuer-xml-
strukturierte-doku-erstellung/>

Schöne Grüße,

- Michael Müller-Hillebrand

--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologie

Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
<http://cap-studio.de/> -- Tel. +49 (9131) 28747

Reng, Dr. Winfried

unread,
May 9, 2008, 7:15:15 AM5/9/08
to ta...@framemaker.de
Hallo,

wir brauchen aber trotzdem etwas aus unseren vorhandenen
Dokumenten und zwar Textrahmen in den Abbildungen mit
einer Erklärung, was die einzelnen Elemente in der
Abbildung sind. Meine Anwender lehnen Zahlen ab.

Wie kann ich so etwas in strukturiertem FrameMaker pflegen?
Ich vermute mal, dass das kein Problem ist, solange ich in
FrameMaker bleibe.

Ich möchte jetzt nicht den Text in der Grafikdatei selbst
pflegen. Das muss ja auch übersetzt werden. Nummern würde
ich auch ungern in die Grafikdatei kopieren, da ich dann
immer schauen müsste, wie groß die nachher im Endformat
sind.

Was machen Sie/macht ihr?

Viele Grüße

Winfried Reng

Ute Mitschke

unread,
May 9, 2008, 7:38:45 AM5/9/08
to ta...@framemaker.de
Hallo Herr Reng,

>>>wir brauchen aber trotzdem etwas aus unseren vorhandenen Dokumenten
und zwar Textrahmen in den Abbildungen mit einer Erklärung, was die
einzelnen Elemente in der Abbildung sind. Meine Anwender lehnen Zahlen
ab.<<<

also ich nehme da zum Beispiel:

1. Variante: einfach Framescript und schreibe beim Export alle
Informationen, die dann nicht mehr direkt per XML im-/exportiert werden
können, weil in verankerten Rahmen angelegt, in entsprechend dafür
eingerichtete Attribute und beim Import wird das dann wieder per Script
in den Rahmen neu angelegt entsprechend vorhandener Attributwerte. So
sind alle Texte im XML-Datenstrom enthalten und können z.B. auch gut
übersetzt werden.

2. Variante - Legenden im XML-Datenstrom und Querverweise auf die
Legenden-Texte innerhalb kleiner Textrahmen im Bild. Und dann werden nur
die Informationen zu den zusätzlichen kleinen Textrahmen überm Bild in
Attributen verpackt durch ein Script.

Das sind nur zwei Ideen, die möglich wären. Und in Abhängigkeit vom
Gesamtsystem, was gewählt wird, kann das noch wieder anders
funktionieren.
Wenn ich da an TIM-RS denke und wenn ich das richtig verstanden habe,
dann kann das System die Inhalte verankerter Rahmen innerhalb des
XML-Datenstroms an sich in XML "zerbröseln" und wieder zusammensetzen.
Dazu sollte aber FCT bitte aber noch mal genauer gefragt werden, was es
da für Randbedingungen gibt - die hab ich nicht im Kopf.

Herzliche Grüße aus der Hauptstadt und
schöne Pfingstfeiertage in die Runde

Ute Mitschke

Reinhard Rausch

unread,
May 9, 2008, 7:33:22 AM5/9/08
to talk framemaker
Holla,
 
die Displayabbildungen für unsere Maschinenbedienung sind in der Betriebsanleitung abgebildet. Die Displaysprache ist je nach Land umstellbar. Um in der BA (Betriebsanleitung) nicht jede Displayabbildung in jeder Sprache gespeichert zu haben, wird die Abbildung ohne Sprache in die BA übernommen und der Text in der jeweiligen Sprachversion der BA eingegeben.
Vorteil: nur ein Bild gespeichert, und bei Änderungen ist eine korrigierte Displayabbildung in allen Sprachen aktualisiert. Sprachkorrektur ggf., wenn nötig.
 
 
Schöne Pfingsten,
 
Reinhard Rausch
- Leiter Technische Dokumentation -
 
Tel.:    +49 (0)451/5302-423
e-mail: reinhar...@baader.com

---
Nordischer Maschinenbau Rud.Baader GmbH+Co.KG
Geniner Str. 249, D-23560 Luebeck / Germany
KG: Sitz Luebeck · HRA 1389 Luebeck
Komplementaerin:
Baader Verwaltungsgesellschaft mbH
Sitz Luebeck · HRB 474 Luebeck
Geschaeftsfuehrer: Konsulin Petra Baader, Dr. Anton Gallhuber, Ralph A. Miller
BAADER certified according to DIN EN ISO 9001:2000

Johannes Graubner (Transcom)

unread,
May 9, 2008, 7:53:13 AM5/9/08
to ta...@framemaker.de

Hallo Herr Rausch,

 

<--- die Displayabbildungen für unsere Maschinenbedienung sind in der Betriebsanleitung abgebildet. Die Displaysprache ist je nach Land umstellbar. Um in der BA (Betriebsanleitung) nicht jede Displayabbildung in jeder Sprache gespeichert zu haben, wird die Abbildung ohne Sprache in die BA übernommen und der Text in der jeweiligen Sprachversion der BA eingegeben. --->

 

das würde mich mal genauer interessieren:

·         Wie kommen Sie zu ihren „sprachlosen“ Screenshots?

·         Wie gehen Sie mit unterschiedlichen Lauflängen der Texte um?

·         Machen Sie sich tatsächlich die Mühe, alle Texte in der richtigen Schriftgröße am richtigen Ort zu platzieren? (Ganz abgesehen davon, dass es dem geübten Auge auffällt, wenn saubere Vektorschriften auf pixeligen Screenshots stehen.)

·         Wie platzieren Sie die Texte – es ging in der Frage um strukturierten FrameMaker?

 

Mit freundlichen Grüßen

Johannes Graubner

 

Johannes Graubner (Transcom)

unread,
May 9, 2008, 8:03:23 AM5/9/08
to ta...@framemaker.de
Hallo in die Runde,

Wilfried Reng meinte: Wir brauchen ...

<--- Abbildungen mit einer Erklärung, was die einzelnen Elemente in der
Abbildung sind. Meine Anwender lehnen Zahlen ab. --->

Ich hatte mal mit SVG experimentiert: Eigentlich sollte das die Lösung für
das Problem sein -- XML-Derivat, Texte als Texte erhalten und theoretisch
von Übersetzungsprogrammen extrahierbar. Leider war es damals in der
praktischen Umsetzung unbrauchbar: FrameMaker brauchte Ewigkeiten, um eine
SVG-Grafik anzuzeigen, beim Export der Grafiken aus dem Grafikprogramm
entstand kein sauberer Textstring, so dass das Übersetzungsprogramm auch
seine Schwierigkeiten hatte. Das Problem der Lauflänge in unterschiedlichen
Sprachen (im SVG ist eine Box mit der vom Text belegten Größe definiert)
habe ich da gar nicht mehr versucht, zu lösen.

Hat jemand aktuelle Erfahrungen mit der Platzierung und Übersetzung von
Texten in der Grafikdatei? Gibt es inzwischen brauchbare Lösungen?

(Das Überlagern von Bildern mit Texten in der Layout-Software halte ich aus
prinzipiellen Gründen für keine gute Lösung: Sowie sich das Ausgabeformat
ändert, und sei es nur die Seitengröße, geschweige denn ein anderes
Dateiformat, kann die schöne Textplatzierung im Eimer sein.)

Mit freundlichen Grüßen
Johannes Graubner

Transcom. Ing.-Büro Johannes Graubner
mailto:grau...@transcom.de Tel. 03641-620 540
http://www.transcom.de Fax 0941-5992 95552

Bernd Meissner

unread,
May 9, 2008, 8:23:18 AM5/9/08
to ta...@framemaker.de
Johannes Graubner (Transcom) wrote:

> Hat jemand aktuelle Erfahrungen mit der Platzierung und Übersetzung von
> Texten in der Grafikdatei? Gibt es inzwischen brauchbare Lösungen?


Hallo Herr Graubner,

wir haben da im Augenblick folgendes Konstrukt in Anwendung. Es geht
ebenfalls um Software-Screens, die in allen Sprachen die gleichen
grafischen Elemente und Aufteilung haben, lediglich die Texte wechseln.

In einem aktuellen Projekt habe ich dafür folgendes Verfahren
ausprobiert, was soweit auch bewährt hat. Lediglich die Anzahl der
entstehenden Quelldateien ist erstmal recht hoch, da jeweils eine
ID-Datei und daraus eine PDF oder EPS entsteht.

- Jeder Screen wird mit allen optischen Elementen in InDesign aufgebaut
(das hätte auch Illustrator sein können, aber der hatte zum Zeitpunkt
der Testphase einen Bug bzgl. Variable/XML/Unicode-Import).

- Für die Textstrings in der Software existiert (in unserem Fall)
sowieso eine XML-Datei. Mittels einer XSLT haben wir diese für unsere
Zwecke optimiert. Diese XML importieren wir ins ID-Screen-Layout und
verknüpfen die Textboxen mit den gewünschten XML-Objekten (incl.
Zuordnung Tag->Format). Anschließend wird aus dieser ID-Datei das Bild
(PDF/EPS/...) exportiert. Erstmal ein gewisser Aufwand, aber:

- Sprachwechsel findet jetzt einfach durch Neueinlesen der XML statt, in
der jeweiligen Sprache. Wenn die Software-Schreiberlinge daran gedacht
haben, die Textlängen zu spezifizieren, dann klappt das auch reibungslos :-)

Schöne Grüße,
Bernd Meißner

--
------------------------------------------------------------
meißner > dokuteam
Bachgasse 1a
D-86438 Kissing
Tel: 08233/73834-0

Inh. Bernd Meißner
USt-Id: DE158289104
http://www.meissner-dokuteam.de
------------------------------------------------------------

thomas becker

unread,
May 9, 2008, 10:44:10 AM5/9/08
to ta...@framemaker.de
<--- Abbildungen mit einer Erklärung, was die einzelnen Elemente in der
Abbildung sind. Meine Anwender lehnen Zahlen ab. --->

..bedeutet das, der Anwender möchte keine Legendierung mittels Ziffern oder
Buchstaben haben, sondern jeweils die Grafik überlagernden Text?

Eine Alternative zu den hier angesprochenen Lösungen wäre noch ein Haushalt
an Variablen, die ja nach Sprache mit den richtigen Inhalten versehen
werden.

..oder, 1 komplette Grafik und passend jeweils zur Beschreibung der
Ausschnitt, auf den sich die Beschreibung bezieht. Was bei ähnlichen
Abbildungen natürlich Problematisch werden kann.
(wenn ich die Anforderung richtig verstanden habe)

Grüße sendet Thomas

20i...@arcor.de

unread,
May 9, 2008, 10:56:51 AM5/9/08
to ta...@framemaker.de
Hallo Dr. Reng,

ich verstehe nicht, weswegen Sie Textrahmen in einem Grafikcontainer setzen wollen. Dazu gibts die Legende. Denken Sie an die Übersetzung, z.B. mit dem TMS Trados. Der Übersetzer, mit der xml-Struktur vor sich, wird seine Schwierigkeiten haben, vermute ich zumindest. TMS wird das Element nicht auflösen können.

Soweit ich informiert bin, ist Text in einem Grafikkasten eine Strukturverletzung, die wiederum bei Publizieren in verschiedene Formate Probleme bereiten kann.

Gruß
Ingo


> wir brauchen aber trotzdem etwas aus unseren vorhandenen

> Dokumenten und zwar Textrahmen in den Abbildungen mit einer

> Erklärung, was die einzelnen Elemente in der Abbildung sind.
> Meine Anwender lehnen Zahlen ab.
>

> Wie kann ich so etwas in strukturiertem FrameMaker pflegen?
> Ich vermute mal, dass das kein Problem ist, solange ich in
> FrameMaker bleibe.

Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv

thomas becker

unread,
May 9, 2008, 11:18:08 AM5/9/08
to ta...@framemaker.de
Hallo Herr Dr.Reng,

>Nummern würde ich auch ungern in die Grafikdatei kopieren, da ich dann
immer schauen müsste, wie groß die nachher im Endformat sind.

2 Alternativen:

1. Grafiken in der Größe 1:1 anlegen, dass passt es auch mir der
Nummerngröße. Allerdings ist die natürlich pixlig und wird sich für den
geübten Betrachter unterscheiden.

2. Legende(nnummer) als Text über die Grafik in FM. Ist etwas pfriemelig
aber mit Bordmitteln schön einstellbar und sieht sauberer aus.

Grüße sendet Thomas Becker

Michael Müller-Hillebrand

unread,
May 10, 2008, 4:42:05 AM5/10/08
to ta...@framemaker.de
Am 09.05.2008 um 13:38 schrieb Ute Mitschke:

> Wenn ich da an TIM-RS denke und wenn ich das richtig verstanden habe,
> dann kann das System die Inhalte verankerter Rahmen innerhalb des
> XML-Datenstroms an sich in XML "zerbröseln" und wieder zusammensetzen.
> Dazu sollte aber FCT bitte aber noch mal genauer gefragt werden,
> was es
> da für Randbedingungen gibt - die hab ich nicht im Kopf.


TIM-RS verwendet einen eigenen XML-Export/Import, der auch die
Inhalte von verankerten Rahmen komplett nach XML auflöst.

Das könnte Adobe bei FrameMaker auch implementieren, allerdings muss
ich zugeben, dass dies einem gewissen Wildwuchs Vorschub leisten
würde und die Anwender nicht zu einem sauberen Grafikprozess zwingt.
Denn leider entziehen sich manuell platzierte Legenden über einer
Grafik einem automatischen Formatierprozess, und wer ist dann
"schuld", wenn die Beschriftungen verrutscht sind? Und selbst wenn
dadurch die Texte auch im XML-Datenstrom stehen, wer ist dafür
zuständig deren Position nach *jeder* Übersetzung zu prüfen und zu
korrigieren. Gerade letzteres bringt in meinen Augen einen schlanken
XMl-Prozess zum Stottern. Und ich vermute einmal, dass dies der Grund
ist, weshalb dafür noch keine Plug-in-Lösung auf dem Markt ist:
Export und Import wären durchaus (auch mit FrameScript) möglich, aber
die Laufweitenunterschiede in den Sprachen bekommt man so nicht in
den Griff.

Am 09.05.2008 um 16:56 schrieb 20i...@arcor.de:

> Soweit ich informiert bin, ist Text in einem Grafikkasten eine
> Strukturverletzung, die wiederum bei Publizieren in verschiedene
> Formate Probleme bereiten kann.

Es ist keine Strukturverletzung, man kann innerhalb von Grafiken
machen, was immer man möchte. Aber gerade dies führt zu den
angedeuteten Problemen.

Schöne Grüße,

- Michael Müller-Hillebrand

--
_______________________________________________________________
Michael Müller-Hillebrand: Dokumentations-Technologie
Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
<http://cap-studio.de/> -- Tel. +49 (9131) 28747

_______________________________________________

Reply all
Reply to author
Forward
0 new messages