[jira] [Commented] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369771#comment-16369771
 ] 

Michaël Krens commented on PDFBOX-3631:
---

Done, same result unfortunately.

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4116) could not add text without unicode in the font

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369763#comment-16369763
 ] 

Tilman Hausherr edited comment on PDFBOX-4116 at 2/20/18 6:39 AM:
--

If it works fine, what is your question now? Re DrawPrintTextLocations, see the 
comments there... the cyan bounds is the most reliable, except for type 3 
fonts. The red is heuristics. The blue is the bounding box for all.


was (Author: tilman):
If it works fine, what is your question now? Re DrawPrintTextLocations, see the 
comments there... the cyan bounds is the most reliable, except for type 3 fonts.

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png, image-2018-02-19-17-42-18-260.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4116) could not add text without unicode in the font

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369763#comment-16369763
 ] 

Tilman Hausherr commented on PDFBOX-4116:
-

If it works fine, what is your question now? Re DrawPrintTextLocations, see the 
comments there... the cyan bounds is the most reliable, except for type 3 fonts.

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png, image-2018-02-19-17-42-18-260.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3631) Signature Interoperability Issue

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369759#comment-16369759
 ] 

Tilman Hausherr commented on PDFBOX-3631:
-

Could you try signing the files with the 2.0.9 snapshot? I wonder if the 
problem is related to PDFBOX-4011.

https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.9-SNAPSHOT/

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Issue Comment Deleted] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Lehmkühler updated PDFBOX-3631:
---
Comment: was deleted

(was: Oggetto: Fuori ufficio
  
Salve,
rientrerò in ufficio il 26 Febbraio 2018.

In questo periodo avrò accesso limitato alla posta, risponderò appena possibile 
al rientro.


Saluti,
Vincenzo
)

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Issue Comment Deleted] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Lehmkühler updated PDFBOX-3631:
---
Comment: was deleted

(was: Oggetto: Fuori ufficio
  
Salve,
rientrerò in ufficio il 26 Febbraio 2018.

In questo periodo avrò accesso limitato alla posta, risponderò appena possibile 
al rientro.


Saluti,
Vincenzo
)

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369736#comment-16369736
 ] 

Michaël Krens edited comment on PDFBOX-3631 at 2/20/18 5:32 AM:


I've done some testing in various browsers / readers. Here the screenshots:

chrome_rendering_incorrect.png:

!chrome_rendering_incorrect.png|width=487,height=309!

acrobat_rendering_correct.png:

!acrobat_rendering_correct.png|width=569,height=362!

libreoffice_rendering_correct.png:

!libreoffice_rendering_correct.png|width=499,height=307!

Microsoft_Edge_on_Windows_10_rendering_correct.png:

!Microsoft_Edge_on_Windows_10_rendering_correct.png|width=512,height=386!

preview_of_Preview_rendering_correct.png:

!preview_of_Preview_rendering_correct.png|width=552,height=407!

Preview_rendering_not_correct.png:

!Preview_rendering_not_correct.png|width=591,height=449!

This pdf is always rendering correct in the above cases: 
[^working_pdf_with_signatures.pdf]

This pdf is signed with PDFBox and used for the screenshots: 
[^not_working_pdf_with_signatures.pdf]

Note that the Preview issue might be a different one but as the other file also 
works in Preview this might be related.
 It looks like this is related the Preview issue: 
[http://www.openradar.me/34276970] (in which case it also might be related to 
this issue somehow).

 


was (Author: mkrens):
I've done some testing in various browsers / readers. Here the screenshots:

chrome_rendering_incorrect.png:

!chrome_rendering_incorrect.png!

acrobat_rendering_correct.png:

!acrobat_rendering_correct.png!

libreoffice_rendering_correct.png:

!libreoffice_rendering_correct.png!

Microsoft_Edge_on_Windows_10_rendering_correct.png:

!Microsoft_Edge_on_Windows_10_rendering_correct.png!

preview_of_Preview_rendering_correct.png:

!preview_of_Preview_rendering_correct.png!

Preview_rendering_not_correct.png:

!Preview_rendering_not_correct.png!

This pdf is always rendering correct in the above cases: 
[^working_pdf_with_signatures.pdf]

This pdf is signed with PDFBox and used for the screenshots: 
[^not_working_pdf_with_signatures.pdf]

Note that the Preview issue might be a different one but as the other file also 
works in Preview this might be related.
 It looks like this is related the Preview issue: 
[http://www.openradar.me/34276970] (in which case it also might be related to 
this issue somehow).

 

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369736#comment-16369736
 ] 

Michaël Krens commented on PDFBOX-3631:
---

I've done some testing in various browsers / readers. Here the screenshots:

chrome_rendering_incorrect.png:

!chrome_rendering_incorrect.png!

acrobat_rendering_correct.png:

