Connect equivalent to looping with showpage() + metadata + Alambic

OL Connect Professional
1

Hi all.

I have a bunch of 7.6 templates which use presstalk to display each page of a pdf, the path of which I am taking from a SQL database in the desired sequence:

Function @showFullPDF(&PDF:String, &Tray:String)
        define(&PDFPage,Integer,0)
        define(&PDFPageCount,Integer,0)

        &PDFPageCount:=pdfpagecount(&PDF)

        For(&PDFPage,1,1,&PDFPageCount)
                definemeta('BackgroundPDF', &PDF)
                definemeta('BackgroundPDFPageNo', inttostr(&PDFPage))
                definemeta('PrinterTray', &Tray)
                $UniqueBarcodeOverlay
                showpage()
        endfor()
endfunction()
&PDFPath := Field('PDFPath',1)
&MediaColour := Field('MediaColour',1)
@showFullPDF(&PDFPath, &MediaColour)

I then use the Alambic and metadata APIs in a script task to stamp the background PDF pages in their set locations, so that I can pull partially colour PDFs without PlanetPress messing up the colours of the source documents. I also use the PrinterTray meta field to pull the correct type of paper.

This setup has been working flawlessly to date, but now I need to add unicode text (Asian fonts) from the database onto the document, so PP7.6 is no longer an option.

Does anybody have any experience with porting the kind of setup above into Planetpress Connect?

2

Just out of curiosity, why is PP7.6 no longer an option? While PlanetPress is not a fully Unicode application, it does support most languages, including Chinese, Japanese and Korean, although with some limitations.

3

The setup is very specific in its requirements. Data source is a database with NVARCHAR fields containing a mixture of variable Chinese and English text. These have never displayed correctly in the data preview regardless of the selected encoding (every character was replaced with a rectangle). That same data displays flawlessly in DataMapper and PDF samples. Any attempts to use the following documentation were unsuccessful:
http://help.objectiflune.com/en/planetpress-design-user-guide/7.6/2827.html
And it doesn’t seem a lot of people had much success before me. As a matter of fact, you guys yourselves seem to be recommending a switch to PPC to get UTF8 support:
http://www.objectiflune.com/forum2/ubbthreads.php?ubb=showflat&Number=52166
In addition, 7.6 will not be supported forever, and the documentation on the official website is already lacking (e.g. excerpts with regards to showbarcode in PressTalk, the Watch object etc.).

I would much rather keep the existing setup, because of how complicated it is - the DB data is feeding an overflowing list of items on the datapage, followed by a set of conditional full PDF sourced documents with multiple personalisations (including barcodes based on document IDs combined with page numbers) and with tables built dynamically based on the line on the datapage - all this is printed on multiple medias on either of the two engines we have available for the job. It’s literally hundreds of lines of PressTalk with nested loops, dynamically updated arrays, the use of values from etc. But the addition of variable data with Asian characters has proven too much for the system to handle, so now I’m attempting to rebuild the lot.

4

Yes, OL Connect is much more suited for internationalized documents, and is indeed the way of the future as far as our products are concerned, although we will still continue to support our older product offerings for quite some time.

I was looking at it with one of your statements in mind, “I would much rather keep the existing setup”, so trying to change as little as possible.

If you have a mix of English and one and only one asian language (only one, very important), you could insert a Translator task to convert the UTF-8 to a supported encoding, for example GB-2312 for Traditional Chinese. This would allow you to use the data natively in PlanetPress and display it properly.

If you have a mix of languages, it is still doable because the encoding is set per-style. However, it can quickly become very complicated, to the point where moving the solution to Connect might be considered less work and risk.

5

Sadly it is a mixture of languages per sheet, and the list isn’t definitive - so I’m guessing every addition would result in additional dev time on top of the existing work. I’m afraid it will have to be Connect. Can you offer any ideas or point me in the direction of some resources that would allow me to mimic the setup I described in PPC? Thanks in advance!

6

You can achieve the same (actually it is much easier than scripting it with presstalk) using the control script API in the connect designer. The exact setup of the data mapper depends on your data sources …

Regards -i.

7

Hi iiliev, thank you for letting me know - do you have a sample of such a script that you can make available?

8

look at
http://help.objectiflune.com/en/pres-connect-user-guide/2018.2/#designer/Scripting/Scripting_Print_Background.htm

and also at
http://help.objectiflune.com/en/pres-connect-user-guide/2018.2/#designer/API/sheetConfig_Object.htm

This should give you an idea, what’s possible with the ControlScriptAPI.
best regards -i.

1 Like