[Scribus] Collaborative publishing using wiki and Scribus

[Louis Desjardins]

>>Le Tigre wrote:

[snip]

>>  About export: I'm always doing:
>>
>>  step 1: select & copy
>>  step 2: select this text in Klipper (Kde)
>>  step 3: past in Scribus
>>
>>  The good thing with the text import is when you want to keep all the
>>  italics, bold, etc. In this case, it doesn't work because it's a txt
>>  file, so I don't really see the interest.
>>
>>  Anyway, that kind of wiki organisation is quite interesting.
>>  I need to use French for the following (how we try to have a workflow
>>  util for Le Tigre), because it'll be a bit technical and too complicated
>>  for me in English.
>>
>>  Pour faire le journal, nous recherchons un outil de ce type qui
>>  permettrait de travailler en type "workflow": la g?n?ralisation du
>>  haut-d?bit permettrait cela.
>>  Mais il faudrait pour que ?a fonctionne bien:
>>  - que les auteurs travaillent sur de vrais traitements de texte
>>  d?centralis?, du type Writely, qui permet d'avoir une mise en forme (et
>>  d'importer depuis des documents Word ou Openoffice, ce qui peut ?tre
>>  utile pour les auteurs qui travaillent d'abord en local)
>>  - et donc que ces traitement de texte soient absolument fiables et
>>  rapides d'utilisation (j'exclus donc tous les wikis par principe, ?
>>  cause des codes n?cessaires pour faire des ital)
>>  - qu'il y ait un syst?me de validation du texte: texte pr?t ? ?tre
>>  corrig?, texte corrig?, texte mis en page
>>  - que l'export se fasse facilement, d'un texte avec enrichissements vers
>>  Scribus (tr?s important: pour ne pas avoir ? remettre des italiques partout)
>>
>>  Pour l'instant, je doute que cela existe.
>>  On utilise donc un syst?me bricol?, avec un site spip o? les auteurs
>>  d?posent leurs textes en fichiers joints et selon le surtitre qu'ils
>>  donnent ? l'article, on voit (code couleur) si c'est une pr?vision, si
>>  c'est en ligne, si c'est corrig?.
>>  Ensuite on r?cup?re le fichier texte (rtf ou sxw, odt) et on fait
>>  l'import dans Scribus.
>>
>>  A moi de vous demander si vous avez des id?es ou des commentaires sur ce
>>  modus operandi.
>>
>>Raphael

>
>
>Another straightforward way to transfer from a wiki to Scribus would be
>to view the Wiki in a browser, View > Source, copy the HTML to Scribus.
>
>Greg

Raphael raises 2 main points (among others).

1. Text enrichment needs to be at the writer's end and transfer of 
italics and bolds into Scribus without the need for re-putting 
italics is compulsory. (I agree. My comment : It's a time consuming 
and not error-free operation. Not really what one would expect from a 
workflow.)

2. Use of a real WP because of the efficient way to enrich text. Plus 
other considerations such as people working first "locally" or if you 
need to import from other documents of other formats. Raphael 
excludes wiki from the start because of the necessity of codes to get 
italics.

The way he works is with a spip site where writers can put their text 
with a color code according to the text status. When the text is 
final, it is then imported into Scribus.

I think the number one issue is the text enrichment and getting this 
into Scribus seamlessly.

As for the use of real WP, I think it might be left to the writers as 
long as if there is a way of getting their text into the 
"collaborative tool" (maybe a wiki, maybe a spip site, maybe 
something else yet to invent).

If there was a way to enrich text seamlessly into the wiki, would 
that be more appealing?

And what about Greg's idea of getting the HTML code into Scribus? 
Would that solve the enrichment issue (at both ends: ease of use and 
ease of export)?

I would prefer by far work from the import (get text) menu than 
copy-paste (say you want to use some custom made text filters, only 
available from the get text command).

So if I get it right, if we could solve the enrichment issue at the 
source and export it properly as a rtf or sxw or odt file directly 
from the wiki, we'd have a rocking way of working. Right?

/foot_note/ Of course, this kind of workflow may not be suitable for 
all the needs! From a classroom perspective, having all the kids work 
the same way and use the same tools can help them concentrate on the 
content and not on the use of any other tool. This can save the 
teacher's time also. Figure a classroom of 25 kids... If all of them 
has its own way, things can rapidly become difficult! Also, it is not 
the young writers that decide when the texts get the ok-to-print 
flag. It's the teacher. From that point of view I think the wiki 
offers more ease of use and rapid overview than uploaded files as 
attachments into a spip site. Of course, professionnals have 
different needs!

Louis