!acrobat_rendering_correct.png!

libreoffice_rendering_correct.png:

!libreoffice_rendering_correct.png!

Microsoft_Edge_on_Windows_10_rendering_correct.png:

!Microsoft_Edge_on_Windows_10_rendering_correct.png!

preview_of_Preview_rendering_correct.png:

!preview_of_Preview_rendering_correct.png!

Preview_rendering_not_correct.png:

!Preview_rendering_not_correct.png!

This pdf is always rendering correct in the above cases: 
[^working_pdf_with_signatures.pdf]

This pdf is signed with PDFBox and used for the screenshots: 
[^not_working_pdf_with_signatures.pdf]

Note that the Preview issue might be a different one but as the other file also 
works in Preview this might be related.
 It looks like this is related the Preview issue: 
[http://www.openradar.me/34276970] (in which case it also might be related to 
this issue somehow).

 

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michaël Krens updated PDFBOX-3631:
--
Attachment: working_pdf_with_signatures.pdf
not_working_pdf_with_signatures.pdf
preview_of_Preview_rendering_correct.png
Preview_rendering_not_correct.png
acrobat_rendering_correct.png
chrome_rendering_incorrect.png
safari_using_preview_incorrect.png
firefox_incorrect_but_expected.png
libreoffice_rendering_correct.png
Microsoft_Edge_on_Windows_10_rendering_correct.png

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: Microsoft_Edge_on_Windows_10_rendering_correct.png, 
> PDFBOX-3631.zip, PDFJS-4743-signature.pdf, Preview_rendering_not_correct.png, 
> acrobat_rendering_correct.png, chrome_rendering_incorrect.png, 
> firefox_incorrect_but_expected.png, libreoffice_rendering_correct.png, 
> not_working_pdf_with_signatures.pdf, 
> preview_of_Preview_rendering_correct.png, safari_using_preview_incorrect.png, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf, 
> working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3631) Signature Interoperability Issue

[Vincenzo Mangiapanello (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369704#comment-16369704
 ] 

Vincenzo Mangiapanello commented on PDFBOX-3631:


Oggetto: Fuori ufficio
  
Salve,
rientrerò in ufficio il 26 Febbraio 2018.

In questo periodo avrò accesso limitato alla posta, risponderò appena possibile 
al rientro.


Saluti,
Vincenzo


> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: PDFBOX-3631.zip, PDFJS-4743-signature.pdf, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michaël Krens updated PDFBOX-3631:
--
Attachment: working_pdf_with_signatures.pdf

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: PDFBOX-3631.zip, PDFJS-4743-signature.pdf, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369701#comment-16369701
 ] 

Michaël Krens commented on PDFBOX-3631:
---

We just hit this issue and will also try to find the root issue here. Here also 
a file signed with pdfbox that fails. The file contains 5 signatures but only 1 
is shown. [^test_out_pdf.pdf]. Here the same file signed with a different 
product. [^working_pdf_with_signatures.pdf]

IMHO not a 'minor' issue as chrome by default opens downloaded pdf's in the 
browser.

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: PDFBOX-3631.zip, PDFJS-4743-signature.pdf, 
> test_out_pdf.pdf, working_pdf_with_signatures.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3631) Signature Interoperability Issue

[Vincenzo Mangiapanello (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369695#comment-16369695
 ] 

Vincenzo Mangiapanello commented on PDFBOX-3631:


Oggetto: Fuori ufficio
  
Salve,
rientrerò in ufficio il 26 Febbraio 2018.

In questo periodo avrò accesso limitato alla posta, risponderò appena possibile 
al rientro.


Saluti,
Vincenzo


> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: PDFBOX-3631.zip, PDFJS-4743-signature.pdf, 
> test_out_pdf.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-3631) Signature Interoperability Issue

[JIRA]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michaël Krens updated PDFBOX-3631:
--
Attachment: test_out_pdf.pdf

> Signature Interoperability Issue
> 
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
>  Issue Type: Bug
>  Components: Signing
>Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
>Reporter: Marco Monacelli
>Priority: Minor
> Attachments: PDFBOX-3631.zip, PDFJS-4743-signature.pdf, 
> test_out_pdf.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome, 
> pdfium foxit. 
> If the same file is signed on some Actobat, Foxit or itext the signature is 
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to 
> communicate the password with a private message.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369571#comment-16369571
 ] 

xing Wang edited comment on PDFBOX-4116 at 2/19/18 11:42 PM:
-

Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
 ^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
 ^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I just tried the example in 
