On Tue, 2005-06-21 at 11:21 +0800, Ow Mun Heng wrote: > On Tue, 2005-06-21 at 04:33 +0200, Christoph Sch?fer wrote: > [SNIP] > > 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. > > And I'm presuming that that includes sub'ing so that text which should > be "bold" will be so and headers will be so? That's a whole lot of > educating. (sort of using a text editor to write LaTeX!)
I personally like the idea of sub editors working in a "domain-specific" editor that knows about Scribus formatting - kind of like Adobe InCopy in principle. Using a special markup and a GetText plugin might be a viable alternative too. http://bugs.scribus.net/view.php?id=1791 http://bugs.scribus.net/view.php?id=2108 > > 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. > > Isn't this already being done? Maybe not for the text, but seems to me > the Pics are done as links. (but the caveat is that if the pics are > moved, the links don't get updated. (figures anyway)) Supporting that would require help from the filesystem. It's do-able on Mac OS X using HFS, where each file has a unique ID that apps are /supposed/ to care about. It's probably do-able on UNIX within a given filesystem by relying on the inode number, but only in a way that's potentially hacky and gross. I see no way to do it across filesystem boundaries without help from the OS, and if network file systems are introduced ... ugh. There probably won't be a good /technical/ solution to that for a while. > > As Craig noticed, it would need someone to implement it, but I think the > > database approach is a means to KISS ("keep it simple, stupid"), as long > > as scribus will provide the interface. It will be much more difficult to > > educate the $office_suite users. As Louis has mentioned many times > > before, DTP is, to a large extent, a social process, so the coders > > aren't necessarily responsible for failures. > > As some would say, the text are more important, and if Scribus can > separate the TXT from the others then it would be great. Sort of like an > OOo file which is zipped up XML, only that scribus zips up the TXT > independent of all the layout/Pics/etc files. That would make diffs even > simpler. It's an interesting idea... I'll be sure to mention it to malex. I'd also be interested in /optionally/ being able to "bundle" linked images and even fonts into a self-contained file that's easily mailed around (not much more than collect-for-output zipped up, really). -- Craig Ringer
