Epic and FO's @background-image

[LynnHales]

I've read through the Epic 'help' on support for the FO attribute
'background-image' and I am still having difficulty in getting one to
appear.

What I am trying to do is have one of two graphics appear on a page. For
those familiar with MIL-SPEC TMs, it is the emergency page border. I have a
page set for emergency pages, and setting the attribute on an
<fo:region-body> does not seem to be working.

Has anyone gotten something like this to work and if so would you be willing
to share.

Many thanks.

Lynn

[ClayHelberg]

Hi Lynn--

This works for me, with 6.0 M050. Have you checked:

1) That your FO's actually contain the specified attribute?
2) That the location of the background graphic you are trying to use is
part of the graphics path?
3) That the graphic renders correctly in general (test by inserting a
reference as a standard document graphic)?
4) If this is meant to insert borders, is it possible that the graphic
is too large for the region-body page area, such that the visible border
markings in the image are hidden behind margins outside the region-body?
You could test this by creating a smaller version of the image which you
know will fit inside the region-body page area and republishing.

--Clay

Clay Helberg
Senior Consultant
TerraXML

[LynnHales]

Clay,

Thanks for the ideas. I've done all you've suggested with no results. I've
even gone and tried to insert a graphic I know works in an XML file into the
FO. Even this fails.

I've used both the background-image and the external-graphic. Neither is
putting anything into the output.

One thing that I have noticed is the actual page set does not seem to be
read. I've put some test output in various places and the one in the page
set does not appear. This may be why the background-image fails as Epic will
only allow it in a region-body.

I am using Epic 6.0 F000 64 bit.

While I'm asking for help. Here's another one. The FO I am working with is
broken into numerous individual files, brought together by xsl:include. Does
anyone know if it is possible to have changes made in an included file show
up in the output without having to totally close Epic and restart. I've
tried some different options (e.g., having a duplicate FO in another folder
and making the same change to both) with no luck.

It gets tedious, changing a couple of lines in the FO then having to stop
and restart Epic to see the results.

Again, many thanks.

Lynn

[ebenton]

Lynn,
This is probably too simplistic, but are you sure that your doctype.DCF file has a <graphic/> element with correct values for the element attribute and entity attribute and/or filename attribute? In the past, whenever I have had trouble with graphics not appearing, it has turned out to be my DCF file being incomplete.
Just a SWAG.

[ClayHelberg]

Hi Lynn--

Ah, the fact that it doesn't seem to be using your page set would
certainly explain things. If you look at the generated FO instance, you
should be able to work out which page set is actually being used. Then
you can make sure your background-image is attached to the right one (or
fix the stylesheet so that it uses the one you intended in the first
place).

You should be able to use external-graphic within your main content flow
for sure. If that's not working, then there is preventing Arbortext from
finding the graphic.

Are you using PE or local composition via Print Composer or Styler? If
you are using PE, you may have to use some PI magic in your XSL
stylesheet to make sure the graphics get transferred over to PE
correctly for XSL-FO composition. Search the Adepters archive, there
should be some messages about this from a few years ago that explain
what to do.

As for picking up stylesheet changes without restarting, you can do this
by using the "clear_stylesheets()" command on the command line. That
tells Arbortext to remove compiled versions of the stylesheets, so the
next time you compose it will recompile them, picking up the changes.
You'll have to do it each time, so you'll do a
(compose->tweak->clear_stylesheets()->compose) cycle.

--Clay


Clay Helberg
Senior Consultant
TerraXML

[LynnHales]

Ed,

Graphics for the DOCTYPE, placed in the XML itself are appearing. The issue
is with the FO for that DOCTYPE and graphics being called directly from the
FO (e.g., Emergency page borders). I hadn't thought about a DCF for the XSL,
but that could very well be the problem.

Thanks.

Lynn

[LynnHales]

Clay,

Thanks again, I've been digging into which page set is being used. That had
(has) me going. I am using the basic print composer (I have no need for PE
for the little printing that I do).

I appreciate the 'clear_stylesheets()' function. That did the trick. I would
have searched for a long time on that one.

For anyone who wants it, here is a quick ACL add to the right click popup
menu. You can stick it into a startup file somewhere to have it all the
time.

mad :EditPopup 'Clear Stylesheet' -cmd {clear_stylesheets()}


Lynn

[ClayHelberg]

Hi Lynn--

You shouldn't need to do anything with the XSL DCF file (in fact, I
strongly recommend NOT modifying it). It should already be configured
correctly. I think there is something else going on that is preventing
your graphic from being found and/or rendered.

Have you looked at the messages generated during composition to see if
there are any complaints about missing graphic files (or other errors
that might explain the issue)? If it doesn't pop up a window for the
composer log, you can force it to show the log with the
show_composer_log() function. If you don't see any red errors, you can
select View->Display->Messages to see the info messages, which may
include some useful info.

--Clay


Clay Helberg
Senior Consultant
TerraXML