[https://apache.googlesource.com/pdfbox/+/trunk/examples/src/main/java/org/apache/pdfbox/examples/util/DrawPrintTextLocations.java]
 to locate the exact bounding box, and it seems to works perfect fine.^ 

  !image-2018-02-19-17-42-18-260.png!


was (Author: william_wang_007):
Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
 ^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
 ^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I just tried the example in 
[https://apache.googlesource.com/pdfbox/+/trunk/examples/src/main/java/org/apache/pdfbox/examples/util/DrawPrintTextLocations.java]
 to locate the exact bounding box, and it seems to works perfect fine.^ 

 

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png, image-2018-02-19-17-42-18-260.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, 

[jira] [Comment Edited] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369571#comment-16369571
 ] 

xing Wang edited comment on PDFBOX-4116 at 2/19/18 11:41 PM:
-

Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
 ^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
 ^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I just tried the example in 
[https://apache.googlesource.com/pdfbox/+/trunk/examples/src/main/java/org/apache/pdfbox/examples/util/DrawPrintTextLocations.java]
 to locate the exact bounding box, and it seems to works perfect fine.^ 

 


was (Author: william_wang_007):
Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
 ^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
 ^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I will try to repeat the process in pdfbox. If possible, could you point me 
the procedures to get the glyph bbox?^

 

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369571#comment-16369571
 ] 

xing Wang commented on PDFBOX-4116:
---

Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf][^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I will try to repeat the process in pdfbox. If possible, could you point me 
the procedures to get the glyph bbox?^

 

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369571#comment-16369571
 ] 

xing Wang edited comment on PDFBOX-4116 at 2/19/18 10:15 PM:
-

Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
 ^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
 ^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I will try to repeat the process in pdfbox. If possible, could you point me 
the procedures to get the glyph bbox?^

 


was (Author: william_wang_007):
Hi [~tilman]

> So sometimes the code there is identical to the unicode value, but often it 
> is not.

I agree with your statement, especially I am working on the math expression 
intensive papers. 

The reason I want to create PDF document is to get the tight bounding box for 
the glyph, which is critical for my analysis. For example, in the attached 
file. I could not correctly get the tight bounding box of the glyph. 

[^6076-learn589519560.pdf.CMSY10.minus.pdf][^6076-learn589519560.pdf.CMSY10.minus.pdf]

 

^I am using a different tool, but I will try pdfbox soon.^ ^My procedure is as 
follows:^
 # ^use the pdfbox to render the glyph as the pdfbox-debugger do. and on the 
rendered image for the glyph to get how to adjust the top and bottom. Such as 
the one with code 33, with glyph name "minus"^
^!image-2018-02-19-16-11-24-611.png!^

 # ^Then I use pdfminer, which is a python tool to get the glyph bounding box 
show in the red.^ 
^!image-2018-02-19-16-12-23-438.png!^

 # ^I assume the black pixels in red bbox should be of the same portion w.r.t 
the rendered bufferimage in step. But this is not true. For the minus in step 
1, it's roughly in the middle, but for the red bbox, it's a bit in the upper 
half.^ 

^I will try to repeat the process in pdfbox. If possible, could you point me 
the procedures to get the glyph bbox?^

 

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

xing Wang updated PDFBOX-4116:
--
Attachment: image-2018-02-19-16-12-23-438.png

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4116) could not add text without unicode in the font

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369570#comment-16369570
 ] 

Tilman Hausherr commented on PDFBOX-4116:
-

The newline is are missing after the operator in the PDF you attached. (if that 
was your question... I am now going to sleep)

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png, 
> image-2018-02-19-16-12-23-438.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

xing Wang updated PDFBOX-4116:
--
Attachment: image-2018-02-19-16-11-24-611.png

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png, image-2018-02-19-16-11-24-611.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

xing Wang updated PDFBOX-4116:
--
Attachment: 6076-learn589519560.pdf.CMSY10.minus.pdf

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

xing Wang updated PDFBOX-4116:
--
Attachment: 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png
6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: 6076-learn589519560.pdf.CMSY10.minus.pdf, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.adj_char_bbox.0.png, 
> 6076-learn589519560.pdf.CMSY10.minus.pdf.org_char_bbox.0.png, 
> image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4116) could not add text without unicode in the font

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369555#comment-16369555
 ] 

Tilman Hausherr commented on PDFBOX-4116:
-

"embedded" is the correct word. The embedded subsetted fonts shouldn't be 
reused for the two reasons I mentioned, i.e. (1) sometimes missing unicode, and 
(2) missing glyphs. (1) is what you had, (2) is because it is subsetted, i.e. 
such a subset won't have all the glyphs, so you may have "a", "b" and "d" but 
not "c".

