oxy_link-text() not resolving on xrefs targeting fn element?

[Bruno.Ballarin]

It seems the oxy_link-text() function does not resolve when targeted at a <fn/> element (whereas I got it to work with all other type of xref targets while customizing my CSS).

The CSS fragment:

Code: Select all

/* fn xref */

*[class ~= "topic/link"][href *= "/fn"]:before,

*[class ~= "topic/xref"][href *= "/fn"]:before,

*[class ~= "topic/link"][type][href *= "/fn"]:before,

*[class ~= "topic/xref"][type][href *= "/fn"]:before{

    vertical-align: super;

    color: rgb(57, 169, 220);

    content: "(x)";

}



*[class ~= "topic/link"][href *= "/fn"]:empty,

*[class ~= "topic/xref"][href *= "/fn"]:empty,

*[class ~= "topic/link"][type][href *= "/fn"]:empty,

*[class ~= "topic/xref"][type][href *= "/fn"]:empty{

  content: "fntext" oxy_getSomeText(oxy_link-text(), 10, true);

}

In oxygen Author view, my footnotes are showing: (x)fntext

So it seems all the CSS fragment above applies except the oxy_link-text() that does not seems to return any text.

An extract of the dita topic to which the CSS applies:

Code: Select all

<fn id="fn_zxw_lpq_t2b" ast:aid="00000023WIH4031572020D820GYZ">Depends on device part number.</fn>

<xref format="dita" href="#overview/fn_zxw_lpq_t2b" ast:aid="00000023WIH4031572020F820GYZ"/></entry>  

[alex_jitianu]

Hello Bruno,

You are correct. Currently, oxy-link_text() doesn't extract any text from a fn element. When we decided how oxy_link-text() extracts content from the targets, we tried to mimic the PDF and HTML publishing. If you publish a content that contains xrefs to fn elements, you will notice a similar behavior.

if you want to change this behavior, you can extend the built-in DITA resolver. Using our SDK, you can implement a custom LinkTextResolver that can extract content from fn elements as well. Please let me know if you are willing to go on this path and I will give you more details.

Best regards,
Alex

[Bruno.Ballarin]

Thank you very much Alex for your reply.

Yes I am interested in going further into finding a solution to this issue:

We often have multiple fn within a same table, each fn being targeted by multiple xrefs (also disseminated within the same table).
When in author mode, I would like to have by default for each xref, a visual indication of which fn it is pointing to, rather than having to wave the mouse over each xref and unveil each xref destination link (on demand).
Note that I have already updated my CSS so that in Author view my footnotes are automatically prefixed by an incremental index that is reset at each new table. It would be nice to have each xref (pointing to a fn) prefixed with the same index as the fn it is pointing to. So the ideal would be that the xref is prefixed with the fn index, alternate solution I was thinking of would be that the xref is prefixed with the first characters of the fn text.

Cheers,

Bruno

[alex_jitianu]

Hello Bruno,

rather than having to wave the mouse over each xref and unveil each xref destination link (on demand).

How about if you render the value of the @href attribute? Is that an acceptable information? I know that it is not perfect but it is the fastest obtainable information.

Code: Select all

/* fn xref */

*[class ~= "topic/link"][href *= "/fn"]:before,

*[class ~= "topic/xref"][href *= "/fn"]:before,

*[class ~= "topic/link"][type][href *= "/fn"]:before,

*[class ~= "topic/xref"][type][href *= "/fn"]:before{

    vertical-align: super;

    color: rgb(57, 169, 220);

    content: "(" attr(href) ")";

}

So the ideal would be that the xref is prefixed with the fn index, alternate solution I was thinking of would be that the xref is prefixed with the first characters of the fn text.

The CSS function oxy_xpath() can help with that:

Code: Select all

[code]/* fn xref */

*[class ~= "topic/link"][href *= "/fn"]:before,

*[class ~= "topic/xref"][href *= "/fn"]:before,

*[class ~= "topic/link"][type][href *= "/fn"]:before,

*[class ~= "topic/xref"][type][href *= "/fn"]:before{

    vertical-align: super;

    color: rgb(57, 169, 220);

    content: "(" 

    oxy_xpath(oxy_concat('doc(resolve-uri(substring-before(@href, "#")))//fn[@id="', oxy_substring(attr(href), oxy_add(oxy_indexof(attr(href), '/'), 1, 'integer')), '"]/text()')) 

    ")";

}

oxy_xpath() can introduce performance penalties. When the document gets modified, these xpath expressions need to be executed again to ensure they present up to date information. The more such xref elements you have, the more intensive the processing becomes. An optional evaluate parameter can help reduce or eliminate these performance aspects. If these "fn" targets are in a different file, you could set the evaluate parameter to static. This means you will have to manually press F5 to refresh the text presented for the xrefs. If the "fn" elements don't change that often then this might be a solution.

Anyway, if none of the above are acceptable, please let me know, and I will begin talking about our Java SDk and how to extend oxy_link-text().

Best regards,
Alex

[Bruno.Ballarin]

Thanks Alex,

the below fragment does the trick of displaying the xref target (<fn>) text.

Code: Select all

content: "(" 

    oxy_xpath(oxy_concat('doc(resolve-uri(substring-before(@href, "#")))//fn[@id="', oxy_substring(attr(href), oxy_add(oxy_indexof(attr(href), '/'), 1, 'integer')), '"]/text()')) 

    ")";

Indeed, as you mentioned, I found it more convenient to use it with the "evaluate static" option, especially since source is stored on a SVN

Code: Select all

content: "(" 

    oxy_xpath(oxy_concat('doc(resolve-uri(substring-before(@href, "#")))//fn[@id="', oxy_substring(attr(href), oxy_add(oxy_indexof(attr(href), '/'), 1, 'integer')), '"]/text()'), evaluate, static) 

    ")";

After having presented this solution to my team mates, they preferred to stay on a more condensed approach consisting of just showing the xref target ID (with first 3 non discriminant characters truncated):

Code: Select all

     content: "[" oxy_substring(attr(href), oxy_add(oxy_indexof(attr(href), '/fn_'), 4, 'integer')) "]";

I also read some stuff about a CSS3 target-counter() function but that does not seem to be usable (yet?) for Author view rendering.

[alex_jitianu]

Hello Bruno,

We have an issue recorder for adding support for the target-counter() function but I have to say that it is not on our short term TODO list. Nevertheless, user requests can increase its priority so I've added your vote for it.

Best regards,
Alex

[Bruno.Ballarin]

Thxs Alex