Mark Fletcher wrote:
>>I'm sorry but I cannot reproduce this problem, at least when I use
> dita.setConref normally.
> 
> Hmm. I've double-checked and I can reproduce with the out-of-the-box
> addon. Again, my steps to reproduce were:
> 
> 1. Open a file with an existing conref.
> 2. Select the conref source element and press F2 Shift+V
> 3. Use the file chooser dialog to choose a different target file.
> 4. Click OK. (The new content is transcluded.)
> 5. Save and close the file.
> 6. Reopen the file. (The old content appears because the original conref
> path is still there.)

We've reproduced, and therefore fixed, the bug. You'll find the fix in
next release. Thank you for your patience.



>>When you use dita.setConref, please always pass it an *URL* (absolute
> or
> relative) and never a filename. If you use [clipboard], the clipboard
> must contain an URL (absolute or relative) and never a filename.
> 
> The file path examples (c:\xxx\xxx.xml) I gave are not what I'm entering
> manually into the dialog; they're just for illustration of the relative
> file locations. I'm using your file chooser dialog to point to my conref
> targets. 

I've retested this on Windows:
---
source file is c:\private\file_1.xml

I use dita.setConref and map a conref to c:\user_doc\topics\file_2.xml

The resulting conref url looks like this:
../../c:/user_doc/topics/file_2.xml
---

When XXE is used normally: no filenames/URLs typed by hand, I didn't
manage to reproduce the problem.

My guess is that the problem is related to the fact that filenames are
case-insensitive on Windows, while URLs are case-sensitive.

Here's what happens (I think):
---
source file is file:/c:/private/file_1.xml (this happens if, for
example, you open a file from the command line: "xxe.exe
c:\private\file_1.xml")

I use dita.setConref and map a conref to
file:/C:/user_doc/topics/file_2.xml (chosen using the dita.setConref dialog)

The resulting conref url looks like this:
../../C:/user_doc/topics/file_2.xml
---

We'll *try* to fix this problem but I cannot give you my word that we'll
succeed.



>>I understand but the rationale is: you have already chosen a conref
> *target* in this directory, therefore there are chances that you choose
> the new conref target from the same directory.
> 
> I think it's great that you can choose another conref target from the
> same directory (ie, the file chooser remembers your last location). I
> just think the Set conref dialog should display the path in relation to
> the conref source, not in relation to the last target. 
> 

You are 100% right. We'll change this in next release.

Reply via email to