{color:#33}"This may or may not work"{color} is because the "raw" command 
parameter is just the end of a chain of calculations. So sometimes the code 
there is identical to the unicode value, but often it is not.

In other words: you'll often have a very bad day reusing subsetted fonts. 
Better get the original font.

I am surprised that you wrote "{color:#33}I am working on extracting 
information from PDF publications" but what you really did was adding 
text.{color}

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Fwd: Travel Assistance applications open. Please inform your communities

[Andreas Lehmkuehler]

Forwarded on behalf of TAC ...

—
The Travel Assistance Committee (TAC) are pleased to announce that travel 
assistance applications for ApacheCon NA 2018 are now open!


We will be supporting ApacheCon NA Montreal, Canada on 24th - 29th September 
2018

 TAC exists to help those that would like to attend ApacheCon events, but are 
unable to do so for financial reasons. For more info on this years applications 
and qualifying criteria, please visit the TAC website at < 
http://www.apache.org/travel/  >. Applications 
are now open and will close 1st May.
Important: Applications close on May 1st, 2018. Applicants have until the 
closing date above to submit their applications (which should contain as much 
supporting material as required to efficiently and accurately process their 
request), this will enable TAC to announce successful awards shortly afterwards.
As usual, TAC expects to deal with a range of applications from a diverse range 
of backgrounds. We therefore encourage (as always) anyone thinking about sending 
in an application to do so ASAP.   We look forward to greeting many of you in 
Montreal


Kind Regards, Gavin - (On behalf of the Travel Assistance Committee)
—



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369547#comment-16369547
 ] 

xing Wang commented on PDFBOX-4116:
---

Hi Tilman, 

Thanks for your response.

I am working on extracting information from PDF publications. It seems very 
common that the subsetted fonts are "embedded" (not sure whether I used the 
right word). I agree that some missing information did cause great trouble in 
my analysis. 

May I ask why they should not be reused? Why the "first" time use works?

Another thing is that you mentioned "This may or may not work", do you mean the 
appendRawCommands is not stable? As later I managed to convert string PDF 
command into bytes and change the content of a page. 

 

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4112) Build and test PDFBox with JDK10

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369498#comment-16369498
 ] 

Tilman Hausherr commented on PDFBOX-4112:
-

KCMS is either no longer available on jdk10, or it must be added with some 
command. All I could find is this:

http://hg.openjdk.java.net/jdk/jdk/log?rev=kcms

This suggests that it been removed 19 months ago, in July 2016.

> Build and test PDFBox with JDK10
> 
>
> Key: PDFBOX-4112
> URL: https://issues.apache.org/jira/browse/PDFBOX-4112
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: jdk10
>
> Issue to collect problems and solutions for building and testing PDFBox with 
> JDK10.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4112) Build and test PDFBox with JDK10

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369493#comment-16369493
 ] 

ASF subversion and git services commented on PDFBOX-4112:
-

Commit 1824810 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1824810 ]

PDFBOX-4112: output text if KCMS is no longer available

> Build and test PDFBox with JDK10
> 
>
> Key: PDFBOX-4112
> URL: https://issues.apache.org/jira/browse/PDFBOX-4112
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: jdk10
>
> Issue to collect problems and solutions for building and testing PDFBox with 
> JDK10.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4112) Build and test PDFBox with JDK10

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369491#comment-16369491
 ] 

ASF subversion and git services commented on PDFBOX-4112:
-

Commit 1824809 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1824809 ]

PDFBOX-4112: output text if KCMS is no longer available

> Build and test PDFBox with JDK10
> 
>
> Key: PDFBOX-4112
> URL: https://issues.apache.org/jira/browse/PDFBOX-4112
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: jdk10
>
> Issue to collect problems and solutions for building and testing PDFBox with 
> JDK10.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4116) could not add text without unicode in the font

[Tilman Hausherr (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-4116:

Environment: Windows  (was: Windows, 2.0.8 of pdfbox. )

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows
>Reporter: xing Wang
>Priority: Minor
> Attachments: image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4116) could not add text without unicode in the font

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369465#comment-16369465
 ] 

Tilman Hausherr commented on PDFBOX-4116:
-

You shouldn't reuse subsetted fonts. There are many things that can go wrong, 
the most common is missing unicode (this is needed for PDFBox) or missing 
glyphs.

We're not planning to remove {{{color:#33}appendRawCommands{color}}} 
(Maruan and I agreed on that a few days ago), but it is risky. This may or may 
not work.

> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows, 2.0.8 of pdfbox. 
>Reporter: xing Wang
>Priority: Minor
> Attachments: image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2142) some /ICCBased colorspaces not rendered correctly

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369415#comment-16369415
 ] 

Tilman Hausherr commented on PDFBOX-2142:
-

Just for the record...

When using jdk8 + LCMS then the CIELAB Logo is correct (black), without it is 
blue. And everything else with CIELAB is correct too.

on jdk9 + KCMS the CIELAB stuff is still bad.

on jdk10 + KCMS the CIELAB stuff is correct.

on jdk8,jdk9,jdk10 + KCMS two XYZ colors from the right are wrong.

