And here we go again, including the file.

On Wed, 23 May 2012, Wolfgang Schuster wrote:

Am 23.05.2012 um 15:41 schrieb Marco:

...

And here we go again, including the file.

You can replace

\the\dimexpr\framedparameter{…}

with

\frameddimension{…}

In my tests that was failing. IIRC, that was because rulethickness is equal to \linewidth, which is a \dimen register. To be usable in MP, we need \the\linewidth. Aditya

On Wed, 23 May 2012, Wolfgang Schuster wrote:

Am 23.05.2012 um 16:30 schrieb Aditya Mahajan:

...

On Wed, 23 May 2012, Wolfgang Schuster wrote:

...

Am 23.05.2012 um 15:41 schrieb Marco:

...

And here we go again, including the file.

You can replace

\the\dimexpr\framedparameter{…}

with

\frameddimension{…}

In my tests that was failing. IIRC, that was because rulethickness is equal to \linewidth, which is a \dimen register. To be usable in MP, we need \the\linewidth.

Do you have a minimal example because this is how \frameddimension is defined:

\def\frameddimension#1{\the\dimexpr\framedparameter{#1}\relax}

Sorry, I misread your comment (\frameparameter instread of \frameddimension). Of course, \frameddimension should work fine. Aditya

On 2012-05-23 Wolfgang Schuster wrote:

You can replace

[…]

BTW: Don’t you want different rules (toprulethicknes, bottomrulethickness etc.) for the “tight” frames?

