[
https://issues.apache.org/jira/browse/PDFBOX-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100421#comment-14100421
]
Petr Slaby commented on PDFBOX-2144:
------------------------------------
[~jahewson]: Thanks, that's basically exactly what I need. Just two questions.
In the old solution, AWT fonts were used to provide all missing fonts. The new
FontProvider interface has separate methods for substitution of ttf, cff and
type 1 fonts. Is it so that a PDF references an external type 1 font and I have
to provide a type 1 font then? Or is this used just when creating PDFs and the
normal way of getting an external font for rendering is
ExternalFonts.getType1EquivalentFont() which can return any of the flavors?
Also, I do not like the static methods in ExternalFonts so much. In our
environment, the configuration can change while the application is running. In
such case, renderings which have already been started have to use the old
configuration, renderings which will start later should use the new one. For
that, I would need the ExternalFonts to have an instance bound to PageDrawer.
It is a minor problem, though. I can probably solve it by binding the active
font configuration to current thread while rendering.
> Provide a pluggable font manager
> --------------------------------
>
> Key: PDFBOX-2144
> URL: https://issues.apache.org/jira/browse/PDFBOX-2144
> Project: PDFBox
> Issue Type: Improvement
> Components: Rendering
> Reporter: Petr Slaby
> Attachments: FontManager.patch
>
>
> Our J2EE application has all fonts and resources configured and stored in its
> database. No files are accessed directly from file system or from system
> environment. To make PDFBox compatible with this philosophy, we need the
> FontManager in pdfbox and fontbox to be pluggable, e.g. as shown in the
> attached patch.
> The proposal defines a FontManager interface and default implementation which
> is the original one. FontManager then needs to be configured on and
> propagated from PDFStreamEngine and PageDrawer. It should also be
> configurable on PDFRenderer, which is not shown in the patch. There I would
> suggest to introduce a configuration object which would take care about all
> the current and future options of PDFRenderer.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