So using (new + slow) LCMS on jdk8 or (old + fast) KCMS on jdk10 fixes the 
CIELAB part. The XYZ part is never fixed.

> some /ICCBased colorspaces not rendered correctly
> -
>
> Key: PDFBOX-2142
> URL: https://issues.apache.org/jira/browse/PDFBOX-2142
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
>Priority: Major
> Attachments: PDFBOX-2142.pdf, PDFBOX-2142.pdf-1.png, PDFBOX-2142.ps
>
>
> I have created a test file from PostScript to show that -CIELAB and XYZ- some 
> colors are different when rendered by PDFBox.
> Btw the RGB colors in the file have no meaning, nor do the colors have a 
> relationship between each others, i.e. they do not have to look identical to 
> any other color anywhere.
> The postscript file was created based on files by [James 
> Cloos|http://jhcloos.com/PostScript/].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Resolved] (PDFBOX-4106) Vertical text creation

[Tilman Hausherr (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr resolved PDFBOX-4106.
-
   Resolution: Fixed
 Assignee: Tilman Hausherr
Fix Version/s: 3.0.0 PDFBox
   2.0.9

[~amake] thank you for your contribution. Setting to resolved.

A snapshot is available at
https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.9-SNAPSHOT/
 .

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Resolved] (PDFBOX-2917) PDF to Image, faint/dim Images

[Tilman Hausherr (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr resolved PDFBOX-2917.
-
   Resolution: Fixed
 Assignee: Tilman Hausherr
Fix Version/s: 3.0.0 PDFBox
   2.0.9

> PDF to Image, faint/dim Images
> --
>
> Key: PDFBOX-2917
> URL: https://issues.apache.org/jira/browse/PDFBOX-2917
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Windows 8.1, jdk1.8.0_51, jre1.8.0_51
>Reporter: Samuil Goranov
>Assignee: Tilman Hausherr
>Priority: Trivial
>  Labels: images, newbie
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: PDFBOX-2917-v2.patch, 
> PDFBOX-2917__Use_linear_RGB_for_image_color_conversion_to_workaround_JDK_bug.patch,
>  saved0.png, screenshot-1.png, selection.pdf
>
>
> {code:title=pdftoimage.java|borderStyle=solid}
> PDDocument document = null;
> File file = new File("F:\\Projects\\java\\pdfbox\\complete.pdf");
> document = PDDocument.load( file );
> try {
> // retrieve image
> BufferedImage bi = new PDFRenderer(document).renderImageWithDPI( 
> 0 , 150, ImageType.RGB );
> File outputfile = new File("saved0.png");
> ImageIO.write(bi, "png", outputfile);
> } catch (IOException e) {
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Resolved] (PDFBOX-4114) ICCBased color spaces wrong color output

[Tilman Hausherr (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr resolved PDFBOX-4114.
-
Resolution: Fixed
  Assignee: Tilman Hausherr

> ICCBased color spaces wrong color output
> 
>
> Key: PDFBOX-4114
> URL: https://issues.apache.org/jira/browse/PDFBOX-4114
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel, Rendering
>Affects Versions: 2.0.8
>Reporter: Michael Vakulich
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: ICCBased_updated.patch, compare.jpg, highResPdf-1.jpg, 
> highResPdf.pdf
>
>
> When rendering page with embedded ICC_profile (DeviceCMYK) it has a wrong 
> colors, like semitransparent white plane covering the page
>  See the render output
> Tried patches suggested here
> [https://forums.adobe.com/thread/1914790]
> https://github.com/haraldk/TwelveMonkeys/blob/master/imageio/imageio-jpeg/src/main/java/com/twelvemonkeys/imageio/plugins/jpeg/JPEGImageReader.java
> and trying one by one found that problem is connected to profileClass
> Here is the one of proposed patches I've found and which worked for me
>  Please review proposed patch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4114) ICCBased color spaces wrong color output

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369384#comment-16369384
 ] 

Tilman Hausherr commented on PDFBOX-4114:
-

Any solution by Harald Kuhr is good for us. Thanks for finding it.  I committed 
your patch in a slightly modified form.

> ICCBased color spaces wrong color output
> 
>
> Key: PDFBOX-4114
> URL: https://issues.apache.org/jira/browse/PDFBOX-4114
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel, Rendering
>Affects Versions: 2.0.8
>Reporter: Michael Vakulich
>Priority: Major
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: ICCBased_updated.patch, compare.jpg, highResPdf-1.jpg, 
> highResPdf.pdf
>
>
> When rendering page with embedded ICC_profile (DeviceCMYK) it has a wrong 
> colors, like semitransparent white plane covering the page
>  See the render output
> Tried patches suggested here
> [https://forums.adobe.com/thread/1914790]
> https://github.com/haraldk/TwelveMonkeys/blob/master/imageio/imageio-jpeg/src/main/java/com/twelvemonkeys/imageio/plugins/jpeg/JPEGImageReader.java
> and trying one by one found that problem is connected to profileClass
> Here is the one of proposed patches I've found and which worked for me
>  Please review proposed patch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2917) PDF to Image, faint/dim Images

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369373#comment-16369373
 ] 

ASF subversion and git services commented on PDFBOX-2917:
-

Commit 1824795 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1824795 ]

PDFBOX-2917, PDFBOX-4114: fix icc profile that has the wrong display class as 
done in twelvemonkeys and suggested by Michael Vakulich

> PDF to Image, faint/dim Images
> --
>
> Key: PDFBOX-2917
> URL: https://issues.apache.org/jira/browse/PDFBOX-2917
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Windows 8.1, jdk1.8.0_51, jre1.8.0_51
>Reporter: Samuil Goranov
>Priority: Trivial
>  Labels: images, newbie
> Attachments: PDFBOX-2917-v2.patch, 
> PDFBOX-2917__Use_linear_RGB_for_image_color_conversion_to_workaround_JDK_bug.patch,
>  saved0.png, screenshot-1.png, selection.pdf
>
>
> {code:title=pdftoimage.java|borderStyle=solid}
> PDDocument document = null;
> File file = new File("F:\\Projects\\java\\pdfbox\\complete.pdf");
> document = PDDocument.load( file );
> try {
> // retrieve image
> BufferedImage bi = new PDFRenderer(document).renderImageWithDPI( 
> 0 , 150, ImageType.RGB );
> File outputfile = new File("saved0.png");
> ImageIO.write(bi, "png", outputfile);
> } catch (IOException e) {
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4114) ICCBased color spaces wrong color output

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369374#comment-16369374
 ] 

ASF subversion and git services commented on PDFBOX-4114:
-

Commit 1824795 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1824795 ]

PDFBOX-2917, PDFBOX-4114: fix icc profile that has the wrong display class as 
done in twelvemonkeys and suggested by Michael Vakulich

> ICCBased color spaces wrong color output
> 
>
> Key: PDFBOX-4114
> URL: https://issues.apache.org/jira/browse/PDFBOX-4114
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel, Rendering
>Affects Versions: 2.0.8
>Reporter: Michael Vakulich
>Priority: Major
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: ICCBased_updated.patch, compare.jpg, highResPdf-1.jpg, 
> highResPdf.pdf
>
>
> When rendering page with embedded ICC_profile (DeviceCMYK) it has a wrong 
> colors, like semitransparent white plane covering the page
>  See the render output
> Tried patches suggested here
> [https://forums.adobe.com/thread/1914790]
> https://github.com/haraldk/TwelveMonkeys/blob/master/imageio/imageio-jpeg/src/main/java/com/twelvemonkeys/imageio/plugins/jpeg/JPEGImageReader.java
> and trying one by one found that problem is connected to profileClass
> Here is the one of proposed patches I've found and which worked for me
>  Please review proposed patch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2917) PDF to Image, faint/dim Images

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369371#comment-16369371
 ] 

