[Scribus] Ideas on collaboration

[Louis Desjardins]

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

(snip)

>>>>With respect to text content, it is always necessary to educate 
>>>>those who create texts.
>>
>>I couldn't agree enough.

I cannot disagree here. At the same time, I think it is only going to 
be an endless task *unless* we find a way to get out of the WP-DTP 
relationship. (I know it's kind of a recurrent statement from me (!) 
but I think the heart of the issue lies there.)

>>>>The average $office_suite user is used to format his/her text 
>>>>while writing it (which is nonsense, but nevertheless current 
>>>>practice).

This is exactly what I think. :)

>>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 it is important to tell the "Office professionals" how to 
>>switch off hyphenation and save to plain text.

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.

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

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

The emphasis issue still exists. But yes, this is workable.

>>Personally, I'm inclined to favour the Adobe InDesign model, where the
>>editors / writers use a special tool that understands the DTP program's
>>text, and talks to a content management system. The tool can be
>>customised to do things like auto-hyphenate or not, permit or not permit
>>text formatting, etc as appropriate, depending on how you want to divide
>>up the workload.
>>
>>This model lets you use a content management system or similar, with
>>versioning and history, without the pain of going back to primitive
>>plain text.

The Quark world has something similar based on CopyDesk (which is the 
"word processor" part of XPress). On top of that, there is something 
called Quark Publishing System. But I am from a small workflow world 
and I never used these tools.

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.

And we're back to human behaviour.

>I agree with you to a degree where you are talking about _inhouse_ 
>production. There you can get the right people do the job, and 
>InCopy's functionality could probably be achieved by using a web 
>interface.
>
>My idea of using plain text files has its origins in experiences 
>with many different authors working in different places and with 
>different skills. I return to my example of the fictious Cezanne 
>catalogue. In an ideal world, all of the contributors would have OOo 
>installed, hyphenation switched off and only apply styles defined in 
>a fictious style guide.

I don't disagree on the principle. But is this feasible?

>In the real world, none or few of them have OOo installed, they do 
>text formatting they way they are used to, hyphenation is switched 
>on, because the text looks better on _their_ screen and so on. 
>Expect most of them to be non tech savvy to a degree that they even 
>won't let you remove a virus or trojan from their computer, out of 
>fear, something would break. (This _is_ real world experience. Last 
>year I had to compile a catalogue for a museum with contributions 
>from 50+ authors, and to finally get the texts into a single layout 
>after receiving everything you can imagine -- *.doc, *.wpd, *.rtf, 
>*.tex and some others -- caused a lot of headaches!)

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?

>Once character styles are available in scribus, it would be possible 
>to send the authors a style guide, with rules like: Don't format 
>your text or your document, NEVER! DON'T EVEN THINK ABOUT IT!!! 
>Instead, use tags like <h></h> for the headline of your article. If 
>you want to emphasise something, tell us that you want it to be 
>emphasised by using <em></em> and so on. WE are responsible for the 
>layout, and WE know how emphasised text will finally look like, you 
>don't. YOU are ONLY responsible for the content. [kind of enforced 
>LaTeX approach]

I like this idea. We're getting close to a relationship between 
TE-DTP (text editor and DTP) which makes lots of sense imo. Also, 
provided Text Editing (only) can be real close to Database editing. 
More efficient in many aspects. More customizable. So, there is a 
need for DB-DTP relationship.

But, on the other side, we have to aknowledge DTP is not the only 
destination of a given text. The surprise in the other corner is: 
just what is the last version of this text that we want to use for 
something else? The one edited to the absolute extremity in the DTP 
file, after the third and last version? Then, is there a way to get 
this last version back?

>And then finally save your file as *.txt (NOT *.txt for DOS!). Once 
>you're finished, you can commit your article to the database [add 
>instruction how to commit to the database]. Commits in formats other 
>than *.txt will be rejected. (Sometimes it's necessary to use such a 
>draconian language, because -- in my experience -- if you ask for 
>plain text, chances are good you will receive *.docs, as many people 
>think *.doc is plain text.)

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.

>Plain text is the smallest common denominator, and with a working 
>text importer for paragraph _and_ character styles, its use still 
>makes sense if you need to handle input from many sources with 
>different degrees of experience and different software installations.

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!

Louis

>
>Christoph
>_______________________________________________
>Scribus mailing list
>Scribus at nashi.altmuehlnet.de
>http://nashi.altmuehlnet.de/mailman/listinfo/scribus