PtxPrint 3.x Solution for allowing '\va' markers after '\p'

Question

error I'm getting:

JAS 3:1-2 Attrib marker 'va' found after 'p' but may only follow 'v' at line 135, char 29

...

These errors were triggered while internally parsing the USFM

Text in question:

+-----------------------

\p \v 1-2 <!--a5f14dd1-082f-4046-8166-3adf7e93b315-->Brothers and sisters, \va 2a\va* we all make many mistakes, \va 1\va* that God will judge one day. But look, you know that God will be even more severe in judging the mistakes of those who teach in the church ⌊because they are spiritual leaders⌋. Therefore, think deeply before you decide to become a teacher in the Church.

\s The Tongue: The Source Of Evil

\p \va 2b\va* When we control our tongues, then we can become mature in our faith and be in full control of ourselves.

+-----------------------

I have a rule in changes.txt that converts these to '\vp .*? \vp*' and that worked in earlier versions of PtxPrint. But with 3.0.1, it throws up this error parsing the USFM, which is happening apparently before it get to the changes.txt process to clean it up.

Is there another solution besides putting the \vp's in Paratext?

Answer 1

It seems to me that the USFM standard for how va is used has changed. In 3.0  it seems that \va could go anywhere.

In  USFM 3.1, \vp is for specifying the printed form of a verse number, and \va  is an alternative (printed) form.  It looks like now BOTH  should follow immediately after the verse number. When used like that, they certainly have a precise meaning for how the XeTeX code should process things going forwards. (\va gets added, in brackets - or other marks - after the printed verse number, \vp sets how the verse number gets represented in headers, as well as the text, etc). Both get moved into margins or whatever if marginal verse numbers are selected, and so on. As they are anchored to the verse number, you can't put them into the middle of the text.

The XeTeX code itself will treat a mid-text \va like in USFM3.0, (i.e. just another character style), although a quick test shows it won't get the brackets (a bug that can be solved fairly easily with start and end hooks), so I guess that the message you're getting is from the parser that the user-interface is using. Perhaps Martin can comment on that...

To avoid that issue, you could define your own style (e.g. \zva, copied from \va), and make your changes file swap "\\va"  >  "\\zva" 

Comments

> that can be solved fairly easily with start and end hooks

I do have that, but...

> you could define your own style (e.g. \zva, copied from \va), and make your changes file swap "\\va"  >  "\\zva" 

The problem is that the parser you mentioned happens before changes.txt, so short of putting ‘\\zva’ in my text, I can’t seem to get past the parser to allow changes to make a change.

Is there anything that runs before the parser?

The other weird thing about it is that the parser doesn’t seem to be refreshing from the text. As an experiment, I actually changed the \va’s in the text to \vp’s to see if they would work and it’s still giving me the same error!?

while the text has \vp rather than \va

Is there anything that runs before the parser?

---

I wonder if adding appropriate sections to your changes.txt file would solve the problem:

This tells it to apply the changes in line 7-18 BEFORE it even gets to the parser. And anything after that happens later in the process.

When you hover over the options shown on the right Code Snippet buttons, a tooltip will tell you more about when the changes in each section are processed. (This little-known functionality has been around for a while, but only recently exposed via the buttons on the right).

---

Mark P, i see sample output in your image, but I don't see any changes code or any Code Snippet button.

---

Steve - there's an issue with images on this site... I have reported it, but nothing has been fixed yet. Notice that a new image pasted into a response "clobbers" images in earlier messages! :-(