verse.sty incompatibility

[YellowJacketLinux]

This may already be known, but when I use testphase=phase-III I get the following error:

[...]
Patching \page@sofar for tagging
(/opt/texlive/2023/texmf-dist/tex/latex/hyphenat/hyphenat.sty)
(/opt/texlive/2023/texmf-dist/tex/latex/verse/verse.sty
! LaTeX Error: Command \theHpoemline already defined.
               Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.34 ...ne}{\arabic{verse@envctr}.\arabic{poemline}}

However testphase=phase-II works fine.

I am loading verse.sty which is probably why.

I'm guessing it's verse.sty that actually needs to be fixed, but thought I'd mention the incompatibility here.

[YellowJacketLinux]

It looks like verse.sty was last updated in 2014, one of the maintainers is inactive, I'll try to contact the other. Maybe I'll need to find a different way to typeset my verses, I do know this tagging implementation is still very development. I'm not too worried about it.

[u-fischer]

Hm. Yes the new code directly also defines a \theH<counter> if \newcounter is used and this clashes with the \newcommand\theHpoemline in the sty. One could change this code to delay the setup and so avoid the error, but the package also errors if it is loaded after hyperref (which redefines \newcounter) in a similar way and imho such loading order dependencies should be removed. So it would be better if the verse package replaced

\newcommand*{\theHpoemline}{\arabic{verse@envctr}.\arabic{poemline}}

by

\providecommand{\theHpoemline}{}
\renewcommand*{\theHpoemline}{\arabic{verse@envctr}.\arabic{poemline}}

Apart from this the tagging doesn't look bad. There is place for improvement to get a better semantic, but one gets at least a more or less sensible list structure.

[YellowJacketLinux]

Hi, sorry it took a few days for me to confirm that suggestion worked.

With that change, the noted bug is fixed but with test-phase=phase-III (where the verse gets tagged) the \\! exclamation mark that marks the end of a stanza gets typeset on a newline.

Minimal example:

\DocumentMetadata{
 uncompress,
 pdfversion=1.7,
 lang=en-US,
 testphase=phase-III
}
\documentclass{article}
\usepackage{fontspec}
\setromanfont{TeX Gyre Termes}
\usepackage{verse}
\begin{document}
\begin{verse}
I took a walk down the street.\\
\hspace{1em}One house was numbered `64k'\\
\hspace{1em}One house was numbered `128k'\\
\hspace{1em}One house was numbered `256k'\\
\hspace{1em}One house was numbered `512k'\\
\hspace{1em}One house was numbered `1M'\\!
It was a trip down memory lane\ldots{}
\end{verse}
\end{document}

There's supposed to be a blank line before the punch-line but because the tagging seems to interfere with the package, the blank line is gone and the exclamation make gets typeset before the punch-line.

[u-fischer]

please do not extend issues. It is difficult to track that correctly. Also issues about the tagging project should go to https://github.com/latex3/tagging-project. pdfresources is only about the PDF management.

[wspr]

@u-fischer — I have sent an update to CTAN with your suggested fix... fingers are rusty but the build.lua file worked a treat!!

[FrankMittelbach]

There's supposed to be a blank line before the punch-line but because the tagging seems to interfere with the package, the blank line is gone and the exclamation make gets typeset before the punch-line.

thought I had already made a remark on this, but I can't find it. Anyway, the issue is that the definition for the verse environment is overwritten at begin document by the tagging code. the simplest solution is therefore to repeat it afterwards. However, doing that showed an error in the block tagging code which needs fixing first. So bottom line this will get corrected (with some firstaid for verse) during the next days and from there will make it into the next -dev release.