Pages: 1 2 3 4 5 6 7 8 9 10
 1 
 on: July 26, 2017, 04:47:55 PM 
Started by jshick - Last post by Derek Read
Not sure where that would be coming from. Does it not say which character is invalid?

Try pasting into a different editor?
Stepping through with a debugger might give more information.

 2 
 on: July 26, 2017, 02:44:10 PM 
Started by jshick - Last post by jshick
I'm getting the following error:

Invalid character
Source line: while(rng.MoveToElement(elemName)) {

 3 
 on: July 26, 2017, 01:55:47 PM 
Started by jshick - Last post by Derek Read
There's almost always a way. Just need to define the problem in enough detail to understand what needs to be done.

Maybe something like this is what you need.

//XMetaL Script Language JScript:
//name of element you are looking for
var elemName = "ref-callout";
//create a range to walk through the document
var rng = ActiveDocument.Range;
//move the range to the start of the document
rng.MoveToDocumentStart();
//for every element that matches the right element name...
while(rng.MoveToElement(elemName)) {
   //...if that element has an @href with the value r101
   if(rng.ContainerAttribute("href") == "r101") {
      Application.Alert("found one...");
      //do whatever you need to do to this element here...
   }
}

 4 
 on: July 26, 2017, 10:55:20 AM 
Started by jshick - Last post by jshick
Alright, after some time away from this, I'm back. Perhaps there is no way for me to do what I'm looking for in a macro since it doesn't seem like I can even do it using the dialog box.

If I bring up the "Find & Replace" dialog box (ctrl+F), there are 3 tabs at the top: Text, Element, Entity. "Text" will find PCDATA within an element. I'm actually trying to find the value (r101) of an attribute (href) in a specific element (ref-callout) when in Normal or TagsOn Views. The ref-callout element doesn't actually contain any PCDATA, only attributes.

I can switch to plain text and just search for "r101" (but it doesn't seem like I am able to restrict by element in PlainTextView) and it will cycle through all of the occurrences of "r101". This is not ideal as I do not want the content authors to switch into PlainTextView.

Thanks,
Jeff

 5 
 on: July 21, 2017, 01:06:10 PM 
Started by pszwec - Last post by Derek Read
I think it's worth it to test with the 64-bit version to see if the 32-bit XMetaL Author is the issue for sure. If the only solution is to run the 64-bit release then an upgrade would be necessary.

If you plan to run this on Windows 8.1 or 10 then an upgrade would be necessary as well. XMetaL Author 11 was the first to support Windows 8.1 and 10.

 6 
 on: July 21, 2017, 10:48:46 AM 
Started by pszwec - Last post by pszwec
Any way around this you can't think of without upgrading?

Peter

 7 
 on: July 20, 2017, 02:19:19 PM 
Started by pszwec - Last post by Derek Read
The first native 64-bit version of XMetaL Author Essential was version 11, released last year. The sales people can help you obtain the current release (12, released this year). That would likely be a free upgrade for the House, I think, as you would probably be under maintenance (the sales people can help you with that).

The trial version of XMetaL Author Enterprise is available at http://xmetal.com (both 64 and 32-bit versions) but as your solution was built for XMetaL Author Essential it would be best to test with that product in case any of the other stuff included with Enterprise somehow interferes.

 8 
 on: July 20, 2017, 01:55:46 PM 
Started by pszwec - Last post by pszwec
Hi, Peter at House of Reps. We are having problems calling a 64 bit compiled dll from our current version of xMetal which is 7.0 Essential 32bit.  We have calls to our 32 bit document management software that has worked for 12 years. Now that we have 64 bit machines, with 64 bit Windows, 64 bit Office with 64 bit iManage client installed, the developer can't get his 64 bit dll to work from the PERL macros. Any help would be appreciated.

Peter

 9 
 on: July 19, 2017, 01:55:09 PM 
Started by lekiert - Last post by Derek Read
You could use an XFT form and have it appear as a modal dialog when the user clicks on the element. In the XFT you could define any business rules you want that aren't necessarily definable in your schema. I guess that's basically what you are asking for, with the difference being that the trigger for opening the form is not in the Attribute Inspector.

The CTM file's <XFTReplacements> section would end up looking something like this:

  <XFTReplacements>
    <XFTReplacement>
      <SelectorName>elementname</SelectorName>
      <FormFileName><![CDATA[myform.xft]]></FormFileName>
      <RunMode>Modal</RunMode>
      <DisplayStyle>Replace</DisplayStyle>
      <OverrideRule>Always</OverrideRule>
    </XFTReplacement>
  </XFTReplacements>


Note that the last two values are set but don't have any effect when <RunMode> is modal.

You could do this with an embedded XFT form as well but that replaces the entire element so if users can enter PCDATA into an element that can make authoring confusing. Also, if there will be many such elements in a document you should not embed XFT forms as that will slow document editing down significantly. Launching them as modal dialogs does not have this limitation.

 10 
 on: July 18, 2017, 06:19:19 AM 
Started by Consigliere - Last post by Consigliere
Hello,

I've once again ran into a problem while trying to modify my PDF output. We're trying to modify the PDF output in order to make it stand out and really look like our documentation. So our company standards have very strict guidelines for headers, which I'm trying to figure out how to reach:

-The headers need to have two parts, with their proportions being 2:1
-The header parts need to be different shades of blue
-The header parts need to have different text: the upper part has the document's title, the lower part has the chapter title, topic title, and so on
-The text needs to be centered, as opposed to being near the edges

So my question is: Is this even possible? I know that simply adding a background color, one way or another, should be possible, but dividing headers into two parts sounds difficult. Here's a very crude and basic mock-up of the header style that's expected from me:

For the background color problem, I've brainstormed a few solutions. The most obvious one would be modifying the files and adding a value for the background color, as if I was trying to change the font color or something. I tried googling it, and I ran into EasyDITA's instructions for it, which I couldn't get working. I must have made a critical mistake somewhere, since even XMetaL was giving me error messages upon trying to output the file.

After this, I tried thinking outside of the box, which led me to looking into adding a background image. Lo and behold, someone on the DITA Users Group on Yahoo had actually treaded these steps before me. But again, I couldn't get the output to work. I am guessing it's because I was referring to a wrong file location, or perhaps even editing the wrong files.


I know that both of these should be possible, as Jarno Elovirta's PDF Plugin Generator supports background color for practically everything BUT headers/footers. As for background images, even Leigh White's DITA for Print talks about adding an image to the header, so clearly it must be possible.

So to sum up:
1.) How should I go about adding the background color? I feel that even if it's not possible to divide the header into two like that, I still need to at least add the color to make it look a bit better. Am I just trying to re-invent the wheel by considering the background image solution?

2.) Is there any way to divide the header information into two like that? "Subheaders" or any concrete divisions aside, even just having the text on different lines would be enough, because then I could just align the text with the background image should worst come to worst.



EDIT: I managed to find out how to change the background color of headers, so that's a non-problem. If anyone else was wondering, it's defined in cfg/fo/attrs/layout-masters-attr.xsl. If you're using the PDF Plugin Generator, then you'll need to add in the variable <xsl:attribute-set name="region-before". So just copy that from e.g PDF2, and add <xsl:attribute name="background-color">#ffffff</xsl:attribute> inside it and bob's your uncle.

My second problem still stands, however. This only solved the color part, I still need to figure out how to divide the header contents into two lines. Any pointers would be appreciated!

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