-
Notifications
You must be signed in to change notification settings - Fork 308
KaTeX (3/n): Support negative margins for spans #1559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@rajveermalviya Copying here for visibility what you told me on our call today: the reason this is a draft (not ready to merge) is that you're still working on the widget test. Apart from that, you consider it ready to review. |
c33f5c2
to
6cfcc0d
Compare
This will prevent string interpolation being evaluated during release build. Especially useful in later commit where it becomes more expensive.
This applies the correct font scaling if the KaTeX content is inside a header.
And rename previous type to KatexSpanNode, also while making it a subtype of KatexNode.
In KaTeX HTML it is used to set the baseline of the content in a span, so handle it separately here.
And inline the behaviour for `inline: false` in MathBlock widget.
6cfcc0d
to
843207d
Compare
Implement handling most common types of `vlist` spans.
Negative margin spans on web render to the offset being applied to the specific span and all the adjacent spans, so mimic the same behaviour here.
843207d
to
d1f5d5c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Here's small comments from a partial skim.
// Like [RenderPadding] but supports negative values. | ||
class RenderNegativePadding extends RenderShiftedBox { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave a TODO tracking our intention to get a version of this upstream:
// Like [RenderPadding] but supports negative values. | |
class RenderNegativePadding extends RenderShiftedBox { | |
// Like [RenderPadding] but supports negative values. | |
// TODO(upstream): give Padding an option to accept negative padding (at cost of hit-testing not working) | |
class RenderNegativePadding extends RenderShiftedBox { |
extension on EdgeInsetsGeometry { | ||
bool get isNegative => !isNonNegative; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is clearer (and hardly much longer) if just inlined.
In particular there's some ambiguity in that "is negative" sounds like it might require all the sides to be negative. So being more transparent, with one fewer layer of indirection, helps mitigate that.
Stacked on top of #1452.
Related: #46