Re: [NTG-context] [dev-context] bTABLE in header and document give unexpected behavior
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 10.06.2012 um 12:19 schrieb Sido Jensma:
This is the first time I am posting here. I am not really sure what a typical bug report should look like.
I had posted a question on stack-exchange and it was suggested to post a bug report here. I’m not sure if this is a bug, but it was unexpected behavior to me.
The original question was posted here: http://tex.stackexchange.com/questions/59134/strange-problem-with-frames-con...
And a ‘not-so-minimal’ example of what is happening is attached (see the last page).
I have tested this with extreme tables and don’t get the same behavior.
When you use a table environment which is broken across pages together with the same environment in header settings can sometimes mix. In your case it’s best to use \framed in the header which does the same and is also faster but even then one problem remains. By default \framed uses \linewidth for “rulethickness” and natural tables assign a different value to this length, this results in wrong rules in the header when you don’t change the value (see example below). Here is a better version for the header of your document. \startsetups[header] \setupframed[width=0.2\textwidth,height=\headerheight,align=middle,offset=2mm,rulethickness=0.4pt] \dontleavehmode \startframed Rev \stopframed \startframed[width=0.6\textwidth,foregroundstyle=\ssbfa] \getvariable{document}{projectname}\\ \getvariable{document}{documenttitle} \stopframed \startframed some text \stopframed \stopsetups BTW: Please use next time the normal mailing list for such problems and not the developer list. Wolfgang
![](https://secure.gravatar.com/avatar/1930c667fbd3884fd581e95eb4d5b15c.jpg?s=120&d=mm&r=g)
Sido wrote:
I had posted a question on stack-exchange and it was suggested to post a bug report here. I’m not sure if this is a bug, but it was unexpected behavior to me.
Wolfgang wrote:
BTW: Please use next time the normal mailing list for such problems and not the developer list.
That was my mistake: I thought it was a bug, and so I advised him to post to dev-context instead of ntg-context. Just to check: is dev-context@ntg.nl also for bug reports, or is it exclusively for development discussions and should (probable) bugs also go on ntg-context@ntg.nl? --Sietse
participants (2)
-
Sietse Brouwer
-
Wolfgang Schuster