∋mim∈ wrote: > > In the Test.ditmap I've sent you I added chunk="to-content" to the > chapter, and not to its first topicref child (add.xml). IMHO, this gave > me a very usable .chm file. > > > What is useful for you might not be useful for someone else, perhaps it > could be useless or, worst, "unwanted". > >> > > > How to avoid this automatic linking mechanism in the chm-toc? > > > > Sorry but I don't see how this could be done. > > Moreover because we do not understand why it's useful to have TOC > entries not linked to any page, we do not plan to change the way ditac > generates CHM TOCs. > > > There is nothing to understand, this is a use case! In the same way I > don't understand why it's useful to have TOC like the current one.
OK. Understood. > > The behavior I've been described is the default behavior in DITA-OT (the > reference implementation of DITA), and we (and perhaps someone else) > find it very useful! We definitely don't use DITA-OT as our reference. Instead we use the DITA spec: * http://docs.oasis-open.org/dita/v1.1/langspec/ditaref-type.html * http://docs.oasis-open.org/dita/v1.1/archspec/archspec.html Please tell me, where in the DITA spec, the behavior you expect is *clearly* documented and we'll try to implement it. > > In SIEMENS, we bought licenses for XFC because DITA-OT misses formats > like wml and odf, and we actually use DITAC+XFC to create these kinds of > formats. Unfortunately this unexpected (let me say also forced and not > customizable) behavior in the chm output of DITAC compells us to rely on > the DITA-OT for chm :(. > I'm sorry for the inconvenience. If you prefer to use DITA-OT, why don't you simply plug XFC in it? XFC is not tied to ditac in any way. I mean, there should be no technical problems doing so. -- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
