For the past couple of years, we have been using Apex Office Print (AOP) as our printing engine on most of our projects. We love the ease with which we can render beautiful printouts using tools most of us are familiar with.

Users of our online reading log have been requesting Printable Book Certificates for a long time. Apparently it’s a great way to promote a reading culture at school. While we are all about an electronic solution to paper reading logs, kids still like to see their work shown off on paper :-). We get it!

We thought, easy peasy! Just design a super cute Word template, and then, using AOP, pull in the book image, author title, kid’s review, and voilà!

Not so easy….

Here is what the kids’ virtual libraries look like on our site:

Notice how the book images are all different sizes. Therein lies the problem.. We had a real hard time setting image heights and widths that would work with all book covers, so our certificates actually ended up looking…. blurry and not cute at all.

AOP does let you specify the image height and width in the query so as to properly render it. We do not, however, store these details in our database. A call to the Amazon API with every print was one solution, but we did not want to go there..

So here is what we did:

Determine actual image height and width with Javascript/jQuery

Because the book cover is rendered on screen, and the user clicks on an icon to generate the Certificate pdf using AOP, AND we know the HTML structure, we could read the image file width/height using following code (executed via a Dynamic Action – Execute Javascript – On Click of the icon)

var vImage = new Image();

vImage.src = $(this).closest(‘div.book-on-shelf’).find(‘a > img’).attr(“src”);
var vWidth = vImage.naturalWidth;
var vHeight = vImage.naturalHeight;

$s(‘P0_P_IMAGE_WIDTH’,vWidth);
$s(‘P0_P_IMAGE_HEIGHT’,vHeight);

Pass the calculated values to AOP report query

So we basically set a few page 0 items (P0_P_IMAGE_WIDTH and P0_P_IMAGE_HEIGHT) when the user requests the report, and pass these to a PL/SQL package. This package, in turn, calls the AOP PL/SQL package to render the report, substituting variables in the query to account for the image height and width. Voilà! Perfectly sized and rendered images with every print.

AOP query syntax

Something that took us a while to find was the naming convention for the AOP query for them to take the image height and width into consideration. If your image column is called ‘BOOK_IMAGE’, your height and width columns must be named: BOOK_IMAGE_HEIGHT and BOOK_IMAGE_WIDTH, respectively, for this to work.

Here is what our AOP query looks like:

select
‘file1′ as “filename”,
cursor(
select
u.first_name “rname”,
TO_CHAR(rub.date_finished,’fmMonth DD, YYYY’) as “fdate”,
rb.title as “bname”,
rb.author as “bauthor”,
review_comments as “breview”,
rb.cover_img as “bimage”,
nvl(:P_IMAGE_WIDTH, 110) as “bimage_width”,    <– these are the values that get substituted dynamically
nvl(:P_IMAGE_HEIGHT, 160) as “bimage_height” <– these are the values that get substituted dynamically
from all_the_tables_in_the_query
where all_the_join_conditions) as “data”
from dual

And here is the super cute result!

Some teachers have promised to send us photos of their walls covered in the kids’ certificates, and we can’t wait! But not gonna lie, we’re mainly glad we don’t have to cringe if the images are warped, compressed or stretched out.