Pages: « 1 2 3 4 5 6 7 8 9 10 »
 61 
 on: May 29, 2018, 05:04:13 PM 
Started by 55 - Last post by 55
Hi,

It doesn't say Spell Check Completed. When I click Spell checker, the Xmetal window becomes inactive, as if the spell checker has popped up, however it is nowhere to be found.

It does spell check while typing...I can see red squiggly lines.

I can run Spell Check in Files - that works.

I will try uninstalling again.

 62 
 on: May 29, 2018, 01:47:18 PM 
Started by 55 - Last post by Derek Read
No error messages are displayed?

It doesn't say "Spell check completed. Close Spell Checker?" (in the case where there are no spelling errors)

What happens if you enable "Check spelling while typing" on the General tab of the Options dialog? In a document with spelling errors you don't see any red squiggles?

To reinstall and make sure all the spell checking files are rewritten (in case something is missing or broken) you can try this:
1. Uninstall.
2. Delete this entire folder if it exists (that's where the spell checker lives):
C:\Program Files (x86)\Corel\Shared\XMetaL\Writing Tools
3. Install.

 63 
 on: May 28, 2018, 05:56:23 PM 
Started by 55 - Last post by 55
Hi,

I'm using Xmetal Author Essential x64 11.0.

I have an .sgm file open in Tags On View and I tried to run a spellcheck using Tools > Spellcheck and using F7, except nothing happens.

I have tried repairing and re-installing the product, but still cannot get spellcheck to work.

Anyone have any ideas on what may be wrong?

TIA

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

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

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

http://forums.xmetal.com/index.php?topic=3990.0

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

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

 69 
 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

 70 
 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?

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