Pages: « 1 2 3 4 5 6 7 8 9 10 »
 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.

 on: May 09, 2018, 02:40:51 PM 
Started by Marvin - Last post by Derek Read
My recommendation would be to only make changes using the spell checker's options dialogs then copy those changes to other machines once things are configured as you want them to be.

If you make a change in the dialogs and something is not changed in the registry then leave it as is.

 on: May 09, 2018, 07:53:38 AM 
Started by Marvin - Last post by Marvin
I'm still quite new to this project, so I'm not exactly sure how this happens and what the consequences are in DITA OT.

morerows: number of additional rows in a vertical span. There shall be at least that many more rows in the appropriate thead or tbody. Any entries with morerows that would attempt to extend further downward is an error.

That is one of the cases we're trying to catch.
The other thing is namest/nameend:

It is an error if the namest value is not defined in a colspec for the current tgroup.
(the same applies for nameend)

 on: May 09, 2018, 07:42:15 AM 
Started by Marvin - Last post by Marvin
Thank you very much. I really appreciate the great support you give us.

What is the DefaultUIDialect registry setting for? It doesn't seem to get updated from "EN" to "UK".
Would it make sense to set this to "UK" as well?

 on: May 08, 2018, 04:22:08 PM 
Started by Marvin - Last post by Derek Read
I'm a bit confused by that oXygen error message. The screenshot shows that in the tgroup @cols="2" so there are two columns. There are also 2 <colspec> elements (so that's consitent). There are two rows and each row has two entry elements (so number of entry elements matches the colspec). I do not see anything that would indicate there are more than 2 cells. Oddly, the error also says something about "row (3)" but there are only two rows shown in this table.

I could imagine a scenario where some authoring tool allowed you to create a table that has too many entry elements in a row, and perhaps that would not be caught by standard XML validation (with DTD). Is that the issue you are trying to show here? Under normal circumstances that would be extremely difficult to do while authoring in XMetaL Author. To do that I think it would be necessary to switch to Plain Text view and then either manually type in the angle brackets, the element name <entry> and other things. Is that something your users need to do? We typically don't see people working with tables that way. Editing in Tags On or Normal view is preferred because the table is rendered as a table and all the various editing features for adding/removing/moving rows and columns make editing easy.

Putting that aside, which transtype are you using that has issues with @morerows?

It sounds to me that if there is an issue with an output transtype when valid XML / DITA / CALS) is passed to it (in the case of the @morerows values) that the issue is with the transformation process itself (ie: there's a bug with the DITA OT transtype). Rather than try to detect and try to avoid issues that trigger a bug in a transtype doesn't it make more sense to log them as bugs with the DITA OT project so they can be corrected?

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