[Scribus] Ideas on collaboration [was: How do you guys share scribu files for collaboration?]

[Craig Ringer]

On Tue, 2005-06-21 at 04:33 +0200, Christoph Sch?fer wrote:

> It has been mentioned before that multiple editing of DTP files is not a 
> good idea.

I don't agree. With suitable style guides and a suitable team, it'd be
an important thing to be able to do. I do agree that if done without
discipline it can end up a mess, though.

If nothing else, it'd be EXTREMELY useful to be able to have different
people working on different parts (sections, liftouts, chapters,
whatever) of a document. Whether this was done through a Word/OO.o style
"master document" system or through true multiple editing isn't too
important.

http://bugs.scribus.net/view.php?id=1925
http://bugs.scribus.net/view.php?id=2107

> With respect to text content, it is always necessary to educate those 
> who create texts.

I couldn't agree enough.

> If you look carefully, you will find that in many 
> publications, created with Quark or InDesign, hyphenation marks appear 
> in the text where they shouldn't, because both programmes offer an 
> import filter for Word files. The average $office_suite user is used to 
> format his/her text while writing it (which is nonsense, but 
> nevertheless current practice).

I don't know ... /text/ formatting (emphasis, etc) probably isn't
nonsense. It's when they start doing "document-level" formatting and
layout or they go overboard that it gets silly.

>  I think it is important to tell the 
> "Office professionals" how to switch off hyphenation and save to plain 
> text. 

Ideally, perhaps ... but often the layout dep't is already overworked
and hand-formatting the editorial text is the last thing they need :S .

> Plain text files are easy to handle for cvs-like programmes and 
> databases. An ideal (text) workflow would consist of text workers 
> writing their texts in a fashion they are used to and after approval of 
> all participants commiting their collaborative work to a database in 
> plain text.

Personally, I'm inclined to favour the Adobe InDesign model, where the
editors / writers use a special tool that understands the DTP program's
text, and talks to a content management system. The tool can be
customised to do things like auto-hyphenate or not, permit or not permit
text formatting, etc as appropriate, depending on how you want to divide
up the workload.

This model lets you use a content management system or similar, with
versioning and history, without the pain of going back to primitive
plain text.

> On the DTP side, it would be extremely useful if scribus could provide a 
> database interface for text frames. If a text frame could be linked to a 
> database entry, many restraints on productivity would be removed in a 
> single step, especially if the whole process could be done via scripting.

http://bugs.scribus.net/view.php?id=1791
http://bugs.scribus.net/view.php?id=1925
http://bugs.scribus.net/view.php?id=1406

> With pictures, the situation is similar, though not exactly the same. 
> Imagine a newspaper with predefined fields for ads: Instead of manually 
> inserting the ad in scribus, a special database field entry would 
> receive the ad for the current issue from a database.

Yep... you're talking basic automatic pagination there. It's already
do-able in Scribus using the Python plugin, though with the restriction
that PDF and EPS are rasterised on import.

> I also think of another aspect, which is linking of different files. 
> This would improve the creation of large documents a lot.

Yep. I'd love to be able to have a "master document" with pages pulled
in from different .sla files (but all able to access the master's
styles, etc). Even possibly individual parts of the page pulled in from
different .sla files - think a frame for a half-page ad done as an
external file.

This also helps a lot for collaboration.

Most of what's being discussed here today isn't new, by the way. A lot
has come up on the ML before, or been discussed on IRC. That doesn't
mean that going over new ideas for such things is in any bad of
course ;-)

--
Craig Ringer