The setdash operator is limited to 11 arguments in the array operand. This is documented as a 'typical' limit for level 1 interpreters, I can't find any limits (other than the size of an array of course) for level 2 PostScript, or for PDF. I discovered this while working on PXL which has a limit of 20 elements, but I did find another way round the problem there. However the fact remains that we do have a low limit on our setdash. Creating this bug and assigning to Robin at Henry's suggestion. This can't be a common case or we would have found it before. The affected areas of the code can be found (I believe) by doing a grep for 'max_dash'. This appears to include the PostScript interpreter, the clist, and the high level vector device, as well as pdfwrite.
Passing to Ken.
My mistake, assigning back to Robin. I thought that all that was needed was to remove the PostScript code which throws a limitcheck on arrays > 11 elements but in fact the clist writer and pdfwrite have a fixed float array (of size 11) which they use to store the current dash pattern. These need to be altered to dynamic arrays (or something even more cunning). Note that there appears to be no documented limit on the size of a dash array now, and I believe that GS no longer limits arrays to 64k entries...... When the C code is altered, it will also be necessary to edit gs_init.ps and remove the line in the definition of /setdash: 1 .argindex length 11 gt { /setdash .systemvar /limitcheck signalerror } if
*** Bug 694310 has been marked as a duplicate of this bug. ***
Commit 94c5ecffe4bf66cc91108d99a802c7c2d3b86e0b fixes this for me.