On 02/21/2012 11:51 AM, Jirka Kosek wrote: > On 21.2.2012 10:09, Hussein Shafie wrote: > >> In all the books (published by a variety of publishers) we have examined >> before implementing ditac, we have found that it is *not* customary to >> have preface or index entries appear in the TOC. That's why this feature >> has not been not implemented. > > I see, but there are so many designs that this should be definitively > under user or stylesheet control.
Agreed. > >> Moreover, the DITA standard does not seem to indicate that such entries >> may be added to the TOC or how (i.e. which attribute? navtitle? toc?) >> such entries could be added to the TOC. > > In my understanding toc attribute is suitable for this purpose. It's not that clear. If my memory serves me well, some parts of the DITA spec are contradictory. We need to carefully reread the DITA spec to find out if this is the case. > >>> I understand that in order to fix these issues changes in Java part of >>> ditac are needed. >> >> No. I don't think so. In principle, the ditac_lists.ditac_list file >> contains all the information needed to add the missing entries to the >> TOC. (Otherwise this would be a flaw in the design of the >> ditac_lists.ditac_list file.) > > Of course I can inject ditac_lists.ditac_list file easiy by using XSLT, > but it would be easier (no need to orchestrate my transformations with > ditac) and cleaner to have such additional entries added directly inside > ditac:toc as ditac:tocEntry elements by preprocessor. That's right, but if and only if there is something in the DITA spec which says: add frontmatter/backmatter components to the TOC when condition XXX is met. > > However I'm little bit list in Java code for preprocessor. > >> After you modify xsl/fo/ditac_figureList.xsl and >> xsl/fo/ditac_indexList.xsl in order to give *fixed* ids to these >> components (e.g. id="__LOF", id="__LOT", id="__IDX" -- this is >> implemented like that in xsl/xhtml/*.xsl), then you'll have everything >> you need to add the corresponding entries to the TOC and to the PDF >> outline. > > I thought that having additional ditac:tocEntry inside > ditac_lists.ditac_list is the correct way to implement this feature. May be you are right. We need to reread the DITA spec to decide on this. > >> No. Please understand that we are a small company, that all our software >> engineers are very, very busy and that we definitely cannot distract >> them from their current tasks. > > I see, thanks for your email assistence. And we thank you for bringing us new requirements for ditac. > >> Here's what I suggest: [1] feel free to patch ditac v2.1.0_01 as you >> want [2] send us a copy of the patched sources [3] we'll make sure that >> the next release of ditac is *functionally* superior or equal to the >> patched version you sent us. However, we cannot guarantee that the next >> release of ditac will be 100% compatible with yours in terms of >> command-line options, XSLT stylesheet parameters, etc. > > Indeed, that's reasonable approach. I understand that my changes can't > be applied without changes for various reasons. After all it is your > product :-) > Ditac is an open source component licensed under a liberal license (MPL, like Saxon 9 on which ditac depends), so you are free to fork a project of your own if you want. However we have embedded this component in all our commercial products, which explains why we need to control both the feature set and the implementation of this component. -- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