ASF subversion and git services commented on PDFBOX-2917:
-

Commit 1824794 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1824794 ]

PDFBOX-2917, PDFBOX-4114: fix icc profile that has the wrong display class as 
done in twelvemonkeys and suggested by Michael Vakulich

> PDF to Image, faint/dim Images
> --
>
> Key: PDFBOX-2917
> URL: https://issues.apache.org/jira/browse/PDFBOX-2917
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Windows 8.1, jdk1.8.0_51, jre1.8.0_51
>Reporter: Samuil Goranov
>Priority: Trivial
>  Labels: images, newbie
> Attachments: PDFBOX-2917-v2.patch, 
> PDFBOX-2917__Use_linear_RGB_for_image_color_conversion_to_workaround_JDK_bug.patch,
>  saved0.png, screenshot-1.png, selection.pdf
>
>
> {code:title=pdftoimage.java|borderStyle=solid}
> PDDocument document = null;
> File file = new File("F:\\Projects\\java\\pdfbox\\complete.pdf");
> document = PDDocument.load( file );
> try {
> // retrieve image
> BufferedImage bi = new PDFRenderer(document).renderImageWithDPI( 
> 0 , 150, ImageType.RGB );
> File outputfile = new File("saved0.png");
> ImageIO.write(bi, "png", outputfile);
> } catch (IOException e) {
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4114) ICCBased color spaces wrong color output

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369372#comment-16369372
 ] 

ASF subversion and git services commented on PDFBOX-4114:
-

Commit 1824794 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1824794 ]

PDFBOX-2917, PDFBOX-4114: fix icc profile that has the wrong display class as 
done in twelvemonkeys and suggested by Michael Vakulich

