Reorganized examples dir. Added minimal example for the tr variant.

parent 36e2763c
......@@ -8,38 +8,51 @@
# new single command approach
COMMAND=linuxdoc --backend=
SOURCE=example.sgml
srcfiles = example.sgml example-tr.sgml logo.png logo.eps.gz Makefile
allext = .txt .html .tex .dvi .ps .pdf .info .lyx .rtf
files = $(addprefix example, $(allext))
trfiles = $(addprefix example-tr, $(allext))
allfiles = $(files) $(trfiles)
all: txt html tex dvi ps pdf info lyx rtf
echo "all output formats are created!"
all: $(allfiles)
@echo "all output formats are created!"
txt:
$(COMMAND)$@ $(SOURCE)
%.txt: %.sgml
$(COMMAND)txt $<
html:
$(COMMAND)$@ $(SOURCE)
%.html: %.sgml
$(COMMAND)html $<
tex:
$(COMMAND)latex -o $@ $(SOURCE)
%.tex: %.sgml
$(COMMAND)latex -o tex $<
dvi:
$(COMMAND)latex -o $@ $(SOURCE)
%.dvi: %.sgml logo.eps
$(COMMAND)latex -o dvi $<
ps:
$(COMMAND)latex -o $@ $(SOURCE)
%.ps: %.sgml logo.eps
$(COMMAND)latex -o ps $<
pdf:
$(COMMAND)latex -o $@ $(SOURCE)
%.pdf: %.sgml logo.eps
$(COMMAND)latex -o pdf $<
info:
$(COMMAND)$@ $(SOURCE)
%.info: %.sgml
$(COMMAND)info $<
lyx:
$(COMMAND)$@ $(SOURCE)
%.lyx: %.sgml logo.eps
$(COMMAND)lyx $<
rtf:
$(COMMAND)$@ $(SOURCE)
%.rtf: %.sgml
$(COMMAND)rtf $<
logo.eps: logo.eps.gz
gzip -d -c $< > $@
pack: distclean
tar -cvzf ../linuxdoc-test-tr.tar.gz $(srcfiles)
distclean: clean
rm -f *~ logo.eps
clean:
rm -f *.txt *.html *.tex *.dvi *.ps *.pdf *.info *.lyx *.rtf
......
<!doctype linuxdoctr system>
<!--
Here's an SGML example file for the tr variant, containing only
what is different in it. If you look for a real example file, look at file
example.sgml in this directory.
-->
<article>
<!-- Title information -->
<title>Quick Example for Linuxdoctr DTD SGML source</title>
<author>
<name>Joe Author First <tt/&lt;joe@author@first/&gt;</name>
<and>
<name>Joe Author Second <tt/&lt;joe@author@second/&gt;</name>
</author>
<date>2009/03/18</date>
<trans>
Translated by Joe Test Translator <tt/&lt;joe@test@translator/&gt;
</trans>
<tdate>
2009/04/10
</tdate>
<abstract>
This document is a minimal example of the differences introduced for the
Linuxdoctr DTD SGML. This contains only what is different in it. If you look for
a real example file, look at file example.sgml in this directory.
</abstract>
<!-- Table of contents -->
<toc>
<!-- Begin the document -->
<sect>
<heading>Introduction</heading>
<p>
This document is a minimal example of the differences introduced for the
Linuxdoctr DTD SGML. This contains only what is different in it. If you look for
a real example file, look at file example.sgml in this directory.
<sect1>Tags introduced by the Linuxdoctr DTD
<p>
<descrip>
<tag/trans/ Translator name
<tag/tdate/ Translation date
</descrip>
Both must be placed after <tt/&lt;author/&gt; and <tt/&lt;date/&gt; tags
</sect1>
</sect>
</article>
<!doctype linuxdoc system>
<!-- Here's an SGML example file. Format it and print out the source,
and use it as a model for your own SGML files. As you can see
this is a comment.
<!-- Here's an SGML example file. Format it and print out the source,
and use it as a model for your own SGML files. As you can see
this is a comment.
-->
<article>
......@@ -11,13 +11,15 @@
<title>Quick Example for Linuxdoc DTD SGML source</title>
<author>
<name>originally written by Matt Welsh <tt/&lt;mdw@cs.cornell.edu/&gt;
as &dquot;Quick SGML Example&dquot;,<newline></name>
<and>
<name>recently updated by Taketoshi Sano <tt/&lt;sano@debian.org/&gt;
for linuxdoc-tools<newline></name>
<name>Matt Welsh <tt/&lt;mdw@cs.cornell.edu/&gt;
Original version as &dquot;Quick SGML Example&dquot;,
<newline>
</name>
<and>
<name>Taketoshi Sano <tt/&lt;sano@debian.org/&gt;
Updated and renamed to current name<newline></name>
</author>
<date>$Id: example.sgml,v 1.2 2002/03/18 13:39:12 sano Exp $</date>
<date>2002/03/18</date>
<abstract>
This document is a brief example using the Linuxdoc DTD SGML.
......@@ -32,14 +34,14 @@ This document is a brief example using the Linuxdoc DTD SGML.
<heading>Introduction</heading>
<p>
This is an SGML example file using the Linuxdoc DTD SGML.
This is an SGML example file using the Linuxdoc DTD SGML.
You can format it using the command
<tscreen>
<verb>
% linuxdoc -B txt example.sgml
% linuxdoc -B txt example.sgml
</verb>
</tscreen>
this will produce a plain ASCII file. You can also produce
this will produce a plain ASCII file. You can also produce
files in various formats including LaTeX, HTML and GNU info
with the commands in linuxdoc-tools.
</p>
......@@ -81,17 +83,17 @@ online manual of linuxdoc command.
<sect>The source
<p>
Looking at the source for this file will be instructive to show you
how to use many of the Linuxdoc-SGML constructs. You should also read
Looking at the source for this file will be instructive to show you
how to use many of the Linuxdoc-SGML constructs. You should also read
the <em/Linuxdoc-SGML User's Guide/, in the file <tt/guide.sgml/.
The source looks and feels like LaTeX, as you can see. Paragraphs are
separated by blank lines, macros are enclosed in angle brackets. It's
quite simple.
separated by blank lines, macros are enclosed in angle brackets. It's
quite simple.
(Warning!) This is just a simplificated explanation as a quick reference.
In fact, the correct way to separate paragraphs are not just to put the
blank lines between them. But since the Linuxdoc DTD was created as an
In fact, the correct way to separate paragraphs are not just to put the
blank lines between them. But since the Linuxdoc DTD was created as an
introduction to the SGML world, it allows us to use the easy way.
If you wish to know the correct but not-so-easy way, then read the source
......@@ -115,9 +117,9 @@ Here's a subsubsection:
<p>
Right. 5 levels of sections are available. Use the commands
<tt/sect/, <tt/sect1/, <tt/sect2/, <tt/sect3/, and <tt/sect4/ to get them.
This document uses the <tt>article</> document style, which is
appropriate for HOWTOs and other docs; the <tt>report</> style (which
includes the <tt/chapt/ sectioning command) should be used for the LDP docs.
This document uses the <tt>article</> document style, which is
appropriate for HOWTOs and other docs; the <tt>report</> style (which
includes the <tt/chapt/ sectioning command) should be used for the LDP docs.
<sect1>Example text
......@@ -132,12 +134,12 @@ As well as:
<tscreen><code>
This is an example code environment.
</code></tscreen>
The <tt/tscreen/ environment just sets the font to small type and
The <tt/tscreen/ environment just sets the font to small type and
indents it nicely. It's not required for using <tt/verb/ or <tt/code/,
but I suggest that you do.
but I suggest that you do.
The <em/Linuxdoc-SGML User's Guide/ explains what special characters you
can and can't use in the <tt/verb/ and <tt/code/ environments.
can and can't use in the <tt/verb/ and <tt/code/ environments.
<sect1>
<heading>Cross references<label id="test-ref"></heading>
......@@ -147,7 +149,7 @@ What about cross-references? This section has been marked with the
<tt>label</> command; using <tt>ref</> will provide a cross reference,
as in ``See Section <ref id="test-ref">'' for more. </p>
<p>
Right now cross-references don't work in the <tt/groff/ translation for
Right now cross-references don't work in the <tt/groff/ translation for
plain ASCII. They do work when generating LaTeX or HTML output.</p>
<sect1>Using fonts
......@@ -166,7 +168,7 @@ Lists are easy as well. Just use the <tt/itemize/ element with the
<itemize>
<item> This is a list.
<item> Nothing exciting about that.
<itemize>
<itemize>
<item> Multiple levels are supported as well.
<item> Again, that's no surprise.
</itemize>
......@@ -195,7 +197,7 @@ be used only in html and latex formats.
</p>
<p>
The usage of these tags without very strong reasons is not recommended.
If you wish to enhance your documents, then it may be the time you should
If you wish to enhance your documents, then it may be the time you should
move up to the DocBook DTD. But if you think you have enough reasons to
use graphics with Linuxdoc DTD for your documents, then it is your choice.
</p>
......@@ -210,7 +212,7 @@ by a blind person, while the heavy graphical documents can't.
<p>
Here is an example of table. Check this in various output formats.
Please take care in using this. There are several limitation.
Each row can not be folded into multiple lines, and too long row
Each row can not be folded into multiple lines, and too long row
will be corrupted in the output. The output in info, lyx, and rtf
may not be correct at all. Anyway, you are warned. Be carefull.
......@@ -230,19 +232,19 @@ QWERTZ|The origin of Linuxdoc|sgml2latex-format
<sect2>
<heading>Figure</heading>
<p>
In html and latex output, the graphics can be included with
In html and latex output, the graphics can be included with
the <it>figure</it> element. It is not encouraged to use this feature
since the LinuxDoc DTD is created for fairiy simple and light way of
since the LinuxDoc DTD is created for fairiy simple and light way of
producing the multiple output formats with the same content.
Using graphics only in some outputs will spoil the value of a simple
plain text output in many cases. And heavy usage of huge graphics
plain text output in many cases. And heavy usage of huge graphics
files was just a pain when the network (and the machine) was too slow.
But when you only need the versions in html and latex format, and if
you don't need to concern the network speed, then you can use this.
</p>
<p>
Here is an example to use the figure in html or tex (tex, dvi, and ps).
This example uses the (unofficial) logo of Linux kernel 2.0, which was
This example uses the (unofficial) logo of Linux kernel 2.0, which was
created by Larry Ewing with the GIMP. Check his site:
<url url="http://www.isc.tamu.edu/&tilde;lewing/linux/">
I use &dquot;convert&dquot; command from ImageMagic and ghostscript
......@@ -250,8 +252,8 @@ to get the png and eps files from the original GIF.
</p>
<p>
You should put all the graphic files into the same directory as the
SGML source file. For html and pdf, use <it>img</it> element with png
or jpeg graphic file. For other latex (tex, dvi, and ps), use <it>eps</it>
SGML source file. For html and pdf, use <it>img</it> element with png
or jpeg graphic file. For other latex (tex, dvi, and ps), use <it>eps</it>
element with ps or eps graphic file.
<figure>
......@@ -297,17 +299,17 @@ You should also note that Linuxdoc DTD is created as a simple and easy
introduction for SGML world. Matt Welsh (the original author of the Linuxdoc
DTD and the tool for it) wrote in his guide:
<quote>
If you'd like to write general documentation in SGML, I suggest using
the original QWERTZ DTD instead of the hacked-up linuxdoc DTD, which I've
If you'd like to write general documentation in SGML, I suggest using
the original QWERTZ DTD instead of the hacked-up linuxdoc DTD, which I've
modified for use particularly by the Linux HOWTOs and other such documentation.
</quote>
</p>
<p>
Now the DocBook DTD, which is maintained by OASIS, has been around
for a while, and is very popular for technical documentation.
Moreover, it uses DSSSL, which is an ISO standard for doing rendering.
In the future this might move to and XML DTD and using XSL instead of
DSSSL, but that doesn't matter to the author. See the following URLs
Now the DocBook DTD, which is maintained by OASIS, has been around
for a while, and is very popular for technical documentation.
Moreover, it uses DSSSL, which is an ISO standard for doing rendering.
In the future this might move to and XML DTD and using XSL instead of
DSSSL, but that doesn't matter to the author. See the following URLs
for more info:
<itemize>
<item><url url="http://nwalsh.com/docbook/">
......@@ -321,7 +323,7 @@ for more info:
<p>
You should use the DocBook DTD if you are serious to be a writer
in the technical documentation world. The Linuxdoc DTD is intended
as an easy introduction, and is considered now as the work-around
as an easy introduction, and is considered now as the work-around
to help many useful documents until they can be converted into the
DocBook based.
</p>
......
This source diff could not be displayed because it is too large. You can view the blob instead.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment