Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: March 15, 2017, 12:12:08 PM 
Started by Fa - Last post by Derek Read
Do you know what the purpose of the element is?
Do the people that are adding it know what it is for?
Are they aware that they are adding an element to the document that is making the document invalid?

By far the simplest solution would be to replace this element with an equivalent valid DITA element.

If you cannot modify the XML so it is valid you could create a specialized DITA DTD. DITA defines something called "specialization". This allows you to create a DTD that defines a select number of elements from the standard DITA DTDs as well as define new elements based on existing DITA elements (effectively performing the same "function" but having a different name). You would need to have someone familiar with creating a specialized DITA DTD do this. Once that is done the process for configuring XMetaL Author Enterprise to recognize that DTD as a DITA DTD is quite simple: you just fill in a couple of fields in a dialog and restart the software. Note that in this case you would still need to modify the XML files to change their PUBLIC id so that they no longer reference the standard DITA DTDs (because they are not standard DITA they are specialized). You would modify the XML's DOCTYPE declaration to use the PUBLIC id for the specialized DITA DTD. For all the information we document about DITA specializations see the Help topic: Working with DITA > DITA Specializations.

Of course any DTD used with XMetaL Author can simply be modified directly to allow any element, but that is a bad idea when working with a standards-based DTD like DITA as you are then creating files that are not compatible with the standard. It is only something you would do if you are in complete control of the DTD (in other words, you created or "own" the DTD, and you can roll out that change to everyone and all tools that need it).

 on: March 15, 2017, 03:01:20 AM 
Started by ChrisTMH - Last post by ChrisTMH
1. Yes
2. Yes that is the main issue
3. We have some topicrefs that are in excess of 600kb, the one I am currently working with has a table that is 500kb in size on it's own. Editing in itself is not slow, however loading the file takes a good fair few minutes. We use DITA.
4. Yes, this is a specialised DITA DTD. Using this function to create a different files containing the chosen elements means that the ditacomponent.dtd is referenced, and as our custom elements are not part of this DTD, they are not recognised. The document is thus always invalid and our custom toolbar is not used - changing the DTD to our specialisation solves this, however we want to save our authoring staff from having to do all of this manually.

 on: March 14, 2017, 06:10:07 PM 
Started by ChrisTMH - Last post by Derek Read
You mention the ditacomponent.dtd so I assume you are authoring DITA content?

Your files are large enough that editing is slow, and you wish to avoid that? That's the main issue?
Files need to be very large (generally) to make editing slow enough to be painful in XMetaL Author Enterprise.
That is even less likely to happen with DITA (since each topic is typically quite small).

You also say you have a custom DTD and customization. Is this a specialized DITA DTD?
If it is a specialized DITA DTD then the Reusable Component feature should work without modification (for authoring and with the DITA Open Toolkit). However, XMetaL Author Enterprise does need to be configured properly to set this up.

For non-DITA documents the Reuse menu and functionality isn't available as it is designed to be used with DITA. So if that is the case I'm not sure how to help.

Or perhaps you want to use files created using ditacomponent.dtd with some other system? In this case (assuming it is a validating XML parser) you should be able to provide it with the ditacomponent.dtd as well.

Or perhaps I'm completely misunderstanding this. I think I need more information or some clarification to help.

 on: March 14, 2017, 05:43:36 PM 
Started by zzz - Last post by Derek Read
At minimum your customization will have these files:



 on: March 14, 2017, 04:02:24 AM 
Started by Fa - Last post by Fa

I usually create all the documentation using XMetaL (using XMetaL 11.0), but for one particular project, my colleagues have created the DITA files (they do not use XMetaL) and they have included an element that XMetaL does not recognize. They need this to be included in the htm files that are generated when building their software, so removing it is not an option.

The element added is <Help_anchor> and has an "anchor" attribute (e.g. <help_anchor anchor="general"></help_anchor>)

I have a few years ago (using XMetaL 6) successfully generated the pdf. Back then, I think the only thing I did was to add an attribute for condition (output="htm", so that would be <help_anchor anchor="general" output="htm"></help_anchor>). XMetaL still would not show the tags on view, but at least it was able to just ignore it when building the pdf. However, this does not seem to work now, even with my old XMetaL. So I must have done something back then that worked, I just don't remember what it was.

Is there any way to just add that element so that it would be recognized by XMetaL? Or is there any other workaround?

Thank you in advance!


 on: March 13, 2017, 02:37:21 AM 
Started by ChrisTMH - Last post by ChrisTMH

XMetaL Author Enterprise version

In order to split some files down into smaller files, to make load time faster, we would like to use the reusable component functionality. The only issue we have is that this creates an XML file that uses the ditacomponent DTD, which means we cannot open the split file and edit it with our custom DTD.

By copying the part of a file we want to split into a new file which we create manually, using our customisation, it is then possible to import this as a reusable component. However, what we want is a user interface similar to the existing "Create Reusable Component", with the only difference being that our DTD is used.

Is it possible to customise this form, or are there any standard functions that we could use in a new form to achieve a similar effect? Or would we have to build this from the ground up?


 on: March 10, 2017, 07:59:08 PM 
Started by zzz - Last post by Derek Read
Something is wrong here. That's not normal behaviour. Not sure what would cause that. These settings are stored in the Windows registry, so if something is blocking those from being written, being read, or altering them (probably deleting them) that would be my best guess.

 on: March 10, 2017, 05:29:41 PM 
Started by zzz - Last post by zzz
Another really simple question: every time I open XMetal, why are the topbar File menu and icon groups always on 4 different rows.  It's like the program can't remember the layout of the toolbars on the top section.  This is version 10.  Word 95 could do this.  What gives?

 on: March 10, 2017, 05:10:37 PM 
Started by zzz - Last post by zzz
I appreciate your reply!  If you happen to know the css filename that would be edited, that'd be nice so I could just do it myself rather than go through administrators.

 on: March 10, 2017, 12:40:31 PM 
Started by Verner - Last post by Derek Read
Your screenshot shows something external to the XMetaL Author Enterprise UI that would be provided by SDL. If you must use it to create DITA conrefs you will have to deal with whatever requirements or limitations that system has.

I'm not sure why you would be forced to use Plain Text view but presumably that means SDL is disabling or modifying the built-in functions provided for conrefs (and perhaps other things) on the Reuse menu or that their system has additional requirements or limitations from the standard DITA markup. I can think of no reason that you could not still use the Attribute Inspector however. You can modify @id and @conref values there as well. Perhaps it seems easier to use Plain Text view as you are happy editing XML markup directly.

I would urge you to check with SDL to see if their system has done this for a reason. If these limitations are put there on purpose then bypassing them by creating DITA conref markup via other means (Plain Text or whatever) may not be a good thing for the SDL system. It is also possible that their system can handle DITA conrefs but that if you use them then you cannot take advantage of some other feature that SDL provides that is incompatible.

It would also be good to check with them in case these are limitations so that they are aware of them and can addess them in a future release, or in case they have already addressed them in a version of their software that is compatible with the current release of XMetaL Author Enterprise (currently version 11 and soon to be 12).

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