It makes sense, yes. I added the code to the module. For my tables the code works just fine (I don't use all the features). However, a small test file fails miserably. The code in the current state has several issues. ∙ The tight frames need a top/bottom…rulethickness setting, otherwise it breaks the compilation. The values should be inherited from the global rulethickness value if the individual rulethicknesss are absent. ∙ Almost everything interferes with each other. See the topframes in the table or the colorfullocalb example. It it coloured, but should be black. I guess that's because they use the same global \framed name space. ∙ For the tight frames the rulethickness is not taken into account when placing the lines, which leads to strange offsets. See examples colorfultight and colorfultightb. These issues should be fixed before the module goes into the core. This does not mean that *you* have to fix these issues! For me the code works, but I guess for most other people the code will fail. I will check how to improve the code. If anyone has suggestions or fixes, please don't hesitate sharing them. Marco

Am 28.05.2012 um 16:40 schrieb Marco:

On 2012-05-23 Marco wrote:

I improved the code. There is no interference any more and no strange offsets. One thing is still unsolved:

The top/bottom/…rulethickness settings are not inherited from rulethickness (see the table example at the end). This breaks the compilation if only rulethickness is provided but not toprulethicknes and bottomrulethickness. I don't know how to fix that. That's not what users expect and is a bug.

Add these setups to the module (there is no need for the braces): \setupTABLE [ \c!left\c!rulethickness=\framedparameter\c!rulethickness, \c!left\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [ \c!right\c!rulethickness=\framedparameter\c!rulethickness, \c!right\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [ \c!top\c!rulethickness=\framedparameter\c!rulethickness, \c!top\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [\c!bottom\c!rulethickness=\framedparameter\c!rulethickness,\c!bottom\c!framecolor=\framedparameter\c!framecolor] Wolfgang

Am 28.05.2012 um 17:08 schrieb Aditya Mahajan:

On Mon, 28 May 2012, Wolfgang Schuster wrote:

...

Am 28.05.2012 um 16:40 schrieb Marco:

...

On 2012-05-23 Marco wrote:

I improved the code. There is no interference any more and no strange offsets. One thing is still unsolved:

The top/bottom/…rulethickness settings are not inherited from rulethickness (see the table example at the end). This breaks the compilation if only rulethickness is provided but not toprulethicknes and bottomrulethickness. I don't know how to fix that. That's not what users expect and is a bug.

Add these setups to the module (there is no need for the braces):

\setupTABLE [ \c!left\c!rulethickness=\framedparameter\c!rulethickness, \c!left\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [ \c!right\c!rulethickness=\framedparameter\c!rulethickness, \c!right\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [ \c!top\c!rulethickness=\framedparameter\c!rulethickness, \c!top\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [\c!bottom\c!rulethickness=\framedparameter\c!rulethickness,\c!bottom\c!framecolor=\framedparameter\c!framecolor]

I made some more changes at

https://github.com/adityam/context-fences-extra

I made also a few modifications on Marcos code, maybe a few of them should be moved to the core. It would be also a good idea to change the name of the module to meta-imp-frame.mkiv or something similar. Wolfgang

On 28-5-2012 18:09, Aditya Mahajan wrote:

On Mon, 28 May 2012, Wolfgang Schuster wrote:

...

I made also a few modifications on Marcos code, maybe a few of them should be moved to the core.

It would be also a good idea to change the name of the module to meta-imp-frame.mkiv or something similar.

In that case, we also need to change local and tight to \v!local and \v!tight (and define a variable for tight).

possible extension (less graphics): \unprotect \startMPinitializations boolean LocalFrameDone ; LocalFrameDone := false ; \stopMPinitializations \startuseMPgraphic {frame_local_top} if not LocalFrameDone : draw topboundary OverlayBox leftenlarged (LeftFrameLinewidth-.5*TopFrameLinewidth) rightenlarged (RightFrameLinewidth-.5*TopFrameLinewidth) shifted (0, .5*TopFrameLinewidth) withpen pensquare scaled (TopFrameLinewidth) withcolor TopFrameColor ; setbounds currentpicture to OverlayBox ; fi ; \stopuseMPgraphic \defineoverlay[localframe][\useMPgraphic{localframe}] \startuseMPgraphic{localframe} \includeMPgraphic{frame_\framedparameter\c!topframe _top} \includeMPgraphic{frame_\framedparameter\c!leftframe _left} \includeMPgraphic{frame_\framedparameter\c!rightframe _right} \includeMPgraphic{frame_\framedparameter\c!bottomframe _bottom} LocalFrameDone := true ; \stopuseMPgraphic \protect \starttext \framed [background=localframe, framecolor=blue, frame=off, leftframe=local, topframe=tight, leftframecolor=red] {test} \stoptext it could permit some analysis and connection of pieces of frame but in that case one will use a dedicated background anyway Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On 28-5-2012 18:01, Wolfgang Schuster wrote:

Am 28.05.2012 um 17:08 schrieb Aditya Mahajan:

...

On Mon, 28 May 2012, Wolfgang Schuster wrote:

...

Am 28.05.2012 um 16:40 schrieb Marco:

...

On 2012-05-23 Marco wrote:

I improved the code. There is no interference any more and no strange offsets. One thing is still unsolved:

The top/bottom/…rulethickness settings are not inherited from rulethickness (see the table example at the end). This breaks the compilation if only rulethickness is provided but not toprulethicknes and bottomrulethickness. I don't know how to fix that. That's not what users expect and is a bug.

Add these setups to the module (there is no need for the braces):

\setupTABLE [ \c!left\c!rulethickness=\framedparameter\c!rulethickness, \c!left\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [ \c!right\c!rulethickness=\framedparameter\c!rulethickness, \c!right\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [ \c!top\c!rulethickness=\framedparameter\c!rulethickness, \c!top\c!framecolor=\framedparameter\c!framecolor] \setupTABLE [\c!bottom\c!rulethickness=\framedparameter\c!rulethickness,\c!bottom\c!framecolor=\framedparameter\c!framecolor]

I made some more changes at

https://github.com/adityam/context-fences-extra

I made also a few modifications on Marcos code, maybe a few of them should be moved to the core.

It would be also a good idea to change the name of the module to meta-imp-frame.mkiv or something similar.

last week I was considering leftframeoffset (but decided to stick to som emp jugling) and wondered if lframeoffset made more sense then (as it matches the loffset keyword which we have in order not to clash with leftoffset elsewhere .. \framed is often used as helper) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------