external BackgroundResource stopped working after Update to 2018.1

OL Connect Professional Designer
1

Hi,

in both, Designer and Workflow, printSection backgrounds images previously read from external source:

printSections[‘mySection’].background.source=‘file:////Server/Share/Resource.pdf’

stopped working after the update to 2018.1, internal images (stored with template) are still working.

Ralf.

2

Hi Ralf,

The source property sets the source type of the PDF background (e.g. None, Datamapper,
PDF Resource) in your template. Could you retry things with the code snippet below?

var printSections = merge.template.contexts.PRINT.sections;
printSections[‘Section 1’].background.source = BackgroundResource.RESOURCE_PDF;
printSections[‘Section 1’].background.url=‘file://///C:/somepdf.pdf’;

Hope this helps,

Erik

3

sure, that’s how it’s already done:

printSections[‘Anreicherung’].enabled=true;
printSections[‘Anreicherung’].background.source=BackgroundResource.RESOURCE_PDF;
AnschreibenURL = path2asset;
printSections[‘Anreicherung’].background.url = AnschreibenURL;

even if the asset path is local like 'file://P:/localpath/data/mypdf.pdf" it doesn’t work in 2018.1 but in the previous 1.8! Support Call opened.

4

Please share the outcome of this. I am yet to update because of the bar chart issues and now there is this…

Regards,

S

5

@Ralf, does your Control Script involve Section cloning?

6

@Ralf, We’ve released Connect 2018.1.1. This patch version contains a fix for an issue related Section cloning which also effected section backgrounds set in a Control Script for these clones. I suggest to update that version and let us know the outcome.

7

Update:

no cloning used! But after installing 2018.1.1 the pdf source from datamapper is still loosing some source pages (red cross) and:

  • external backgrounds from local path not stored in the template folder render correctly, but only the first page, if there are more pages in external pdf these are empty! URGENT!
  • external backgrounds from mapped network drive render with a file naming convention like file:///// (5x slash, previously I thought there were 4 slashes), Can’t use that because when rendered through the server, those paths are different from client paths. Backside page renders empty! same error as before.
  • external backgrounds from UNC paths previously worked but I can’t fiddle out the new naming tried several slash combinations. Urgent!

Even with Control script off UNC paths don’t work.Just try to set a backgorund to any unc ressource (don’t store the asset in the template, keep it external).

external background images stored within the template render correct, even with more than one page.

thx to VM snapshot I’ll revert to 1.8 (everything’s running there)

8

I filed a report and asked R&D to take a look at this [internal ref: TS-3995]

9

Ralf,

We are able to reproduce the problem when the path (and/or file name) contains spaces or backslashes. When escaping these characters using encodeURI() things should work correctly (see the sample below). Can you confirm that your paths contain these characters (or other special characters)?

Erik

printSections[‘Anreicherung’].enabled=true;
printSections[‘Anreicherung’].background.source=BackgroundResource.RESOURCE_PDF;
AnschreibenURL = path2asset;
printSections[‘Anreicherung’].background.url = encodeURI( AnschreibenURL ) ;

10

Update on this:external multipage background pdfs:

file:///// (5 slashes) only shows first page

file:/// (3 slashes) shows all pages.

file:///// (any combination) UNC-path still doesn’t work, with or without encoding

File pathes and filenames are without any special chars.

11

Hi Ralf,

This is indeed a regression. We did find a workaround. Not very elegant but it resolves the issue on our development machines.

Use the following pattern:
file:///{two escaped backslashes}servername/volume/file

Consider the following code:
var pdfPath = ‘file:///’ + encodeURI(‘\Server1/Transit/SomeFolder/MyPDF.pdf’);

The result will look like this:
var pdfPath = ‘file:///%5C%5CServer1/Transit/SomeFolder/MyPDF.pdf’);

Sorry for the inconvenience we are doing our best to solve this.

Erik

12

Hi Ralf,

We are planning for a 2018.1.2 patch release which will include a fix for this problem.

Erik