I was able to get a valid PDF by removing the 8-bit restriction, but the font
name becomes gibberish. I spent some time looking for why we have such
restriction and the only thing I found was the following:
https://api.itextpdf.com/iText5/java/5.5.11/index.html?com/itextpdf/text/pdf/PdfName.html#:~:text=Class%20PdfName&text=PdfName%20is%20an%20object%20that,(page%2056-58)
When I went into the Manual mentioned I did not manage to find a reason for the
restriction. I also tried to create a font with the same font name as the one
in your PDF but FontForge had a similar restriction to FOP (ASCII characters
only and not the escaped characters).
I'm not sure if we should be changing FOP until we determine how the original
font was created. If we do change FOP, we could change the exception to a
warning but I'm not sure what else could be impacted by this change.
Thanks
-----Original Message-----
From: Mark Gibson <[email protected]>
Sent: 23 January 2026 09:03
To: [email protected]
Subject: RE: Font names using multi-byte strings
Thanks Chris.
Attached is the only example we have, and have knowingly seen. And we've been
working with Japanese clients for years now.
Mark
-----Original Message-----
From: Chris Bowditch <[email protected]>
Sent: 23 January 2026 14:44
To: [email protected]
Subject: Re: Font names using multi-byte strings
[EXTERNAL]
Hi Mark,
Are you able to attach your PDF so we can replicate this?
Thanks,
Chris
On 15/01/2026 17:09, Mark Gibson wrote:
>
> Hi,
>
> I thought I’d just poll the community on this one, as I can’t see it
> reported anywhere.
>
> We have a PDF that lists its fonts using Japanese characters (in this
> case, it’s MS Gothic and MS PGothic, where “Gothic” actually is in
> Japanese characters).
>
> When trying to import that image using fo:external-graphic
> (fop-pdf-images.jar), we get an exception with the message “Only 8-bit
> characters allowed by this implementation”.
>
> In reviewing FOP code, org.apache.fop.pdf.PDFName.toHex() throws this
> exception if the character id is > 256.
>
> Does this mean FOP cannot handle cases where the names of PDF records
> are not in simple ascii range?
>
> Caused by: java.lang.IllegalArgumentException: Only 8-bit characters
> allowed by this implementation
>
> at org.apache.fop.pdf.PDFName.toHex(PDFName.java:78)
>
> at org.apache.fop.pdf.PDFName.escapeName(PDFName.java:64)
>
> at org.apache.fop.pdf.PDFName.<init>(PDFName.java:42)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFClon
> er.java:106)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner
> .java:154)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFClon
> er.java:104)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSObject(PDFCloner.jav
> a:134)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFClon
> er.java:84)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner
> .java:154)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFClon
> er.java:104)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner
> .java:154)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFClon
> er.java:104)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFBoxAdapter.cloneForNewDocument(PDF
> BoxAdapter.java:141)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFBoxAdapter.createStreamFromPDFBoxP
> age(PDFBoxAdapter.java:212)
>
> at
> org.apache.fop.render.pdf.pdfbox.AbstractPDFBoxHandler.createStreamFor
> PDF(AbstractPDFBoxHandler.java:111)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFBoxImageHandler.handleImage(PDFBox
> ImageHandler.java:77)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
________________________________
Joao Andre Goncalves
Customer Developer
t | m 07733161880
[email protected]
smartcommunications.com<https://www.smartcommunications.com/>
[https://www.smartcommunications.com/wp-content/uploads/025_Trends2026-450x160_v1.jpg]<https://scale.smartcommunications.com/2026-Trends-White-Paper.html?utm_source=outlook&utm_medium=email&utm_campaign=wc-global-2026-white-paper-2026-trends>
Explore the new era of AI-powered customer engagement. Get your copy of the
2026 Trends Report
now.<https://scale.smartcommunications.com/2026-Trends-White-Paper.html?utm_source=outlook&utm_medium=email&utm_campaign=wc-global-2026-white-paper-2026-trends>
Smart Communications is a trading name of SmartComms SC Limited which is
registered in England under No. 4303041 whose registered office is at Suite 23,
LCLB, 95 Mortimer Street, London, W1W 7GB. Please consider the environment
before printing. The contents of this e-mail are intended for the named
addressee only. It contains confidential information. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. Smart Communications will process your data as described in
the Smart Communications' External Privacy
Policy.<https://www.smartcommunications.com/external-privacy-policy/>
Follow us on LinkedIn,<https://www.linkedin.com/company/15166060/admin/>
YouTube,<https://www.youtube.com/@Smart_Communications/> and
X.<https://x.com/ccminnovators?lang=en>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
