[Scribus] Ideas on collaboration [was: How do you guys

[Christoph Schäfer]

Hi Greg,

>> Hi Peter,
>>
>>> There really are not many elements needed. The ones I use in my HTML 
>>> approach
>>> are more or less only <em>, <strong> and <code>.
>>
>>
>> at first glance, using HTML seems not a bad idea, and I know of at 
>> least workflow which is built on HTML. 
> 
> I didn't think Peter was suggesting *using* HTML, only that he only 
> needed a few different tags. At any rate, the reason HTML itself won't 
> work is the reason that XML exists in the first place -- HTML is a 
> markup designed for a particular purpose, rather than being 
> multipotential and flexible.

Well I think he was suggesting HTML a few posts before, and I don't 
think it's not necessarily a bad idea, I only tried to point at the 
problems that might occur.

If we are talking about collaboration in publishing, it seems clear to 
me that we need maximum flexibility (publishing and publishing isn't 
necessarily the same, not to mention publishing) on the publisher's side 
and varible degrees of complexity on the side on contributors. The 
biggest problem are probably contributors of text, because digital 
imaging and graphics require a certain set of skills which will make 
collaboration easier.

I think for text contributors we should (as a first step) assume the 
worst, which means people who think *.doc is plain text or turn their 
computers off by turning off the monitor -- good old PEBKAC. Bright 
minds in many cases, but natural enemies to computers.

For these guys we need to reduce complexity as much as possible. 
Different approaches have been discussed here.

1. On a low level, a project with an individual layout and few authors 
for instance, one doesn't have to think too much about collaboration. 
Let them write their texts, proofread, and then use OOo to convert 
whatever file format you recieve for use in scribus.

2. In more complex projects, using UNO as a tool for automated 
conversion will be useful. However, the problem of checking the results 
of the conversion remains. At a certain size of the project (newspaper, 
for instance) this is no longer feasible.

3. Craig has introduced the idea of domain specific markup, which is, in 
my opinion, a perfect solution for implementation in large shops and 
provides a maximum of flexibility. I think it would be no big deal to 
provide contributors with a web interface or a customised/cusomisable 
GUI with exactly the formatting options needed for specific jobs.

4. Unfortunately, I still expect problems (assuming the worst is always 
a good idea). To give an example, a newspaper will require different 
styles for headlines and texts (small vs. large articles). Let us 
further imagine, we have five different styles for headlines and five 
different style for articles. How can we prevent our brilliant 
journalists from messing up the layout by confusing styles? Introducing 
self-explanatory names for styles will help, no doubt about it. But I 
will bet, there are still enough people in your company or freelancers 
who won't or don't want to "get" it. Now we face the challenge to reduce 
complexity even more (and this the new point that hasn't been discussed 
yet IIRC). We need to provide an interface with an absolute minimum of 
formattig options, say headline, bold, italic (could be more, it's just 
an example). Now it is necessary to add more flexibility on the DTP 
side, without sacrificing automation opportunities. One solution might 
be to apply styles on a frame level, i.e. attaching certain style 
properties to a frame. As a result, writers need not care about the kind 
of headline they need. They will only format "headline". The style 
attached to the frame will control the appearance. IOW, the formatting 
of <h></h> depends on the frame. Now my question to (but not 
exclusively) malex: is this already possible with the new format? Would 
you think it would be possible or useful? It may not be on the roadmap 
for scribus anytime soon, but to have the file format prepared for such 
a feature might be worth a discussion.

Christoph