Pages: 1 2 3 4 5 6 7 8 9 10
 on: September 20, 2017, 11:18:48 PM 
Started by thomas9059 - Last post by thomas9059
Installing new PC's for user.
Win 7 32bit
Xmetal Icons and font too small.
I have tried most all options in personalization with no luck.  Most users are unable to read menu/icon font.
I have changed the size to 125%, adjusted the DPI and screen resolution. This has no effect at all in Xmetal.
The menus size can be change in the Windows color options but the Icons under the menus are still too small.
I have tried searching  using multiple terms with no luck. (I.E. win 7 Xmetal fonts and icons too small.
I had one user that was able to change everything to a desired size, these settings were copied over to another user with same results but all other tries with other users have not worked. (2 out of 180 are happy haha)
Any help or suggestions would be greatly appreciated.

 on: September 20, 2017, 04:31:18 PM 
Started by scott44 - Last post by scott44
Again, I am grateful for your time, but I realized we have bigger problem.  Our schema uses a different set of tags for optional column headers in our tables. For column headers, the custom row tags are ColumnLabelRow, and the custom cell tags are ColumnLabel (vs TableContentsRow and TableEntry for the data rows).  It doesn't look like the Tables element in the CTM file will allow two different custom tags for <row> and <cell>.  So, it looks like the solution may be to change our custom table tag to de-conflict with XMetaL's table tag. 

The least disruptive (though quite inelegant) approach would be to transform the document (changing the "Table" tag to "myTable") when the document is opened then transform it back (thus reverting "myTable" to "Table") when saving or validating.  In other words, while the document is in XMetaL, the "myTable" tag would prevent the conflict.  By reverting the tag a lot downstream processing tools would not have to change.  I've looked at the Developer's Guide and see some references to transformations for output to PDF or HTML, but I'm not sure if the in-memory transformation is possible.  Kind regards.

 on: September 20, 2017, 03:16:43 PM 
Started by scott44 - Last post by Derek Read
If the table is being inserted using a macro then that would be the issue.

You might have created the macro(s) because the Insert Table menu item (in the Table menu) wasn't functional.
I would recommend trying all the newly available functions in the Table menu and if they work (which should be the case) then you likely don't need their equivalents as macros.

If the InsertTable macro does still need to be used (it might do something our menus don't) then calling the API method ActiveDocument.formatGraphicTable(nodeTblNode) on the particular table in question should get it to render as a table. See the Programmer's Guide for details (including why this is necessary).

 on: September 20, 2017, 11:02:25 AM 
Started by Fa - Last post by Derek Read
Yes, it should still function basically the same. RenderX has not changed this functionality (at least not to any degree that would change this behaviour that I'm aware of). One thing that has changed is the values in these files. More fonts have been added to the list of Windows font paths and that section has been enabled (in older versions that section was commented out).

Though RenderX XEP is licensed and configured for use with the DITA OT included with XMetaL Author Enterprise I don't think you can say it is the default rendering because different deliverable types use different engines to create their output.

These deliverables use RenderX XEP:
Book via RenderX
Book via Structured FrameMaker
XMetal Enhanced PDF via RenderX XEP
XMetaL Enhanced PDF via RenderX XEP and Acrobat Distiller

This deliverable uses Apache FOP (also included):
PDF via FO with default processing

These deliverables use Antenna House XSL Formatter:
XMetaL Enhanced PDF via Antenna House XSL Formatter

 on: September 20, 2017, 10:49:25 AM 
Started by rhastah - Last post by rhastah
It works! Thank you very much, this is exactly what I needed.

Ctrl+Alt+V now pastes more or less plain text, saving me lots of time. Anything that shaves a second or two off a repetitive task can be hugely beneficial.

So thanks again!!

 on: September 20, 2017, 08:05:07 AM 
Started by scott44 - Last post by scott44
You are correct that our customization is old.  It was originally developed ~2003 using XMetaL 3.  Your recommendation to add the <Tables> element to the CTM file worked great (sort of).   Now I have the opposite problem, but it may be easier to deal with.  Existing tables now render correctly in Tags-on and Normal views, but a new table is incorrectly rendered when it is initially inserted.  However, after switching to Plain Text view then back to Normal or Tags-on view, the table is correctly rendered.  It seems that returning to Normal or Tags-on view from Plain Text view fires some sort of redraw event.  Is it possible to force that redraw event from macro code?
The attached picture illustrates the case.  A newly added 4x4 table is initially rendered as a 1x1 table, but after switching to Plain Text view and back to Tags-on view, the table is rendered correctly.  I am also looking at our macro code to see if we need to modify our InsertTable function.
You have been a great help.

 on: September 20, 2017, 01:16:26 AM 
Started by Fa - Last post by Fa

I am having a very hard time figuring out how to deal with fonts. From my previous experience on XMetaL 6 with DITA-OT 1.3, it was quite straightforward: you would set the font in e.g. commons-attr.xsl to logical font (e.g. Serif), then you would tell in font-mappings what that logical font corresponds to (according to the language, if not specified it reverts to default), e.g. default is "DefaultFont", Simplified Chinese is "CNFont", etc. and then in XEP you would give the font data.

E.g. if I wanted DefaultFont to be Arial, then

      <font-family name="Arial">
          <font-data ttf="BAUHS93.TTF"/>
        <font style="oblique">
          <font-data ttf="ariali.ttf"/>
        <font weight="bold">
          <font-data ttf="arialbd.ttf"/>
        <font weight="bold" style="oblique">
          <font-data ttf="arialbi.ttf"/>

And then when the text was translated into Chinese, and I wanted CNFont to be e.g. SimSun, I'd have

      <font-family name="CNFont" embed="true">
        <font><font-data ttc="Simsun.ttc"/></font>

But I find that much has changed between 1.3 and 2.4, and there has probably has been much development in RenderX as well.

So I guess my first question is: does it still work like this (it doesn't seem so), and if it doesn't, what has changed?

And before I go any further, I also want to make sure that my plugin uses RenderX. I was under the impression that that was the default renderer that XMetaL uses, but I am not sure. Is it? If it is not, where do I set the renderer to be RenderX? (Or alternatively, how do I solve my problem using FOP?)

I have tried modifying the font data in the xep.xml file, but it doesn't seem to have any effect on my plugin output, not even on the English. However, changing the base-font in, e.g. common-attrs lets me choose the font I want for the pdf content, and the same goes for toc-attrs to select fonts for the TOC, etc.

Any hint is welcome!

Thank you!

 on: September 19, 2017, 04:26:21 PM 
Started by scott44 - Last post by Derek Read
I think the issue is that your customization is set up for the old way of doing things, which uses CSS only (and possibly complicated by the fact that the main element is named Table, which is fine, but without any additional settings the software is probably guessing if this is supposed to be HTML, CALS, other, and then maybe partially working but ultimately failing to figure it out).

If you add the following to your CTM file things should behave properly, and the new table editing behaviours will be enabled for your custom table type, including the functions in the Tables menu (that apply) and the Table Properties dialog (with functions that aren't relevant being disabled).

    <CustomTable useFindInsertLocation="true">

The <Tables> section should be made a sibling of the <ElementPropertiesList>, <Templates>, <ChangeLists>,  <OCXReplacements>, and <Images> sections in the CTM file.

 on: September 19, 2017, 11:13:58 AM 
Started by scott44 - Last post by scott44
Thank you for the post, Derek.

While waiting to see if I can upload our XSD (it is "owned" by another group), I will add a bit of information to my previous post.

I noticed that a table is properly rendered in Normal and Tags-on views immediately after the table is inserted in the document. I can switch between the Normal and Tags-on views with no effect on the table. However, as soon as I switch to Plain Text view (or close and re-open the document), the table is no longer rendered.  I attached a picture with some excerpts to illustrate.

Many thanks.

 on: September 18, 2017, 01:56:27 PM 
Started by rhastah - Last post by Derek Read
Yes, we've considered making this a first class feature. However, the number of different requests we have received with specific requirements for such a feature has made it difficult to create something that we feel would work for everyone. Maybe one day.

However, you might consider adding this macro, or making modifications to it and adding your own modified version:,26.0.html

It was written specifically for the DITA authoring functionality, but should work for most other customizations depending on the functionality they have included in their own MCR files associated with the DTD or XSD. This could potentially also conflict with application-level customizations (application-level MCR files). If so, you would likely want to incorporate these few lines of script into those customizations and make them compatible.

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