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

[Oleksandr Moskalenko]

* Craig Ringer <craig at postnewspapers.com.au> [2005-06-21 12:31:00 +0800]:

> 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.

I would like to second Craig's statement. My current model of the way scribus
objects are written into an XML file is to organise them as "atoms" and
"molecules". In this way the atoms could be combined into various molecules
without breaking the document. At the moment the smallest text molecule is a
paragraph. I arbitrarily decided that it would be the right size for change
tracking and collaborative work. The text object locking would happen on the
paragraph level, so two people couldn't edit the same paragraph at the same
time, but they could change two adjacent paragraphs without any ill effects.

> > 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.

Riku Leino's OOWriter import comes in handy here, at least on the
paragraph/character level if we indeed shun the larger scale formatting
attempts, which is fine with me.

> >  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 .

Can't this be handled on the OOWriter importer plug-in level by stripping the
formatting we don't trust? This way some level of compromise could be established.

> > 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 could be handled on the database level, too once the relationship between
paragraphs/text frames and database entries is established through
paragraphID/textID identifiers. I like the writing tool idea a lot because it
can be naturally extended to scripting applications.

> 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.

As I already mentioned, text frame granularity could be a bit too high level.
While we are at it why not establish finer division of the textual molecules?

> > 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.

Well, anything we put into an XML file is an entity. Combining these external
entities or "individual parts" as you put it is as simple as referencing them,
after declaring of course. A more involved part is the establishment of the
TOC continuity methinks. We could start with a brute force approach by
introducing master/partial document attributes and see how it works out in the
code.

> 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 ;-)

On the contrary - the more corner and mainstream usage cases are spelled out
in plain English, the easier it is to implement them on the file format level
and in the code, I think. Please don't hold your thoughts to yourself as
everyone would be poorer because of that. Not all of us are working with DTP
and "layman" explanations are priceless.

> --
> Craig Ringer

Regards,

Alex