Epic and FO implementation

[LynnHales]

I've been working with a couple of different FO implementations. When I run the FO in anything except Epic, I have few problems. Epic seems to add to any issues.

In doing followup on some of the problems Epic gives me, I am finding that Epic is NOT following the FO standard in many cases. To me, this is unacceptable.

How can one expect to really share information developed through other resources when Epic goes off on their own direction?

One example (and I am not 100% sure I believe the standard is right, but it is what is there) is in tables (and yes, I agree with Ed that "Tables are the spawn of Satan"). The XSL standards (both 1.0 and 1.1) allow the 'table-body' to contain either (table-row+ | table-cell+). Not sure why I would have table cells without a row, but ...

Anyway, I'm finding Epic DOES NOT allow this. The error states I MUST have a table-row wrapping my table-cell's, or processing STOPS with a Java error. The error is explained if one has the Java console open or if one knows to go out and open the composer log (neither is opened automatically when the processing stops).

I'm not sure if I am looking for a solution (I know what I have to do), but more venting.

Another thing I have found in attempting to parse a series of XSL files with Epic is Epic DOES NOT seem to recognize the xsl:include statement. My previous employer 'inherited' some rather 'shoddy' (to put it mildly) FO. The FO used ENTITY declarations to point to the other referenced files. Epic had no problem with this (though the FO itself had CONTEXT errors). When we changed all the ENTITES to xsl:include, Epic would only parse the root file. Maybe I missed something, but frustrating.

That is not to say that Epic does not READ the xsl:include's when processing an XML instance, it just does not read the INCLUDED files when trying to parse/edit in Epic.

Okay, I'm done. 😄

Lynn

[bibach]

Hi, Lynn...

Have you looked at the "XSL Support" document? It is a copy of the
XSL-FO spec with annotations to indicate what Arbortext does and
doesn't support, as well as ways in which their support differs from
the spec. At least in 5.4, the Help Center has a copy of the document
under "Stylesheet Development".

[ClayHelberg]

Hi Lynn--

As someone who's done a fair amount of XSL-FO development, I share your pain. To be fair to Arbortext (and other XSL-FO engine vendors), there's enough ambiguity in the spec to make sure that no two implementations will be 100% compatible. The Annotated XSL Spec document contained in the Arbortext Help Center generally does a pretty good job of spelling out what things are only partially covered or not covered by Arbortext's implementation.

About your table-body issue, it looks like, according to the spec, if you have table-cells as direct children of table-body (no table-rows), then you have to use the starts-row/ends-row attributes to group cells into rows in lieu of table-row container elements. But as Brandon pointed out, Arbortext doesn't support those attributes, so the only way you can group cells into rows is with explicit table-row elements.

As for xsl:include, this is not meant to be analogous to Xinclude inclusion, where the referenced document is loaded and rendered inline in Editor. It's more analogous to #INCLUDE in C, where the referenced content is interpreted inline on compilation/processing, but not generally on editing.

--Clay

Clay Helberg
Senior Consultant
TerraXML

[bibach]

On Tue, Mar 29, 2011 at 2:53 PM, Clay Helberg <chelberg@terraxml.com> wrote:
> As for xsl:include, this is not meant to be analogous to Xinclude inclusion, where the referenced document is loaded and rendered inline in Editor. It's more analogous to #INCLUDE in C, where the referenced content is interpreted inline on compilation/processing, but not generally on editing.

Ack, thbbft! I should have known this is what Lynn was referring to
(he and I even talked about it a bit, a couple of months back). My
bad for glazing over the finer point.

-Brandon 🙂

[KR]

Hi Clay --

If you've done a fair amount of XSL-FO development in Arbortext, then maybe you've experienced the magic that occurs when Arbortext renders lists where the label is not on the same line as the body. Any ideas on what causes that? I have looked at every attribute, everything before in the hierarchy and CANNOT figure out what is causing this. The FO works fine in other rendering tools. Actually it works fine in some cases in Arbortext but explaining that would be lengthy. Suffice it to say, I'm looking for any clues at all. I have 2 days to find an answer.

Kathy

[ClayHelberg]

Hi Kathy--

It's hard to say what's happening without seeing your actual FO instance and the resulting output, but some things to check would be the vertical-align attributes on the blocks inside the list-item-label and list-item-body, and the relative-align attribute on the list-item container elements. (If there aren't any such attributes, you might get more consistent results by adding them.) Also, make sure you don't have any funny business with different values for margins or padding on the blocks inside the list-item-label and -body.

Good luck!

--Clay

Clay Helberg
Senior Consultant
TerraXML