Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: May 16, 2018, 06:58:17 PM 
Started by davesw - Last post by davesw
Sadly it is not the nested_xft_fix INI setting. That string value is not in my local XMetaL folder and I added it to my xmetal.ini with a value of false and it had no affect.

I completely understand that more than a few embedded XFT forms would cause the app to run slower, but it is odd that this worked really quickly in XMetaL8 but does not in XMetaL11.

Before I share out a sample, is it possible to change the replacement process to insert a text string instead of an image/form? This one XML file has ~50 images and I imagine that XMetaL support will tell us that this scenario should never have worked as well as it did back in XM8...

 on: May 16, 2018, 02:59:23 PM 
Started by davesw - Last post by Derek Read
There is a chance that the INI setting nested_xft_fix is set to true. That will slow things down significantly in versions 5 and up (the functionality did not exist prior). That feature enables an element to contain an embedded XFT form and one or more children to also contain an embedded XFT form. With this setting enabled all forms are assumed to affect each other, so that every form in the document must be updated after every other form is updated, slowing things down. When that INI setting is not enabled after an XFT form is updated all of its children are assumed to not have any XFT forms.

See the third message in this thread for some additional details:,3348.msg8649.html#msg8649

If that isn't the issue then it would be best to submit a sample to XMetaL Support so they can have a look (preferably something minimal that reproduces just the one issue but contains enough to demonstrate the issue).

Keep in mind that the software has never supported running more than a few embedded XFT forms quickly as it was not designed to do so. So, the issue could simply be that having lots of XFT forms in a document makes it slow whenever it needs to be redrawn (open, switching views, or making significant changes to content).

 on: May 15, 2018, 09:52:12 AM 
Started by davesw - Last post by davesw
We recently moved from XMetaL Author Essential 8 to XMetaL Author Essential 11 (x86) and most everything worked great. One item that we are noticing is that the XFTReplacement script takes several times longer to process than it used to. We have 4 of them and they replace images and videos in our files with visual placeholders. In XMetaL8, a long XML file with 50 images would open and be ready for editing in under 10 seconds. In XMetaL11, that same file takes over one minute to load. If I turn off the 4 XFTReplacement rules that we have, that same file loads in 3-5 seconds. Is this a known issue in XMetaL11? Any workarounds to improve the performance?

Here is one of the XFTReplacement scripts (the other 3 just change the SelectorName and FormFileName):
        <SelectorName ns="">image</SelectorName>


 on: May 11, 2018, 12:50:16 PM 
Started by Randy316 - Last post by Derek Read
I would not upload anything a company owns here, especially if you need to get permission to do so. The entire world can see what is up here, which is a benefit as sometimes other users can help (that is the main purpose of the forum), but of course that also means people have access to anything you upload here.

I would recommend submitting files and any other information to XMetaL Support so it can be dealt with properly as a support case.

 on: May 11, 2018, 09:04:03 AM 
Started by Randy316 - Last post by Randy316
Thanks for your reply, Derek. I will have to discuss this with my support person at work to get permission to upload anything; I don't think we have access to any later versions of XMetal.

I don't think any of the APIs you might be using to move the selection have changed between these versions. APIs generally are only every modified to extend them (though this is rare). I think you've either you've found a bug or an API was being used incorrectly and happened to function the way you wanted it to in 6 but has since been fixed.

Either way, please submit a support case to XMetaL Support and include all the necessary files to reproduce the issue. XMetaL Support can have a look at it, reproduce the issue, and try to help you figure it out.

Another option would be to test again in version 12 or 13. If the issue is due to some bug with an API it may have been corrected for one of those versions (assuming a client found the same issue and reported it or it was found through testing).

 on: May 10, 2018, 03:01:19 PM 
Started by Marvin - Last post by Marvin
I completely agree.
I'm not sure how these invalid documents were created - normally it shouldn't be possible to create them in the first place.

But we probably have some invalid documents already at this point, so it would be great to be able to detect this.
Would be difficult to implement such validation in XMetaL, in addition to trying to avoid new document from becoming corrupted?

 on: May 10, 2018, 02:55:05 PM 
Started by Marvin - Last post by Marvin
Makes sense. Thank you!

 on: May 09, 2018, 06:14:46 PM 
Started by megl - Last post by Derek Read
I would say that this Windows update has somehow caused one or more pieces of the XMetaL Author Enterprise installation to become unregistered, or something has broken files or removed them.

XMetaL Author needs to be registered as a COM server with Windows (this allows it to be customized and controlled through script the same as MS Word, Excel, and similar applications). When you install XMetaL Author the installer does the COM server registration together with a number of DLLs.

Your best bet is to reinstall the software in hope that doing so will restore any missing or broken files and register all the things that need to be registered.

 on: May 09, 2018, 03:36:32 PM 
Started by megl - Last post by megl
I have a user on XMetaL Author Enterprise 12 on a Windows 10 computer who is getting the attached errors after a hot fix to Windows 10 was implemented.

Any advice on what we can do to resolve this?


 on: May 09, 2018, 03:28:33 PM 
Started by Marvin - Last post by Derek Read
If an author uses the XMetaL Author Enterprise UI provided for working with tables then these issues should not generally be a problem. Perhaps that is what we should recommend here.

In other words, if the user has a document open in Tags On or Normal view, where CALS tables are rendered visually as a table (or HTML or some custom table type), they can use various table editing features to split and merge cells and avoid all the complications of possibly inserting extra elements or incorrect attribute values.

On the Table menu we provide a "merge cells" dialog that lets you merge left/right/up/down and that automatically handles the setting of the various attributes for CALS tables (morerows, namest, nameend). The Table toolbar provides similar functions: "Merge Cell Right", "Merge Cell Left", "Merge Cell Up", "Merge Cell Down", "Split Cell into Rows" and "Split Cell into Columns" (together with many others that allow you to add rows/columns, and move rows and columns up/down/left/right).

Of course, it is always possible to create messy table structures that are invalid or that violate some rules if you are working with raw XML or directly with tags and attributes. That is why XMetaL Author provides a large number of UI features for table editing (see attached images). Perhaps if you have issues with tables being created that have problems it would be best to deal with those issues directly in the tool that is helping create those issues? Perhaps there are similar features or a method of dealing with them.

Pages: « 1 2 3 4 5 6 7 8 9 10 »