[Scribus] Ideas on collaboration

[Christoph Schäfer]

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

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

>>>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.
> 
> We also have to find a way for efficient text emphasis (bold, italic, 
> at least). This is what lots of people bothers the most with. Having 
> a way to keep that formatting and get rid of anything else... 
> Basically, emphasis has to do with the publisher's decisions. Where 
> typographic enhancement is not. So, tools to keep the publisher's 
> will and tools to automate typographic formatting.

I think this problem will be much easier to solve as soon as character 
styles are available in scribus.

> Would it be reasonnable to consider having a filter do that? I 
> definitely have to check but I think the real problem is with people 
> using auto-hyphenation *and* discretionary hyphens *and* people 
> missing the alt key or the command key while hitting the hyphen... 
> This puts a "hard" hyphen (whatever we can call it) that will always 
> remain in the text, no matter the quality of the filter.

One of the problems is that most users are stuck with M$ Word. You would 
have to convert all the *.docs to *.sxw or OASIS, which, I suppose, can 
be easily done with OOo's scripting opportunities. But you'd still have 
to check the documents before submitting them.

>>>Ideally, perhaps ... but often the layout dep't is already overworked
>>>and hand-formatting the editorial text is the last thing they need :S .
> 
> 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 ;-)

> My understanding is this can be used successfully in proven workflow. 
> In realworld production, to what extent do you wish to let people 
> modify their text even though they have a mean to see exactly what 
> the effect is in the layout? It's kind of funny, but we have to 
> realize we are very close to the point where one could make a "last 
> minute" correction directly on the plate with the press running! You 
> think I am laughing... well, in fact yes. But there is at least 5% 
> truth behind any joke!
> 
> Honest. Editing PDFs and linking live text to a DTP file is where it 
> brings us. The real question that any person in charge of a workflow 
> will have to answer is "just *when* is the last minute for 
> change?"... At some point, we have commit ourselves and finish the 
> job. Last minute corrections are sure sand in the workflow.
> 

See above. A reasonable collaboration process will allow submits until 
the very last minute before the final PDF will be produced.

 >
 > And we're back to human behaviour.
 >

Couldn't agree more (ignorance is a mighty force)

> Actually, the very first task we have to do - and we do ask our 
> clients do that - is gather *all* the final texts and put them in one 
> single file (or conveniently named single files, depending on the 
> kind of work) where it is going to be easy to screen down all and 
> every text bugs, starting with crunching all strange uses of fonts 
> (ha! fonts!) and formatting attempts. Plus, have this text proofread 
> (remember, we said many many times we'd only start working on final 
> version of text files - no, it is *not* going to go faster if we 
> *start* with intermediate versions) and finally, hand this to 
> production, whether in QXP, ID or Scribus. This is a workflow.
> 
> 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.

> With the Web, can we state everything is now part of a huge database? 
> Then, text should be considered as such: data. And be treated 
> accordingly. With the proper tools.

And the proper education of authors, I'd like to add.

> In the end, I think it is only easier to narrow text to one source 
> and then format.
> 
> The same applies to pictures, but this is another discussion!

100 % agreed!

Christoph