[
https://issues.apache.org/jira/browse/FOP-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245647#comment-15245647
]
adam Retter edited comment on FOP-2601 at 4/18/16 1:23 PM:
-----------------------------------------------------------
Hi Chris, the problem for us came because font-base was removed, previously we
were able to use that. As we now can't use it we had to write our own
URIResolver. Our fonts are stored and then being loaded from within our
document database, so it makes sense to use a custom URI scheme to retrieve the
fonts.
I think the mistake in Fop was not in allowing custom URI schemes, but rather
later in the font-cache making the assumption that somehow these would all be
resolvable by java.io.File, which is obviously not correct.
I would argue that not everyone that embeds FOP will write their own
URIResolver, I suspect that actually as FOP already supports `http` and `file`
schemes out of the box, then very few people will actually implement their own
resolvers.
I do understand that this is a small architectural change, but actually I can't
see a better way to fix the deficiency in the font-caching, however I am open
to any suggestions you might have on changes to this approach.
was (Author: adamretter):
Hi Chris, the problem for us came because font-base was removed, previously we
were able to use that. As we now can't use it we had to write our own
URIResolver. Our fonts are stored and then being loaded from within our
document database, so it makes sense to use a custom URI scheme to retrieve the
fonts.
I think the mistake in Fop was not allowing custom URI schemes, but later in
the font-cache making the assumption that somehow these would all be resolvable
by java.io.File, which is obviously not correct.
I would argue that not everyone that embeds FOP will write their own
URIResolver, I suspect that actually as FOP already supports `http` and `file`
schemes out of the box, then very few people will actually implement their own
resolvers.
I do understand that this is a small architectural change, but actually I can't
see a better way to fix the deficiency in the font-caching, however I am open
to any suggestions you might have on changes to this approach.
> [PATCH] Cannot resolve fonts from custom URI schemes
> ----------------------------------------------------
>
> Key: FOP-2601
> URL: https://issues.apache.org/jira/browse/FOP-2601
> Project: FOP
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: adam Retter
> Attachments: fop-last-modified-resolution.patch,
> xmlgraphics-commons-last-modified-resolution.patch
>
>
> I attach two patches (one for xmlgraphics-commons and one for fop) that allow
> fonts to be resolved from custom URI schemes. Previously this only worked if
> you disabled font caching, because the font cache tries to get the last
> modified date using java.io.File, which will fail for fonts that are resolved
> from locations other than the filesystem. The fix is relatively trivial,
> basically the UriResolver needs to also be able to resolve the last modified
> date of the resource or return -1 if it is not possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
