[Scribus] Ideas on collaboration
Wed Jun 22 02:17:19 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.
>>>>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
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
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
>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
>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
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!
>Scribus mailing list
>Scribus at nashi.altmuehlnet.de
More information about the scribus