[Scribus] Ideas on collaboration
Wed Jun 22 12:59:06 CEST 2005
>>>>>>It has been mentioned before that multiple editing of DTP files
>>>>>>is not a good idea.
>>>>I don't agree.
>>Don't agree either. We need a way to achieve this, sooner or later.
>>I recall a discussion on that specific issue months ago. For one
>>thing, I was pointing out the need for database relationship for
>>formatting on the fly and creating layouts. In some workflow, there
>>simply isn't any other efficient way to produce a document. Fast.
>Well, somehow that's what I meant when I wrote about multiple
>editing of DTP files as a bad idea. In my view, and your comments
>further down seem to support that view, separation of layout and
>content is essential.
Absolutely. This is one key issue. Nonetheless, this calls for one
nuance. When we get to the last touch of a nice piece of
layout/typography, intense collaboration between the two teams
(content/laytout) is compulsory. For example, a title could be too
long from the layout perspective... at the same time it reflects
exactly the author's idea... With good collaborative work, this can
be worked out - it has to! - and will only be if everyone listens to
On the "DTP file being edited", the basic idea is to let teams
organize their workflow the way they want, thus provide them with
tools designed for this. As I see it, it's more like multiusers
having access to a database. One specific file cannot be edited
simultaneously by two co-workers is the basic rule. Other than that,
security levels could be applied so some part of the page can/cannot
be edited and or workflow specifications (agreed by the people
working on that project) could be established.
This way, many people could work on the same document, to accelerate
the production process. In some areas, this is definitely a need:
newspapers, ad flyers, catalogs, to name a few.
>If you look at how company publications are sometimes patched up,
>moving through x departments for approval, including all the
>commenting tools, bitmaps moved around, a third and fourth font
>added ..., you know what I mean. In the end you have a poorly
>formatted *.doc file on your desk/computer with pictures from the
>website that (might) look good on screen. If you tell the
>$OFFICE_SUITE users, that despite all their work, the file can't be
>printed, they will be at least disappointed, sometimes even angry.
I agree. We could say this is where starts the uncollaborative work
in workgroups! The workaround is, simply put, education and workflow
awareness. What people have to understand is publishing is a
complicated task. The computers are only a powerful tool to help get
the job done. Computers don't do the job! Humans do. The workflow is
there to help humans accomplish that in the most efficient possible
way. If people don't agree on the workflow, then it's useless!
>My idea was to let the content remain editable, but not the layout.
>It's enough to let different people work on a text after or before
>the layout is defined (depends on the customers). The reason for my
>text frame approach was based on my fictious catalogue: the authors
>know how much text can be submitted to "their" text frames. But they
>can submit changes until the last minute before the plates will be
>produced. The (future) scribus user will only have to update the
>_content_ of the text frame, check hyphenation and finally produce
Actually, if content and layout are separated (which is good), then I
guess it would only be reasonnable to allow separate editing
authorization for each. Works on both sides imo. And we cannot afford
to let the proofreaders aside of the workflow!
>>Well, in my view, if we are overworked, the last we want is a badly
>>pre-formatted text. :)
>I'm sure you won't mind if I say: 100% agreed ;-)
>>Going back and forth, up and down the hill, can puzzle any
>>production team and make professionals look like pee-wees: a sure
>>way to miss something important at some level and make *the*
>>mistake that will force a reprint. And remember, lots of clients
>>don't have the money for decent proofreading, but they sure have
>>the money to reprint if anything goes wrong. Now, just how much
>>costs proofreading? and a reprint?
>Gorgeous! Thank You! That's real life! But again, submitting text to
>a database and to let the DTP people simply update the files and
>therefore the _frames_ before producing the plates could make the
>whole process a lot easier.
Agree! The database approach is very interesting.
More information about the scribus