Thank you for letting us know, but R&D does not process bug reports in this forum.

What you need to do is to open a support case (aka ticket) and provide a full Job Archive of your sample with the ticket.

If you're asking here to see of there is some kind of "workaround", then you haven't given enough details. Is there anything unusual about the text that is in the continued header row? Is it just straight text, or is there anything in it that itself is generated text?

Are you on the very latest release of XPP (9.4.1)?

Yes Kai, just like Jonathan said, your shortest route to a solution is to open up a ticket with SDL support and supply SDL engineering with a job archive of your problem job

I will open a ticket for that.

I am using XPP8.4 on Solaris.

This error still exists in XPP9.3 on Solaris.

The error is caused by the endline character "|--" appearing at the end of each line

If I add an empty line after the table head (i.e  "form"  for this case) and compose, the error will be gone.

Chung

Toppan Merrill

Yes, please open a ticket.

You still didn't answer the question as to what is "different" or "special" about your table header row and whether there is something in it that itself is generating text or what's different/unusual about your table coding or before/after your table. But that's why you need to open the ticket and submit the Job Archive.

Other customers do running table header rows all the time and do not have this problem. Even the XPP 9.3 release is getting pretty "ancient" now; very soon there will no longer be any patch support for that release (aka "retired").

The "|--" endline character you mention is not "causing" this problem. This character is a "break" line end and only signifies that the line has been ended without a space (between that word and the next one, such as when you end a line with a <qa> with no following space). The other possible types of line ends are a "space" line (which displays as just a "space") end and a "hyphen" line end (which displays as a "hyphen", but where the hyphen is generated by composition and not part of the data).

The tool use to import the text is the same as normal, the source text was provided from our client.

We are using classic, the import source is a text file converting from a word file.

I don't find anything unusual about the text in the continued header row.

This is a word file with the content with the error table:

Hello, 

A ticket has been opened with SDL support (Case No. 00582600). I've verified that this error exists using the delivered JOB_xybase2 and all delivered tabular macros.

Kind regards
Thomas

Hello -

There is nothing special about the header row other than it continues when it breaks across the page. 

I was able to replicate this issue using a delivered JOB and standard macros on XPP 9.4.1. The code attached to SDL support case No. 00582600 can be dropped directly below the last item in JOB_xybase2 to replicate the issue reported above. 

OK, seeing is believing.  

But I was convinced that there must be something "unusual" about the circumstances where this problem happens, because otherwise I would have expected a ton of tickets from customers (continued running table headers are, after all, very commonly used).

And especially since I went all the way back to the XPP 9.0.0 release to test the submitted sample and the problem still occurred, which meant it wasn't something that got "broken" along the way (at least not since then).

And there is something "unusual", or rather a combination of things making it unlikely for the problem to happen, but it's not something "obvious" that a user would be able to pick out.

I've now identified what the "scenario" is that's causing composition to do the wrong thing (and why this is not being seen "wholesale" by all customers).

1. The font setup has ligature replacements active.
2. There is only one word on the last line of the continued running header row.
3. The last word of the (to be a continued running header) table row is "form", which begins with 'f' which is the beginning of some of the RP (replacement spec) rules, so composition begins to process for a possible ligature replacement.
4. The maximum size of all the RP spec rule strings is greater than 4 characters, so the ligature replacement processing code buffers up characters past the full word "form" - and this is where things go wrong - it gets into the next line, which is no longer part of the running header row. Because of that the current logic then turns off that it is processing continued running header text and then the ligature buffer (which didn't match any RP rule) gets pushed back onto the input stack BUT is no longer marked as running header (i.e. generated) text. Then when that text gets re-processed again the "state" of that text is messed up.

I don't know if it's plausible as a workaround until a fix can be determined and a hotfix delivered (which might not take too long), but if you can (temporarily) turn off ligature replacements in the last cell of the "continued" row(s), or even the just the last word, then this problem will not happen.

To do that you would have to have a (or define a new) Font Variant spec FF/FV pair where the Lig/Accent Replace field is set to "none" and then set the FF and/or FV (e.g. with <ff> and/or <fv> macros) to that rule around the text in the last table row cell (or the last word of that last cell).

As "proof-of-concept" I tried that with the provided sample. The FF/FV being used was 0/1. I copied that rule in the Font Variant spec and changed the Font Variant field to 4 (an unused FV value for that Font Family) and the Lig/Accent Replace field to "none". Then back in the table (with fresh DIV contents), I changed that last word "form" to "<fv;4>form<fv;1>". When I composed, the problem did not occur.

Looks good -

I was able to test against JOB_xybase2 the issue no longer appears in the continued heading row when the table breaks to a second page. Steps taken (as Jon described above) in JOB_xybase2:

Open the FV spec and duplicate all font family 0 entries (I numbered the duplicate family "100")

In each rule for font family 100, change Lig/Accent Replace from 95 to none

Update the font used in the table to use font family 100 and compose

The last word in the last line of the continued header is now showing properly as generated:

Kai Chung Lew - let me know if this workaround addresses the issue in job you mentioned above. 

A hotfix is now available (being tested/verified by support first).

Anyone else that is worried about this situation can open a ticket with support and request a hotfix for CRQ-23097 (9.3.2 or 9.4.2 pre-patches only).