Re: Font names using multi-byte strings
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 <
[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
RE: Font names using multi-byte strings
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 Sent: 29 January 2026 13:53 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> 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 mailto:[email protected]>> 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 [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>
Re: Font names using multi-byte strings
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 <
[email protected]> 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
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 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 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 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 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.(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.a
Re: Font names using multi-byte strings
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]> 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 > 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 > 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.(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 > >
RE: Font names using multi-byte strings
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 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 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.(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&
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 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.(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] 707685_876d5f93-a14f-4469-b588-a2b1044860b3.pdf Description: 707685_876d5f93-a14f-4469-b588-a2b1044860b3.pdf - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Font names using multi-byte strings
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.(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: [email protected] For additional commands, e-mail: [email protected]
