Background PDFs (dynamic PDF content of Print Context from datamapper) loses some pages, e.g. a incoming pdf is split in datamapper, then used as background of a print context. Output pdf shows some missing pages (red cross), same in Proof-Output (but there some other pages are missing). Preview shows correct pages.
So reverting to 1.8 (restoring the server) and everything, e.g. Designer and Workflow work as before (including external asset references).
Update: how can I install the old version on the client machine? Installer of 1.8 tells me that there’s no product version in obecttif lunes online repository.
I’d strongly advise contacting your local support team to get hold of an offline installer for connect 1.8 and to register this behaviour a ticket so we can investigate it in more detail. If you have a template setup that will demonstrate this behaviour please include it.
Could someone provide feedback to the forum on this issue? In 2018.1, setting a Print Section background to a PDF image, the image doesn’t appear in Preview in Connect. The PDF does appear when printing…
yet not solved in 2018.3 but according to support an error showing up in 2018.1. The reason was the image cache size setting of mozilla. It was too low when dealing with several large external pdf assets, even from the datamapper.
Here’s the fix:
C:\Program Files\Objectif Lune\OL Connect\plugins\com.objectiflune.xulrunner.win32.x86_64_38.0.6.20180321-0856-49789\xulrunner\greprefs.js (number may vary) add two lines at the top (right after the first comment):
Does anyone have idea if this still is applicable for Ol Connect Enterprise 2023.2.0.17816?
We are facing some issues where the Create print Content step fails to load the pdfs through Standard Dynamic Background, even though the pdfs are in the specified location.
Normally if the pdf is missing there is this red x in the middle of the page we have all seen and know about it
If I use Ctrl+Print from Connect I don’t get this behaviour.
Bellow the sequence of pages in the produced pdf from an automated workflow process
I assume that the issue you are facing is different from the issue reported here as the latter appears to have been fixed in version 2018.2 [internal reference: SHARED-64870].
I cannot find anything specifics about the mentioned internal reference, but the following is documented in the version 2018.1.6* release notes:
Blank pages encountered in jobs with PDF backgrounds of 30 pages or more
An issue was discovered in jobs in which the PDF background input exceeded 30 pages. In this scenario some pages would output blank after the 30 page limit was reached. This error was due to the internal image cache being exhausted and has now been fixed. (SHARED-65209)
Since 2023.1 there are no more red crosses for broken images in output.
As of that version you can use the selector [data-broken-image] to validate images. For example, you can add a post pagination script with the selector [data-broken-image] that calls fatalError to abort the job if there are any broken images.
The image cache limitation mentioned above (with the greprefs.js workaround) is still applicable. It is documented as a known issue here.
