Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: October 17, 2017, 07:35:07 AM 
Started by scott44 - Last post by scott44
Hi Derek,

I was off on another task, but now back on this one.  Many thanks for your replies.  I am going to submit an excerpt of the table portion of our schema and sample XML.

 on: October 10, 2017, 06:09:19 PM 
Started by jodekirk - Last post by Derek Read
If you put the following into an event macro named On_Document_Open_Complete inside the document-level MCR file for your customization, or in an event macro named On_Application_Document_Open_Complete for an application-level MCR file (one in Startup) you will be part way there.

var nodes = ActiveDocument.getNodesByXPath("//image");
var tooManyImagesForMe = 200;
if(nodes.length > tooManyImagesForMe) {
var response = Application.MessageBox("This document has a lot of images.\nWould you like to disable image rendering?\n\n(this is a global setting that affects all documents)",36);
if(response == 6) { //6 = yes
//turn "show inline images" off
Application.IniVariable("show_inline_images") = "false";

Answers to some (anticipated) questions:

1. This is using the global setting (as set in Tools > Options on the View menu) and so it affects all documents, currently open or to be opened. User can turn it back on in Tools > Options.

2. You might want to re-enable the setting when the document is closed. If not, the user needs to go into Tools > Options and enable it themselves. The logic for that might be to simply call Application.IniVariable("show_inline_images") = "true"; However, if you have two such documents open then, without additional logic, closing one would re-enable the setting and the other doc would then have its images rendered. So, you'd probably want to store another global variable somewhere that keeps track of how many such documents are open. Then when the last one is closed you would enable the setting (probably in the On_Document_Close event). Or you might provide a separate macro for the user to run to toggle the feature back on. You might also want to turn the setting back on when XMetaL Author shuts down.

3. An alternative method for doing this, specifically for SVG or other image types that are not drawn natively, might be to add logic into the On_Should_Create event that tells XMetaL Author whether to run the code in On_Initialize for the ActiveX control that renders your SVG (which is probably Internet Explorer). This would then only affect SVG images. You would probably have a similar macro to what I've listed above, but instead of toggling inline images off it would just check how many of a given element there are (same logic as above) then set some variable you choose that means "don't draw SVG images for this document" (you may need to use the CustomDocumentProperties API to pass values between macros). Then your On_Should_Create macro could check to see if that value is set to "don't draw SVG images for this document" and if it is then On_Should_Create would be set to "false" (which means that On_Initialize won't run). The On_Should_Create will run very briefly for every image in the document, so it might be very slightly slower than turning show_inline_images off, but when compared to instantiating 1000 embedded copies if Internet Explorer it should

 on: October 10, 2017, 01:57:23 PM 
Started by jodekirk - Last post by Derek Read
If you know you are going to be opening this document the easiest way to do this would be to turn off the "show inline images" setting beforehand. That's in the Tools > Options dialog on the View tab.

There is likely a way (I haven't tried to write the script code) to count the number of specific elements in a document after it has been opened and before it has been rendered but I don't know if there is a way to turn "show inline images" off through an API at that point.

 on: October 10, 2017, 10:28:32 AM 
Started by jodekirk - Last post by jodekirk
Sometimes I want to open a very large manual that has over 1,000 images. This causes XMetaL to take about 30 minutes to display anything. I can't close the document until it finishes opening, so it is faster to force XMetaL to Close using Task Manager.

Is there a way to dynamically hide all images if there are more than 100 images in the document?
If it skips loading all images for large docs it would open much faster. We use SVG and SVGZ images.

 on: September 26, 2017, 02:19:55 AM 
Started by Mythri - Last post by Mythri
Thank you, Derek. I will submit a case to XMetal Support.


 on: September 25, 2017, 01:45:25 PM 
Started by Mythri - Last post by Derek Read
Lots of things could be at issue here. You might want to submit a support case to XMetaL Support.

To start, it would help to know the following:

1. The version of XMetaL Author Enterprise you have installed.
2. The version of XMetaL Author Enterprise for Sharepoint that you have installed.
3. The version of Windows you are running.
4. The version of Sharepoint running on your server.
5. The Sharepoint URL that you are using (this is why I recommend dealing with this issue via XMetaL Support and not publicly on this forum).
6. Are you prompted to log in?
7. Are you using a valid login? To test that you can log in using the web interface or another application that supports Sharepoint.

 on: September 25, 2017, 06:10:43 AM 
Started by Fa - Last post by Fa
Thank you Derek!

As I suspected, my plugin is not using XEP, but FOP. Even with the RenderX folder renamed it produces the same layout.

This might explain why the xmfo plugin recognizes "Sans", and my custom plugin requires "sans-serif". My custom plugin only uses sans-serif, serif and monospaced, I have no reference to any font name, so the "fallback" fonts are probably those you cited, referenced in the pdf2 plugin.

I have tried changing throughout my plugin all fop references to xep references, but that breaks the output.

The files I have modified are:

xsl/fo/topic2fo_shell_fop.xsl renamed to xsl/fo/topic2fo_shell_xep.xsl (I have also modified the integrator.xml file reference to the file to reflect this name change) and modified as follows:

  <xsl:import href="plugin:org.dita.pdf2.fop:cfg/fo/attrs/commons-attr_fop.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.fop:cfg/fo/attrs/tables-attr_fop.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.fop:cfg/fo/attrs/toc-attr_fop.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.fop:xsl/fo/root-processing_fop.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.fop:xsl/fo/index_fop.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.fop:xsl/fo/tables_fop.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.fop:xsl/fo/flagging_fop.xsl" />

Changed to

   <xsl:import href="plugin:org.dita.pdf2.xep:cfg/fo/attrs/commons-attr_xep.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.xep:cfg/fo/attrs/layout-masters-attr_xep.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.xep:xsl/fo/root-processing_xep.xsl" />
  <xsl:import href="plugin:org.dita.pdf2.xep:xsl/fo/index_xep.xsl" />

In cfg/fo/attrs/basic-settings.xsl, I changed the line
  <xsl:param name="pdfFormatter" select="'fop'" />


  <xsl:param name="pdfFormatter" select="'xep'" />

Are there some files at a higher level (e.g. DITA_OT level) that would require editing for this to work, or is this the wrong approach?

Also, should I define another plugin under "require" in plugin.xml? Currently it is set to
  <require plugin="org.dita.pdf2" />

Thank you!

 on: September 25, 2017, 01:00:13 AM 
Started by Mythri - Last post by Mythri

I have configured the repository options with the Sharepoint URL. However, after following the steps provided in the XMetal Author Enterprise - SP Edition help, I was unable to connect to the Sharepoint location due to the following error:

The request failed with HTTP status 401: Unauthorized.

Can you please help me to resolve this?



 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?

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