> ICCBased color spaces wrong color output
> 
>
> Key: PDFBOX-4114
> URL: https://issues.apache.org/jira/browse/PDFBOX-4114
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel, Rendering
>Affects Versions: 2.0.8
>Reporter: Michael Vakulich
>Priority: Major
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: ICCBased_updated.patch, compare.jpg, highResPdf-1.jpg, 
> highResPdf.pdf
>
>
> When rendering page with embedded ICC_profile (DeviceCMYK) it has a wrong 
> colors, like semitransparent white plane covering the page
>  See the render output
> Tried patches suggested here
> [https://forums.adobe.com/thread/1914790]
> https://github.com/haraldk/TwelveMonkeys/blob/master/imageio/imageio-jpeg/src/main/java/com/twelvemonkeys/imageio/plugins/jpeg/JPEGImageReader.java
> and trying one by one found that problem is connected to profileClass
> Here is the one of proposed patches I've found and which worked for me
>  Please review proposed patch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4114) ICCBased color spaces wrong color output

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368380#comment-16368380
 ] 

Tilman Hausherr edited comment on PDFBOX-4114 at 2/19/18 5:42 PM:
--

I need some time to review the effects with different jdks and different 
configurations (KCMS / LCMS). I ran a rendering diff test and the rendering of 
8 files of 1000 are different. One of them was known to have bad rendering 
(PDFBOX-2917) and that looks good now, so this is getting interesting :)
 - eci_altona-test-suite-v2_technical2_one-patch-per-page_x4.pdf: p13 better
 - gs-bugzilla691182.pdf: slight difference
 - immo-kurier_arsenal_93x62.pdf: slight difference
 - PDFBOX-1274.pdf: much better
 - PDFBOX-2917.pdf ("the pepsi bottle"): much better
 - PDFBOX-3494.pdf: better
 - PDFBOX-3802: better
 - PDFBOX-4022-slow.pdf: slight difference

Shouldn't {{fixProfile}} be called *after* {{is_sRGB}}?

And what if java has fixed this bug in some later version - wouldn't your fix 
"undo" it?

Your parameter is named "cmykProfile" but ICC profiles don't have to be CMYK. 
There can be with 3 colors or gray (PDFBOX-1274).

Please edit your question to add what you've found "across internet", i.e. put 
a link or two there.


was (Author: tilman):
I need some time to review the effects with different jdks and different 
configurations (KCMS / LCMS). I ran a rendering diff test and the rendering of 
7 files of 1000 are different. One of them was known to have bad rendering 
(PDFBOX-2917) and that looks good now, so this is getting interesting :)

- eci_altona-test-suite-v2_technical2_one-patch-per-page_x4.pdf: p13 better
- gs-bugzilla691182.pdf: slight difference
- immo-kurier_arsenal_93x62.pdf: slight difference
- PDFBOX-1274.pdf: much better
- PDFBOX-2917.pdf ("the pepsi bottle"): much better
- PDFBOX-3494.pdf: better
- PDFBOX-4022-slow.pdf: slight difference

Shouldn't {{fixProfile}} be called *after* {{is_sRGB}}?

And what if java has fixed this bug in some later version - wouldn't your fix 
"undo" it?

Your parameter is named "cmykProfile" but ICC profiles don't have to be CMYK. 
There can be with 3 colors or gray (PDFBOX-1274).

Please edit your question to add what you've found "across internet", i.e. put 
a link or two there.

> ICCBased color spaces wrong color output
> 
>
> Key: PDFBOX-4114
> URL: https://issues.apache.org/jira/browse/PDFBOX-4114
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel, Rendering
>Affects Versions: 2.0.8
>Reporter: Michael Vakulich
>Priority: Major
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: ICCBased_updated.patch, compare.jpg, highResPdf-1.jpg, 
> highResPdf.pdf
>
>
> When rendering page with embedded ICC_profile (DeviceCMYK) it has a wrong 
> colors, like semitransparent white plane covering the page
>  See the render output
> Tried patches suggested here
> [https://forums.adobe.com/thread/1914790]
> https://github.com/haraldk/TwelveMonkeys/blob/master/imageio/imageio-jpeg/src/main/java/com/twelvemonkeys/imageio/plugins/jpeg/JPEGImageReader.java
> and trying one by one found that problem is connected to profileClass
> Here is the one of proposed patches I've found and which worked for me
>  Please review proposed patch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-4117) Implement GoToE action-type

[Gilad Denneboom (JIRA)]

Gilad Denneboom created PDFBOX-4117:
---

 Summary: Implement GoToE action-type
 Key: PDFBOX-4117
 URL: https://issues.apache.org/jira/browse/PDFBOX-4117
 Project: PDFBox
  Issue Type: New Feature
  Components: AcroForm
Affects Versions: 2.0.8, 1.8.13
Reporter: Gilad Denneboom


