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

Craig Ringer craig
Tue Jun 21 06:41:05 CEST 2005

On Tue, 2005-06-21 at 11:21 +0800, Ow Mun Heng wrote:
> On Tue, 2005-06-21 at 04:33 +0200, Christoph Sch?fer wrote:
> [SNIP]
> > 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.
> And I'm presuming that that includes sub'ing so that text which should
> be "bold" will be so and headers will be so? That's a whole lot of
> educating. (sort of using a text editor to write LaTeX!)

I personally like the idea of sub editors working in a "domain-specific"
editor that knows about Scribus formatting - kind of like Adobe InCopy
in principle. Using a special markup and a GetText plugin might be a
viable alternative too.


> > 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.
> Isn't this already being done? Maybe not for the text, but seems to me
> the Pics are done as links. (but the caveat is that if the pics are
> moved, the links don't get updated. (figures anyway))

Supporting that would require help from the filesystem. It's do-able on
Mac OS X using HFS, where each file has a unique ID that apps
are /supposed/ to care about. It's probably do-able on UNIX within a
given filesystem by relying on the inode number, but only in a way
that's potentially hacky and gross. I see no way to do it across
filesystem boundaries without help from the OS, and if network file
systems are introduced ... ugh.

There probably won't be a good /technical/ solution to that for a while.

> > As Craig noticed, it would need someone to implement it, but I think the 
> > database approach is a means to KISS ("keep it simple, stupid"), as long 
> > as scribus will provide the interface. It will be much more difficult to 
> > educate the $office_suite users. As Louis has mentioned many times 
> > before, DTP is, to a large extent, a social process, so the coders 
> > aren't necessarily responsible for failures.
> As some would say, the text are more important, and if Scribus can
> separate the TXT from the others then it would be great. Sort of like an
> OOo file which is zipped up XML, only that scribus zips up the TXT
> independent of all the layout/Pics/etc files. That would make diffs even
> simpler.

It's an interesting idea... I'll be sure to mention it to malex. I'd
also be interested in /optionally/ being able to "bundle" linked images
and even fonts into a self-contained file that's easily mailed around
(not much more than collect-for-output zipped up, really).

Craig Ringer

More information about the scribus mailing list