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

 on: May 21, 2018, 04:01:48 AM 
Started by lerche - Last post by lerche

In my XMetaL Developer project I have several JavaScript macros that are going to be bundled in an mcr-file. The default encoding format for this mcr-file is UTF-16 but I want have it in UTF-8, because my .js-Files have to be in UTF-8. Is it possible to configure the output encoding format?
Currently I have problems with letters like ä, ö, ü or ß. These letters are converted into cryptic characters.

My Question relates to the following system:

XMetaL(R) Author Enterprise
XMetaL(R) Developer Version
Visual Studio 2015 (Community Edition) Update 3
OS: Windows 10 Pro, English

Thank you for your help!

Kind regards,

 on: May 18, 2018, 02:08:02 PM 
Started by JRP - Last post by JRP
We're using XMetal on Windows 7.

We have code that runs on the FILE_CLOSE event macro that basically does some document cleanup and calls ActiveDocument.Close().  This worked fine in XMetal 7 even if the user had "tiled" their windows using the Window menu.  However, with the introduction of Tabs, and specifically Tab Groups, our macro fails to close the correct document in one specific case.  When a user has created a new "Tab Group" (horizontal or vertical), and they click the little x on the tab associated with a document that isn't the active document (their cursor is in another document), the document with the cursor closes.  In other words, clicking the x does not activate the document contained in that tab before closing.  Is this a bug?  Clicking the tab itself activates the document, but clicking the little x does not.  Any help with how we could catch this event and close the appropriate document would be appreciated.  

As an aside, if we disable our FILE_CLOSE event macro, XMetal knows to close the correct document.  We just need to know too :)

As another aside, we submitted a support case for this as well.

 on: May 16, 2018, 07:11:53 PM 
Started by davesw - Last post by davesw
Oh yeah! I should be able to use CSS to insert a text string... I'll try that route.


 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...

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