The trick here is in providing a document to the MSApp.getHtmlPrintDocumentSource method that correctly represents what you want printed, which isn't necessarily the same as what's displayed on the page.
The sample you reference simply passes the current document object to getHtmlPrintDocumentSource, and is the easiest way to print, but as you've noticed, may not give you exactly the results you want.
A simple way to customize the output, as noted in chapter 15 of Kraig Brockschmidt's excellent (and free) ebook on HTML and JavaScript Windows Store apps, is to add a media query for the print media type, and use CSS to modify the output of the page, like so:
@media print {
.win-backbutton {
display: none;
}
.watermark {
display: none;
}
.titlearea {
font-size: xx-large;
}
}
This will not, however, likely solve the problem you're facing. In your case, what will probably work best is to create a separate page that provides output which is more print-friendly.
As an example, based on scenario 4 in the print contract sample, if I place an HTML page called print.html in the root of my app, I can reference it using the following code (note the ms-appx:/// scheme, which refers to content in my app package):
// set the alternate content
var alternateLink = document.createElement("link");
alternateLink.setAttribute("id", "alternateContent");
alternateLink.setAttribute("rel", "alternate");
alternateLink.setAttribute("href", "ms-appx:///print.html");
alternateLink.setAttribute("media", "print");
document.getElementsByTagName("head")[0].appendChild(alternateLink);
Now, when the devices charm is invoked, my alternate content page is supplied as the source for printing, rather than the current page. You can have your alternate page load the content from the JSON source and render it in a printer-friendly fashion, which may be different from how the content is displayed on the page.
For more info on Windows Store app development, register for Generation App.