Skip to main content
Participant
February 13, 2014
Question

FrameMaker 12 Publish Crash

  • February 13, 2014
  • 2 replies
  • 2122 views

Using Framemaker 12.0.1.331 all publish operations crash if the document contains a UserString of 1 or more characters in a table element.  We use UserStrings in this way to hold metadata about tables such as database keys and effective dates.

The Mif looks like this:  [We would normally have an xml fragment here but this is enough to produce a crash]

<Tbl

  <TblID 10>

<UserString `A'>

  <TblTag `Format A'>

  <TblFormat

Incidently a zero length UserString doesn't result in a crash.

Looks like a bug to me.

regards,

    Colin

This topic has been closed for replies.

2 replies

Inspiring
May 8, 2014

Hello All,

This issue has been fixed with Framemaker 12.0.2 patch. Please go to FM12- Help->Updates to get the latest updates.

Let us know if any problem persists.

Regards,

Anchal Arora

Framemaker Engineering

frameexpert
Community Expert
Community Expert
May 13, 2014

Hi Anchal,

Thank you for all your efforts with this. However, the UserString issue is not fixed with the FrameMaker 12.0.2. Here is the way I am testing this:

1) Create a new Portrait FrameMaker document.

2) Create two small text frames at the top of the page.

3) Select one frame and run this:

#target framemaker

var doc = app.ActiveDoc;

var textFrame = doc.FirstSelectedGraphicInDoc;

textFrame.UserString = "Set with ExtendScript";

alert (textFrame.UserString);

The fifth line displays "Set with ExtendScript" like you would expect. However, when you comment out the fourth line and just try to display UserString, it displays "undefined".

I tried selecting the second text frame and repeating the test with FrameScript:

Set oTextFrame = FirstSelectedGraphicInDoc;

Set oTextFrame.UserString = 'Set with FrameScript 6';

Display oTextFrame.UserString;

It displays the UserString like it should. When I comment out the second line and run it again, it still displays the correct UserString. If I save and close the document and reopen it, it still displays the correct UserString.

FrameScript 6 is correctly reading and writing the UserString property, but ExtendScript is not. Please let me know if you have any questions or comments. Thank you very much.

Rick

www.frameexpert.com
Inspiring
May 19, 2014

Hi Rick,

Here is a list of objects that we have fixed it for:

  1. AFrame
  2. BookComponent
  3. Cell
  4. CharFmt
  5. Color
  6. CondFmt
  7. Doc
  8. Flow
  9. FootNote
  10. Marker
  11. Pgf
  12. PgfFmt
  13. Row
  14. Ruling
  15. Session
  16. SubColumn
  17. Table
  18. TblFmt
  19. Variable
  20. Xref

You can test it on these objects. Meanwhile, we will see what needs to be done for TextFrame object. Can you think of any other object that is not included in this list and this property is used for?

Regards,

Anchal

Arnis Gubins
Inspiring
February 13, 2014

Hi Colin,

I just confirmed this in unstructured mode as well. Adding the UserString with a value to any table and then trying any of the Publish modes results in:

I'm wondering if the UserString attached to other objects could also trigger a crash.

Adobe Employee
February 20, 2014

Hi Colin/Arnis,

Thanks for reporting the issue. We have noted the issue with us. Seems like the crash had been there since long (in the TCS route) – but went unreported as we had not been using UserString much internally. Now that the Publishing route (earlier part of TCS only) is a part of FM itself, the issue seems to have surfaced.

We are evaluating a fix for it and would like to understand more on the usage of “UserString”:

  • UserString stores private data, what kinds of data is generally taken to the output?
  • how is it interpreted (used) in the outputs: pdf/webhelp/epub?
  • do you use its value in all outputs or some of them?

Regards,

Amit

Arnis Gubins
Inspiring
February 20, 2014

Amit,

The UserString, in my case, is used more as either a processing instruction or internal flag (marking) for a script to handle a specific object of interest. It typically doesn't bring anything to an output stream nor is the content stored for this property meant for output. It is for the scripts to use and the Publish routines should simply ignore it along with the content it contains.

Arnis