Friday, July 7, 2006, 2:42:57 PM, Hussein Shafie wrote:
> Daniel Dekany wrote: >> >> I support that showing the structure/semantic is the priority. But why >> does the current CSS (no vertical space) makes it easier to >> understand, compared to the patched CSS? OK, this question should be >> split into two independent questions. In the first iteration, let's >> say you will ignore the "spacing" attribute in the CSS. So, you have >> two CSS-es to chose from, A and B (neither considers the spacing >> attribute). Both shows the structure equally well, but with B the >> result is closed to the final output of most XSL-s. I think that's >> only good, and there was no tradeoff for that. B has only advantage as >> far as I can see. So why don't you prefer B over A? I.e. using >> vertical space around listitems over no vertical space? This is what I >> mostly don't get here. > > OK, let's say that like you, we prefer B to A. Therefore let's say we'll > change the stock DocBook CSS to add more space between listitems unless > spacing="compact" is specified. I said, neither A or B takes spacing="compact" into consideration. The only difference is that B uses vertical margin around listitems (always), while A (the current one) doesn't. Hence B resembles more to the typical final output (PDF, HTML, etc). So, as I said, there are two question here, and they are independent. So, what do you say for the first question, i.e. A VS B (again, neither cares about spacing="compact")? > Now where should we stop? > > Why just support spacing="compact"? > Why not support > * orderedlist/@continuation, > * orderedlist/@inheritnum, > * programlisting/@startinglinenumber, > * programlisting/@linenumbering, > * xref/@endterm, > etc? Because you have no energy for it? I hope not because you think that it will be bad if they are supported... > Do we have to support all the processing expectations described in > http://www.docbook.org/tdg/index.html ? ??? Supporting spacing="compact" is not like signing a contract that you will support everything. If you *can* show one more thing about the document content with a trivial CSS change, then why not? It's just improvement (that's trivial to implement), a bit better out-of-the-box DocBook editing in XXE. And you want to improve your product, don't you? > I'm sorry if this seems strange, not very professional, not very > serious, etc, but for now, we have answered no to the above question. > > This may change if in the future, XXE or its descendant is retargeted as > a DocBook editor. > > For now, please consider that the whole DocBook configuration, and this > includes the CSS style sheet, is just a *starting* *point* that needs to > be customized/enhanced before being used professionally by technical > writers. I understand that. But I hope you don't hold aloof from improving the included CSS. In general, I find it strange that you guys don't seem to target being as good DocBook editor out-of-the-box as you can. Or at all. Like if you had signed something that says "XXE must remain a non-professional DocBook editor". Even if you don't invest a lot into it, you should at least try to pick the low hanging fruits, shouldn't you? BTW, you have mentioned earlier your competitor. My I ask who is that? I did a research before choosing DocBook editor (including commercial ones), and I didn't find anything that was even near as good for the task as XXE. (However, I hadn't have chance to try ArborText's stuff, so I don't know about that... but however good it is, I suspect that's a very expensive software.) So I think you are in a good starting position on the XDocBook editor field. It appears to me that XDocBook is more and more dominant for project documentations (like for OSS projects, and you have an OSS friendly licence). These authors need a good XDocBook editor a lot... I can tell you that, because I have written many XDocBook software documentation. There is a vacuum here. So I don't think you head toward bankruptcy if you invest a bit into the DocBook thing, rather I think the opposite. -- Best regards, Daniel Dekany
