X-Git-Url: https://git.proxmox.com/?p=pve-docs.git;a=blobdiff_plain;f=README.adoc;h=6964087d6b37ed46bb323c7ae5ece5f7ecb0c7ec;hp=67179cee44bf34989640c059de250ef94af8ea85;hb=6a6f83747ec67a47d5ad624d7559a57dd0c8dcf2;hpb=d067c2ad940989c15c5756aa50e9eb2e4f063e1a

diff --git a/README.adoc b/README.adoc
index 67179ce..6964087 100644
--- a/README.adoc
+++ b/README.adoc
@@ -1,16 +1,15 @@
 Proxmox VE Documentation
 ========================
-include::attributes.txt[]
 
 We try to generate high quality documentation for
-http://www.proxmox.com[Proxmox VE], and choose to use
+{website}[{pve}], and choose to use
 http://www.methods.co.nz/asciidoc/[AsciiDoc] as base format.
 
 The basic idea is to generate high quality manual pages, and assemble
 them into a complete book, called link:pve-admin-guide.adoc[Proxmox VE
 Administration Guide].  So we have one source, and generate several
 documents from that. It is also possible to generate printable PDF
-files, or ebook formats ('.ebup').
+files, or ebook formats ('.epub').
 
 When possible, we provide scripts to extract API definitions,
 configuration or command line options from the source code.
@@ -37,19 +36,34 @@ build time.
 
 Another package called 'pve-docs' is used to publish generated
 '.html' and '.pdf' files on our web servers. You can generate
-those debian packages using:
+those Debian packages using:
 
  make deb
 
 
-Common Macro definition in link:attributes.txt[]
-------------------------------------------------
+Common Macro definition in link:asciidoc/asciidoc-pve.conf[]
+------------------------------------------------------------
 
 'asciidoc' allows us to define common macros, which can then be
 referred to using `{macro}`. We try to use this mechanism to improve
 consistency. For example, we defined a macro called `pve`, which
-expands to "Proxmox VE". The plan is to add more such definitions for
-terms which are used more than once.
+expands to "Proxmox VE".
+
+For URLs which are used more than once, two macros should be defined:
+
+* `{name-url}`, which just contains the http(s) URL
+* `{name}`, which contains the complete link including the canonical
+description
+
+For example, the macro `{forum-url}` expands to {forum-url}, and the macro
+`{forum}` expands to {forum}.
+
+The plan is to add more such definitions for terms which are used more
+than once.
+
+WARNING: When asciidoc encounters a misspelled macro name, it will
+silently drop the containing line!
+
 
 Autogenerated CLI Command Synopsis
 ----------------------------------
@@ -82,7 +96,7 @@ below the title text:
  Level 3:                 ^^^^^^^^^^^^^^^^^^^^^^
  Level 4 (bottom level):  ++++++++++++++++++++++
 
-Section titles should always be preceeded by two empty lines. Each word
+Section titles should always be preceded by two empty lines. Each word
 in a title should be capitalized except for ``articles, coordinating
 conjunctions, prepositions, and the word to in infinitives unless they
 appear as the first or last word of a title'' (see
@@ -128,7 +142,7 @@ Labeled Lists
 ^^^^^^^^^^^^^
 
 Labeled lists should be used to make lists of key-value style text
-more readable, such as command line parameters or config options:
+more readable, such as command line parameters or configuration options:
 
 .Regular labeled lists
 -----
@@ -176,11 +190,11 @@ Text and Block Styles
 * 'Emphasized text': created using \'text', used for emphasizing words
 and phrases
 * `Monospaced text`: created using \`text`, used for command / program
-names, file paths, inline commands, option names and values
+names, file paths, in-line commands, option names and values
 * *Strong text*: created using \*text*, used for emphasizing concepts
 or names when first introduced in a section.
 
-There are also different builtin block styles that are used in
+There are also different built-in block styles that are used in
 our documentation:
 
 Complete paragraphs can be included literally by prepending each
@@ -225,6 +239,44 @@ text:
 For example, block headers can be used to add file names/paths to file
 content listings.
 
+Screenshots
+-----------
+
+[thumbnail="gui-datacenter-search.png"]
+
+First, it should be noted that we can display screenshots on 'html'
+and 'wiki' pages, and we can include them in printed doumentation. But
+ith is not possible to render them inside manual pages. So screenshot
+inside manual pages should be optional, i.e. the text should not
+depend on the visibility of the screenshot. You can include a
+screenshot by setting the 'thumbnail' attribute on a paragraph:
+
+----
+[thumbnail="gui-datacenter-search.png"]
+First, it should be noted ...
+----
+
+The corresponding file need to reside inside folder
+`images/screenshot`, and should be in `.png` image format. We include
+the screenshots in printed documentation, and 'pdftex' uses the
+density (DPI) specified inside the file. So all screenshots should use
+the same density. We currently require the density set to 146 DPI, so
+that we can display a 1024 pixels wide image. You should not include
+larger screenshots (although it is possible).
+
+You can use the `./png-cleanup.pl` script to set the correct
+density. Simply use the following command to import a screenshot
+image:
+
+----
+# ./png-cleanup.pl screenshot.png images/screenshot/screenshot.png
+----
+
+TIP: You can use `identify -verbose screenshot.png` command to show
+all image attributes (from debian package 'imagemagick')
+
+
+
 
 Copyright
 ---------