shortcut groups formatting causing problems

Hello,

You recently added a feature to shortcut groups that allows one to format the names of shortcut groups with italics, superscript, subscript, etc. Unfortunately, the change is causing me terrible headaches. The problem, I think, is that you chose to use the escape sequence \n to terminate formatting in a string; for example, to write ^tBu, one would use \i\St\n Bu.

The problem is that \n escape sequence. We use Javascript to acquire a structure from MarvinSketch, use AJAX to send it to the JChem code at the server, extract the structure (as it may have been modified by the JChem code) from the text file returned by AJAX, and then put the structure back into the MarvinSketch applet with a Javascript method. At some point during this process, the \n gets converted to a return character, causing all sorts of havoc. I've tried several ways to distinguish the \n of the escape sequence from the \n return character, but so far, I've had no luck. I'm about ready to throw up my hands and remove all formatting from shortcut groups, but before I do, I was hoping you might have some insight into what I could do to avoid this problem. Can you replace the \n sequence with something else, like \N?

-- Bob

Well, I managed to develop an ugly kludge to work around the problem: replacing the \n escape sequence with \N before printing the MRV to the page returned by AJAX, extracting the MRV into a Javascript variable, then replacing the \N with \n.

I found another problem, too, which I was also able to work around, but I thought it should be documented here. Consider this MRV:

<?xml version="1.0" encoding="UTF-8"?>

<cml xmlns="http://www.chemaxon.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.chemaxon.com/marvin/schema/mrvSchema_14_12_01.xsd" version="ChemAxon file format v14.12.01, generated by v15.4.27.0">

<MDocument>

  <MChemicalStruct>

    <molecule molID="m1">

      <atomArray>

        <atom id="a1" elementType="C" x2="-26.360000610351562" y2="9.359999656677246"/>

        <atom id="a2" elementType="R" sgroupRef="sg1" x2="-24.820000610351563" y2="9.359999656677246"/>

      </atomArray>

      <bondArray>

        <bond id="b1" atomRefs2="a1 a2" order="1"/>

      </bondArray>

      <molecule id="sg1" role="SuperatomSgroup" title="tBu" molID="m2">

        <atomArray atomID="a3 a4 a5 a6" elementType="C C C C" attachmentPoint="1 0 0 0" sgroupAttachmentPoint="1 0 0 0" x2="-27.900000610351565 -28.67000061035157 -28.67000061035157 -26.360000610351566" y2="9.359999656677246 8.02632053484921 10.693678778505282 9.359999656677244"/>

        <bondArray>

          <bond id="b2" atomRefs2="a3 a4" order="1"/>

          <bond id="b3" atomRefs2="a3 a5" order="1"/>

          <bond id="b4" atomRefs2="a3 a6" order="1"/>

        </bondArray>

        <SgroupAtom>

          <scalar title="graphicalMarvinProperty::FormattedLabel" convention="atomprop" dataType="xsd:string">\i\St\n&#8201;Bu</scalar>

        </SgroupAtom>

        <AttachmentPointArray>

          <attachmentPoint atom="a3" order="1" bond="b1"/>

        </AttachmentPointArray>

      </molecule>

    </molecule>

  </MChemicalStruct>

</MDocument>

</cml>

It contains a shortcut group whose graphical label includes a non-ASCII character entity reference, for example, \i\St\n Bu. If I import this MRV into a Molecule mol, then subject mol to MolExporter.exportToFormat(mol, "mrv:PS"), then the character entity reference is converted to a Unicode character in the output, i.e., \i\St\n Bu. If you then print the string to a Web page, the Unicode character may display as ?. The solution is to convert all Unicode characters in the output from exportToFormat() into their corresponding character entity references before printing them to a Web page.

Hi Bob,

Thank you for pointing these issues out. For the first issue, the \n means that from now on the label is in normal, and not bold/italic/etc. . We will consider changing it so it does not mess up while sending it through other systems, or try to find an other solution. 

Regards,

Tamas Fazekas-Vigh