General XMetaL Discussion

XMetaL Community Forum General XMetaL Discussion File Open and File Save

  • jrob61

    File Open and File Save

    Participants 0
    Replies 1
    Last Activity 10 years, 4 months ago

    Hi, having read various forum posts we learned that .css background-color and .css border properties can cause slow editing, espically in larger documents.  Also have experienced slowness in editor with uses of tables and .css 'display: pre' property in larger documents.  However, can anyone comment on whether or not the total number of tags in a documents can cause slowness during the open and during the save?

    we have a .css without any of the previously mentioned .css properties that cause slowness, but xmetal7 still takes approx 1 minute to open a file with approx 65000 tags.  Once we eliminated 40000 tags (25000 being empty tags) we are able to open the file in a respectable 8 seconds.  Curious if total number of tags is a known issue, or is there a known work-around.  Thanks.


    Derek Read

    Reply to: File Open and File Save

    Simple answer: absolutely.

    When a document is opened XMetaL Author (and XMAX) loads the DTD or XSD and builds up a set of rules that allows validation and “rules checking” to be performed (this is cached for subsequent files that use the same schema so you may see slightly faster speeds for second and subsequent opens of XML files that use the same schema).

    It also builds a DOM representation of the document in order to keep track of whether the document is valid while the user is editing (see “rules checking” in the Help). By default, the document is also fully validated when it is opened and (if defined in your customization) a number of events will fire.

    It isn't just the number of elements that affects open, it also includes their relationship (parents, siblings and children) as well as attributes that are defined in the schema. Loading a large complex DocBook or DITA document (hundreds of defined elements with complex rules) versus loading a file of the same number of elements that uses a simpler schema will generally take longer. The following is basically the fastest schema to work with (for test comparison purposes):

    Which view you open the document into also affects opening time. Opening a document into Plain Text view is far faster because a full DOM representation is not created (this is why “rules checking” is off in Plain Text view and why the Element List always shows all elements). CSS and CTM rendering is not performed either. These things are only done when you open a document into Tags On or Normal view (which occurs basically the same way when you open a document from disk or when you switch from Plain Text into one of these other views).

    You can get a fairly good idea of how long XMetaL takes to validate your entire document (part of the open process) in any particular view or state by timing how long it takes to do Tools > Validate (F9).

    The save process should generally be quicker than open because less is being done. In particular, there is generally less (and usually no) rerendering going on but the document is, by default, fully validated at save and a number of events also run at that time (if defined in your customization).

    To eliminate all possibilities that a script running at open or save is slowing things down you can remove the MCR file associated with your schema. However, you can't simply delete the CSS or CTM files as they will be auto-generated when not found. You can provide XMetaL with an empty CSS file or a very basic one. When empty almost all elements (not HTML or CALS tables) will be rendered using *{display:inline}. You might also test with a CSS file containing just *{display:block}. Don't provide XMetaL with an empty CTM file. In this case it is best to either leave it as is or reduce the complexity (which will usually be the case if you let the CTM file be auto-generated).

    Document rendering time is also affected somewhat by the amount of text in a single element, somewhat more by the complexity and number of CSS selectors, element nesting, table formatting, list formatting, and the presence of images, and even more so by inline XFT and ActiveX controls.

    Integration's with 3rd party software (a CMS for example) can also affect opening and save as some form of communication between XMetaL Author Enterprise and that external software is often implemented at these times inside various events.


  • You must be logged in to reply to this topic.

Lost Your Password?