Skip to main content
K.Daube
Community Expert
Community Expert
October 24, 2018
Answered

Special characters not displayed correctly in variable if inserted via script

  • October 24, 2018
  • 1 reply
  • 802 views

Dear all

I came across a nasty bug: https://tracker.adobe.com/#/view/FRMAKER-5522 (please vote on it).

Script InsertVariable.jsx creates a variable with this content:

\+9\st007\st199\st254\st740\st991

However, what is displayed, even after screen refresh:

+9st007st199st254st740st991

This happens with any FM since version 10 and ESTK 4.0.0.1 (CC).

However after editing (replacing with itself) of any character in the variable definition the display becomes correct. There is no problem creating this variable manully via UI.

Using the corresponding Unicode characters is not an option, because this depends on the font - which mostly do not contain these characters (U2009

THIN SPACE, U+2212 MINUS SIGN or U+2011 NON-BREAKING HYPHEN).

The test script inserts some text at the top of an open document. It then inserts the variable into this text.

#target framemaker

TestInsertVariable (); //

=======================================================

function TestInsertVariable () {

  var paraText = "Far far away, behind the word mountains, far from the countries Vokalia and Consonantia, there live the blind texts. "

  var  oDoc = app.ActiveDoc, sValue, sVarName, oTextLoc, oPgf, oTR;

  if(oDoc.ObjectValid()) {

    oPgf = oDoc.MainFlowInDoc.FirstTextFrameInFlow.FirstPgf;

    oTextLoc = new TextLoc(oPgf, 0);

    oDoc.AddText(oTextLoc, paraText);              // create a paragraph

    oTextLoc = new TextLoc(oPgf, 17);              // arbitrary place

    sVarName = "GugusVariable";

    sValue   = "\\+9\\st007\\st199\\st254\\st740\\st991"; // \ to be doubled in string!

    InsertVariable (oDoc, oTextLoc, sVarName, sValue);

  } else {

    alert ("Document does not exist or is invalid");

  }

} //--- end TestInsertVariable

function InsertVariable (oDoc, oTextLoc, sVarName, sValue) {

// Arguments oDoc:     current document

//           oTextLoc: where to insert the variable

//           sVarName: name of the variable, it may already be in the catalgoue

//           sValue:   contents of the variable

var oVar, NewVar;

if (!oDoc.GetNamedVarFmt(sVarName).ObjectValid()) { // needs to be defined first

    oNewVar = oDoc.NewNamedVarFmt(sVarName);

    oNewVar.Fmt = sValue;

    oVar = oDoc.NewAnchoredFormattedVar (oNewVar.Name, oTextLoc); // insert at location

  } else {

    oVar = oDoc.NewAnchoredFormattedVar (sVarName, oTextLoc); // already defined, just insert

  }

} //--- end InsertVariable

This topic has been closed for replies.
Correct answer frameexpert

Further tests show, that some 'special characters' are handled correctly (immediately displayed), while others are not:

Handled correctly:

      \   (required blank)  \#  (numeric sp.)    \M  (m-sapce)        \N (n-space)   \t  (TAB)     \r  (Forced return)  \- (Optional hyphen)

Not handled correctly:

      \st (thin space)      \+  (non breaking hyphen)

Exactly those most relevant in my case ....


Hi Klaus,

Try just adding the literal characters in the variable definition instead of the symbolic codes that you enter in the interface. The symbolic codes are only for the GUI, but when you query the definition programmatically, you see the literal character. In other words, instead of inserting a non-breaking space with this \\ , use this \x11 instead.

#target framemaker

var doc, varFmt;

doc = app.ActiveDoc;

varFmt = doc.NewNamedVarFmt ("TestValue");

varFmt.Fmt = "99\x11mm";

-Rick

1 reply

K.Daube
Community Expert
K.DaubeCommunity ExpertAuthor
Community Expert
October 25, 2018

It turs out that a 'touch' (pseudo edit in UI) the varible gets a magic blessing. Also in the future - when again and agin created by the script - it behaves and displays correctly:

Watch this video, which was created after the script inserted the variable:

K.Daube
Community Expert
K.DaubeCommunity ExpertAuthor
Community Expert
October 25, 2018

Guess what?

The codes for Non Breaking Hyphen is \x15, that one of Thin Space is \x12. You may use these codes in a Search/replace dialogue. Be aware that these are not character codes, but functions in FM independently of font.

Hence I tried these in the script.

Replacing the line in the script

sValue  = "\\+9\\st007\\st199\\st254\\st740\\st991"; // \ to be doubled in string!

with the following (

sValue  = "\x159\x12007\x12199\x12254\x12740\x12991"; // Codes, not characters

Seemed to fix the problem! After the script the display is correct.

But later, when I impleted this into the full script (FMcalc) the display error is back also with the codes. So my bug report https://tracker.adobe.com/#/view/FRMAKER-5522 is still valid.

For your information:

Function
Symbolic characterCode
TAB\t\x08
Forced return\r\x09
End of paragraph\p\x0a
End of flow, end of cell\f\0b
Optional hyphen\-\x04
Suppress hyphenation\_ (underscore)\x05
Non breaking space\ (space)\x11
Numeric space\s# or \#\x10
Thin space\st or \i\x12
n-space\sn or \N\x13
m-space\sm or \M\x14
K.Daube
Community Expert
K.DaubeCommunity ExpertAuthor
Community Expert
October 27, 2018

Further tests show, that some 'special characters' are handled correctly (immediately displayed), while others are not:

Handled correctly:

      \   (required blank)  \#  (numeric sp.)    \M  (m-sapce)        \N (n-space)   \t  (TAB)     \r  (Forced return)  \- (Optional hyphen)

Not handled correctly:

      \st (thin space)      \+  (non breaking hyphen)

Exactly those most relevant in my case ....