Graphics not displaying in FO output

Forum|Forum|15 years ago
September 17, 2010
7 replies
1710 views

As most of you know, we've been working on updating the Army's 40051 XSL style sheets. I think we've made headway, but there are so #%#$%^ permutations we'll never cover them all. 😞

Anyway one of the things we've been sort of ignoring in favor of real formatting is that graphics are not showing up. The appear in the screen display and when I process using a print FOSI, but are totally absent in the FO.

One of our ladies says she has it working, but only if she puts the graphics in the same folder as the FO files. Okay for testing, but definitely not what one would want for production.

So is there a secret that we're missing here.

Lynn

C

ClayHelberg

18-Opal

Hi Lynn--

Check the archives, I had an exchange with John Jarrett about this a while back. If you are using PE, you need special PI's in the FO instance to make the graphics work right.

--Clay

C

ClayHelberg

18-Opal

Hi Lynn--

I dug up a copy of that message, here it is:

Hi John—

I think you said in previous messages that you’re using XSL-FO, is that right? Are you using PE to publish?

In that case, the problem may have to do with a special thing you have to do with XSL-FO composition on PE for graphics. I’ll paste a summary I wrote up in response to a similar question a while back that should explain things below. This is sketchily documented in the Arbortext help (see e.g. the help topic for “set pegraphicpi”), but it took me some experimentation to figure out just how to make it work.

--Clay

PE has a special way of handling graphics, so that Editor can send local graphic files with the document to the server and the server can do the right thing with them. This is done using processing instructions, which FOSI and Styler grok automatically, but which need a little extra work with XSL-FO. Basically, you have to make sure your XSL-FO stylesheet copies the PI’s from the input to the FO output in order for PE to be able to find the uploaded graphics and use them. There will be one PI for each graphic, and it should be copied to appear *immediately after* the corresponding <fo:external-graphic> in the output tree.

The good thing about this is that you don’t have to worry about graphic paths at all—if Editor can find the graphics, it will insert all the necessary info into the _graphic_data PI for you, and upload the actual graphic when you publish on PE. In fact, when you use this approach, the contents of the src attribute on <fo:external-graphic> are ignored in favor of the info in the PI. (But, oddly, even though it’s ignored, you do have to have *some* value for the src attribute—if you just leave it empty or omit it, the graphic won’t appear.)

If you don’t use the _graphic_data PI’s (by turning the set pegraphicpi option to “off”, or by just not copying them in your XSL-FO stylesheet), then you do have to worry about getting the path right for the fo:external-graphic src attribute. And of course the graphics have to be on a shared location somewhere that PE can access them.

L

LynnHales

Author

1-Visitor

Clay,

Thanks for the response. Now I guess the 50 cent question is this.

Does this apply only to the PE or would it also apply to the print composer? We're not doing anything major, just using our print license to do print previews and PDF of our sample data.

Lynn

C

ClayHelberg

18-Opal

Hi Lynn--

That solution only applies to PE--it has to do with how images and information about them are passed from the client editor to PE. So I guess it won't help if you are using print composer locally.

Your colleague's report that she can get graphics to appear by putting them in the same folder as the document indicates that the filenames are being interpreted as relative paths independent of the graphicspath setting. In that case, you might need to modify your XSL-FO stylesheet to include path information about the graphics in the fo:graphic src attribute. So instead of <fo:external-graphic src="foo.gif"/">, you might need something like <fo:external-graphic src="images/foo.gif"/"> in your FO instance. Give that a try and see if it works better.

--Clay

P

ptc-3050150

1-Visitor

Lynn,

If you had access to all my emails, you would have seen my complaint on this one. I eventually gave up and sent it to PTC.

When you Print Composed using a local PDF print driver, graphics show. When you Compose | PDF File, they do not.

I got y'all to include the previous PTC fix to put a graphic PI at most of the graphics (warning icons and such...I think y'all may have still missed a couple but I don't recall this early in the morning).

There is a routine in xsl-fo_main that strips the path making the graphics unlocatable. I've got to where I comment that out when I get a new version from LOGSA rather than fighting to get the PIs inserted where they were missed. And the PIs are only needed because the path is getting stripped in main.

I have not seen any errors as a result of commenting out this routine as follows:

<xsl:template name="substring-after-last">
<xsl

aram name="str"/">
<xsl

aram name="delim" select="/"/">
<xsl:value-of select="$str"/">

</xsl:template>

John T. Jarrett CDT
Senior Tech Writer, Integrated Logistics Support,Land & Armaments/Global Tactical Systems

T832.673.2147 | M 832.363.7234 | F 832.673.2376| x1147 | -
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

P

ptc-3050150

1-Visitor

This applies to the PE. Once the graphic path is stripped, your computer can still find them with Print Composed, as can your local PDF print driver - but the PE cannot find them with no path data.

Clay, you are spot on. That graphic PI you sent me way back when fixes most of the issues...of course, if the FO didn't strip the path to begin with, the point would probably be moot. I've wondered ever since what problem they were trying to fix when they added the routine to strip the path...and if it is resurfacing someplace I'm not seeing it when I take that routine out.

John T. Jarrett CDT
Senior Tech Writer, Integrated Logistics Support,Land & Armaments/Global Tactical Systems

T832.673.2147 | M 832.363.7234 | F 832.673.2376| x1147 | -
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

L

LynnHales

Author

1-Visitor

EUREKA!!!!!!!!!!!!

Thanks John.

Lynn

---- "Jarrett wrote:
> Lynn,
>
> If you had access to all my emails, you would have seen my complaint on this one. I eventually gave up and sent it to PTC.
>
> When you Print Composed using a local PDF print driver, graphics show. When you Compose | PDF File, they do not.
>
> I got y'all to include the previous PTC fix to put a graphic PI at most of the graphics (warning icons and such...I think y'all may have still missed a couple but I don't recall this early in the morning).
>
> There is a routine in xsl-fo_main that strips the path making the graphics unlocatable. I've got to where I comment that out when I get a new version from LOGSA rather than fighting to get the PIs inserted where they were missed. And the PIs are only needed because the path is getting stripped in main.
>
> I have not seen any errors as a result of commenting out this routine as follows:
>
> <xsl:template name="substring-after-last">
> <xsl

aram name="str"/">
> <xsl

aram name="delim" select="/"/">
> <xsl:value-of select="$str"/">
>
> </xsl:template>
>
> John T. Jarrett CDT
> Senior Tech Writer, Integrated Logistics Support,Land & Armaments/Global Tactical Systems
>
> T832.673.2147 | M 832.363.7234 | F 832.673.2376| x1147 | -
> BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
> www.baesystems.com
>

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded