[
https://issues.apache.org/jira/browse/PDFBOX-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861221#comment-16861221
]
Henning von Bargen commented on PDFBOX-4565:
--------------------------------------------
Right. Even if the idea proposed by Maruan Sahyoun might work, it would be a
code smell.
Anyway, I realized that (for my idea of porting BIRT to PDFBox) I need three
different tasks basically:
# Scan the file system once, and for each font, get some basic information
about it (postscript name, family name, weight (bold or not), style (italic or
not), and probably more info (serif-less?, fixed-pitch width?), and store this
information in a cache.
# Find out if a font supports a character or better unicode code-point
# For a given PDDocument (to write) and a combination of family name, weight,
style etc. choose a font from the cache as a PDFont.
My first approach was to combine tasks 1 and 3.
This failed due to the PDFBox limitations mentioned in this issue.
*Probably that was using FontBox and PDFBox in a wrong way.*
I now decided to divide this in two parts 1 and 3.
For part 1, I can go with FontBox alone (without PDFBox). I'll need something
like a MyFontInfo class, probably I'll have to write that myself. As a result
of part 1, I'll have
* a map postscriptname->MyFontInfo
* a function MyFontInfo(template, with only some attributes specified) ->
postscriptname
This will allow the program to choose a specific (TTF) font for a given
combination of font attributes.
For part 3, I need an additional cache which maps MyFontInfo templates to
PDFont instances.
*While working on parts 1 and 3, I noticed the following possible improvements
for FontBox/PDFBox:*
For finding out if a font is bold or italic etc., I had to use different
low-level functions like this:
{{OS2WindowsMetricsTable os2 = ttf.getOS2Windows();}}
{{ int fsSelection = os2.getFsSelection();}}
{{ if ((fsSelection & (OS2_ITALIC | OS2_OBLIQUE)) != 0}}
A common API inside FontBox would help make a developer's life easier.
_In fact, classes can be found in PDFBox pdmodel.font package which look as if
they are made for tasks 1 and 3: FontInfo, FontProvider, FontMapper,
FileSystemFontProvider, FileSystemFontProvider.FSFontInfo, PDFontDescriptor,
PDFontFactory. But I failed using them actually._
For part 2, the PDFBox API seems sub-optimal, because it seems the only
solution is to call the PDFont encode method which returns a byte[] or raises
an exception. I'd prefer a simple boolean function similar to FontBoxFont
hasGlyph, but with a unicode code-point as input.
I'll close this issue anyway, because I could solve it by splitting parts 1 and
3.
Right now the next problem is BIRT's complicated build process, but that' not
related to PDFBox :).
> Make constructors PDPanoseClassification and CIDSystemInfo public
> -----------------------------------------------------------------
>
> Key: PDFBOX-4565
> URL: https://issues.apache.org/jira/browse/PDFBOX-4565
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox, PDModel
> Affects Versions: 2.0.15
> Reporter: Henning von Bargen
> Priority: Trivial
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> The constructors for the classes PDPanoseClassification and CIDSystemInfo are
> package-visible only (not public).
> This makes coding a different FontProvider similar to FileSystemFontProvider
> an unnecessarily hard task.
> Background:
> I'm working on replacing iText with PDFBox for Eclipse BIRT. One task is to
> support BIRTs fontconfig.xml for locating TTF fonts etc.
> Obviously I need something simlar to the FileSystemFontProvider, but instead
> of using the file system directly, use the information in BIRTs
> fontconfig.xml file.
> So I started with copying FileSystemFontProvider to a new class
> ConfigFontProvider in a different package.
> Now this fails because the classes PDPanoseClassification and CIDSystemInfo
> have non-public (package-only) constructors. So I'd have to copy a whole
> bunch of source files in order to make this work.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]