Support RTF Paste #134
Replies: 1 comment
-
RTF paste is now supported about as well as it's going to get. I ended up just using the Foundation-supported RTF-to-AttributedString and AttributedString-to-HTML mechanism:
This does a proper translation of lists, tables, and links, which is good. What it doesn't do is capture the H1, H2, etc. Everything ends up as a P element. What I call "format elements" in the MarkupEditor - bold, italic, etc - are dropped. Images are dropped. Why is this? To understand, look at what the HTML that emerges looks like:
(I also added an HTML paste test that uses this HTML as input.) The bolding, as an example, is accomplished using CSS styling, not by identifying a Here's what my "Rosetta Stone" test looks like in the Notes app on the Mac: When everything is selected and pasted into the MarkupEditor, it looks like this: @JohnKuan You might be interested in this discussion relative to #128 |
Beta Was this translation helpful? Give feedback.
-
In working on #128, I noticed that none of the nice formatting in the Notes app gets pasted into the MarkupEditor. This is because the Notes app doesn't populate the pasteboard with HTML, so the MarkupEditor paste mechanism just pastes the text it can get from the pasteboard. Looking at it more closely, Notes does populate public.rtf, so Rich Text Format (RTF) content is available.
It seems like to me it would not be hard to go from RTF-to-AnnotatedString and from AnnotatedString-to-HTML in Swift. I don't see any readily available RTF-to-HTML converters, which may be an indication that it's not simple once you start to deal with all the detailed differences between RTF vs HTML. It's probably at least as filled with edge cases as Markdown-to-HTML and HTML-to-Markdown, which is no picnic.
Anyway, a simple version of this would just involve adding RTF as a supported type for pasting in
PastableType
and then invoking the conversion from RTF to HTML in MarkupWKWebView.paste(_:). The sanitizing/cleanup of the resulting HTML would be handled automatically on the JavaScript side. The fidelity of the results will depend on how much the AnnotatedString-to-HTML conversion depends on <style> tags to preserve appearance, as opposed to direct use of <p>, <h1>, etc. The sanitizing/cleanup on the JavaScript side will just strip out all the styling. Also, per the discussion in #120, checkboxes, which are supported natively in Notes and apparently in RTF, won't come across. Right now, they come across as text, which perhaps unsurprisingly, looks a lot like Markdown (-[ ] Item).If this feature is of interest, someone could do the "simple" version I outlined above and report results. Does it work? What happens with the different text sizes in Notes vs the standard HTML and MarkupEditor <p>, <h1>, etc? How bad or non-existent do checkboxes come out? What about tables and images? Basically, some effort into scoping the problem would be helpful. I'm not planning on putting effort in this area, but if the scoping shows that it could be useful and bounded, I would probably jump it up in my priority list.
Beta Was this translation helpful? Give feedback.
All reactions