\bf{xxx} => {\bf xxx}

diff --git a/docs/manuals/de/concepts/newfeatures.tex b/docs/manuals/de/concepts/newfeatures.tex
index e954e91fe1296cf6e0a4e8257c04d2e937f4116b..8f7b3cf09e2dfeae9ad854ca299a95cada1b72f9 100644 (file)
--- a/docs/manuals/de/concepts/newfeatures.tex
+++ b/docs/manuals/de/concepts/newfeatures.tex
@@ -21,12 +21,12 @@ writing it to a volume in a different pool.
 
 In some respects the Vbackup feature works similar to a Migration job, in
 that Bacula normally reads the data from the pool specified in the 
-Job resource, and writes it to the \bf{Next Pool} specified in the 
+Job resource, and writes it to the {\bf Next Pool} specified in the 
 Job resource.  The input Storage resource and the Output Storage resource
 must be different.
 
 The Vbackup is enabled on a Job by Job in the Job resource by specifying
-a level of \bf{VirtualFull}.
+a level of {\bf VirtualFull}.
 
 A typical Job resource definition might look like the following:
 
@@ -96,7 +96,7 @@ run job=MyBackup level=Incremental
 
 So providing there were changes between each of those jobs, you would end up with
 a Full backup, a Differential, which includes the first Incremental backup, then two
-Incremental backups.  All the above jobs would be written to the \bf{Default} pool.
+Incremental backups.  All the above jobs would be written to the {\bf Default} pool.
 
 To consolidate those backups into a new Full backup, you would run the following:
 
@@ -105,7 +105,7 @@ run job=MyBackup level=VirtualFull
 \end{verbatim}
 
 And it would produce a new Full backup without using the client, and the output would
-be written to the \bf{Full} Pool which uses the Diskchanger Storage.
+be written to the {\bf Full} Pool which uses the Diskchanger Storage.