We've been trying to add some variables on a watermark page that would relay to those in production the details of the job when printed.
Some of the variables are cause errors, right now mostly print related information like Main Stock e.t.c.
Jobs are submitted by JMF/JDF to freeflow core.
We were directed by xerox support to look at the xpaf files for the printer for the value to use for a ProductID that was missing from our JDF. Looking at the xpaf files I'm not sure where I should be looking for this ProductID (nothing is clearly marked thus) or where in the JDF the ProductID should go.
Assistance in this would be appreciated.
Jedidiah
Solved! Go to Solution.
The xpaf file is based on the response FFCore gets back after quering for capabilities via IPP.
Those responses are not always exactly the same, but in most cases you can find the media information in the media-col-database element. The JDF ProductID is mapped to the value of the media-key attribute.
Or more to the point: /xcap/media-col-database/value/media-key
The xpaf will have a value element for each media the DFE returns. The media-key is the element that contains the value that should be used in the JDF ProductID
Thanks for the information Javier.
By default it seems uStore is sending in varied stock information as class consumable
E.G.
<Media Class="Consumable" ID="M4858" Status="Available" MediaType="Paper" MediaUnit="Sheet" DescriptiveName="Media Type Thin" Thickness="4" />
<Media Class="Consumable" ID="M4859" Status="Available" MediaType="Paper" MediaUnit="Sheet" DescriptiveName="Media Type Thick" Thickness="40" />
These are missing the ProductID.
Is this information readable by Freeflow core? What variable(s) would this map to if so?
If this information is not readable without productID and this had to be added, how does FF core deal with multiple media nodes?
Thanks again.
I am not sure how we would handle multiple media elements. I think it would depend on whether they are inline within LPP or DPP or not.
If there are multiple elements but they are referenced only once I think that would be ok.
We support either the ProduID or Media attributes but the descriptions below generally look ok.
I would suggest that you register for the FFC SDK: https://www.xerox-solutions.net/developers
You can get details on all the JDF that FFCore supports.
Thanks for your prompt response.
They are indeed referenced in line with LPP and DPP
I.E.
<LayoutPreparationParams ID="LPP1" PartIDKeys="RunIndex" Status="Available" Class="Parameter" Sides="TwoSidedFlipY">
<LayoutPreparationParams ID="LPP4856" RunIndex="0~4 " Sides="TwoSidedFlipY">
<MediaRef rRef="M4856" />
</LayoutPreparationParams>
<LayoutPreparationParams ID="LPP4857" RunIndex="5 " Sides="TwoSidedFlipY">
<MediaRef rRef="M4857" />
</LayoutPreparationParams>
....
....
</LayoutPreparationParams>
and
<DigitalPrintingParams Class="Parameter" ID="DPP1" Status="Available" PartIDKeys="RunIndex" PageDelivery="ReverseOrderFaceUp">
<DigitalPrintingParams Class="Parameter" ID="DPP4856" Status="Available" RunIndex="0~4 ">
<MediaRef rRef="M4856" />
</DigitalPrintingParams>
<DigitalPrintingParams Class="Parameter" ID="DPP4857" Status="Available" RunIndex="5 ">
<MediaRef rRef="M4857" />
</DigitalPrintingParams>
...
...
</DigitalPrintingParams>
I guess the pages of the document is being split by varied stock types.
What does this change? I checked the FFC SDK and couldn't find a JDF example that matched this. Most, if not all, seemed to only contain one media reference as you suggested.
So would it be safe to say that while the printer might be able to recognize it, this is a scenario we might not be able to manipulate in a FF Core workflow?
If you look at JDF #5 in the Job Information folder in the SDK you will see that the LPP media and plex in your JDF should map to media and plex exceptions.
I believe FFCore supports the media references in DPP. However, I would remove those off the JDF. They convey the same information as the media references in LPP so they are superfluous.
THe information in the JDF will be mapped to a print ticket that will pass through FFC and be consumed to the printer.
FFCore cannot select pages for manipulation based on their ticketing attirubtes.
I thought it seemed redundant as well. That's just the way XMPIE has decided to send it across.
Yes. I did notice that example (JDF - 5).
I'm guessing this provides Main Stock information and Main Colour information but if I understand you correctly
I wouldn't be able to set apart a set of pages based on their colour.
Thanks for the information.
The references at the root of the LPP node are for the main stock, color and plex.
The references in the LPP elements that are inside the top LPP element are for exceptions - strock, color and plex.
The example shows both levels of ticketing.
I would start one at a time. Try only using the variable for the main stock with JDF #2.
If you get that working make a copy of that file and add the stock color from JDF #3 to the new file and send that in.