fbox: add padding only to framed boxes generated by \fbox, \framebox

[xworld21]

Apply padding:3pt only to boxes generated by \fbox and \framebox, or more precisely the ones that respect \fboxsep. That includes a few other boxes I have found by grepping for framed.

This resolves issues like \textul, \underbar gaining padding that they should not have.

While I was there, I have added support for \fboxsep where it was missing in amsmath, color, xcolor. amsmath now also uses the current color as frame color.

[brucemiller]

Cool! I like where you're going with this. I think it would be better if integrated after the changes in #2798, however; there's at least additional properties (padding(left|right|top|bottom)) used to compute the size of the result. And I also wanted to include the effect of \fboxrule into the CSS, not only into the box size.

Rather than you including lots of boiler plate code, perhaps I should introduce a framedProperties helper that you could use. Basically it would do what's in latex_constructs.pool, \@framebox prroperties, getting parameters from \fboxsep,\fboxrule, font, maybe an %options arg to allow overriding them. Does that sound appealing? Any feature requests?

In fact, it's annoying to have all those 3pt, 1pt defaults in LaTeXML.css, and have these silly tests to try to avoid using cssstyle if the values are the same defaults. Even though that allows user css to easily override the defaults, it makes it harder to override the NON-defaults. I'm inclined to just put all of these values in cssstyle for now, and hope to come up with a grand scheme later (maybe css variables?) that works better. But that change would allow removing any spacing added by ltx_framed.

[xworld21]

there's at least additional properties (padding(left|right|top|bottom)) used to compute the size of the result

interesting

framedProperties sounds good. I suggest fboxProperties, or frameboxProperties though? @framed is being used for anything with a border, while \fboxsep et al. are fbox/framedbox specific. I haven't actually checked if all those commands respect \fboxrule as well, but I'd be surprised, plus you already mentioning adding an easy override mechanism... so DRY away.

[brucemiller]

I'd think that anything framed probably has some notion of sep or margin, but not necessarily \fboxsep; framed.sty uses eg. \FrameSep. I now think I should finish #2798 as it is and start a new draft PR that we can iterate on and work together to get all our cases working.

[brucemiller]

OBTW, #2829 is now finished, and should be a good basis for simplifying this one (and resolving the conflicts :> )

[xworld21]

We could drop \lst@@frame in favour for something like this, by the way, and avoid the LISTINGS_INLINE checks.

[brucemiller]

But \lst@@frame is called by listings in response to the frame keyval (I think), so we can't drop it (or I misunderstood your suggestion). But maybe \lst@@@set@frame should call framedProperties with LST@framesep and store all of the frame/sep/color stuff? Then you could avoid the `LISTINGS_INLINE test, if only the block version uses those properties. (but don't you need to add the framed, framecolor attributes?)

Either way, shouldn't the block you added above only happen when a frame has been selected?

[xworld21]

But \lst@@frame is called by listings in response to the frame keyval (I think), so we can't drop it (or I misunderstood your suggestion)

I meant to say, if we do not define \lst@@frame, the value will be saved in \LST@frame, and we can access it from the constructor in the same way as for framesep here.

Either way, shouldn't the block you added above only happen when a frame has been selected?

Yeah, I decided to apply the padding regardless, so that if you create two listings with and without frame, they remain aligned to the pixel ugh, no, if you use border-box for box sizing, adding the frame will squeeze the content a little!

The context is that in PDF, the listings content is always \textwidth wide with or without frame, because frame and padding are drawn outside, spilling into the margins. So listings with and without frames are aligned with each other. In HTML... well, I just realised that the frame itself will shift and shrink the listing, so the alignment is lost anyway even if we apply the padding unconditionally. What was I thinking.

Let me update the PR with both changes (i.e. implement the frame without \lst@@frame so it all gets easier to understand).

[xworld21]

I folded \lst@@frame inside afterDigest, and used framedProperties. I have added support for the 'tlbr' frame specifiers. I couldn't get rid of LISTINGS_INLINE because it's used by \lst@@backgroundcolor which has a mergeFont, so probably not something that can be moved to afterDigest.

[brucemiller]

This looks good; Thanks!

[brucemiller]

But \lst@@frame is called by listings in response to the frame keyval (I think), so we can't drop it (or I misunderstood your suggestion). But maybe \lst@@@set@frame should call framedProperties with LST@framesep and store all of the frame/sep/color stuff? Then you could avoid the `LISTINGS_INLINE test, if only the block version uses those properties. (but don't you need to add the framed, framecolor attributes?)

Either way, shouldn't the block you added above only happen when a frame has been selected?

[xworld21]

The only thing that makes me slightly nervous now is that the color is resolved in afterDigest. As far as I can tell, by this point, the color is reset to whatever it was at the start of the listing, so it gets the correct value (I checked!).