DAPS lets you publish your DocBook 4 or Docbook 5 XML sources in various output formats such as HTML, PDF, ePUB, man pages or ASCII with a single command. It is perfectly suited for large documentation projects by providing profiling support and packaging tools. DAPS supports authors by providing linkchecker, validator, spellchecker, and editor macros. DAPS exclusively runs on Linux.

Download & Installation

For download and installation instructions refer to https://github.com/openSUSE/daps/blob/master/INSTALL.adoc
Highlights of the DAPS 2.0 release include:

• fully supports DocBook 5 (production ready)
• daps_autobuild for automatically building and releasing books from different sources
• support for EPUB 3 and Amazon .mobi format
• default HTML output is XHTML, also supports HTML5
• now supports XSLT processor saxon6 (in addition to xsltproc)
• improved “scriptability”
• properly handles CSS, JavaScript and images for HTML and EPUB builds (via a “static/” directory in the respective stylesheet folder)
• added support for JPG images
• supports all DocBook profiling attributes
• improved performance by only loading makefiles that are needed for the given subcommand
• added a comprehensive test suite to ensure better code quality when releasing
• tested on Debian Wheezy, Fedora 20/21 openSUSE 13.x, SLE 12, and Ubuntu 14.10.

Please note that this DAPS release does not support webhelp. It is planned to re-add webhelp support with DAPS 2.1.

For a complete Changelog refer to https://github.com/openSUSE/daps/blob/master/ChangeLog

Support

If you have got questions regarding DAPS, please use the discussion forum at https://sourceforge.net/p/daps/discussion/General/. We will do our best to help.

Bug Reports

To report bugs or file enhancement issues, use the issue Tracker at https://github.com/openSUSE/daps/issues.

The DAPS Project

DAPS is developed by the SUSE Linux documentation team and used to generate the product documentation for all SUSE Linux products. However, it is not exclusively tailored for SUSE documentation, but supports every documentation written in DocBook.
DAPS has been tested on Debian Wheezy, Fedora 20/21 openSUSE 13.x, SLE 12, and Ubuntu 14.10.

The DAPS project moved from SourceForge to GitHub and is now available at https://opensuse.github.io/daps/.

Name: hot-chili-sauce
Summary: Toms’s Hot Chili Sauce
License: BSD
Version: 1.0
Group: Cooking/Sauce/Chili

# Ingredients
#
Requires:   chili => 5pcs
Requires:   sugar = 3pcs
Requires:   ginger = 30gr
Requires:   vinegar = 3tbsp
Requires:   water = 250ml

# Equipment
#
Requires:   libfunnel
Requires:   libglassjars-multiple => 50ml
Requires:   libcookingpots
Requires:   libtap
#
Recommends: salt
Recommends: wheat-flour

%description
This hot sauce can be used to spice up your food, give you creative
energy, and is a nice gift for your friends and family members -- not
only for Hackweek.

%prep
%setup

head /dev/tap/water > /dev/pot1/WATER
mv /dev/jars > /dev/pot1
heat --target-temp 100C --gentle /dev/pot1

%build

