Hi Greg, >> Hi Peter, >> >>> There really are not many elements needed. The ones I use in my HTML >>> approach >>> are more or less only <em>, <strong> and <code>. >> >> >> at first glance, using HTML seems not a bad idea, and I know of at >> least workflow which is built on HTML. > > I didn't think Peter was suggesting *using* HTML, only that he only > needed a few different tags. At any rate, the reason HTML itself won't > work is the reason that XML exists in the first place -- HTML is a > markup designed for a particular purpose, rather than being > multipotential and flexible.
Well I think he was suggesting HTML a few posts before, and I don't think it's not necessarily a bad idea, I only tried to point at the problems that might occur. If we are talking about collaboration in publishing, it seems clear to me that we need maximum flexibility (publishing and publishing isn't necessarily the same, not to mention publishing) on the publisher's side and varible degrees of complexity on the side on contributors. The biggest problem are probably contributors of text, because digital imaging and graphics require a certain set of skills which will make collaboration easier. I think for text contributors we should (as a first step) assume the worst, which means people who think *.doc is plain text or turn their computers off by turning off the monitor -- good old PEBKAC. Bright minds in many cases, but natural enemies to computers. For these guys we need to reduce complexity as much as possible. Different approaches have been discussed here. 1. On a low level, a project with an individual layout and few authors for instance, one doesn't have to think too much about collaboration. Let them write their texts, proofread, and then use OOo to convert whatever file format you recieve for use in scribus. 2. In more complex projects, using UNO as a tool for automated conversion will be useful. However, the problem of checking the results of the conversion remains. At a certain size of the project (newspaper, for instance) this is no longer feasible. 3. Craig has introduced the idea of domain specific markup, which is, in my opinion, a perfect solution for implementation in large shops and provides a maximum of flexibility. I think it would be no big deal to provide contributors with a web interface or a customised/cusomisable GUI with exactly the formatting options needed for specific jobs. 4. Unfortunately, I still expect problems (assuming the worst is always a good idea). To give an example, a newspaper will require different styles for headlines and texts (small vs. large articles). Let us further imagine, we have five different styles for headlines and five different style for articles. How can we prevent our brilliant journalists from messing up the layout by confusing styles? Introducing self-explanatory names for styles will help, no doubt about it. But I will bet, there are still enough people in your company or freelancers who won't or don't want to "get" it. Now we face the challenge to reduce complexity even more (and this the new point that hasn't been discussed yet IIRC). We need to provide an interface with an absolute minimum of formattig options, say headline, bold, italic (could be more, it's just an example). Now it is necessary to add more flexibility on the DTP side, without sacrificing automation opportunities. One solution might be to apply styles on a frame level, i.e. attaching certain style properties to a frame. As a result, writers need not care about the kind of headline they need. They will only format "headline". The style attached to the frame will control the appearance. IOW, the formatting of <h></h> depends on the frame. Now my question to (but not exclusively) malex: is this already possible with the new format? Would you think it would be possible or useful? It may not be on the roadmap for scribus anytime soon, but to have the file format prepared for such a feature might be worth a discussion. Christoph
