Am 10.02.2026 um 12:55 schrieb Daniel Gredler:
Hi Tilman,
It looks like I may need to go back to 2.x for now. The on-demand table
loading removed in PDFBOX-5460 (
https://issues.apache.org/jira/browse/PDFBOX-5460) was important for me,
and the header-only mode added in PDFBOX-5847 (
https://issues.apache.org/jira/browse/PDFBOX-5847), which might have served
as a sort of replacement, doesn't include all of the information I'm
currently reading (e.g. units per em or horizontal header info), since it's
very focused on just supporting the needs of
FileSystemFontProvider.scanFonts(). Is a more generic on-demand load mode
completely off the table for 3.0?
Re your last question, I'd prefer not to touch that part due to the
problems we had when it existed. But we could get UnitsPerEm because we
read that table in HeaderTable.readHeaders(). What do you mean with
"horizontal header info"? Do you need the complete "head" or "hhea"
table? That would be too much. It might be easier for you to fork that
code and delete everything you don't need and just get the values you
want. And then use the official fontbox for the actual work.
Tilman
Take care,
Daniel
On Mon, Feb 9, 2026 at 10:15 PM Daniel Gredler<[email protected]> wrote:
Actually, it looks like a JIRA entry won't be necessary. Switching to
OTFParser seems to do the trick for this file.
Further, I think the difference in behavior was due to the disappearance
of the "parseOnDemand" option, which I was using (when on-demand is enabled
in FontBox 2.x, this CFF validation doesn't run).
Thanks again for the pointers!
Daniel
On Mon, Feb 9, 2026 at 9:13 PM Daniel Gredler<[email protected]> wrote:
That's odd. It has a ".otf" file extension, and FontBox 2.x didn't seem
to have any issues with it.
I'll create a JIRA issue with more information, since it sounds like
feature parity is expected here (and I should be able to attach the
offending file).
Take care,
Daniel
On Mon, Feb 9, 2026 at 8:57 PM Tilman Hausherr<[email protected]>
wrote:
Am 09.02.2026 um 20:43 schrieb Daniel Gredler:
Ah, got it -- thanks! This indeed fixed the EOF issue.
However, I'm now getting the following error: "True Type fonts using
CFF
outlines are not supported"
This is while reading the Noto Sans CJK Regular font file. Is this an
area
where FontBox 3.x functionality is more limited than FontBox 2.x was?
No, you should get the same exception in 2.0. If you don't have it as a
ttf file, it should work as a ttc file, however the calls are different
https://github.com/notofonts/noto-cjk/tree/main/Sans/OTC
https://github.com/notofonts/noto-cjk/tree/main/Sans
from the EmbeddedMultipleFonts.java example
TrueTypeCollection ttc2 = new TrueTypeCollection(new
File("c:/windows/fonts/batang.ttc"));
PDType0Font font2 = PDType0Font.load(document,
ttc2.getFontByName("Batang"), true); // Korean
TrueTypeCollection can take an inputstream.
However I see from that website that ttf files are also available, if
you know which country you need.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
