Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: September 22, 2017, 02:07:02 PM 
Started by scott44 - Last post by Derek Read
If you cannot share the entire schema (for copyright or other reasons) you could perhaps just snip out the portions that define the tables and include those in a dummy partial schema for testing that you could share with XMetaL Support. All that would need to include is a root element and the table model. If sharing an XML sample would be equally frowned upon you could then also remove everything from it except the dummy root and the table, and if necessary remove or change #PCDATA or attributes to dummy but valid values.

Perhaps that will allow you to bypass any strict regulations your organization(s) has about sharing such files.

 on: September 22, 2017, 01:58:32 PM 
Started by scott44 - Last post by Derek Read
Transformation would probably be best done before opening the file (if only one table model is defined in the schema). There is an event that lets you intercept a file that is being opened (the file path) that lets you do what you want with it before actually opening it.

Making modifications to the file after it is open would be tricky (to the point that I would avoid trying to do that). However, if the document model (your Schema / DTD) supports both types of tables then this would be easier.

Saving would be similarly tricky, and also probably made easier if both table models are defined in the schema. There are several events that let you make changes to a document before saving, and it would also be possible to write out a file using script (bypassing XMetaL's own save) though this needs to be done carefully.

However, having said that, I'm quite certain most table models can be supported by the table authoring feature with the right settings in the CTM file. Seeing your files will allow XMetaL Support to properly help.

Your statement that you feel it would be easier to transform to another table model (not sure which, CALS, HTML?) to make it easier to work with your documents with other downstream tools makes me wonder why you aren't just using CALS or HTML in the first place. There must be some reason for that?

 on: September 22, 2017, 01:52:27 PM 
Started by scott44 - Last post by Derek Read
I'm pretty sure this is probably supported (there are a lot of other settings available for this feature that I have not listed here).

I'll wait for you to be able to provide a copy of your schema and whatever you have currently set up as well as a sample XML file. If you can submit that to XMetaL Support we can help you configure things as needed.

 on: September 22, 2017, 01:49:10 PM 
Started by Fa - Last post by Derek Read
Quick answer before I try to start digging into the other stuff.

To test if whatever deliverable you are using uses RenderX I would just change the name of the RenderX folder. That will break output. Change it back and it will work. If not, then it is using another rendering engine (the only other one installed with XMetaL Author Enterprise is Apache FOP; Antenna House XSL Formatter needs to be purchased and installed by you).

As for "Sans" vs "sans-serif", those names are going to be used in the XSLFO (generated by the XSLT), so I think you should just search for them in the .xsl files inside the plug-in to see where they are called. Most likely "sans-serif" is used and "Sans" is not, in which case the "fallback" is going to be whatever default font family the PDF spec states is the default which will be one of Arial, Helvetica, Courier or Symbol (which make up the 14 default fonts that must be shipped with a PDF rendering engine, if it follows the PDF spec).

 on: September 22, 2017, 12:28:56 PM 
Started by thomas9059 - Last post by Derek Read
If this is a recent version (10 or higher or either XMetaL Author Enterprise or XMetaL Author Essential) you can right click in the toolbar area, select Customize, select Options, then check the box labeled "Large Icons".

If this is for another XMetaL product I would need more details.

 on: September 21, 2017, 05:34:50 AM 
Started by Fa - Last post by Fa
Thank you for your answer, Derek.

I thought I had managed to get it to work, but I just tested and it's not working as I thought it should.

In my commons-attrs.xsl file, I have my base font set as:

<xsl:attribute-set name="base-font">
<xsl:attribute name="font-family">sans-serif</xsl:attribute>

Then I have applied that base font throughout the file using an __fo__root attribute set.

<xsl:attribute-set name="__fo__root" use-attribute-sets="base-font">

Note that I had to use "sans-serif", while I thought that "Sans" would have been the obvious choice, but it did not work, although they are listed as aliases in my font-mappings.xml (and "Sans" works for my xmfo plugin!!!)

      <alias name="sans-serif">Sans</alias>

Using "Sans" reverts to using a serif font (I'm not sure which one and I have no idea where it gets it from).

Anyway, font-mappings.xml defines Sans (so sans-serif, too, if aliases work) as using Arial as default

    <logical-font name="Sans">
      <physical-font char-set="default">

From what I understand (and I've been able to test that using the xmfo plugin XMetal Enhanced PDF via RenderX XEP), Arial here is only a "face", you then point to the font files in the xep.xml file. In xep, I have Arial defined as follows:

      <font-family name="Arial">
          <font-data ttf="arial.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 I replaced the first font file with a totally different font, which makes the change obvious in the output:

<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"/>

This works with the xmfo plugin, i.e. I see the Bauhaus font used wherever the regular sans (or sans-serif) font should be used when generating, but I see no change in my own plugin.

Another very odd thing is that, as stated above, in the xmfo plugin, I can use "Sans" and not "sans-serif", and it is recognized, but as I said, my own plugin only recognizes "sans-serif".

So to summarize, my plugin applies the correct font when I refer to "sans-serif", but when I use "Sans" (which works for xmfo), it just falls back to to a serif font, and I don't know what that fall back mechanism is, neither where the said serif font is defined. And this is very annoying, because before I figure that out for default (US English) documents, I won't be able to get my other languages to work with different fonts (Chinese at the moment only shows hashtags ## instead of the Chinese glyphs, although Sans and Serif are both mapped in Font Mappings and xep to Chinese fonts).

I'm kind of short of ideas about what to do or try next, so I'd really appreciate a small nudge in the right direction. Ideas anyone?

And by the way, is there a way to know for sure that my plugin uses renderX? Where is the pdf renderer defined?


 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

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