Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X

Epic and XSL-FO


Epic and XSL-FO

I am having some issues with Epic and some XSL-FO I work with.

I want to use Editor to make changes to the FO, but I continually get errors
that I do not get with processors like XML Spy or Oxygen. The first problem
I have is that when I try to add FO elements, they are not listed in the
insert markup box(es). Next Epic does not seem to like <xsl:include>. It
will read them when publishing, but not when editing.

I have validated this by commenting out all the "includes" in my main file
and replacing them with ENTITIES. The errors I get change, presenting a
couple I know are in the referenced files.

Lastly, does anyone know what parser Epic uses to validate XSL files? I get
errors with Epic that I do not see with Spy or Oxygen.

Right now, though I love Epic as an XML editor, I have less than kind terms
to use for its support of XSL.


Hi Lynn--

I don't think Arbortext was ever intended for use as an XSL editor. The
main issue is this: XSLT is basically an incomplete doctype fragment.
Because XSLT can be used to transform any kind of XML into any other
kind of XML (or into text or HTML), it would literally be impossible to
know what literal elements (as opposed to xsl namespace elements) should
be available for insertion. Consider that <xsl:for-each> would need to
allow essentially any FO element as a child, and you would need to allow
this inside almost every FO element. So basically your quicktags menu
would have to include all XSLT elements and all FO elements in most
circumstances. So the benefit of the quicktags menu would be minimal at

My advice would be to use a specialized tool for XSLT/XSL-FO editing.
jEdit has a good XSLT mode, and I've heard good things about Oxygen,
though I haven't personally used it.

The XSLT processor in Arbortext is Saxon, which is more or less the
industry standard, written by Michael Kay, one of the major contributors
to and chair of (IIRC) the W3C spec committee, and is one of the few
engines that supports XSLT 2.0. If you prefer the Xalan processor, you
can change the configuration to use that engine instead by modifying


Clay Helberg
Senior Consultant

I agree with Clay. I've been using jedit specifically for a few years now and recommend it regularly. Beyond the built in xsl assist it also has add-ins that do other handy xml tasks such as auto-indentation which can be quite handy.

Trevor Hendricks
Project Analyst -- Publication Systems
Kohler Co.

oXygen user here. It can even debug XSLT which comes in handy...


I'm an oXygener too.

I like Oxygen, it is a nice, fairly inexpensive tool. I had to do some
internal documentation to a schema last month. I used Spy for the input and
Oxygen for the output file. Much better than what Spy did.


Ok Adepters, here is my issue. I am working with Arbortext 5.4 M70. I have an sgml file that has a change tag with the attribute of Mark = "1", the default value is "0". The value of "1" tells the publishing application to put a change bar in the margins, (i,e, paper/PDF publications)

When I open this file up in Arbortext, the attribute does not show up until I go in and reset it. Is there a "setting" in Arbortext that I am not aware of to make these change tags show up the way they should.

Below is the before and after pics of what is happening.


This is the way it shows up when the file is opened.

[cid:image007.png@01CD90E6.428B5DC0]You will notice the Mark attribute is set in the dialog box,

But doesn't show up in the file;


If I go in and delete the attribute value and re-populate it

Then this happens;

[cid:image005.png@01CD90E3.C118DB20][cid:image004.png@01CD90E3.4B672800]Notice the "mark" text has turned blue to show that a value has been set.

[cid:image006.png@01CD90E3.C118DB20] Now the attribute shows up in the change tag as it should.

Ok I seem to be on a roll today.

I have an sgml file that appends a -1 to the end of a graphic boardno.

The best that I can figure is that once a graphic has been inserted into the file, it lists it in the graphic entities, if the graphic is re-inserted into the file is when it adds the -1, -2 to the end of the boardno. This happens even if the graphic is physically not in the file but is listed in the graphics folder.


That is strange, but the first thing I noticed is that the 'mark' attribute
is not showing up as blue. When an attribute is set that is other than the
default value, the attribute name changes to blue. With an SGML document,
attributes listed in the DTD are not required to show up in the start tag.

So what is happening, is Epic is reading this as a manually set value. One
thing to do is when you initially open the file run this from the command

eval oid_attr(oid_current_tag(), mark)

If Epic is reading it, it should show up as "1". If not, then it should
appear as the default of "0". I'd also double check the DTD to make sure no
one has changed the default value. You can verify this with the following

Eval tag_attr_default(change, mark)

I thought at one time there was a set command that would do what you want,
but I didn't see it. You may want to open up the help center and go through
the set commands list and see if I missed anything.

Another place to check would be your dcf file.



Shoot this is going to be fun to ask. When Epic adds the -# is it by the
'boardno' or by the <graphic>? I guess is there a boardno='a-1' and a
boardno='b-1' or would it be boardno='a-1' followed by boardno='b-2' (with
no b-1). Not sure what would be causing the problem, but that might help
find a bug if that is what it is.

The next question is, does Epic find the graphic with the new boardno?


It is adding it to the end of the boardno.
For example <figure><graphic boardno="abc123"></graphic></figure>
There are occasions when we open the file that the graphic viewer (IsoView) does not display the graphic. When this happens you have to put the graphic back it. When you do it will do this is what happens <figure><graphic boardno="abc123-1"></graphic></figure>. It doesn't matter if you map directly to the location of the graphic or if you drag and drop the graphic into the file.
The only way to get it to NOT do it is to delete the original graphic tag and reinsert it.
As some of our documents are quite large, my authors are balking at this added step.


Someone has reset the default value to "1".
Thanks for pointing me in that direction.


If you look at the entity declarations (enter "edit -current -untaggedascii" on the command line) you will find that there are two declarations after you insert the entity again. When Epic inserts a graphic entity declaration it will not duplicate an existing emtityname, so it appends a number to the existing graphic entity declaration as you describe.

Your .dcf file will specify the name of the attribute holding the entityname as "entity";


I haven't seen the problem here since I changed the instructions on how to replace a graphic.

Entity method (MIL-STD-38784 based DTDs). An attribute where the graphic is referenced contains the name of an entity that actually references the graphic file. e.g. <graphic boardno="" reprodep="8.25in" reprowid="7.5in" hplace="center">

o The entity name must start with a letter and is not allowed to contain any characters except period, dash, alphabetical, and numeric characters. The underscore, space, and all other keyboard and all non-keyboard characters are specifically disallowed

o To replace the graphic with a new graphic DO NOT change the entity name (contents of BOARDNO attribute must remain the same). Doing so causes a duplicate declaration and only the first declaration found will be effective. Instead, highlight the graphic tag, click on Entities->Graphic, and edit the file name inside the entity declaration as shown (this changes the declaration instead in inserting a new one):
Maybe this will help,
\ / Andy Esslinger LM Aero - Tech Order Data
______-/\-______ (817) 279-0442 1 Lockheed Blvd, MZ 4285
\_\/_/ (817) 777-3047 Fort Worth, TX 76108-3916

Top Tags