[Scribus] Ideas on collaboration [was: How do you guys
Thu Jun 23 23:34:13 CEST 2005
>> Hi Peter,
>>> There really are not many elements needed. The ones I use in my HTML
>>> 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
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.
More information about the scribus