Hi,
I have a document that changed to be built in 8minutes instead of 20seconds after changing fonts via CSS.

running prince with --debug -vvv shows me that the majority (>5minutes) is spent between

prince: debug: pack
prince: debug: writing output: solar.pdf.tmp

During this time the machine spins one Core at 100%.

Is there a way to profile what prince is churning on? I guess with some tweaking of the layout I could get prince back on track.

This is with prince 7.0b1 on a MacBook 13" (2GHz CPU, 4GB RAM). The document itself is 110 pages from a single html file built with docutils.

Cheers,
Harald

The conversion time increased so dramatically just by changing fonts? That's worrying. Which is the slow font? Are you able to email me a document that demonstrates the problem?

I'll happily blame the fonts. I'll send you the document with a way to easily switch the fonts via email.

We've narrowed the issue down to kerning. On my machine the document takes 1m 30s to convert with kerning enabled, and only 16s when kerning is disabled. (Note: there is no user-accessible method for disabling kerning yet, although we made add one).

It is a fairly long document, and the font has many kerning pairs available. As a result, Prince is checking over 5 million times, and finding about 700k kerning opportunities. This is what takes the time.

We should be able to reduce this performance cost with some appropriate caching of kerning information. This may have to wait until 7.1, though.

Impressive. Thanks for looking into it.

I might have found a similar problem. I have documents that take ~4 seconds to convert with arial as the font and >30 seconds with Adobe Garamond Pro. Any suggestions on how to improve the performance with Garamond?

Edit: --no-embed-fonts and --not-subset-fonts don't show any improvements, btw.

Sounds like a similar issue, caused by the presence of kerning. We're addressing this now and may be able to solve it before the release of 7.0.

Is this speed issue a regression? We just noticed it when we upgraded to 7.0b1, but it's possible we just didn't notice it since most of our printing doesn't use a special TTF font. I'm trying to figure out how to get around it until you guys are able to address it.

Is there a workaround maybe, that still allows the use of the offending fonts? I wasn't familiar with the term kerning, but from my wikipedia-gained-understanding, is there anything I can do with font-spacing or some such that will alleviate the issue for now?

We've come up with a solution for this issue to apply OpenType layout features without the performance penalty, and should be ready to release it soon.

fantastic! Looking forward to it.

I'm also getting bit by this issue (the font in question is Adobe Caslon Pro). Looking forward to the fix!

Prince 7.0 is now available, and should be faster for documents using complex OpenType fonts.

Hi, here is a old discussion about PrinceXML's kerning... So, today, 2013, with v8.x, there are CSS3 kerning capabilities?

Examples: "text-rendering:optimizelegibility", for user control the process time; or "font-kerning" property, that enable kerning with OpenType fonts.

Prince enables kerning automatically for all OpenType fonts that support it.