It appears that the issue is actually a problem with the OT in that the coderef resolution processor resolves code ref references relative to the temp directory, not the original source directory.
Waiting for confirmation that this is in fact a bug in the OT.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm running into this problem. Using the DITA-OT and d4p's html2 and html5 plugins, no coderefs resolve. They do resolve when I use DITA-OT's built-in xhtml transtype.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue is that the general map-driven processing code turns off the preprocess copy step, which causes the coderef resolution to fail because the code file won't have been copied.
from build_common_mapdriven.xml in org.dita4publishers.common.mapdriven
I'm testing this change with the 1.0 code from GitHub. The main potential problem is that the copy process copies all referenced graphics to the temp area, which is a redundant action with the map-driven-specific graphic copying process. But it shouldn't be an issue with the output, but I need to verify that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have committed this fix to the GitHub code and there don't appear to be any adverse effects for the output other than extra copies of graphics files. I'll have to see what, if anything, can be done about that but I don't consider it a critical issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It appears that the issue is actually a problem with the OT in that the coderef resolution processor resolves code ref references relative to the temp directory, not the original source directory.
Waiting for confirmation that this is in fact a bug in the OT.
I'm running into this problem. Using the DITA-OT and d4p's html2 and html5 plugins, no coderefs resolve. They do resolve when I use DITA-OT's built-in xhtml transtype.
The issue is that the general map-driven processing code turns off the preprocess copy step, which causes the coderef resolution to fail because the code file won't have been copied.
The fix/workaround is to remove the line:
from build_common_mapdriven.xml in org.dita4publishers.common.mapdriven
I'm testing this change with the 1.0 code from GitHub. The main potential problem is that the copy process copies all referenced graphics to the temp area, which is a redundant action with the map-driven-specific graphic copying process. But it shouldn't be an issue with the output, but I need to verify that.
I have committed this fix to the GitHub code and there don't appear to be any adverse effects for the output other than extra copies of graphics files. I'll have to see what, if anything, can be done about that but I don't consider it a critical issue.