Hi!

I am currently evaluating Prince for use in a number of server based COBOL environments (don't worry about that though as I have plans on how to glue everything together). I am currently using Prince to test our standard document layouts, so that I can import the templates I design into our software as formatted XML/HTML/CSS pages.

When writing the template though, I am having huge problems getting the CSS column-span property to recognise its upper border. It appears to be a bug which is why I am posting here.

Basically on a column-span: 4; (though it happens with other span lengths but this is my example ), the upper border of that column, past the first span vanishes ... i.e

-------------------------------------------------
| | | etc
----------------- -----------
| |
-------------------------------------

Is this an intended feature? or incorrect interpretation of the span?

I have looked at the documentation and done my best to replicate it, but no matter what I try I end up with the same result.

Please help!

Looks like the BB code doesnt like spaces so I will illustrate another way ...
= lines
- spaces

========================

=======--------------=========
///////////////////////////
===============


//////////// is the span element

Hi,

It seems that you have indeed found a bug affecting column-span in tables with collapsing borders.

We will include a fix for this bug in the next maintenance release of Prince 5.0, due to be released in the near future.

Thank you for reporting the issue!

Michael

For the record, this bug has been fixed in Prince 5.0 rev 4.

Thanks again for reporting the issue!

Michael

Hi Mike,

Wow! Very fast bug fix, you can count me impressed!!! Hopefully Prince will fit into my plans. Second to none customer service there (and I'm only on an evaluation hehe)

Have just tested out the new release.

It appears to have the same but not consistent problem.
2 Column colspans work, then don't on the second iteration, then work fine again. I am guessing there is some problem with parsing a loop in your code.

4 Column colspans (consistently) fail to work after the first row.

Thanks for trying out the new release.

We will need to do some further investigation of the colspan issue. It seems to affect the table cell borders in very specific circumstances, when cells overlap in particular ways. (If you could send us any sample files that are affected by the issue it might help us to nail down the problem).

We should have a suitable fix ready for the next release of Prince.

Best regards,

Michael

We have reviewed and rewritten the handling of colspan/rowspan and table border collapsing in Prince, which has solved the issue that you reported and also improved the conformance to the CSS 2.1 specification.

Please try the new maintenance release of Prince 5.0 rev 5 which is now available to download.

Thanks!

Hi Mike and Xuehong!

Thanks for the update ... however, I have a new one on the colspan issue for you :0(

The draw method for the pdf (and hence a printout) isnt completely straight.
On a multi column spanned row (4 in this case) the PDF output changes co-ordinates on the 2nd and 3rd columns, dropping by what looks like 1px. Giving a
---______---
effect. Its nitpicking I know but unfortunatley presentation is everything these days, am sure its a minor co-ordinate bugfix for you though.

Cheers
Stuart

I have examined the PDF output more closely (that zoom tool is magic!) and I am wrong ... its not that the stepping is out ... its the line thickness on columns 2 and 3.

Its actually 1px thicker, which looks as though its stepped and lower when zoomed out and antialiased in Acrobat Reader. In effect its a

---======---

problem not as I previously stated ... doh!

Sorry for the confusion there.

Stuart

Hi Stuart,

If you zoom in to the maximum level in Acrobat Reader, or examine the underlying PDF instructions, you will see that all of the lines actually have consistent thickness.

The apparent difference in thickness when previewing the file in Acrobat Reader at some zoom levels is caused by a quirk in the way Acrobat Reader displays rectangles created using the "rectangle" instruction compared to rectangles of the same size created using four line segments. There should be no difference in the printed output.

Nevertheless, to avoid this unfortunate situation we may just switch to using a single method for drawing all line segments so that the appearance looks consistent in Acrobat Reader. (This will be marginally less efficient and make the PDF file size slightly larger, but it is probably a small price to pay to improve the preview quality).

UPDATE: A quick correction, the visual difference in line thickness when previewing the file in Acrobat Reader seems to be caused by the "Automatic Stroke Adjustment" in Acrobat Reader 6.0 and 7.0 and is not affected by the manner in which the lines are drawn. While the issue should not affect print output, we will still look for a suitable workaround to improve the appearance when previewing the PDF file on the screen.

Best regards,

Michael

Prince 5.1 includes a new implementation of collapsing table border rendering which should produce results that look much more consistent when viewed with Acrobat Reader.

Please give it a try and let us know how it goes

Hello Mike,

Just tried it (having come back from my very sunny hols) ... huzzah it works as promised.

I will now try to make some more complicated forms and see if I can break it for you again hehehe

Top class customer support

Cheer

Stuart