On Tue, 2005-06-21 at 04:33 +0200, Christoph Sch?fer wrote: > It has been mentioned before that multiple editing of DTP files is not a > good idea.
I don't agree. With suitable style guides and a suitable team, it'd be an important thing to be able to do. I do agree that if done without discipline it can end up a mess, though. If nothing else, it'd be EXTREMELY useful to be able to have different people working on different parts (sections, liftouts, chapters, whatever) of a document. Whether this was done through a Word/OO.o style "master document" system or through true multiple editing isn't too important. http://bugs.scribus.net/view.php?id=1925 http://bugs.scribus.net/view.php?id=2107 > With respect to text content, it is always necessary to educate those > who create texts. I couldn't agree enough. > If you look carefully, you will find that in many > publications, created with Quark or InDesign, hyphenation marks appear > in the text where they shouldn't, because both programmes offer an > import filter for Word files. The average $office_suite user is used to > format his/her text while writing it (which is nonsense, but > nevertheless current practice). 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. > I think it is important to tell the > "Office professionals" how to switch off hyphenation and save to plain > text. Ideally, perhaps ... but often the layout dep't is already overworked and hand-formatting the editorial text is the last thing they need :S . > 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. 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. > On the DTP side, it would be extremely useful if scribus could provide a > database interface for text frames. If a text frame could be linked to a > database entry, many restraints on productivity would be removed in a > single step, especially if the whole process could be done via scripting. http://bugs.scribus.net/view.php?id=1791 http://bugs.scribus.net/view.php?id=1925 http://bugs.scribus.net/view.php?id=1406 > With pictures, the situation is similar, though not exactly the same. > Imagine a newspaper with predefined fields for ads: Instead of manually > inserting the ad in scribus, a special database field entry would > receive the ad for the current issue from a database. Yep... you're talking basic automatic pagination there. It's already do-able in Scribus using the Python plugin, though with the restriction that PDF and EPS are rasterised on import. > I also think of another aspect, which is linking of different files. > This would improve the creation of large documents a lot. Yep. I'd love to be able to have a "master document" with pages pulled in from different .sla files (but all able to access the master's styles, etc). Even possibly individual parts of the page pulled in from different .sla files - think a frame for a half-page ad done as an external file. This also helps a lot for collaboration. Most of what's being discussed here today isn't new, by the way. A lot has come up on the ML before, or been discussed on IRC. That doesn't mean that going over new ideas for such things is in any bad of course ;-) -- Craig Ringer