One of the major Action Types is not implemented in any version of PDFBox, and 
I believe it should be. I'm referring to "Embedded Go-To Actions" (defined 
under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an attache 
file. Currently, such "GoToE" actions are interpreted as "null" by PDFBox, 
which is not ideal.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

xing Wang created PDFBOX-4116:
-

 Summary: could not add text without unicode in the font
 Key: PDFBOX-4116
 URL: https://issues.apache.org/jira/browse/PDFBOX-4116
 Project: PDFBox
  Issue Type: Wish
  Components: PDModel
Affects Versions: 2.0.8
 Environment: Windows, 2.0.8 of pdfbox. 
Reporter: xing Wang
 Attachments: image-2018-02-19-09-23-00-110.png

!image-2018-02-19-09-23-00-110.png!

As shown in the debugger, that the PDFType1Font map the code of 33 to "minus", 
but there is no unicode value associated with it. 

If we use the code `contentStream.showText("\u0021");` to add content, it will 
cause an error of following. 

Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
('exclam') is not available in this font AMZNGR+CMSY10 (generic: FREBPT+CMSY10) 
encoding: built-in (Type 1) with differences
 at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
 at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
 at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)

The best way I could do is used the "appendRawCommands", but I find it's marked 
as deprecated. I am wondering why or is there any replacement for this function?

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4116) could not add text without unicode in the font

[xing Wang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

xing Wang updated PDFBOX-4116:
--
Description: 
!image-2018-02-19-09-23-00-110.png!

As shown in the debugger, that the PDFType1Font map the code of 33 to "minus", 
but there is no unicode value associated with it. 

If we use the code `contentStream.showText("\u0021");` to add content, it will 
cause an error of following. 

Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
('exclam') is not available in this font AMZNGR+CMSY10 (generic: FREBPT+CMSY10) 
encoding: built-in (Type 1) with differences
at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)

The best way I could do is used the "appendRawCommands", but I find it's marked 
as deprecated. I am wondering why or is there any replacement for this function?

 

  was:
!image-2018-02-19-09-23-00-110.png!

As shown in the debugger, that the PDFType1Font map the code of 33 to "minus", 
but there is no unicode value associated with it. 

If we use the code `contentStream.showText("\u0021");` to add content, it will 
cause an error of following. 

Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
('exclam') is not available in this font AMZNGR+CMSY10 (generic: FREBPT+CMSY10) 
encoding: built-in (Type 1) with differences
 at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
 at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
 at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)

The best way I could do is used the "appendRawCommands", but I find it's marked 
as deprecated. I am wondering why or is there any replacement for this function?

 


> could not add text without unicode in the font
> --
>
> Key: PDFBOX-4116
> URL: https://issues.apache.org/jira/browse/PDFBOX-4116
> Project: PDFBox
>  Issue Type: Wish
>  Components: PDModel
>Affects Versions: 2.0.8
> Environment: Windows, 2.0.8 of pdfbox. 
>Reporter: xing Wang
>Priority: Minor
> Attachments: image-2018-02-19-09-23-00-110.png
>
>
> !image-2018-02-19-09-23-00-110.png!
> As shown in the debugger, that the PDFType1Font map the code of 33 to 
> "minus", but there is no unicode value associated with it. 
> If we use the code `contentStream.showText("\u0021");` to add content, it 
> will cause an error of following. 
> Exception in thread "main" java.lang.IllegalArgumentException: U+0021 
> ('exclam') is not available in this font AMZNGR+CMSY10 (generic: 
> FREBPT+CMSY10) encoding: built-in (Type 1) with differences
> at org.apache.pdfbox.pdmodel.font.PDType1Font.encode(PDType1Font.java:439)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:323)
> at org.apache.pdfbox.debugger.CreatePDF.main(CreatePDF.java:63)
> The best way I could do is used the "appendRawCommands", but I find it's 
> marked as deprecated. I am wondering why or is there any replacement for this 
> function?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4071) Improve code quality (3)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369067#comment-16369067
 ] 

ASF subversion and git services commented on PDFBOX-4071:
-

Commit 1824744 from [~msahyoun] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1824744 ]

PDFBOX-4071: use Float.compare for float comparison

> Improve code quality (3)
> 
>
> Key: PDFBOX-4071
> URL: https://issues.apache.org/jira/browse/PDFBOX-4071
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Major
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2852, which was getting too long.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4071) Improve code quality (3)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369045#comment-16369045
 ] 

ASF subversion and git services commented on PDFBOX-4071:
-

Commit 1824741 from [~msahyoun] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1824741 ]

PDFBOX-4071: use Float.compare for float comparison

> Improve code quality (3)
> 
>
> Key: PDFBOX-4071
> URL: https://issues.apache.org/jira/browse/PDFBOX-4071
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Major
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2852, which was getting too long.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org