i don't actually think it was possible to supply a relative path
with the way this worked before? now it definitely is, which is super
nice for loading fonts from the classpath.
absolute font paths can still be used if needed, but they absolutely
must include a scheme prefix, e.g. 'file:/path/to/font.ttf'
apparently didn't test that get-base-resource-path-url function nearly
enough... oops.
this new ability to specify a custom uri resolver is much better anyway.
the default resolver (using the resolve-uri function) is geared towards
the common case (or what i assume will be the common case) where you
want to refer to css/image/etc resources located on the classpath (e.g.
under your project's "resources" directory somewhere).
this should fix the most common usage scenario where you would probably
like to be able to use e.g. <img> tags to point to image files that
exist locally within your project's "resources" directory somewhere.
the :base-uri option can still be overridden in the call to ->pdf for
the more uncommon scenarios
Open HTML to PDF's built-in support for this document tree conversion
breaks SVG support when using the Batik renderer. luckily, more recent
versions of JSoup include their own W3C document tree converter, so we
just use that one instead. and as a bonus, we're no longer using an
ancient version of JSoup.
the -fs-table-paginate property has an old and still unfixed bug where
it basically resets/ignores the border-collapse property of the table.
setting border-spacing to 0 is a workaround for this, but it does
result in borders that are a tad bit thicker then they would be if
-fs-table-paginate was not used
Gered
