You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Mark Gibson <ma...@staff.bluematrix.com> on 2026/01/15 17:09:34 UTC
Font names using multi-byte strings
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(PDFCloner.java:106)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner.java:154)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:104)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSObject(PDFCloner.java:134)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:84)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner.java:154)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:104)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner.java:154)
at org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:104)
at org.apache.fop.render.pdf.pdfbox.PDFBoxAdapter.cloneForNewDocument(PDFBoxAdapter.java:141)
at org.apache.fop.render.pdf.pdfbox.PDFBoxAdapter.createStreamFromPDFBoxPage(PDFBoxAdapter.java:212)
at org.apache.fop.render.pdf.pdfbox.AbstractPDFBoxHandler.createStreamForPDF(AbstractPDFBoxHandler.java:111)
at org.apache.fop.render.pdf.pdfbox.PDFBoxImageHandler.handleImage(PDFBoxImageHandler.java:77)
Re: PDFSignature NullPointerException
Posted by David Law via fop-users <fo...@xmlgraphics.apache.org>.
ok, it turned out to be a problem with our custom ResourceResolver...
...returning null in getOutputStream(...) wasn't a good idea. 😎
Best regards,
DaveLaw
On 17/03/2026 12:50, David Law wrote:
> Hi there,
>
> I'm trying to create a signed PDF with FOP v2.11 & JDK 17.
>
> I am NOT using a Config file (i.e. fop.xconf).
>
> Instead I'm supplying an instance of PDFSignParams.
> -> FOP then internally creates an instance of PDFSignature.
> -> I've checked the PDFSignature instance is able to read the Keystore
> & sign content.
>
> When creating the PDF from the FO, a *NullPointerException* is raised.
> The only Method invoked on PDFSignature is add(final PDFPage page).
>
> The message is:
> Cannot invoke "java.io.OutputStream.write(byte[], int, int)" because
> "this.out" is null
>
> (I did something similar for encryption with an instance of
> PDFEncryptionParams. That worked fine)
>
> Before I take time to create a detailed example,
> I thought I'd ask if anyone has had the same problem.
>
> The generatePDFfromFO Method looks like this:
>
> private static byte[] generatePDFfromFO(final byte[] bytesFO, final
> TransformerFactory factory) throws Exception {
>
> final var foUserAgent = FOP_FACTORY.newFOUserAgent();
> ; foUserAgent.setProducer("ap FOP");
> ; foUserAgent.setCreationDate(new Date());
> ; foUserAgent.setTargetResolution(300 /* dpi */);
>
> final var foSignParms = new
> PDFSignParams("path/fopTest.pkcs12", null, null, null, "fopTest");
>
> @SuppressWarnings("unchecked")
> final var foRendOpt = (Map<Object, Object>)
> foUserAgent.getRendererOptions();
> ; foRendOpt.put("sign-params", foSignParms);
>
> final var pdfBytesSizeGuess = bytesFO.length / 2;
> final var pdfBytesBaos = new
> ByteArrayOutputStream(pdfBytesSizeGuess);
>
> try (pdfBytesBaos)
> {
> final var fop =
> foUserAgent.newFop(MimeConstants.MIME_PDF, pdfBytesBaos);
> final var saxResult = new
> SAXResult(fop.getDefaultHandler());
>
> final var xmlSource = getSource(bytesFO);
>
> final var transformer = factory.newTransformer();
> ; transformer.transform(xmlSource, saxResult); // ->
> *NullPointerException*
> }
> return pdfBytesBaos.toByteArray();
> }
>
> Any ideas, anyone?
>
> Thanks in advance,
> DaveLaw
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
FOP seems to think PNG Image is an SVG
Posted by David Law via fop-users <fo...@xmlgraphics.apache.org>.
Hi Folks,
I'm reading a PNG Image in our custom ResourceResolver.
It works & finds its way into the resulting PDF.
But...
...org.apache.fop.image.loader.batik.PreloaderSVG reports an error:
/"Error while trying to load stream as an SVG file: Invalid byte 1 of
1-byte UTF-8 sequence."
/
I've tried this...
return new Resource(MimeConstants.MIME_PNG, uri.toURL().openStream());
...but can't seem to find what type the Resource should have.
(also tried "PNG" & "png")
How can I tell FOP it's a PNG and not an SVG?
Thanks in advance,
DaveLaw
PDFSignature NullPointerException
Posted by David Law via fop-users <fo...@xmlgraphics.apache.org>.
Hi there,
I'm trying to create a signed PDF with FOP v2.11 & JDK 17.
I am NOT using a Config file (i.e. fop.xconf).
Instead I'm supplying an instance of PDFSignParams.
-> FOP then internally creates an instance of PDFSignature.
-> I've checked the PDFSignature instance is able to read the Keystore &
sign content.
When creating the PDF from the FO, a *NullPointerException* is raised.
The only Method invoked on PDFSignature is add(final PDFPage page).
The message is:
Cannot invoke "java.io.OutputStream.write(byte[], int, int)" because
"this.out" is null
(I did something similar for encryption with an instance of
PDFEncryptionParams. That worked fine)
Before I take time to create a detailed example,
I thought I'd ask if anyone has had the same problem.
The generatePDFfromFO Method looks like this:
private static byte[] generatePDFfromFO(final byte[] bytesFO, final
TransformerFactory factory) throws Exception {
final var foUserAgent = FOP_FACTORY.newFOUserAgent();
; foUserAgent.setProducer("ap FOP");
; foUserAgent.setCreationDate(new Date());
; foUserAgent.setTargetResolution(300 /* dpi */);
final var foSignParms = new
PDFSignParams("path/fopTest.pkcs12", null, null, null, "fopTest");
@SuppressWarnings("unchecked")
final var foRendOpt = (Map<Object, Object>)
foUserAgent.getRendererOptions();
; foRendOpt.put("sign-params", foSignParms);
final var pdfBytesSizeGuess = bytesFO.length / 2;
final var pdfBytesBaos = new
ByteArrayOutputStream(pdfBytesSizeGuess);
try (pdfBytesBaos)
{
final var fop =
foUserAgent.newFop(MimeConstants.MIME_PDF, pdfBytesBaos);
final var saxResult = new
SAXResult(fop.getDefaultHandler());
final var xmlSource = getSource(bytesFO);
final var transformer = factory.newTransformer();
; transformer.transform(xmlSource, saxResult); // ->
*NullPointerException*
}
return pdfBytesBaos.toByteArray();
}
Any ideas, anyone?
Thanks in advance,
DaveLaw
Re: Font names using multi-byte strings
Posted by David Law via fop-users <fo...@xmlgraphics.apache.org>.
Hi,
Would it make sense to use:
characters = name.substring((skipFirst ? 1 :
0)).getBytes(StandardCharsets.UTF_8);
...which does not throw an UnsupportedEncodingException?
All the best,
Dave
On 29/01/2026 20:53, Luca Bellonda wrote:
> I was able to get the same name and I suggest this method:
> 1- Translate the string to UTF-8 bytes representation.
> 2- Get the bytes and encode them instead of characters.
>
> This way the UTF-8 statement should be respected.
> In code (beware: not efficient and without error management):
>
> in escapeName of PDFName:
>
> byte[] characters ;
> // get UTF-8 bytes
> try {
> characters = name.substring((skipFirst ? 1 : 0)).getBytes("UTF-8");
> } catch (UnsupportedEncodingException e) {
> throw new RuntimeException("Invalid Name:"+name);
> }
>
> // encode bytes
> for (int i = 0, c = characters.length; i < c; i++) {
> int ch = (0x00FF&characters[i]);
>
> if (ch < 33 || ch > 126 || ESCAPED_NAME_CHARS.indexOf(ch) >= 0)
> {
> sb.append('#');
> toHex(ch, sb);
> } else {
> char cxc = (char)ch ;
> sb.append(cxc);
> }
> }
> return sb.toString();
>
> where toHex() manages an int
>
> Best regards.
>
> Il giorno gio 29 gen 2026 alle ore 01:28 Joao Andre Goncalves <
> JGoncalves@smartcommunications.com> ha scritto:
>
>> 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.
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Font names using multi-byte strings
Posted by Joao Andre Goncalves <JG...@SmartCommunications.com>.
Thanks,
your suggestion seems to work. I'll had some unit tests and get in merge in the next couple of days.
From: Luca Bellonda <lb...@gmail.com>
Sent: 29 January 2026 13:53
To: fop-users@xmlgraphics.apache.org
Subject: Re: Font names using multi-byte strings
You don't often get email from lbellonda@gmail.com<ma...@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
I was able to get the same name and I suggest this method:
1- Translate the string to UTF-8 bytes representation.
2- Get the bytes and encode them instead of characters.
This way the UTF-8 statement should be respected.
In code (beware: not efficient and without error management):
in escapeName of PDFName:
byte[] characters ;
// get UTF-8 bytes
try {
characters = name.substring((skipFirst ? 1 : 0)).getBytes("UTF-8");
} catch (UnsupportedEncodingException e) {
throw new RuntimeException("Invalid Name:"+name);
}
// encode bytes
for (int i = 0, c = characters.length; i < c; i++) {
int ch = (0x00FF&characters[i]);
if (ch < 33 || ch > 126 || ESCAPED_NAME_CHARS.indexOf(ch) >= 0) {
sb.append('#');
toHex(ch, sb);
} else {
char cxc = (char)ch ;
sb.append(cxc);
}
}
return sb.toString();
where toHex() manages an int
Best regards.
Il giorno gio 29 gen 2026 alle ore 01:28 Joao Andre Goncalves <JG...@smartcommunications.com>> ha scritto:
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.
________________________________
Joao Andre Goncalves
Customer Developer
t | m 07733161880
JGoncalves@SmartCommunications.com
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>
Re: Font names using multi-byte strings
Posted by Luca Bellonda <lb...@gmail.com>.
I was able to get the same name and I suggest this method:
1- Translate the string to UTF-8 bytes representation.
2- Get the bytes and encode them instead of characters.
This way the UTF-8 statement should be respected.
In code (beware: not efficient and without error management):
in escapeName of PDFName:
byte[] characters ;
// get UTF-8 bytes
try {
characters = name.substring((skipFirst ? 1 : 0)).getBytes("UTF-8");
} catch (UnsupportedEncodingException e) {
throw new RuntimeException("Invalid Name:"+name);
}
// encode bytes
for (int i = 0, c = characters.length; i < c; i++) {
int ch = (0x00FF&characters[i]);
if (ch < 33 || ch > 126 || ESCAPED_NAME_CHARS.indexOf(ch) >= 0)
{
sb.append('#');
toHex(ch, sb);
} else {
char cxc = (char)ch ;
sb.append(cxc);
}
}
return sb.toString();
where toHex() manages an int
Best regards.
Il giorno gio 29 gen 2026 alle ore 01:28 Joao Andre Goncalves <
JGoncalves@smartcommunications.com> ha scritto:
> 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.
>
>
>
RE: Font names using multi-byte strings
Posted by Joao Andre Goncalves <JG...@SmartCommunications.com>.
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 <lb...@gmail.com>
Sent: 28 January 2026 07:20
To: fop-users@xmlgraphics.apache.org
Subject: Re: Font names using multi-byte strings
You don't often get email from lbellonda@gmail.com<ma...@gmail.com>. 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 <JG...@smartcommunications.com>> 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 <ma...@staff.bluematrix.com>>
Sent: 23 January 2026 09:03
To: fop-users@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
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 <bo...@hotmail.com>>
Sent: 23 January 2026 14:44
To: fop-users@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
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: fop-users-unsubscribe@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
________________________________
Joao Andre Goncalves
Customer Developer
t | m 07733161880
JGoncalves@SmartCommunications.com<ma...@SmartCommunications.com>
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: fop-users-unsubscribe@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
Re: Font names using multi-byte strings
Posted by Luca Bellonda <lb...@gmail.com>.
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 <
JGoncalves@smartcommunications.com> 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 <ma...@staff.bluematrix.com>
> Sent: 23 January 2026 09:03
> To: fop-users@xmlgraphics.apache.org
> 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 <bo...@hotmail.com>
> Sent: 23 January 2026 14:44
> To: fop-users@xmlgraphics.apache.org
> 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: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
> ________________________________
> Joao Andre Goncalves
> Customer Developer
>
> t | m 07733161880
> JGoncalves@SmartCommunications.com
> 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: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
RE: Font names using multi-byte strings
Posted by Joao Andre Goncalves <JG...@SmartCommunications.com>.
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 <ma...@staff.bluematrix.com>
Sent: 23 January 2026 09:03
To: fop-users@xmlgraphics.apache.org
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 <bo...@hotmail.com>
Sent: 23 January 2026 14:44
To: fop-users@xmlgraphics.apache.org
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
________________________________
Joao Andre Goncalves
Customer Developer
t | m 07733161880
JGoncalves@SmartCommunications.com
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Font names using multi-byte strings
Posted by Mark Gibson <ma...@staff.bluematrix.com>.
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 <bo...@hotmail.com>
Sent: 23 January 2026 14:44
To: fop-users@xmlgraphics.apache.org
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Font names using multi-byte strings
Posted by Chris Bowditch <bo...@hotmail.com>.
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(PDFCloner.java:106)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner.java:154)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:104)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSObject(PDFCloner.java:134)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:84)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner.java:154)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:104)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.readCOSDictionary(PDFCloner.java:154)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFCloner.cloneForNewDocument(PDFCloner.java:104)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFBoxAdapter.cloneForNewDocument(PDFBoxAdapter.java:141)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFBoxAdapter.createStreamFromPDFBoxPage(PDFBoxAdapter.java:212)
>
> at
> org.apache.fop.render.pdf.pdfbox.AbstractPDFBoxHandler.createStreamForPDF(AbstractPDFBoxHandler.java:111)
>
> at
> org.apache.fop.render.pdf.pdfbox.PDFBoxImageHandler.handleImage(PDFBoxImageHandler.java:77)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org