LaTeX problem: Changebar package failures

[Former user]

Originally reported on Google Code with ID 98

I'm starting to encounter some strange LaTeX failures in working copies of the language
spec that exceed about 20 annotated changes. It doesn't seem to matter where those
changes appear or their content, and it appears somewhat sensitive to unrelated changes
in headers like upc-specification-issues.tex. It sometimes manifests as a failure for
latex to converge, but more frequently as an inscrutable error message on the second
or third pass.

The most common error is:

! Argument of \cb@pdfparsexy has an extra }.
<inserted text> 
                \par 
l.88 ...shared [nbytes] char[nblocks * nbytes].^^M

Based on this error and the apparent triggering causes I suspect we may be encountering
some scalability limit on the changebar package, but that's just a guess.

I did note this in the "known bugs" for the package:

There is a limit of (\cb@maxpoint􀀀\cb@minpoint+1)=4 bars per page (four
special points per bar). Using more than this number yields unpredictable
results (but that could be called a feature for a page with so many bars).
This limitation could be increased if desired. There is no such limit with
PDFTEX.

I'm not sure how to check if that's what I'm encountering.

This doesn't affect the current document in SVN, but will once I start committing PendingApproval
changes. Any Latex expert opinions?

Reported by danbonachea on 2012-10-16 17:09:53

[Former user]

Perhaps try nulling out the \upcspecissue command (or just have it say "Issue #1" and
see if that helps.

Also, if you could attach a diff file with a set of changes that triggers the failure,
I can see if it replicates here.

Reported by gary.funck on 2012-10-16 20:20:31

[Former user]

I've made a branch with the changes in the lang directory that demonstrates the problem:

https://upc-specification.googlecode.com/svn/branches/issue98

I've replicated it on two very different machines, so I'm relatively certain it's not
something broken about my specific LaTeX install.

Reported by danbonachea on 2012-10-16 21:28:20

[Former user]

I checked out the issue98 branch and it fails with my set up as well.
It failed to converge, with this message in the log.

Package Changebar Warning: Changebar info has changed.
(Changebar)                Rerun to get the bars right on input line 43.

Reported by gary.funck on 2012-10-17 01:26:41

[Former user]

I've confirmed this problem is being caused by the changebar package, and that this
problem will most likely affect the draft we are trying to produce for SC. This makes
it a top priority to be addressed this week if possible.

At this point the only fully reliable solution I have is to completely disable changebars.
They are somewhat redundant with the changes package, so that might not be terrible.

I believe the problem is being created/exacerbated by the fact the changebar package
insists on putting bars on not only the wrapped body text but also embedded footnotetext
- which is completely irrelevant to our document because it's putting change bars on
the change annotation footnotes inserted by the changes package (which are already
colored and clearly marked as a change annotation). This effectively doubles the number
of changebars being rendered per page and causes it to blow up. I've prototyped some
latex hacks to suppress the change bars on the footnotes that fix this particular problem,
but also create other unrelated anomalies that make it an unacceptable solution (breaks
footnote numbering and hyperref). If someone with greater tex-pertise has cycles to
look at this they might be able to design a better hack which allows us to keep our
changebars, otherwise I think they will have to go.

Reported by danbonachea on 2012-10-30 03:33:29

[Former user]

Reported by danbonachea on 2012-10-30 05:37:17 - Labels added: Milestone-Spec-1.3

[Former user]

SVN r182: commit a locally-modified version of changebar.sty 
that disables changebars in footnotes. This fixes the spec build
problems, at least for now.

Marking this issue as "Done" for now, although it's entirely possible we'll encounter
it again later after more changes are inserted.

Reported by danbonachea on 2012-10-31 20:54:26 - Status changed: Done