On Tue, 2005-06-21 at 12:41 +0800, Craig Ringer wrote: > 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
Got to see those bug reports :-) (No I-net currently) > > > > 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. Ah.. That's an idea. using the FS as the database. But as mentioned, with the current FS in *nix, it'll be hacky I guess > > 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). Yep. My guess is that OOo is doing that of sorts. Makes distribution simpler though I can't tell how that will help in using it for a CVS/SVN/RCS based system for diffing the txt. I'm assuming that the text is all that's important and the pics etc will come later. (They are easier to lay-out compared to the text) -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 1.5GB RAM 98% Microsoft(tm) Free!! Neuromancer 13:09:51 up 2 days, 15:12, 6 users, load average: 0.25, 0.19, 0.18
