Chris Papademetrious

Results 177 comments of Chris Papademetrious

Using [`ditaot_save_preprocessing.pl`](https://github.com/chrispy-snps/DITA-ditaot-utilities), I found that the `topic2` keyref in topic1.dita is resolved to "topic2.dita" in `keyref`: ``` $ diff -r temp-05-branch-filter/topic1.dita temp-06-keyref/topic1.dita 7c7 < See also: --- > See also:...

When I explicitly add `@processing-role="resource-only"` to topic2: ``` ``` then `copy-to` does not duplicate the topic when `force-unique=true`: ``` $ diff temp2-06-keyref/ temp2-07-copy-to/ $ ``` Should `copy-to` be looking for...

This bug also causes duplicate search results in Oxygen WebHelp: ![image](https://user-images.githubusercontent.com/50950969/178108613-f21523bb-9c22-4f53-a63f-21835a7a81ae.png) The duplicate copy of the topic opens with no WebHelp navigation (because it is not in the TOC). Here's...

The following XSLT template applied in `mapref` seems to work around the issue (for our source content, at least): ``` ``` @antonyterrence - does the following DITA-OT plugin work around...

Thanks @raducoravu! I will test the pull request on our production content when it's ready.

Here are the log files: [out-direct.log](https://github.com/dita-ot/dita-ot/files/9260238/out-direct.log) [out-project.log](https://github.com/dita-ot/dita-ot/files/9260240/out-project.log) I am using a fresh DITA-OT 3.7.2 installation (installed just now), running in Ubuntu 20.04 in Windows 10 WSL. The invocation commands are:...

The results on a true linux box (CentOS) are similar: ``` log-arg: [echo] ***************************************************************** [echo] * basedir = /u/chrispy/3983/ditaot-default-project-tmpdir/dita-ot-3.7.2 [echo] * dita.dir = /u/chrispy/3983/ditaot-default-project-tmpdir/dita-ot-3.7.2 [echo] * transtype = html5 [echo]...

This is an interesting issue. I didn't know about it until after it was closed. To help me explore it, I created a modified testcase that uses regular topics: [2905.zip](https://github.com/dita-ot/dita-ot/files/8600221/2905.zip)...

The trigger for this bug is the presence of `keys="foo"` on the reference to container.ditamap. If I keep the `@keys` definition, the output of `mapref` preprocessing is: ``` map container...

For comparison, here is the `mapref` output using the `` workaround: ``` map container ```