Input

book: Create a structured PDF document with headings, chapters, etc.
webpage: Specifies that the HTML sources are unstructured (plain web pages.) A page break is inserted between each file or URL in the output.
continuous: Specifies that the HTML sources are unstructured (plain web pages.) No page breaks are inserted between each file or URL in the output.
Title of the document for the front page.
Extract the first heading of the document and use it as title. If checked the title field has no effect.
The title image or HTML page. These file has to be an attachments!
Specify document version to be displayed on the title page.
Intellectual property owner of this document.
Copyright notice for this document.
Information about who and when modified the document are applied at the end.

Output

Specifies the output format.
Grayscale document  Title page
Compression :   JPEG big images 

Pagina

 
User defined page size 		 Choose one of the predefined standard sizes or select user defined.
Specifies the page size using a standard name or in points (no suffix or ##x##pt), inches (##x##in), centimeters (##x##cm), or millimeters (##x##mm).
Set the target browser width in pixels (400-1200). This determines the page scaling of images.
   2-Sided   Landscape
   
   
   
Specifies the margin size using points (no suffix or ##x##pt), inches (##x##in), centimeters (##x##cm), or millimeters (##x##mm). Keep empty for default value.
Left
Middle
Right
Sets the page header to use on body pages.
Left
Middle
Right
Sets the page footer to use on body pages.

Indice

Sets the number of levels in the table-of-contents. Empty for unlimited levels.
   Numbered headings Check to number all of the headings in the document.
Sets the title for the table-of-contents. Empty for default title.
Left
Middle
Right
Sets the page header to use on table-of-contents pages.
Left
Middle
Right
Sets the page footer to use on table-of-contents pages.

Colors

Enter the HTML color for the body (background).
Enter the image file for the body (background). These file has to be an attachments!
Enter the HTML color for the text.
Sets the color of links.
Enables generation of links in PDF files.

Fonts

Set the default size of text.
Set the spacing between lines of text.
Choose the default typeface (font) of text.
Choose the default typeface (font) of headings.
Set the size of header and footer text.
Choose the font for header and footer text.
Change the encoding of the text in document.
Check to embed font in the output file.

PDF

Controls the initial viewing mode for the document.
Document: Displays only the docuemnt pages.
Outline: Display the table-of-contents outline as well as the document pages.
Full-screen: Displays pages on the whole screen; this mode is used primarily for presentations.
Controls the initial layout of document pages on the screen.
Single: Displays a single page at a time.
One column: Displays a single column of pages at a time.
Two column left/right: Display two columns of pages at a time; the first page is displayed in the left or right column as selected.
Choose the initial page that will be shown.

Security

Check to number all of the headings in the document.
 Versione stampabile   Modify
 Copy   Annotate		 Specifies the document permissions.
Specifies the user password to restrict viewing permissions on this PDF document. Empty for no encryption.
Specifies the owner password to control who can change document permissions etc. If this field is left blank, a random 32-character password is generated so that no one can change the document.

Expert

Specify language to use for date and time format.
Shrink code blocks on page.
Show line numbers for code blocks.
Make spaces visable by dots (·) instead of white spaces.
Make line breaks visable by a extra character (¶) at the end.
Enable this feature if you searching for problems or intent to report a bug report

About

Version 2.4.2 (MoinMoin 1.9.7)


MoinMoin - Generate PDF document using HTMLDOC

This action script generate PDF documents from a Wiki site using
the HTMLDOC (http://www.htmldoc.org) software packages which has
to be preinstalled first.

Copy this script in your's MoinMoin action script plugin directory.

Thanks goes to Pascal Bauermeister who initiated the implementaion.
Lot of things changes since then but the idear using HTMLDOC is the
main concept of this implementation.

Please visit the homepage for further informations:
http://moinmo.in/ActionMarket/PdfAction

@copyright: (C) 2006 Pascal Bauermeister
@copyright: (C) 2006-2010 Raphael Bossek <raphael.bossek@solutions4linux.de>
@license: GNU GPL, see COPYING for details

       

Italiano English
Modifica History Actions

wndw/revisione

Le sedi di Ninux sono:

a Roma presso il FusoLab

  • Fusolab

a Pisa all'EigenLab

  • Eingelab

a Cosenza presso la sede dell'Hacklab Cosenza

  • HLCS

a Catanzaro presso la sede dell'Hacklab Catanzaro

  • HLCZ

a Firenze presso l'exfila

  • exfila

a Bologna presso il makerspace di RaspiBO

  • NinuxBO

Ninux.org partecipa al World IPv6 day

  • WorldIpv6Day

Indice

  1. Cosa intendiamo per revisione
  2. Il processo di revisione
  3. Come procedere alla revisione
    1. Errori di battitura
    2. Errori di traduzione - struttura del periodo/frase
    3. Terminologia
    4. Proposte di modifica
  4. That's all folks!

Se state leggendo questa pagina significa che perlomeno siamo finalmente mooolto vicini a completare la traduzione di Wireless Network in the Developing World! Un grazie immenso a tutti coloro che hanno contribuito!
Ora, il processo di revisione che inizierà (spero) tra pochi giorni, sarà importante tanto quanto la traduzione iniziale. E' in questa fase infatti che verranno corrette tutte le imperfezioni ed errori che inevitabilemnte si troveranno nella prima traduzione di un libro di 250 pagine. Data la lunghezza del libro, la revisione richiederà anch'essa un bel pò di tempo. Credo che un grosso vantaggio sia il poter anticipare alla fase online il più possibile del processo di revisione, rimandando ad un'eventuale riunione dal vivo il completamento di quella parte di interventi che non si riusciranno a concludere tramite le pagine di questo wiki. Questa che leggete è la prima versione del workflow che ho pensato per la revisione. E' sottointeso che è solo una proposta e che ogni commento/suggerimento/modifica di quanto riportato è come sempre più che ben accetto!

BlaXwan

Cosa intendiamo per revisione

Nel processo di revisione vedo tutte quelle attività di rilettura e modifica finalizzate a:

  • correggere eventuali errori di traduzione
  • verificare il corretto uso della terminologia tecnica
  • addolcire traduzioni troppo letterali o con struttura del periodo/frase che ricalcano ancora l'idioma straniero
  • correggere eventuali errori di battitura
  • rendere omogenea la traduzione fatta da persone diverse

La soluzione di tutte queste imperfezioni renderà il testo pronto per essere pubblicato come valida traduzione del libro originale.

Il processo di revisione

Attualmente, nel processo di revisione, individuo perlomeno tre fasi:

  • una prima fase in cui tutti i traduttori rileggono tutto il testo ed evidenziano i passaggi da migliorare/modificare
  • una seconda fase in cui i traduttori propongono una modifica/soluzione alle parti individuate nel passaggio precedente
  • una terza fase, possibilmente comunitaria (web o live) in cui tutti i traduttori decidono assieme quale modifica, tra le proposte segnalate, utilizzare per finalizzare il testo

Attualmente credo sia importante cercare di rendere possibile la maggior parte di questo processo attraverso strumenti di collaborazione online, dato che le fasi indicate portano comunque via molto tempo e non ho affatto la certezza di riuscire ad incontrarsi di persona per tutto il tempo richiesto. Perciò la mia intenzione è di adottare un metodo per riuscire a completare online almeno le prime due fasi.

Come procedere alla revisione

Grazie al nostro eclettico Clauz, abbiamo a disposizione uno strumento che agevolerà di molto il compito di fare online le prime due fasi della revisione: l'evidenziazione colorata del testo. Direi che sicuramente possiamo utilizzare questo strumento per rileggere tutto il testo tradotto e segnalare i "punti oscuri" ovvero le parti del testo che contengono errori o imperfezioni. Purtroppo non ci è possibile evidenziare direttamente il testo perchè la sintassi utilizzata per evidenziarlo conflitta con alcune direttive utilizzate nella formattazione del testo del wiki. Per questo useremo le evidenziazioni per mettere dei marker START-STOP facilmente riconoscibili. Allo scopo individuare velocemente queste porzioni di testo, progongo di dargli un minimo di numerazione, in modo da velocizzare anche il lavoro collettivo di soluzione. L'evidenziazione del testo implementata da Clauz consiste nel racchiudere tra un evX(''' e un ''') le parti di testo da evidenziare, con X:

  • 0 = colore GIALLO
  • 1 = colore VERDE
  • 2 = colore CELESTE
  • 3 = colore ARANCIONE

Errori di battitura

Si tratta di errori semplici da correggere, anche se spesso non semplici da individuare. Ad ogni modo propongo che questo tipo di errori possono essere corretti autonomamente da chi, rileggendo il testo per la revisione, riesce ad individuarli.

Errori di traduzione - struttura del periodo/frase

Nella rilettura, se si incontrano errori più o meno palesi di traduzione o imperfezioni nella costruzione della frase/periodo, che magari portano a frasi incomprensibili o di dubbio signifiato, propongo di racchiuderli tra due segnalazioni di questo tipo:
NumCapitolo.NumParagrafo.NumProgressivo - Descrizione imperfezione - START
....testo...
NumCapitolo.NumParagrafo.NumProgressivo - Descrizione imperfezione - END - NomeTraduttore

Ecco un esempio:

5.1.12 - non si capisce - START
l'antenna a melanina hardware dove il ghignotto flangiato con estensione parabolica siamo andati fare il config...
5.1.12 - non si capisce - END - blaxwan

Terminologia

Qui si parla di segnalare nomi di apparecchiature/protocolli o altra terminologia tecnica che sono stati magari tradotti in modo quasi letterale, mentre, quasi sicuramente, hanno una traduzione propria in italiano che ha poco a che fare con le parole della relativa versione inglese. La sintassi che suggerirei di usare è la stessa, magari però usiamo il colore giallo. Vai con l'esempio:
7.3.2 - Terminologia - START
il commutatore a canale fotonico instradante
7.3.2 - Terminologia - END - blaxwan

o, in questo caso, data la brevità della parte da segnalare, possiamo evidenziare direttamente il testo:

TERMINOLOGIA blaxwan: il commutatore a canale fotonico instradante

Proposte di modifica

Di seguito ad ogni segnalazione, ogni traduttore può riportare la sua proposta di modifica, ovvero come lui risolverebbe l'imperfezione. La proposta va accodata a quella precedente se qualcun altro ha già provveduto a fare la sua proposta. Mantenendo la stessa sintassi, direi di utilizzare il celeste come colore per racchiudere le proposte. Esempio

7.3.2 - Terminologia - START
il commutatore a canale fotonico instradante
7.3.2 - Terminologia - END - blaxwan
blaxwan: il router-switch Fibre Channel

(p.s. non scherzo, questa m'è capitata davvero!!!)
Ad ogni modo, anche se porta via più tempo, credo sia fondamentale indicare chi ha segnalato il problema e chi ha proposto la correzione, faciliterà il compito quando, davanti a decine di segnalazioni, ci si chiederà "chi l'ha segnalato? Perch? Che c'è che non va?".

That's all folks!

Please, fatemi sapere che ne pensate di questo metoduccio e se e come vogliamo cambiarlo e migliorarlo, GRAZIE!

P.S. Il VERDE lo riserverei per segnalare tag diversi, ad esempio una PROPOSTA SCELTA, un paragrafo come COMPLETATO, oppure un segnalibro REVISIONATO FIN QUI, noh?