Multiple references to alternative verses (vp) in a cross reference (Esther Greek)

Question

Since the is detail lacking in the USFM documentation and I am not able to find the answer here, 
please can you clarify the correct syntax for the following case:

- Our Esther Greek uses many publisher verses (\vp) e.g. ESG 3:13a, ESG 3:13b, etc. with the verse number increasing incrementally e.g. ESG 3:13b is 3:14.
- We reference multiple verses in our cross-references e.g. 
\x - \xo 3:7 \xk 14de ... Adar: \xt EstGr 3:13<!--95d9291a-d20b-43ec-be7f-d1054bd96638-->|ESG 3:19\xta \+it f\+it*; \xt 8:12<!--4b17af55-c222-44ed-8dac-193006ac63cc-->|ESG 8:30\xta \+it s\+it*; \xt 9:1,15,21; 10:3<!--24cf66a4-6257-43be-a2b8-dbf3a2359a4a-->|ESG 10:13\xta \+it k\+it*\x*
- You will notice I have moved the italics letter outside the reference as \xta's to keep Paratext happy

Do I need to add bar attributes to each of the 9:1,15,21 references or just add in an extra \xt so that the sequence doesn't get set as one link to 10:13?

\x - \xo 3:7 \xk 14de ... Adar: \xt EstGr 3:13<!--{C}%3C!%2D%2D95d9291a-d20b-43ec-be7f-d1054bd96638%2D%2D%3E-->|ESG 3:19\xta \+it f\+it*; \xt 8:12<!--{C}%3C!%2D%2D4b17af55-c222-44ed-8dac-193006ac63cc%2D%2D%3E-->|ESG 8:30\xta \+it s\+it*; \xt 9:1|ESG 9:1,15|ESG 9:15,21|ESG 9:21; 10:3<!--{C}%3C!%2D%2D24cf66a4-6257-43be-a2b8-dbf3a2359a4a%2D%2D%3E-->|ESG 10:13\xta \+it k\+it*\x*

or

\x - \xo 3:7 \xk 14de ... Adar: \xt EstGr 3:13<!--{C}%3C!%2D%2D95d9291a-d20b-43ec-be7f-d1054bd96638%2D%2D%3E-->|ESG 3:19\xta \+it f\+it*; \xt 8:12<!--{C}%3C!%2D%2D4b17af55-c222-44ed-8dac-193006ac63cc%2D%2D%3E-->|ESG 8:30\xta \+it s\+it*; \xt 9:1,15,21; \xt 10:3<!--{C}%3C!%2D%2D24cf66a4-6257-43be-a2b8-dbf3a2359a4a%2D%2D%3E-->|ESG 10:13\xta \+it k\+it*\x*

Answer 1

The example you have that has multiple "|" characters in the \xt would be the cause of the message about "having stopChars in the searchStr value is not supported".
I'm not sure what you are trying to do with the embedded HTML comment after the verse reference, but having that data there will probably not work as you want it to by all users of your DBL resource once it is uploaded.

You could do something like this:

\xt EstGr 3:13|link-href="ESG 3:19" x-refId="95d9291a-d20b-43ec-be7f-d1054bd96638"\xt*

The x-refId would be considered a custom attribute that would then be passed along with the same name in the USX. Only users of the USX that know what to do with the attribute would see it.
The value of link-href should just be a single reference - no commas, but a range is acceptable.

Comments

Thanks John.

I had missed the additional attributes added from the copy/paste from Paratext in my original post.
Copying from Paratext has become worse than copying from Word :)

My 1st example should be:

\x - \xo 3:7 \xk 14de ... Adar: \xt EstGr 3:13|ESG 3:19\xta \+it f\+it*; \xt 8:12|ESG 8:30\xta \+it s\+it*; \xt 9:1,15,21; 10:3|ESG 10:13\xta \+it k\+it*\x*

which should display as

3:7 14de ... Adar:  EstGr 3:13f; 8:12s; 9:1,15,21; 10:3k

EstGr 3:13f needs to point to ESG 3:19 because

\v 19 \vp 13\+it f\+it*\vp*

EstGr 8:12s needs to point to ESG 8:30 because

\v 30 \vp 12\+it s\+it*\vp*

and EstGr 10:3k needs to point to ESG 10:13 because

\v 13 \vp 3\+it k\+it*\vp*

Unfortunately we have multiple references that we need to point to alternative references and I need to know how to handle the markup in Paratext. The USFM documentation is lacking in this area. We keep having to change how we handle this as the Paratext and DBL checks get updated and change what is or isn't acceptable. 

This is the AFR20 project.

---

The use of the \vp marker after a verse with a nested \it marker will result in significantly different USX than \vp marker without a nested style. This may be important to how the USX will be used.

\v 19 \vp 13\+it f\+it*\vp* will create: 

<verse number="19" style="v" sid="ESG 1:19" />
    <char style="vp">13<char style="it">a</char></char>

\v 19 \vp 13f\vp* will create:

<verse number="19" pubnumber="13f" sid="ESG 1:19" />
I don't know the intricacies of EstGr, maybe it would be useful to find out what others have done.

---

I think the complication comes in from the translators wanting the verse letter to be styled differently from the verse number.
I can see where having the pubnumber include the letter would be useful for searching, but the user would not otherwise see this in terms of navigation. My concern here is to make sure that the code validates on DBL and is acceptable use. Are both of your examples considered correct?

---

Both of my examples are syntactically correct, but the USX is different. I actually think you want the USX to be in this form:

<verse number="19" pubnumber="13f" sid="ESG 1:19" />

That would mean you don't want to do the italics on the section letter. The format shown above will allow other users of the USX to display the pubnumber for the verse instead of the original verse in the number attribute. When the other format is used, most likely both versions of the verse will be displayed.

Maybe you can discuss the formatting with the typesetter to see if they can do the formatting the users want without special markup in the project.

---

This seems to be a chicken-egg situation.
The cross references are required to have an italics letter referencing a verse number with an italic letter.
Unfortunately Paratext needs to support this somehow. I'm really not too worried about the USX. Only that this will be stored and published (digitally and in print) so that the cross references and verses can have an attached italic letter.

We were somehow able to accomplish this in the past, and now it seems this is no longer possible.
We can't at this stage (the text has been in print for 5 years) just change the translation (this was a translation decision at the time of translation when this was possible) to accommodate the limitations of Paratext.
We also need to have multiple references to \vp's of this nature within the same cross reference. This was also supported in the past (if not correct syntax) and is now also no longer possible.

Please can the devs come up with a solution beyond a request to change an existing translation just to accommodate a software limitation?