Author: shinz
Date: 2007-04-25 12:52:12 +0200 (Wed, 25 Apr 2007)
New Revision: 6178
Log:
tools.de.xml translated into German; tools.de updated on the fly
Modified:
trunk/mysqldoc-guide/tools.de.xml
trunk/mysqldoc-guide/tools.xml
Modified: trunk/mysqldoc-guide/tools.de.xml
===================================================================
--- trunk/mysqldoc-guide/tools.de.xml 2007-04-25 10:19:36 UTC (rev 6177)
+++ trunk/mysqldoc-guide/tools.de.xml 2007-04-25 10:52:12 UTC (rev 6178)
Changed blocks: 6, Lines Added: 188, Lines Deleted: 111; 25816 bytes
@@ -40,22 +40,37 @@
</listitem>
<listitem>
- <para>Auflösung von Problemen, die sich ergeben, wenn eine Datei auf Abschnitte außerhalb des aktuellen Dokuments verweist.</para>
+ <para>
+ Auflösung von Problemen, die sich ergeben, wenn eine Datei
+ auf Abschnitte außerhalb des aktuellen Dokuments verweist.
+ </para>
</listitem>
</itemizedlist>
</para>
<para>
- Hierfür wird eine Reihe von Skripts verwendet, die die DocBook XML-Quelldateien parsen und eine Liste der IDs erzeugen, die diese enthalten. Außerdem werden die Eltern-IDs, die den IDs zugeordneten Überschriften (falls verfügbar) und deren Typ aufgezeichnet. Diese Informationen werden pro geparster Datei in jeweils eine separate Datei geschrieben, die allesamt im Verzeichnis <filename>metadata</filename> liegen.
+ Hierfür wird eine Reihe von Skripts verwendet, die die DocBook
+ XML-Quelldateien parsen und eine Liste der IDs erzeugen, die diese
+ enthalten. Außerdem werden die Eltern-IDs, die den IDs
+ zugeordneten Überschriften (falls verfügbar) und deren Typ
+ aufgezeichnet. Diese Informationen werden pro geparster Datei in
+ jeweils eine separate Datei geschrieben, die allesamt im
+ Verzeichnis <filename>metadata</filename> liegen.
</para>
<para>
- Wenn eine DocBook XML-Datei validiert wird, werden alle ID Maps der Dateien, aus denen das Hauptdokument besteht, geladen. Die Ausgabe der Validierung wird dann durch ein Skript geleitet (<command>idvalidate.pl</command>), das überprüft, ob die fehlenden IDs in der Datei zumindest im Gesamtbild des Dokuments gültig sind.
+ Wenn eine DocBook XML-Datei validiert wird, werden alle ID Maps
+ der Dateien, aus denen das Hauptdokument besteht, geladen. Die
+ Ausgabe der Validierung wird dann durch ein Skript geleitet
+ (<command>idvalidate.pl</command>), das überprüft, ob die
+ fehlenden IDs in der Datei zumindest im Gesamtbild des Dokuments
+ gültig sind.
</para>
<para>
- Für IDs, die nicht im gesamten Dokument vorhanden sind, werden Querverweise in Form von Links zu externen URLs erzeugt. Die Ziele
+ Für IDs, die nicht im gesamten Dokument vorhanden sind, werden
+ Querverweise in Form von Links zu externen URLs erzeugt. Die Ziele
dieser Links befinden sich auf der MySQL-Website; insofern ist
dieses Mapping hart kodiert. Hierdurch bleiben Links gültig, die
von einem beliebigen Dokument (das beispielsweise nur aus einem
@@ -64,7 +79,8 @@
<para>
Die vom ID-Mapping-System erzeugte Datenbank von Abschnitts-IDs
- findet auch für weitere Anwendungsfälle Gebrauch, beispielsweise für das <quote>System beliebiger Dokumente</quote>, siehe
+ findet auch für weitere Anwendungsfälle Gebrauch, beispielsweise
+ für das <quote>System beliebiger Dokumente</quote>, siehe
<xref linkend="mysqldoc-guide-tools-arby"/>.
</para>
@@ -77,36 +93,66 @@
<para>
Das <quote>System beliebiger Dokumente</quote> (von uns kurz auch
<quote>Arby</quote> genannt, von arbitrary = beliebig) ist eine
- Methode zum Erzeugen komplexer Dokumente, mit der einzelne Dateien und Abschnitte aus verschiedenen Teilen des MySQL-Dokumentationsbaums vermischt werden können.
+ Methode zum Erzeugen komplexer Dokumente, mit der einzelne Dateien
+ und Abschnitte aus verschiedenen Teilen des
+ MySQL-Dokumentationsbaums vermischt werden können.
</para>
<para>
Die standardmäßige Methode zum Erzeugen eines individuell
- zusammengestellten Dokuments beruht auf der Aufteilung der DocBook XML-Dokumentation in einzelne Dateien, die in einem übergeordneten Dokument (<quote>Hauptdokument</quote>) importiert werden. Diese Methode wird im MySQL-Dokumentationsbaum für nahezu alle Dokumente angewandt, deren Kapitel (und gelegentlich auch Abschnitte) in individuellen Dateien vorliegen, die im Hauptdokument explizit importiert werden.
+ zusammengestellten Dokuments beruht auf der Aufteilung der DocBook
+ XML-Dokumentation in einzelne Dateien, die in einem
+ übergeordneten Dokument (<quote>Hauptdokument</quote>) importiert
+ werden. Diese Methode wird im MySQL-Dokumentationsbaum für nahezu
+ alle Dokumente angewandt, deren Kapitel (und gelegentlich auch
+ Abschnitte) in individuellen Dateien vorliegen, die im
+ Hauptdokument explizit importiert werden.
</para>
<para>
- Beispielsweise ist das vorliegende Dokument, der Überblick über die MySQL-Dokumentation, in vier separate Teile aufgespalten: <filename>tools.xml</filename>, <filename>writing.xml</filename>,
+ Beispielsweise ist das vorliegende Dokument, der Überblick über
+ die MySQL-Dokumentation, in vier separate Teile aufgespalten:
+ <filename>tools.xml</filename>, <filename>writing.xml</filename>,
<filename>overview.xml</filename> und
- <filename>formats.xml</filename>. Um diese zu einem einzigen Dokument zusammenzufassen, werden sie im Hauptdokument
+ <filename>formats.xml</filename>. Um diese zu einem einzigen
+ Dokument zusammenzufassen, werden sie im Hauptdokument
<filename>mysqldoc-guide.xml</filename> importiert.
</para>
<para>
- Das Problem dieser Methode ist jedoch, dass sich nur vollständige Dateien, nicht aber einzelne Abschnitte importieren lassen. Für letzteres müsste man die gesamte Dokumentation auf Abschnittsebene in Dateien aufspalten, was bei größeren Dokumenten wie dem MySQL-Referenzhandbuch zu mehreren tausend Dateien und der damit verbundenen Unübersichtlichkeit führen würde.
+ Das Problem dieser Methode ist jedoch, dass sich nur vollständige
+ Dateien, nicht aber einzelne Abschnitte importieren lassen. Für
+ letzteres müsste man die gesamte Dokumentation auf
+ Abschnittsebene in Dateien aufspalten, was bei größeren
+ Dokumenten wie dem MySQL-Referenzhandbuch zu mehreren tausend
+ Dateien und der damit verbundenen Unübersichtlichkeit führen
+ würde.
</para>
<para>
Darüber hinaus kann bei Verwendung dieser Methode auch kein
- Abschnitt importiert und als Kapitel verwendet werden, oder umgekehrt ein Kapitel zu einem Abschnitt gemacht werden.
+ Abschnitt importiert und als Kapitel verwendet werden, oder
+ umgekehrt ein Kapitel zu einem Abschnitt gemacht werden.
</para>
<para>
- Diese Probleme geht das <quote>System beliebiger Dokumente</quote> an. Es funktioniert in Kombination mit dem ID-Mapping-System und ermöglicht es, ein zusammengesetztes Dokument zu erzeugen, das aus beliebigen Komponenten innerhalb des Dokumentationsbaums besteht (daher der Name). Einzige Voraussetzung an diese Komponenten ist es, das sie mit einer ID versehen sind. Das System ist auch in der Lage, Abschnitte in Kapitel zu konvertieren und umgekehrt, und kann in den ausgewählten Komponenten enthaltene Unterkomponenten einschließen oder ausschließen.
+ Diese Probleme geht das <quote>System beliebiger Dokumente</quote>
+ an. Es funktioniert in Kombination mit dem ID-Mapping-System und
+ ermöglicht es, ein zusammengesetztes Dokument zu erzeugen, das
+ aus beliebigen Komponenten innerhalb des Dokumentationsbaums
+ besteht (daher der Name). Einzige Voraussetzung an diese
+ Komponenten ist es, das sie mit einer ID versehen sind. Das System
+ ist auch in der Lage, Abschnitte in Kapitel zu konvertieren und
+ umgekehrt, und kann in den ausgewählten Komponenten enthaltene
+ Unterkomponenten einschließen oder ausschließen.
</para>
<para>
- <quote>Arby</quote> funktioniert mittels eine einzigen Skripts in Kombination mit einer XML-Definition des beliebig zusammengestellten Dokuments, das erzeugt werden soll, und einem Wrapper in DocBook XML, der für die grundlegende Dokumentstruktur verwendet wird.
+ <quote>Arby</quote> funktioniert mittels eine einzigen Skripts in
+ Kombination mit einer XML-Definition des beliebig
+ zusammengestellten Dokuments, das erzeugt werden soll, und einem
+ Wrapper in DocBook XML, der für die grundlegende Dokumentstruktur
+ verwendet wird.
</para>
<section id="mysqldoc-guide-tools-arby-xml">
@@ -114,14 +160,18 @@
<title><quote>Arby</quote> XML schreiben</title>
<para>
- Beispieldateien für beliebig zusammengestellte Dokumente liegen im Verzeichnis
- <filename>arbitrary</filename> des
- <literal>mysqldoc</literal>-Repositories. Um zu zeigen, wie das System funktioniert, verwenden wir die Spezifikation <filename>windows.aspec</filename>
- und die Wrapper-Datei <filename>windows.xml</filename>.
+ Beispieldateien für beliebig zusammengestellte Dokumente liegen
+ im Verzeichnis <filename>arbitrary</filename> des
+ <literal>mysqldoc</literal>-Repositories. Um zu zeigen, wie das
+ System funktioniert, verwenden wir die Spezifikation
+ <filename>windows.aspec</filename> und die Wrapper-Datei
+ <filename>windows.xml</filename>.
</para>
<para>
- Die Struktur der Spezifikationsdatei sieht wie folgt aus:
+ Die Struktur der Spezifikationsdatei sieht wie folgt aus (das
+ Beispiel erzeugt aus Ausschnitten des MySQL-Referenzhandbuchs
+ ein Windows-spezifisches Handbuch):
</para>
<programlisting><![CDATA[<?xml version="1.0" encoding="utf-8"?>
@@ -140,210 +190,235 @@
</book>]]></programlisting>
<para>
- Inhaltsblöcke werden in Fragmenten angeordnet und benötigen eine eindeutige ID. Diese ID wird verwendet, wenn das Fragment in das Wrapper-Dokument eingefügt wird. Das Fragment selbst enthält keinen DocBook XML-Abschnitt, sondern ist schlicht der Name, der einem beliebigen Textblock zugewiesen wurde, der seinerseits beliebige Abschnitte und Kapitel enthalten kann.
+ Inhaltsblöcke werden in Fragmenten angeordnet und benötigen
+ eine eindeutige ID. Diese ID wird verwendet, wenn das Fragment
+ in das Wrapper-Dokument eingefügt wird. Das Fragment selbst
+ enthält keinen DocBook XML-Abschnitt, sondern ist schlicht der
+ Name, der einem beliebigen Textblock zugewiesen wurde, der
+ seinerseits beliebige Abschnitte und Kapitel enthalten kann.
</para>
<para>
- Der Tag <literal>include</literal> wird benutzt, um den Abschnitt der Dokumentation anzugeben, der ins Fragment eingefügt werden soll. Abschnitte werden in der Reihenfolge eingefügt, in der sie hier angegeben werden. Die Definitionen zum Einfügen haben folgende Attribute:
+ Der Tag <literal>include</literal> wird benutzt, um den
+ Abschnitt der Dokumentation anzugeben, der ins Fragment
+ eingefügt werden soll. Abschnitte werden in der Reihenfolge
+ eingefügt, in der sie hier angegeben werden. Die Definitionen
+ zum Einfügen haben folgende Attribute:
</para>
<itemizedlist>
<listitem>
<para>
- <literal>src</literal> — die ID des Abschnitts, der importiert werden soll. Diese muss eine gültige ID aus einem beliebigen Dokument innerhalb des Dokumentationsbaums sein.
+ <literal>src</literal> — die ID des Abschnitts, der
+ importiert werden soll. Diese muss eine gültige ID aus
+ einem beliebigen Dokument innerhalb des Dokumentationsbaums
+ sein.
</para>
</listitem>
<listitem>
<para>
- <literal>prefix</literal> — if the ID you have
- specified is defined in multiple documents then you can use
- the prefix to select which source document to use.
+ <literal>prefix</literal> — wenn die angegebene ID in
+ mehreren Dokumenten vorhanden ist, kann ein Präfix
+ verwendet werden, um das gewünschte Dokument festzulegen,
+ aus der die ID stammen soll.
</para>
</listitem>
<listitem>
<para>
- <literal>filter</literal> — you can choose whether to
- filter the subsections within a given ID. The valid options
- are <literal>none</literal>, which implies that all sections
- are incorporated (including any imported documents) or
- <literal>all</literal>, which filters all subsections,
- including imported documents.
+ <literal>filter</literal> — hiermit lässt sich
+ festlegen, was herausgefiltert werden soll. Es gibt zwei
+ Möglichkeiten: <literal>none</literal> (nichts) bedeutet,
+ dass alle enthaltenen Abschnitte inklusive eventueller
+ importierter Dokumente eingeschlossen werden, während
+ <literal>all</literal> (alles) bedeutet, dass sämtliche
+ Unterabschnitte inklusive eventueller importierter Dokumente
+ herausgefiltert werden.
</para>
</listitem>
<listitem>
<para>
- <literal>markas</literal> — if you are importing a
- section and want the section to be treated as a chapter, or
- for a chapter to be treated as a section, you can specify
- what the imported section should be remapped as.
+ <literal>markas</literal> — hiermit lässt sich ein
+ Abschnitt in ein Kapitel oder umgekehrt
+ <quote>ummünzen</quote>.
</para>
</listitem>
</itemizedlist>
<para>
- For example, the first <literal>include</literal> tag within the
- Windows arbitrary document specification shows that we are
- importing the section <literal>windows-installation</literal>,
- that we shouldn't filter an sub-sections, that we should source
- the section from the <filename>refman-5.1</filename> directory
- and that the section should be remapped as chapter.
+ Im oben aufgeführten Beispiel eines Windows-spezifischen
+ Referenzhandbuchs bedeutet der erste
+ <literal>include</literal>-Tag, dass der Abschnitt
+ <literal>windows-installation</literal> importiert wird, und
+ dass in diesem keine Unterabschnitte herausgefiltert werden. Der
+ Abschnitt soll darüber hinaus aus dem Verzeichnis
+ <filename>refman-5.1</filename> stammen und zum Kapitel
+ <quote>umgemünzt</quote> werden.
</para>
<para>
- You can close the tag at this point if this is the only section
- that you want to import. However, if you want to include
- additional sections to form subsections of the section you have
- just specified, you can add more <literal>include</literal>
- statements. An example of this is shown in the Windows arbitrary
- document.
+ Falls keine weiteren Abschnitte importiert werden sollen, kann
+ der Tag an dieser Stelle bereits geschlossen werden. Sollen
+ jedoch weitere Abschnitte importiert werden, die Unterabschnitte
+ des gerade festgelegten Abschnitts bilden sollen, werden weitere
+ <literal>include</literal>-Anweisungen hinzugefügt. Das wird im
+ oben genannten Beispiel ebenfalls gezeigt.
</para>
<para>
- For any included section, you can also change the title of the
- section when it is imported by using the
- <literal>title</literal> tag within the
- <literal>include</literal> tag. In the example specification,
- the <literal>installation-windows</literal> section title has
- been altered.
+ Für jeden importierten Abschnitt kann die Überschrift
+ geänderte werden, indem innerhalb des
+ <literal>include</literal>-Tags ein <literal>title</literal>-Tag
+ angegeben wird. Im obigen Beispiel wird die Überschrift des
+ Abschnitts <literal>installation-windows</literal> geändert.
</para>
<para>
- You can have as many <literal>include</literal> statements as
- you like, and an unlimited structure of nesting. You can also
- specify as many fragments as you like in the arbitrary
- specification file. The only limitation is that you cannot
- import the same section multiple times (because this would
- introduce multiple IDs into the final document).
+ Es können beliebig viele <literal>include</literal>-Anweisungen
+ angegeben werden. Auch die Schachtelungstiefe ist unbegrenzt.
+ Innerhalb einer Spezifikationsdatei können beliebig viele
+ Fragmente vorhanden sein. Die einzige Einschränkung besteht
+ darin, dass derselbe Abschnitt nicht mehrfach importiert werden
+ darf, denn das würde zu nicht eindeutigen IDs im Zieldokument
+ führen.
</para>
<para>
- To actually generate your document, you also need the wrapper
- file into which the fragments will be inserted as part of the
- build process.
+ Um aus der Spezifikation ein Dokument zu erzeugen, wird
+ zusätzlich noch eine Wrapper-Datei benötigt, in die die
+ Fragmente als Teil des Erzeugungsprozesses eingefügt werden.
</para>
</section>
<section id="mysqldoc-guide-tools-arby-wrapper">
- <title>Writing an Arby Wrapper</title>
+ <title>Die <quote>Arby</quote>-Wrapper-Datei</title>
<para>
- An Arby wrapper is just a DocBook XML document that includes
- specially formatted comment tags. These comment tags will be
- replaced with the corresponding fragment from the arbitrary
- documentation specification. The wrapper document can contain
- any standard DocBook XML, even additional chapters, sections and
- statements to include other entire files into the document.
+ Ein <quote>Arby</quote>-Wrapper ist ein gewöhnliches DocBook
+ XML-Dokument, das speziell formatierte Kommentar-Tags
+ beinhaltet. Diese Kommentar-Tags werden durch die entsprechenden
+ Fragmente in der <quote>Arby</quote>-Spezifikationsdatei
+ ersetzt. Das Wrapper-Dokument kann ansonsten jegliches gültige
+ DocBook XML enthalten, selbst zusätzliche Kapitel, Abschnitte
+ und Anweisungen zum Importieren sonstiger Dateien in das
+ Dokument.
</para>
<para>
- When you want to insert a fragment definition from the
- arbitraryt specification you use an XML comment of the form:
+ Zum Einfügen einer Fragment-Definition aus der
+ <quote>Arby</quote>-Spezifikationsdatei wird folgende Form eines
+ XML-Kommentars verwendet:
</para>
<programlisting><![CDATA[<!--SRCFILE fragment-id-->]]></programlisting>
<para>
- Where <literal>fragment-id</literal> is the ID of the
- corresponding fragment in the specification.
+ Hierbei ist <literal>fragment-id</literal> die ID des
+ entsprechenden Fragments in der Spezifikationsdatei.
</para>
<para>
- These specifications should be placed in the appropriate palce
- within your document. For example, if your fragment
- specification creates a chapter, then the specification can be
- placed at top level in the document. If the specification is a
- section, then it must be included in a parent chapter.
+ Diese Festlegungen sollten innerhalb eines Dokuments an der
+ entsprechenden Stelle platziert werden. Wenn die
+ Fragment-Festlegung beispielsweise ein Kapitel erzeugt, kann die
+ Festlegung auf oberster Ebene im Dokument platziert werden. Wenn
+ die Festlegung dagegen einen Abschnitt ergeben soll, muss sie in
+ ein übergeordnetes Kapitel eingebettet werden.
</para>
<para>
- Also be aware that you could, if you wanted, generated multiple
- arbitrary documents which are themselves imported and inserted
- into existing documents.
+ Eine weitere Anwendungsmöglichkeit besteht darin, mehrere
+ <quote>Arby</quote>-Dokumente zu erzeugen, die ihrerseits
+ importiert und in bestehende Dokumente eingefügt werden.
</para>
</section>
<section id="mysqldoc-guide-tools-arby-building">
- <title>Building an Arby Document</title>
+ <title>Erzeugen eines <quote>Arby</quote>-Dokuments</title>
<para>
- To build an arbitrary document you use the same method as you
- would any other document, <command>make</command> with a
- specific target. The <literal>-arbitrary</literal> after the
- base name of the source files indidicates that we should build
- using the arbitrary system. For example, to build the Windows
- arbitrary document as a PDF you would use:
+ Arby-Dokumente werden mit genau denselben Methoden erzeugt wie
+ alle anderen Dokumente, also mittels <command>make</command>
+ unter Angabe eines spezifischen Ziels. Die Angabe von
+ <literal>-arbitrary</literal> nach dem Dateinamen der Quelldatei
+ gibt an, dass ein Dokument mittels des
+ <quote>Arby</quote>-Systems erzeugt werden soll. Um das im
+ obigen Beispiel genannte Windows-spezifische Handbuch als
+ PDF-Datei zu erzeugen, würde folgender Befehl verwendet werden:
</para>
-<programlisting>make windows-arbitrary.pdf</programlisting>
+<programlisting>shell> <userinput>make windows-arbitrary.pdf</userinput></programlisting>
<para>
- Behind the scenes, the following happens:
+ Hinter den Kulissen passiert folgendes:
</para>
<orderedlist>
<listitem>
<para>
- The <command>genarbelements.pl</command> script is executed.
- This accepts the arbitrary specification file and wrapper
- file as arguments.
+ Das Skript <command>genarbelements.pl</command> wird
+ ausgeführt. Es nimmt die Arby-Spezifikationsdatei und die
+ Wrapper-Datei als Argumente entgegen.
</para>
</listitem>
<listitem>
<para>
- The arbitrary specification is parsed and validated.
+ Die Spezifikationsdatei wird geparst und validiert.
</para>
</listitem>
<listitem>
<para>
- For each each fragment, the script then:
+ Danach wird für jedes Fragment folgendes ausgeführt:
</para>
<orderedlist>
<listitem>
<para>
- Parses each <literal>include</literal> statement, first
- loading the file that contains the specified ID.
+ Jede <literal>include</literal>-Anweisung wird geparst,
+ indem zunächst die Datei geladen wird, die die
+ festgelegte ID enthält.
</para>
</listitem>
<listitem>
<para>
- The DocBook XML block (be it section, chapter, or
- appendix) is extracted from the file.
+ Der DocBook XML-Block (der Abschnitt, das Kapitel oder
+ der Anhang) wird aus der Datei extrahiert.
</para>
</listitem>
<listitem>
<para>
- If subsections are filtered, these sections are removed.
+ Falls Unterabschnitte ausgefiltert werden sollen, werden
+ diese Abschnitte entfernt.
</para>
</listitem>
<listitem>
<para>
- If the section is to be remapped, the correesponding
- tags are updated.
+ Wenn der Abschnitt zu einem Kapitel oder Anhang werden
+ soll, werden die entsprechenden Tags aktualisiert.
</para>
</listitem>
<listitem>
<para>
- If the <literal>include</literal> section has additional
- subsections defined, these are appended to the end of
- the section before the closing tag for that section.
+ Wenn im <literal>include</literal>-Abschnitt
+ zusätzliche Unterabschnitte festgelegt sind, werden
+ diese ans Ende des Abschnitts angehängt, bevor der Tag
+ für diesen Abschnitt geschlossen wird.
</para>
</listitem>
@@ -352,24 +427,26 @@
<listitem>
<para>
- Once a fragment specification is complete, the corresponding
- import specification in the wrapper XML is located and
- replaced with the fragment text.
+ Sobald eine Fragment-Spezifikation vollständig ist, wird
+ die entsprechende Import-Spezifikation in der Wrapper-Datei
+ gesucht und durch den Fragment-Text ersetzt.
</para>
</listitem>
<listitem>
<para>
- The update wrapper document is written out as a file with
- name <filename>filename-arbitrary.xml</filename>.
+ Das aktualisierte Wrapper-Dokument wird als Datei
+ geschrieben, wobei als Dateiname
+ <filename><replaceable>filename</replaceable>-arbitrary.xml</filename>
+ verwendet wird.
</para>
</listitem>
</orderedlist>
<para>
- The generated file is then processed as normal by the rest of
- the documentation build process into the desired format.
+ Diese Datei wird dann mittels der normalen
+ Transformationsprozesse ins gewünschte Zielformat umgewandelt.
</para>
</section>
Modified: trunk/mysqldoc-guide/tools.xml
===================================================================
--- trunk/mysqldoc-guide/tools.xml 2007-04-25 10:19:36 UTC (rev 6177)
+++ trunk/mysqldoc-guide/tools.xml 2007-04-25 10:52:12 UTC (rev 6178)
Changed blocks: 3, Lines Added: 5, Lines Deleted: 4; 1334 bytes
@@ -304,7 +304,7 @@
</para>
<para>
- These specifications should be placed in the appropriate palce
+ These specifications should be placed in the appropriate place
within your document. For example, if your fragment
specification creates a chapter, then the specification can be
placed at top level in the document. If the specification is a
@@ -332,7 +332,7 @@
arbitrary document as a PDF you would use:
</para>
-<programlisting>make windows-arbitrary.pdf</programlisting>
+<programlisting>shell> <userinput>make windows-arbitrary.pdf</userinput></programlisting>
<para>
Behind the scenes, the following happens:
@@ -409,8 +409,9 @@
<listitem>
<para>
- The update wrapper document is written out as a file with
- name <filename>filename-arbitrary.xml</filename>.
+ The updated wrapper document is written out as a file with
+ name
+ <filename><replaceable>filename</replaceable>-arbitrary.xml</filename>.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6178 - trunk/mysqldoc-guide | stefan | 25 Apr |
