Post Comments With API, But Keep Text Formatting


We are currently having an issue where we are uploading items to SG via an internal tool, but when we are populating the Description column it has been stripping the text formatting. I also tried updating an item on SG directly with the SG API and it is still stripping the formatting. We were having issues with non-ascii items on our farm but that has been resolved, so I wonder if this is the case here as well under the hood.

For example, this comment:

-Here is a comment
    -And a sub-comment*

Will be posted as:
-Here is a comment -And a sub-comment

Is there something we are missing for us to have it keep the formatting when we upload/update SG items? In the past when debugging this it was working when we would type in directly using the site or copy/paste formatting. However, now this is not the case and it will strip formatting. So we know in some way it was supported, at least on the front end.

Thank you!

1 Like


In order to keep the formatting you’d need to use escape codes.
For your example you’d need to supply this string to your update function

-Here is a comment\n\t-And a sub-comment*

Resulting in the following being displayed on Shotgrid


Escape code cheatsheet
\n - New line
\t - Tab
\' - Single Quote
\" - Double Quote

1 Like

Aha, I believe that is what was missing. Users are not inputting these (as expected) and the tool is not capturing these escape codes it seems, so this is most likely the solution.
I will give this a shot, thanks!


I gave this a shot and ensured that the text had escape characters and it still did not keep the formatting when it creates the version on SG.

I changed my QTextEdit to use a QTextDocument object with the QTextOption ShowTabsAndSpaces applied (which did have formatting in it), which captured all the desired characters. Even the description is formatted correctly on the farm; we copy the comment in this case for easier tracking.

I am not sure what process is stripping the characters when posting with the SG API…I also checked the toPlainText() call that QLineEdit has and that is also not the issue, as it grabbed the string as seen on the farm (screenshots below).

I added screenshots below to show what I mean, let me know if you need more information to try and debug this!



On SG after processing (incorrect formatting)

All steps before processing, with correct formatting intact:

In Tool

Arg on Farm (NDA imformation removed)

Farm Job Comment

Hi, I just wanted to bump this thread, we have been trying for a while now to get around this but to no avail. Is there any suggestions as to how to proceed?

Hello @khopkin ,
I just tried the following script:

import pprint # Useful for debugging
import shotgun_api3


sg = shotgun_api3.Shotgun(SERVER_PATH, SCRIPT_NAME, SCRIPT_KEY)

entity_type = "Note"
data = {"project": {"type": "Project", "id": 254},"content" : u'hahaha\nhehehe', "user" : None}

test = sg.create(entity_type, data)


Which returned me:

{'content': 'hahaha\nhehehe',
 'id': 6657,
 'project': {'id': 254, 'name': 'SG-21292-test2', 'type': 'Project'},
 'type': 'Note',
 'user': None}

And looked like that in SG:

I believe it is not the same Entity/Field that you are creating, but I believe the behavior to be the same… Maybe during the process something the string is altered…?

Interesting, then yes it looks like it may be something on our end then, thank you for double checking!
We do have wrapper classes we use for our publishes to SG, but did not see much in the was of escape character stripping. At least now it is confirmed that it is not the SG upload api for certain.

Also, here are the entity ids and type for a test, though I am not sure if you will have access to it or not:
sg_id: 255118
sg_type: Version/Shot

Hello @khopkin ,
I can have access to that, I just miss your site name…

I will see if I can get this info to you through the Autodesk help slack channel, as I don’t want to post that to the open internet

I can confirm that the database does not contain the new line char so the issue should be in the string processing before sending it to Shotgrid.

Got it, so it’s something for sure on our end that’s stripping this
Thanks for looking into this! If I find the solution I will update the post

It looks like our internal submission tool was causing the issue, it was designed with another show in mind a few years back and was doing some extra formatting and stripping deep in the code.
Thank you for your help!

1 Like