Hello,

I've been testing PrinceXML for a few days now and I am really impressed what I've seen so far. After years of being sure cross media publishing can be done, I actually see a way how to achieve it.

I have a problem related to my lack of in deepth css knowledge:

I've got an XHTML file with long list of images named nameofoneimage-thumbnail.jpg, totallydifferentname-thumbnail.jpg etc.

To get better quality for printing, I want to drop the "-thumbnail" part to get a higher quality version of the same image. Obviously this could be done on the web server or on a locally saved xhtml file by some search-and-replace tool. But I want to know if there is a CSS / PrinceXML way.

This is the code:

<a href="nameofoneimage" class="imagelink" title="Go to Name of one image detail page">
<img src="images/nameofoneimage-thumbnail.jpg" alt="Name of one image" />
</a>

Notice that the image links to a page with the same name, just without any extension.

So I'd like to have something like:

a:link:before, a:visited:before { 
	 	content:url("/images/"attr(href)".jpg);
	 	width:70px;
 }

or use something like

prince-text-replace: "-thumbnail" ""

Thank you for your help

This isn't possible yet, but if we do support it we will extend the content property, not the text-replace property. Allowing multiple strings to be concatenated to form a URL seems reasonable!

No problem. Thank you for the fast reply.

Of course I used the forum search before posting, but only now I found a similar thread:

http://www.princexml.com/bb/viewtopic.php?t=231&

Is it possible yet to concatenate counters and other named strings into a generated content URL yet?
Our use case is making a request to get a data matrix image which includes arbitrary named strings from the document (like an account number), as well as the current page number, for document tracking.

Alternately, can content: url accept the return value of a prince-script function?

Edited 6 Aug 2013 by mdarens

That is an incredibly sensible request and I'm temporarily baffled as to how to do it, as prince-script() only returns text, not URLs. But surely there must be a way; I'll do some further investigation.

Thanks for the quick reply!

For anyone else trying to generate barcodes with render-time information encoded into them, our previous method was using tualo-barcode to construct the actual data matrix in Prince's js engine. This worked, but ended up being prohibitively slow, so we wanted to attempt just letting prince-script do URL concatenation, leaving the data matrix generation to ZXing.Net.

Edited 7 Aug 2013 by mdarens

It turns out generating the whole image in script doesn't work either, as finding and replacing the correct content depends on either getComputedStyle and .content or being able to return a data URI from prince-script().

Please let me know if we can help with testing any experimental builds.

Edited 7 Aug 2013 by mdarens

Have you tried using tualo-barcode with Prince 9? We have tested against Google's qrcode generation, and it's much much faster than Prince 8.1.

Hi Mike

I'm working with mdarens on this project. We are using Prince 9 and are generating the datamatrix barcodes on the server without page numbers. This yields us 1300 PDFs in about 4 minutes.

We tried using barcodes via tualo-barcode at first and were getting around 20 pdfs rendered in the same timeframe.

So we are currently generating the datamatrix codes on the server -- however, we now have a requirement to include the page numbers in the datamatrix code. So we need some way to build up a url using the page number.

Do you think the ability to generate a url from prince-script will be in a soon-to-be build? Otherwise, we will have to look at post-processing the PDFs with another library to insert a datamatrix image.

Looking at this issue, I don't think we will be able to implement it until September, as August is fully booked with new DOM improvements.

Thanks!
We're looking forward to it.

Has there been any movement on this lately?

No, it turned out to be trickier than I expected.

We don't know the size of the image until after the script runs, but we need to perform layout first to determine the page numbers, so that's complicated. We can workaround that by fixing the image width/height using CSS properties, and ignoring the intrinsic size. But then we can end up downloading a separate image for each page, which bypasses our new parallel downloader, slowing everything down dramatically. So we're trying to come up with another way of doing it.

If it were restricted to use in background-image as opposed to src attributes and content properties, it wouldn't cause reflow, correct? Then the download of those script-generated image URLs could be deferred and deduplicated.

In theory yes, but it will take a bit of digging to get all that to work.