Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: May 25, 2018, 05:56:06 PM 
Started by lerche - Last post by Derek Read
OK, so here's my fix:

1. Open your .JS file in XMetaL Developer's script editor (double click on it in the Project window).
2. In the Visual Studio main menu open File and select Save As.
3. In the Save As dialog save using the same filename and path (to overwrite the file) but change the encoding (using the little arrow on the Save button) to "Unicode - Codepage 1200". This is Microsoft's equivalent of UTF-16.

Note that this assumes your file contains the correct characters (if not fix them before step 3).

Now when you build the project the MCR file will be encoded to UTF-16 (which you cannot change) and because this .JS input file is in the same encoding (also UTF-16) there won't be any character encoding issues.

Why building a project doesn't trigger a proper encoding change from UTF-8 (or whatever other encoding you might have the .JS file in) into UTF-16 for the MCR file I don't know, but I don't know that it is worth looking into if the fix is this simple.

 on: May 25, 2018, 05:28:50 PM 
Started by Marvin - Last post by Derek Read
That might be easier.

 on: May 25, 2018, 05:26:22 PM 
Started by Derek Read - Last post by Derek Read
This topic has been moved to DITA and XMetaL Discussion.

 on: May 25, 2018, 05:26:13 PM 
Started by Mythri - Last post by Derek Read
Presumably this is DITA.

What does the XML look like?

I would check to see that there isn't some stray border attribute set for that portion of the table.

 on: May 25, 2018, 05:24:24 PM 
Started by lerche - Last post by Derek Read
It looks like even when a .JS file is created in an XMetaL Developer 12 project and saved using the correct encoding (in this case UTF-8) when you build the project the MCR file that is generated can be encoded using UTF-16 LE for some reason.

At this point I don't know why this occurs, whether this is a Visual Studio issue, or whether XMetaL Developer can be made to control this.

The main issue is not the encoding however. XMetaL Author is capable of reading UTF-16 encoded MCR files or UTF-8 encoded MCR files. The issue is that for whatever reason, some characters are encoded incorrectly into the MCR file(in your example these include ä, ö, ü or ß). As far as I can tell the file is being written out as UTF-16 but the encoding for these characters is actually appears to be Latin1 for some reason.

The only immediate solution I can think of (unfortunately) is to build the MCR file as usual then open it directly in a text editor and replace incorrectly encoded characters before resaving the file (either as UTF-16 or UTF-8). Seems really painful.

 on: May 25, 2018, 04:58:49 PM 
Started by JRP - Last post by Derek Read
This was dealt with as a support case, so for anyone else following this issue...

By default, the close button in the new UI (versions 8 and up) is drawn as a single button that is shared by all documents. This button is not tied properly to the ActiveDocument.Close() API. Development is looking into making this consistent for the next release.

In the meantime, enabling a feature that draws a close button (X) on each document tab resolves the issue.

1. Press Alt+Shift+S to open the XMetaL Appearance dialog.
2. Enable the checkbox labeled "Show 'Close' button on the active tab".
3. Click OK to save settings.

The INI variable for that setting is: app_look_activetab_closebutton = true

 on: May 23, 2018, 05:13:51 AM 
Started by Marvin - Last post by Marvin
I guess most likely it would make more sense to implement this as a validation macro then?

 on: May 22, 2018, 02:51:36 PM 
Started by Marvin - Last post by Derek Read
I suspect it should be possible given the right requirements. I can't guess how much effort would be required to get it working. I think it would be difficult to justify possibly doing so much work for (what I suspect) is of minimal benefit. Most likely it would be easiest to rewrite it from scratch based on the requirements for what to check (what is considered "invalid").

If the Schematron that DeltaXML created was straightforward, consisting of just asserts and rules then that would likely just work, or possibly need minimal changes. However, their Schematron uses <include> to bring in a couple of complicated XSL files and if those are required I don't think that is going to be easy. There are also a number of namespaces declared and for the most part Saxon-CE implementation of XSLT2 does not handle namespaces (though JustSystems has implemented support for a number of the ones used by Schematron with some workarounds so that Saxon-CE never sees those).

 on: May 22, 2018, 06:38:15 AM 
Started by Mythri - Last post by Mythri

When I convert files from XMetaL to PDF using Book via RenderX, table borders are missing for some tables.

Please find attached the screenshot. Kindly help in resolving the issue.


 on: May 21, 2018, 03:53:08 PM 
Started by lerche - Last post by tonys
To change the encoding of an XML file:
  • open it in XMetaL
  • switch to plain text mode
  • edit the encoding="..." in the XML declaration
  • save the file

To change to UTF-8 you can just remove the encoding, since UTF-8 is the default.

When you open a .mcr file in XMetaL it will probably ask you to locate macros.dtd - this can be found in the Author/Rules folder.

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