FEP-dc88: Formatting Mathematics #642
No reviewers
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#642
Loading…
Reference in a new issue
No description provided.
Delete branch "pounce/akkoma:formatting-mathematics"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
See #641
We're so back
this is how it looks in akko-fe
and how it is supposed to look, in mastodon-fe:
Good news, the Vue bug appears to have been fixed a few week s ago: vuejs/core@d42b6ba3 and this fix is part of release 3.4.0+
I wonder, is the front-end the only thing blocking this? As I understand, it does work with other front-ends like masto-fe, so I wonder if we should really wait until front-end is fixed. People generally install Akkoma-fe, but as I understand the idea is that Akkoma doesn't force/push one specific front-end.
Btw, re
I’m not too familiar with Elixir’s macro stuff, but some examples I’ve seen seem to suggest using regular
for
is at least sometimes capable of looping over macros and the below at least compiles (with math enabled) fine for me. Is there going something wrong during runtime later? (might want to add some basic tests)Yes agree. I'll rebase this soon to get it ready to merge
so this doesn't work, but it turns out if you
unquote(tag)
then it does. thanks for pointing me in the right direction!1b838627df
tobfde898225
bfde898225
to1cf33a318d
WIP: FEP-dc88: Formatting Mathematicsto FEP-dc88: Formatting Mathematicsok my bad i forgor about this pr
but now it's ready to merge
Thanks!
Is there a post to test with which neither requires auth-fetch (like https://types.pl/@pounce/111105464618076520) nor is MFM (like https://genau.qwertqwefsday.eu/notes/9k1517t772; since MFM posts get reparsed from source atm and we don't parse LaTeX input in MFM (yet))?
Creating a local HTML post with content copied from a FoundKey example confirms the backend part works fine, but there are still some catches wrt to frontend.
(side note: i’m surprised HTML posts are still supported; i thought they were intended to be dropped over a year ago)
Example HTML
me being confused while things actually work fine
Taken as is only the annotation shows up in Firefox and no math at all in Chromium:
Moving
</semantics>
to only enclose the annotation leads to the intended displa in chromium, but both annotations and the intended MathML showing up in Firefox, but FoundKey really seems to enclose everything in<semantics>
, check e.g. the post above. Is this a FoundKey bug?EDIT: but also the above example post linked above seems to work fine. It turns out Firefox or MathML in general is sensitive to whether annotation comes before or after math. If it’s placed at the end of but still inside
<semantics>
, after all the actual MathML everything works as expectedReal FoundKey posts also place it at the end so there’s nothing wrong here
I upgraded all vue related packages in the frontend
and assume we’ll wan’t to add CSS to explicitly hide annotations.Are there any other frontend changes you’d suggest?indeed, this stuff is usually supposed to be autogenerated. I use something like https://temml.org/ most of the time with 'annotate' checked on. In this case the annotation(s) should go at the end.
The current vue package ref in the frontend already works for this (we just need 3.4). but cutting a new release would probably be good. I think the frontend is mostly equipped to handle these changes, but everything will look like crap if an incomming post with math is scrubbed (e.g. if
:allow_math
is false) either way. I was thinking about implementing the other half of the fep (correct scrubbing) in another PR, but i can also do it here if need-be.not sure if
:allow_math
should be default or not tbhwe need better scrubbing if it's off
Personally i’d even prefer math to be enabled by default (after all we want to improve the reliability of math federation), but it’s ofc up to floati
re better scrubbing: this prob needs changes in the scrubber library. It currently has the option to handle scrubbing of
style
fields with a custom function (which we don't use atm). Something similar would need to be added for math nodes, so we can e.g. replace the whole math env with its annotation content if present and fallback to something else (current behaviour?) for annotation-less nodesView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.