Good catch, and thank you for the precise report —
both numbers are correct. We are pointing at two different things, and it is on purpose. Let me explain it plainly, because it is not obvious from the output.
Your file has:
163: <guide>
164: </guide>
epubcheck says 164:9. That is the character right after </guide>.
epubveri says 163:1. That is the <guide> itself.
Why epubcheck lands there: it reads the file from top to bottom, one tag at a time, and reports the spot it had reached when the problem became apparent. A
"this element is missing something inside it" problem cannot become apparent until the closing tag arrives — until then, the missing thing might still be coming. So it reports at
</guide>, because that is where it found out.
Why we land where we do: we load the whole file first, so we can point at the element that is actually wrong rather than at the moment of discovery. To fix an empty <guide> you go to the <guide>. That is the line we give you.
If you want the evidence that epubcheck's position is a side effect of how it reads rather than a deliberate choice, it uses three different anchors for three kinds of problem. I measured each one on its own small book:
- element X not allowed → just after X's opening tag
- element X incomplete → just after X's closing tag (your case)
- a bad attribute → just after the > of the opening tag, which points at neither the element nor the attribute it is complaining about
All three are simply "wherever the cursor was". The same thing explains something else you may have noticed: when epubcheck rejects an element it repeats that same message once for every child inside it. On one real book here, 80 <article> elements produced 1887 messages.
There is a practical reason too.
epubsana, the repair tool, uses these positions to go and fix the fault. Given the closing tag it would have to search backwards, and with nested elements it could not reliably tell which opening tag the position belonged to.
So I am going to leave this one as it is — not because matching would be hard (it is about two lines of code) but because I think the start of the problem is the more useful place to be sent. If that ever gets in your way in practice rather than in a diff, tell me and I will look again.