Beautify docbook files

1 files changed, 10 insertions, 32 deletions

diff --git a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook
index 03834e67b4c..398873f991c 100644
--- a/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook
+++ b/tde-i18n-pt/docs/tdemultimedia/artsbuilder/porting.docbook
@@ -4,47 +4,25 @@ To validate or process this file as a standalone document, uncomment
 this prolog. Be sure to comment it out again when you are done -->
 
 <chapter id="porting">
-<title
->Passar as Aplicações para o &arts;</title>
+<title>Passar as Aplicações para o &arts;</title>
 
 <sect1 id="using-artsdsp">
-<title
->Usar o &artsdsp;</title>
+<title>Usar o &artsdsp;</title>
 
-<para
->O utilitário &artsdsp;, <link linkend="artsdsp"
->descrito anteriormente</link
->, permite à maioria das aplicações de som legadas que falem directamente com os dispositivos de áudio, funcionarem convenientemente com o &arts;. As aplicações que foram criadas para usar o Enlightenment Sound Daemon (<application
->esd</application
->) irão também funcionar na maioria dos casos, se for executado o <application
->esd</application
-> sobre o &artsdsp;. </para>
+<para>O utilitário &artsdsp;, <link linkend="artsdsp">descrito anteriormente</link>, permite à maioria das aplicações de som legadas que falem directamente com os dispositivos de áudio, funcionarem convenientemente com o &arts;. As aplicações que foram criadas para usar o Enlightenment Sound Daemon (<application>esd</application>) irão também funcionar na maioria dos casos, se for executado o <application>esd</application> sobre o &artsdsp;. </para>
 
-<para
->Isto possibilita uma solução a curto prazo para passar as aplicações existentes para o &kde;. Todavia, não permite que a aplicação tire directamente partido de todas as potencialidades do &arts;, como a utilização dos módulos e das sequências multimédia que não sejam apenas áudio digital. Se a aplicação necessitar de algo mais do que a reprodução de ficheiros de som, normalmente fará sentido adicionar o suporte nativo para o &arts; na aplicação. </para>
+<para>Isto possibilita uma solução a curto prazo para passar as aplicações existentes para o &kde;. Todavia, não permite que a aplicação tire directamente partido de todas as potencialidades do &arts;, como a utilização dos módulos e das sequências multimédia que não sejam apenas áudio digital. Se a aplicação necessitar de algo mais do que a reprodução de ficheiros de som, normalmente fará sentido adicionar o suporte nativo para o &arts; na aplicação. </para>
 
-<para
->Ao usar o &arts; significa também que a aplicação não terá assim muito trabalho -- poderá remeter as funções para o &arts;, de modo a resolver alguns problemas, como por exemplo os codificadores para lidar com diferentes formatos multimédia e controlar o 'hardware' de som. </para>
+<para>Ao usar o &arts; significa também que a aplicação não terá assim muito trabalho -- poderá remeter as funções para o &arts;, de modo a resolver alguns problemas, como por exemplo os codificadores para lidar com diferentes formatos multimédia e controlar o 'hardware' de som. </para>
 
 </sect1>
 
 <sect1 id="adding-native-arts-support">
-<title
->Adicionar o suporte nativo do &arts;</title>
-
-<para
->Ao usar o &arts;, você tem um conjunto de <link linkend="arts-apis"
-><acronym
->API</acronym
->s</link
-> diferentes por onde escolher. A decisão de qual usar depende de um conjunto de factores, como o tipo de conteúdos multimédia a usar (som, &MIDI;, &CD; áudio, &etc;), as funcionalidades necessárias da <acronym
->API</acronym
->, e se é escrito em C++. Na maioria dos casos, a escolha deverá ser relativamente óbvia com base nas funcionalidades pedidas. </para>
-
-<para
->Para uma portabilidade entre plataformas, as aplicações que precisem de correr noutros ambientes que não sejam o &kde;, não poderão confiar na presença do &arts;. Se usar o paradigma dos 'plugins' terá uma boa forma de suportar vários ambiente multimédia. Se tornar a <acronym
->API</acronym
-> de 'plugins' aberta e documentada (especialmente para as aplicações com código fechado), terá também a vantagem de permitir que alguém que não o programador da aplicação implemente um 'plugin' do &arts;. </para>
+<title>Adicionar o suporte nativo do &arts;</title>
+
+<para>Ao usar o &arts;, você tem um conjunto de <link linkend="arts-apis"><acronym>API</acronym>s</link> diferentes por onde escolher. A decisão de qual usar depende de um conjunto de factores, como o tipo de conteúdos multimédia a usar (som, &MIDI;, &CD; áudio, &etc;), as funcionalidades necessárias da <acronym>API</acronym>, e se é escrito em C++. Na maioria dos casos, a escolha deverá ser relativamente óbvia com base nas funcionalidades pedidas. </para>
+
+<para>Para uma portabilidade entre plataformas, as aplicações que precisem de correr noutros ambientes que não sejam o &kde;, não poderão confiar na presença do &arts;. Se usar o paradigma dos 'plugins' terá uma boa forma de suportar vários ambiente multimédia. Se tornar a <acronym>API</acronym> de 'plugins' aberta e documentada (especialmente para as aplicações com código fechado), terá também a vantagem de permitir que alguém que não o programador da aplicação implemente um 'plugin' do &arts;. </para>
 
 </sect1>