Help

Re: Formatting is broken when retrieving a rich text enabled long text field through the API

Solved
Jump to Solution
1704 1
cancel
Showing results for 
Search instead for 
Did you mean: 
Mutsuda
5 - Automation Enthusiast
5 - Automation Enthusiast

When I retrieve the content of a rich text enabled long text field through the API, only “bold” formatting works. Strikethrough and Italic are retrieved with a whitespace before the markdown symbol and therefore are not parsed correctly.

Example:
Screenshot 2020-04-28 at 11.13.06

Is retrieved like this:
Screenshot 2020-04-28 at 11.11.11

You can see how 50 años posteriores shows up as _ 50 años posteriores_ instead of underscore50 años posterioresunderscore without spaces between the underscores and the thing I want to make italic.

Has anyone experienced this? Is there a way to fix it?

1 Solution

Accepted Solutions
kuovonne
18 - Pluto
18 - Pluto

I suspect that you are seeing a space between the underscore and the other characters that are italic because when the text was originally placed in italics, the space was also included as part of the italicized text. You don’t see the space as italicized because a space in italics looks exactly like a normal space.

I have tried formatting rich text as italic, bold, strike-through, etc., (both including and excluding surrounding spaces), and the Markdown source returned by the Scripting API exactly matches what I entered. Even though you are using the Standard API instead of the Scripting API, both APIs should return the same values.

See Solution in Thread

6 Replies 6
kuovonne
18 - Pluto
18 - Pluto

I suspect that you are seeing a space between the underscore and the other characters that are italic because when the text was originally placed in italics, the space was also included as part of the italicized text. You don’t see the space as italicized because a space in italics looks exactly like a normal space.

I have tried formatting rich text as italic, bold, strike-through, etc., (both including and excluding surrounding spaces), and the Markdown source returned by the Scripting API exactly matches what I entered. Even though you are using the Standard API instead of the Scripting API, both APIs should return the same values.

Mutsuda
5 - Automation Enthusiast
5 - Automation Enthusiast

This makes total sense, I checked and that’s what I think is going on there, but is this how Airtable should interpret it?

_ITALIC _ and ITALIC

Both should never be italic, so I think Airtable’s interpreter should remove leading and trailing whitespaces before placing the formatting symbols… right?

But if I go to my Rich text field and do this:
italic

I get this:
Screenshot 2020-04-30 at 00.38.22

Anyway, thanks for your help! :slightly_smiling_face:

Can you give an example of a different text editor that automatically removes leading and trailing whitespace when applying text formatting as you suggest?

Mutsuda
5 - Automation Enthusiast
5 - Automation Enthusiast

Stackedit for example won’t let you format a trailing whitespace.
italic

Also this html to markdown editor:
Untitled-1

I guess the Standard API is not returning what it should.

Thank you for the examples. Those examples seem to follow John Gruber markdown, which does not allow a trailing space between a word and a closing * or _.

But if you surround an * or _ with spaces, it’ll be treated as a literal asterisk or underscore.

Airtable uses a different version of Markdown. According to this support article

Rich text in Airtable is based on on a variation of Markdown

Emphasis/bold is mine.

Hopefully Airtable will eventually support more Markdown features, including this change. However, it might be difficult for Airtable to implement this particular change without breaking existing rich text fields.

Mutsuda
5 - Automation Enthusiast
5 - Automation Enthusiast

Hopefully Airtable will eventually support more Markdown features, including this change.

I’ll be looking forward to that :slightly_smiling_face:

Thanks again for your time!