%define very_hot 1
%define thicken 0
split -b 5 CHILI1 chili/CHILI1-CHOPPED
split -b 5 CHILI2 chili/CHILI2-CHOPPED
split -b 5 CHILI3 chili/CHILI3-CHOPPED
%ifdef %{very_hot}
split -b 5 CHILI4 chili/CHILI4-CHOPPED
split -b 5 CHILI5 chili/CHILI5-CHOPPED
%endif
peel GINGER > PEELED_GINGER && split -b 5 PEELED_GINGER ginger/GINGER-CHOPPED
peel GARLIC > PEELED_GARLIC && split -b 5 PEELED_GARLIC garlic/GARLIC-CHOPPED
mv SUGAR /dev/pot2
heat --target caramel /dev/pot2
mv chili/* garlic/* /dev/pot2
heat --time 5min --target-temp 80C /dev/pot2
mv ginger/* SALT WATER VINEGAR /dev/pot2
stir --dont-shake /dev/pot2
mv TOMATO_PASTE /dev/pot2
heat --time 15min --target-temp 100C /dev/pot2
%ifdef %{thicken}
mv WHEAT-FLOUR /dev/pot2
%endif

%install
# FIXME: add adequate safety measures. This is hot.
mv /dev/pot1/jars /dev
mv /dev/pot2/* /dev/jars
seal /dev/jars && turn /dev/jars
sleep 60m

%files /dev/jars

With the invaluable work and effort from Petr Gajdos, Takashi Iwai, and all the creative designers, we now have more than 100 open source fonts in the M17N:fonts repository. Most fonts are licensed under the OFL or other open/free licenses. Thanks a lot to all! This repository contains fonts like the previously mentioned Exo typeface, the famous Linux Libertine, or fonts from the Google Webfonts page to name a few. With all these fonts available at your hand, you have many choices to make your text readable and attractive as you like, be it on the Web or in print.

Previous to openSUSE 12.1, all the fonts had a terrible naming convention: some contained a “fonts” prefix, other don’t. Now all fonts follow a naming convention to make it easy to find. So don’t be surprised when your font package has been renamed. If you need further information, check out my original idea from FATE#313035. Packagers will probably find the article about Packaging Fonts in the openSUSE Wiki helpful.

The new M17N:fonts repository collects all fonts now and in the future. New fonts will appear and developed there. To use it, add the repository to your list:

zypper ar http://download.opensuse.org/repositories/M17N:/fonts/openSUSE_12.1/M17N:fonts.repo

Currently, the supported distributions are openSUSE 11.4, 12.1, Evergreen 11.1, 11.2, Factory, Tumbleweed, as well as SLE11 SP1 and SP2.

Have fun and be creative with the new fonts!

The sans serif font is beautifully crafted and contains 9(!) different width as you can see in the following graphic:

Natanael, the graphic designer, wrote about his font:

Today Exo is already a very mature font family, with over 700 characters supporting most Western, Central and Eastern European languages – and it can still go further! This coverage has been reached for all 9 weights, the maximum possible on the web. Each weight has an upright style and the corresponding ‘true’ italic style. Many ‘techno’ fonts have only the simple slanted oblique companion styles, but for the highest typographic quality it is essential to have true italics that are drawn specially.

Some unique OpenType features:

• small caps
• discretionary ligatures
• stylistic alternates
• old style figures, tabular figures, fractions
• a lot more…

If this project reaches its funding goal it will be published in Google Web Fonts under the SIL Open Font License. Currently, almost 80% is pledged, but only 18 days are left. If you find this project useful, please help Natanael and make the Web a more beautiful place. I already did so. Thanks!

browsed through a book, used your favorite search engine, or posted on LinkedIn, Xing, or the DocBook mailinglist to hunt for answers to your problems?

As an additional alternative, I’m happy to announce my latest project:

The DoCookBook Project
(released  under Creative Commons License)

The tongue-twisting name is a word play and picks up the two central topic about DocBook and cookbook.

What is the “DoCookBook Project”?

This project is a collection of problems and solution towards DocBook and the DocBook stylesheets. The book contains helpful topics with step-by-step instructions.

Why another project about DocBook?

Information about DocBook can be find in books or somewhere in the Internet. However, it can be an exhausting task to extract the necessary piece which fits to your problem. This project can help you to get your work done more quickly.

Is it done?

Not yet. Currently it is a draft. However, the structure is almost complete. The book contains some useful topics and it will be improved and extended over time.

Can I see the source code?

Sure! The source code of this book is published and maintained as a Mercurial repository.

Ok, you’ll get me! How can I support the project?

• Register on the project mailinglist to influence the direction or to get updates
• Point out typos, ambiguities, inconsistencies, or errors.
• Let me know what’s your favorite topic.
  Send me your topics directly or use the project’s ticket system (see Ticket#15).
  If you want to use the latter, you’ll have to register at Sourceforge
• Write your own topics.
• Create a cool new layout.
• Support this project and donate a small amount.

Have fun!

Have fun!

Apart from Russian, I’m very happy that the Hungarian translation of the openSUSE documentation is underway! Thanks to Kálmán Kéménczy, he will publish the Hungarian documentation soon. Currently, some translatation, proofreading, and polishing have to be done, so stay tuned (see https://svn.berlios.de/svnroot/repos/opensuse-doc/trunk/documents/distribution/hu.)
By the way, the Hungarian books from the 11.1 and 11.2 release can be downloaded in the Hungarian portal.

If someone from the Hungarian community wants to help, please support Kálmán and contact him for futher details.

Thanks Kálmán, for your ongoing work! I’m sure, everybody appreciates your work, be it in the past, present, or future.

The doc team had had three different, independent repositories on BerliOS (opensuse-ha-doc, opensuse-docmaker, and opensuse-lfl) all holding separate information. This was a bit silly, so my task was to consolidate them into opensuse-doc by keeping all history.

A SVN history is nice as you can see what you or others have done with the files. Loosing the history is the same as starting from scratch — which can be sometimes a good idea. In that case, the doc team wanted to preserve the history as we use it very often. So I had to think of a solution how to merge different SVN repositories into one. I came up with a solution containing the following steps:

1. Create a test repository
2. Create the dump files
3. Filter the dump files and extract trunk only
4. Rename trunk content
5. Edit the dump files
6. Load dump files into test repository

Several tools are needed: svnadmin and svndumpfilter are already available from the subversion package. Additionally, Darix recommended the svndumptool from devel:tools:scm:svn (thanks Darix!). A very convenient tool when dealing with SVN dumps.

Apart from this, all three SVN repositories consist of the usual trunk, branches, and a tags directories.

Step 1: Creating Test Repository

Before I got my hands dirty, I needed a test repository. Luckily, the subversion package contains everything what I need.  In my case, I’ve used the hotcopy command to create this test repository. I’ve logged in to BerliOS and made a hotcopy of my target SVN repository:

# ssh svn.berlios.de
# svnadmin hotcopy /svnroot/repos/opensuse-doc opensuse-doc

I did the same for my other repositories as well, just for safety reasons:

# svnadmin hotcopy /svnroot/repos/opensuse-lfl opensuse-lfl
# svnadmin hotcopy /svnroot/repos/opensuse-docmaker opensuse-docmaker
# svnadmin hotcopy /svnroot/repos/opensuse-ha-doc opensuse-ha-doc

Later, I will use the opensuse-doc hotcopy to test my modifications before I apply them to the production SVN repository. With this method, I wanted to make sure everything is correct. Of course, you have to be sure that nobody commits to your repositories, otherwise any later commits won’t be incorporated.

Step 2: Creating Dump Files

Dump files contain everything what’s inside a repository including SVN properties. However, they don’t contain the configuration or repository hooks from the repository. If you want to keep them, you’ll have to save them manually.

It’s very easy to create a dump file. In BerliOS, everything lives under /svnroot/repos/PROJECT:

# svnadmin dump /svnroot/repos/opensuse-lfl > opensuse-lfl.dump
# svnadmin dump /svnroot/repos/opensuse-docmaker > opensuse-docmaker.dump
# svnadmin dump /svnroot/repos/opensuse-ha-doc > opensuse-ha-doc.dump

The above lines create a dump file for each of my SVN repositories. As the BerliOS server doesn’t have the svndumptool command, I have to copy them to my own machine:

toms@earth:~ > scp shell.berlios.de:~/opensuse-*.dump .

Step 3: Extracting trunk

In most SVN repositories, tags and branches contain information which were at some point in time copied (for tags) or copied and modified later (for branches). I haven’t found a satisfying solution to use svndumptool and take into account these two directories. Anyway, I’ve decided to just concentrate on trunk and manually adjust tags and branches later. This makes it easier when dealing with dump files.

To extract only parts of a dump file, the svndumpfilter command is the right tool. Combined with the needed options and subcommands, I’ve used:

toms@earth:~ > svndumpfilter --renumber-revs --drop-empty-revs \
    include trunk < opensuse-docmaker.dump > docmaker-trunk.dump
toms@earth:~ > cat dumps/opensuse-ha-doc.dump | \
    svndumpfilter --renumber-revs --drop-empty-revs  include "trunk" | \
    svndumpfilter exclude trunk/package > ha-doc-trunk.dump
toms@earth:~ > svndumpfilter --renumber-revs --drop-empty-revs \
    include trunk < opensuse-lfl.dump > lfl-trunk.dump

The commands are not exactly the same, as the SVN repositories are slightly different. For example, the opensuse-ha-doc repo contained a trunk/package directory which I don’t want. Therefor you see the exclude command in svndumpfilter. The resulting dump files contain only trunk, nothing else.

Step 4: Renaming trunk Directory

The last step created dump files which contain only the trunk directory. The dump files can already be loaded into the target SVN repository. However, this is only partly successful. After loading you have to rename and move subdirectories around which is unconvenient. To avoid this cumbersome task, I’ve used the svndumptool command which does the job directly on the dump file!

For example, the former docmaker repository has to appear under trunk/tools/docmaker, not directly under trunk. This can be done with the merge subcommand of svndumptool:

toms@earth:~ > svndumptool merge -o docmaker-trunk-rename.dump \
   -i docmaker-trunk.dump \
   -s '^trunk' 'trunk/tools/docmaker' \
   -d trunk/tools/docmaker

The -d option creates the trunk/tools/docmaker directory in case it doesn’t exist in your target. The -i and -o options are the input and output stream of the dump files, -s contains a regular expression how to rename the source (^trunk) into the target (trunk/tools/docmaker). The other repositories are similar:

toms@earth:~ > svndumptool merge -o ha-doc-trunk-rename.dump  \
  -i ha-doc-trunk.dump \
  -d trunk/documents/ha/ \
  -s '^trunk/books/en' 'trunk/documents/ha/en' \
  -s '^trunk/books' 'trunk/documents'
toms@earth:~ > svndumptool merge -o lfl-trunk-rename.dump  \
  -i lfl-trunk.dump \
  -d trunk/documents/lfl/ \
  -s '^trunk/books/en' 'trunk/documents/lfl/en' \
  -s '^trunk/books' 'trunk/documents'

After this step I have three files, named *-trunk-rename.dump which contains the renamed directories.

Step 5: Editing Dump File

This step is a bit tricky and I haven’t found a better solution yet. Probably this can also be done with cat and sed magic, but I preferred vi. The task is to list the content of the dump files and decide which directory entries need to be deleted. This step is absolutely necessary to avoid any SVN error (something like “directory/file already exists”) when trying to load the dump file into the repository.

1. Get an overview of the contents:

   toms@earth:~ > svndumptool ls ha-doc-trunk-rename.dump
   /trunk
   ...
   toms@earth:~ > svndumptool ls docmaker-trunk-rename.dump
   /trunk
   /trunk/documents

   Usually this is /trunk and probably some other directories (depending on the structure).

2. Modify the dump file(s) and remove any directories which are available in the target SVN repository.
   The renamed directories from the last step contains a single trunk “node” which has to be removed. The same applies for trunk/documents. Both exist already on the BerliOS server. Manually edit the dump files and remove the following lines:

   Node-path: trunk
   Node-action: add
   Node-kind: dir
   Prop-content-length: 10
   Content-length: 10
   PROPS-END
   ...
   Node-path: trunk/documents
   Node-action: add
   Node-kind: dir
   Prop-content-length: 10
   Content-length: 10
     [[ Some other content could be available here ]]
   PROPS-END

3. Save the dump file

Be careful! It is very important not to destroy any structure in the dump file!

I’ve checked the result with “svndumptool ls DUMPFILE”. No lonely trunk directory should be shown anymore. To be on the safe side, I’ve checked the two files with svndumptool check -A DUMPFILE, too.

Step 6: Loading Dump Files into Test Repository

The last step created the dump files with the correct structure. As this was done on my own machine, I have to copy the files back to BerliOS (remember to use the shell.berlios.de server):

toms@earth:~ > scp *-rename.dump  shell.berlios.de:

It’s almost done! Logged into BerliOS and loaded the dump files in my hotcopy test repository (see step 1):

# svnadmin load opensuse-doc  < docmaker-trunk-rename.dump
# svnadmin load opensuse-doc  < ha-doc-trunk-rename.dump
# svnadmin load opensuse-doc  < lfl-trunk-rename.dump

After playing around a bit, everything was successful. So I repeated it, but replaced the opensuse-doc hotcopy with the correct path /svnroot/repos/opensuse-doc.

The remaining pieces are the tags and branches directory. As revision numbers have been changed, the revision number in the original repository and the revision number in opensuse-doc are obviously not the same anymore. Creating tags can only be done with a correct date, because dates are preserved. For this reason, it is convenient to still have the original repositories around to look for the exact date and log message:

$ svn copy -r "{2010-10-20T10:00:00}" -m "..." \
   $BERLIOSURL/trunk/tools/docmaker \
   $BERLIOSURL/tags/tools/docmaker/obs

The branches are a bit different. Maybe the history can be preserved with the same method as with trunk, but I haven’t tried it. Our three repositories hadn’t had meaningful information in branch, or it wasn’t worth the effort.

Conclusion

The steps above showed how to merge different SVN repository into one while keeping the history.  Unfortunately, this task could be easier. Although svndumpfilter is very easy, it is also very limited. Especially when you have to modify the dump file itself, svndumpfilter won’t rescue you. It would be very good, if svndumpfilter could be extended to work with dump files in the same way as svndumptool. That would be fun.

http://rtfm.opensuse.org http://doc.opensuse.org

Thank you guys! I like the thrilling name.

It’s a static page (at the moment?) and collects the current documentation from several products and projects. Probably you will see more to come in the next weeks.

Have fun!

Update (AJ since Thomas is ill) 2010-10-27: Based on the feedback received, we’re going to  change now rtfm.opensuse.org to docs.opensuse.org. So, you can reach the fine side under http://docs.opensuse.org and http://doc.opensuse.org.

Today, lots of e-book readers are available and more will be ready in the future. Apart from the problem, if an e-book reader supports EPUB, the EPUB file itself has to adhere to certain specifications. This is the task for epubcheck, a commandline utility which validates an EPUB file.

The RPM package can be found in my OBS repository home:thomas-schraitle as usual. To use it, just run epubcheck with your EPUB file and see what it finds.

Have fun!