uPRoduce, graphic adors, and hiden layers.

[ppietras]

We are building a direct mail campaign in uProduce. 

In order to make the InDesign template flexible, I am considering using layers and a vsibility ADOR or ADORS to turn certain layers on or off. 

However, I don't want to introduce inefficiency into our workflow in uProduce. Cany anyone alswer this for me.

If I have graphic ADORS on hidden layers, will uPRoduce evaluate and resolve those even though the layer they are on is turned off? Or, does uProuce only evaluate and resolve the graphic ADORs on active/visibile layers?

We have uProduce 26.0.0.16604 installed.

Any help of guidance on this would be most appreciated.

[SteveL]

From memory, that used to happen with early version of uProduce, but with v26 it no longer happens.

I don't recall the version where the behaviour changed, but I think it changed a couple of years ago.

[Scot Kendrick]

As I understand, if an ADOR exists on a "hidden" layer (not visible), it is still resolved (via data call) whether it is used or not. 

I've been told "don't leave ADOR's on pasteboard, as well, because they still create XMPie work" to produce results.

[ppietras]

Thanks All.

It's funny. When I asked the question to XMPie Tech Support, I was told that the ADOR on hidden layer is still resolved. However, I ran a simple test. I created 2 layers and a visibility ADOR, and then had an image on it with a graphic ADOR. On some records I had the image name correct. On other layers I had the image name incorrect. When the layer was visible - I got an error message in uProduce that the image was missing. When they layer was turned off, I didn't get an error. I think this confirms Steve's comment - that if the layer is hidden, uProduce doesn't try to resolve the image - otherwise I would have gotten errors about the missing image. 

Thanks for the help everyone.

[west-digital.fr]

Maybe I'm old-school - I'm afraid I AM 🥸

In my understanding (and sadly: in my long experience), all Content Objects (all) are calculated, when data is pulled and processed by the Logic. Only then does the document personalization occur (including Graphics and Visibilities). Regardless docs are print, emails, RURLs, SMS, etc.

Now, if I was due to process tons of data and produce huge output files, with the fear that the use of Visibility COs and heavy hidden Graphics COs would slow the process - then I would try to combine the visibility logic with the graphic logic. It may require more preparation time, but also save time at production.

Per instance, if I know that Layer1 (which would be the only one that uses Graphic1) is controled by Visibility1, whose QLingo is

GetEnv( "CurWheatherAtHome" ) == "Sunny"

...then I would move this Logic to a separate, shared Variable ("Variable1" in my case).

The Visibility QLingo would thus become something like

@{Variable1}

... and the Graphic1 QLingo could look like

If ( @{Variable1} ) { |->[The Field or Variable that holds the Image name] }

Else { "" }

If the empty string above raises painful warnings such as "Graphic1 has no value", then I would create a tiny, transparent PNG and change the QLingo into something like

If ( @{Variable1} ) { |->[The Field or Variable that holds the Image name] }

Else { "my tiny transparent image name.png" }

This way, I'm sure that, even if Layer1 (and its fellow Graphic1) and hidden, then Graphic1 would be empty or at worst very light, for the sake of a better production time.

Now, if I was not due to process tons of data or to produce huge output files, I would refrain from doing such things, because inventing a Logic that is so close to a given document is not really the XMPie spirit I think - guess that you have another document in the same Campaign, where Graphic1 is not located on Layer1, then you won't print the image?!

I hope all the above is old-school and no longer applies to recent versions, but I honestly can't figure out an XMPie Release Note that detailed such an important change - maybe I missed it.

west-digital.fr

[Amit Cohen]

Hi all,

A bit of clarification, since both views in the thread are partially correct, and the disagreement comes from "resolved" meaning two different things.

There are two distinct phases:

1. Asset resolution (plan interpreter). The graphic ADOR is evaluated, and the asset reference is produced. This happens for every graphic ADOR, regardless of layer visibility. In most cases, the ADOR resolves to an asset name, which is then mapped to a path. That work still runs, but in most cases it is very cheap. The cases where this phase does real, non-negligible work are:
   • Barcodes (the barcode stream is generated here)
   • uImage (the compound document is flattened)
   • Image from URL (HTTP fetch)
2. InDesign population (placing the resolved asset into the frame during composition). For graphic ADORs on an invisible layer, this step is skipped in v26. And of course, nothing is rendered to output either.

So Pietras's test (no missing-image error when the layer is hidden) is consistent with this: the population step that would have placed the image and surfaced the error did not run.

Bottom line: using visibility ADORs to hide plain graphic ADORs is fine and cheap. If your hidden frames contain barcodes, uImage, or URL-fetched images, the resolution work runs anyway, so gate those with conditional logic upstream rather than relying on layer visibility.

Side note on pasteboard: Scot is right that ADORs left on the pasteboard still create work, but this is a separate thing from layer visibility. Pasteboard items sit on a layer like any other element, so if that layer is visible, they go through full population (even though they are outside the page and never rendered to output). If the layer is hidden, they are skipped just like any other hidden-layer element.

Best regards,
Amit