I tried that earlier but while the PDF is valid, the font name would not match the original PDF. I did find the following on the ISO document:
c) Any character that is not a regular character shall be written using its 2-digit hexadecimal code, preceded by the NUMBER SIGN only. FOP probably has this restriction because we can't display a char with an index over 255 with just 2 digits. Still, the original PDF does have that field with chars over 255 so it has to be possible. I'll keep looking for an alternative. Thanks From: Luca Bellonda <[email protected]> Sent: 28 January 2026 07:20 To: [email protected] Subject: Re: Font names using multi-byte strings You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> The ISO 32000-1 standard for PDF 1.7 (available free of charge from Adobe) in paragraph 7.3.5, page 18, states that the Name object, in some situations, can interpret numeric bytes as part of a UTF-8 string. There is also a note on Unicode normalization. Accepting all non-illegal characters and converting them to a UTF-8 sequence would likely be correct, even without generating warnings. Il Mar 27 Gen 2026, 22:23 Joao Andre Goncalves <[email protected]<mailto:[email protected]>> ha scritto: 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]<mailto:[email protected]>> Sent: 23 January 2026 09:03 To: [email protected]<mailto:[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]<mailto:[email protected]>> Sent: 23 January 2026 14:44 To: [email protected]<mailto:[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]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> ________________________________ Joao Andre Goncalves Customer Developer t | m 07733161880 [email protected]<mailto:[email protected]> smartcommunications.com<http://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]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]>
