[jira] [Commented] (PDFBOX-3551) CLI Decrypt broken, only allows 1 argument
[ https://issues.apache.org/jira/browse/PDFBOX-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627179#comment-15627179 ] acker apple commented on PDFBOX-3551: - IF you only supply the keyStore argument, that PASSWORD is empty-string and the error of "keyStore password was incorrect". > CLI Decrypt broken, only allows 1 argument > -- > > Key: PDFBOX-3551 > URL: https://issues.apache.org/jira/browse/PDFBOX-3551 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.3 > Environment: java >Reporter: acker apple > Labels: CLI, Decrypt, Decrypt.java, keyStore > Original Estimate: 1h > Remaining Estimate: 1h > > This is about the Decrypt.java CLI wrapper fails when using certificates. > Plain and simple. The following file just simply doesn't allow for more than > one CLI argument: tools/src/main/java/org/apache/pdfbox/tools/Decrypt.java > WHEN, I supply the argument keyStore and password, the usage documentation is > thrown. > WHEN, I hack the Decrypt.java CLI wrapper in tools, and allow the password > AND keyStore arguments to BOTH be present, the decrypt works. > The command I am trying to run: > java -jar pdfbox-app-2.0.3.jar Decrypt -password password -keyStore > keystore.p12 encrypted.pdf decrypted.pdf > PDFBox CLI docs for decrypt WHERE clearly password AND keyStore need to be > used together: http://pdfbox.apache.org/2.0/commandline.html#decrypt > IN CLOSING, instead of fighting my case that the CLI Decrypt method is NOT > working, I am choosing to keep it simple by stating fact that ONLY ONE > argument is allowed OTHERWISE the usage docs are thrown. > Thank you kindly. I have been able to rebuild the jar files with my own fix > by using Maven to re-jar. I absolutely sure I am generating proper certs and > p12 keyStore files and again I am successfully encrypting/decrypting with my > update pdfbox.jar file -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3551) CLI Decrypt broken, only allows 1 argument
[ https://issues.apache.org/jira/browse/PDFBOX-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627173#comment-15627173 ] acker apple commented on PDFBOX-3551: - FYI, the following folder has NO tests for encrypt/decrypt: tools/src/test/java/org/apache/pdfbox This is how I think certificate based issues have been overlooked > CLI Decrypt broken, only allows 1 argument > -- > > Key: PDFBOX-3551 > URL: https://issues.apache.org/jira/browse/PDFBOX-3551 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.3 > Environment: java >Reporter: acker apple > Labels: CLI, Decrypt, Decrypt.java, keyStore > Original Estimate: 1h > Remaining Estimate: 1h > > This is about the Decrypt.java CLI wrapper fails when using certificates. > Plain and simple. The following file just simply doesn't allow for more than > one CLI argument: tools/src/main/java/org/apache/pdfbox/tools/Decrypt.java > WHEN, I supply the argument keyStore and password, the usage documentation is > thrown. > WHEN, I hack the Decrypt.java CLI wrapper in tools, and allow the password > AND keyStore arguments to BOTH be present, the decrypt works. > The command I am trying to run: > java -jar pdfbox-app-2.0.3.jar Decrypt -password password -keyStore > keystore.p12 encrypted.pdf decrypted.pdf > PDFBox CLI docs for decrypt WHERE clearly password AND keyStore need to be > used together: http://pdfbox.apache.org/2.0/commandline.html#decrypt > IN CLOSING, instead of fighting my case that the CLI Decrypt method is NOT > working, I am choosing to keep it simple by stating fact that ONLY ONE > argument is allowed OTHERWISE the usage docs are thrown. > Thank you kindly. I have been able to rebuild the jar files with my own fix > by using Maven to re-jar. I absolutely sure I am generating proper certs and > p12 keyStore files and again I am successfully encrypting/decrypting with my > update pdfbox.jar file -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3551) CLI Decrypt broken, only allows 1 argument
acker apple created PDFBOX-3551: --- Summary: CLI Decrypt broken, only allows 1 argument Key: PDFBOX-3551 URL: https://issues.apache.org/jira/browse/PDFBOX-3551 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 2.0.3 Environment: java Reporter: acker apple This is about the Decrypt.java CLI wrapper fails when using certificates. Plain and simple. The following file just simply doesn't allow for more than one CLI argument: tools/src/main/java/org/apache/pdfbox/tools/Decrypt.java WHEN, I supply the argument keyStore and password, the usage documentation is thrown. WHEN, I hack the Decrypt.java CLI wrapper in tools, and allow the password AND keyStore arguments to BOTH be present, the decrypt works. The command I am trying to run: java -jar pdfbox-app-2.0.3.jar Decrypt -password password -keyStore keystore.p12 encrypted.pdf decrypted.pdf PDFBox CLI docs for decrypt WHERE clearly password AND keyStore need to be used together: http://pdfbox.apache.org/2.0/commandline.html#decrypt IN CLOSING, instead of fighting my case that the CLI Decrypt method is NOT working, I am choosing to keep it simple by stating fact that ONLY ONE argument is allowed OTHERWISE the usage docs are thrown. Thank you kindly. I have been able to rebuild the jar files with my own fix by using Maven to re-jar. I absolutely sure I am generating proper certs and p12 keyStore files and again I am successfully encrypting/decrypting with my update pdfbox.jar file -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3519) COSName is not ascii
[
https://issues.apache.org/jira/browse/PDFBOX-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-3519:
---
Fix Version/s: 2.1.0
> COSName is not ascii
>
>
> Key: PDFBOX-3519
> URL: https://issues.apache.org/jira/browse/PDFBOX-3519
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
>Affects Versions: 2.0.3
>Reporter: simon steiner
>Priority: Minor
> Fix For: 2.1.0
>
> Attachments: COSNameAcrobat.png
>
>
> Trunk seems ok
> PDF is from PDFBOX-783
> {code}
> public static void main( String[] args ) throws IOException {
> PDDocument doc = PDDocument.load(new File("A02Gj780LZ.pdf"));
> COSDictionary x = doc.getPage(0).getResources().getCOSObject();
> read(x);
> doc.close();
> }
> private static void read(COSBase b) {
> if (b instanceof COSObject) {
> read(((COSObject) b).getObject());
> } else if (b instanceof COSDictionary) {
> for (COSBase x : ((COSDictionary) b).getValues()) {
> read(x);
> }
> } else if (b instanceof COSName) {
> if(((COSName) b).getName().charAt(0) > 256)
> throw new RuntimeException(((COSName) b).getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3519) COSName is not ascii
[
https://issues.apache.org/jira/browse/PDFBOX-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626782#comment-15626782
]
Maruan Sahyoun commented on PDFBOX-3519:
[~jahewson] the fix you made in PDFBOX-3347 was available in truck only not in
2.0.x - should that be incorporated there too.
> COSName is not ascii
>
>
> Key: PDFBOX-3519
> URL: https://issues.apache.org/jira/browse/PDFBOX-3519
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
>Affects Versions: 2.0.3
>Reporter: simon steiner
>Priority: Minor
> Fix For: 2.1.0
>
> Attachments: COSNameAcrobat.png
>
>
> Trunk seems ok
> PDF is from PDFBOX-783
> {code}
> public static void main( String[] args ) throws IOException {
> PDDocument doc = PDDocument.load(new File("A02Gj780LZ.pdf"));
> COSDictionary x = doc.getPage(0).getResources().getCOSObject();
> read(x);
> doc.close();
> }
> private static void read(COSBase b) {
> if (b instanceof COSObject) {
> read(((COSObject) b).getObject());
> } else if (b instanceof COSDictionary) {
> for (COSBase x : ((COSDictionary) b).getValues()) {
> read(x);
> }
> } else if (b instanceof COSName) {
> if(((COSName) b).getName().charAt(0) > 256)
> throw new RuntimeException(((COSName) b).getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3519) COSName is not ascii
[
https://issues.apache.org/jira/browse/PDFBOX-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626766#comment-15626766
]
ASF subversion and git services commented on PDFBOX-3519:
-
Commit 1767585 from [~msahyoun] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1767585 ]
PDFBOX-3519: use Windows-1252 encoding when parsing COSName values if not UTF-8
> COSName is not ascii
>
>
> Key: PDFBOX-3519
> URL: https://issues.apache.org/jira/browse/PDFBOX-3519
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
>Affects Versions: 2.0.3
>Reporter: simon steiner
>Priority: Minor
> Attachments: COSNameAcrobat.png
>
>
> Trunk seems ok
> PDF is from PDFBOX-783
> {code}
> public static void main( String[] args ) throws IOException {
> PDDocument doc = PDDocument.load(new File("A02Gj780LZ.pdf"));
> COSDictionary x = doc.getPage(0).getResources().getCOSObject();
> read(x);
> doc.close();
> }
> private static void read(COSBase b) {
> if (b instanceof COSObject) {
> read(((COSObject) b).getObject());
> } else if (b instanceof COSDictionary) {
> for (COSBase x : ((COSDictionary) b).getValues()) {
> read(x);
> }
> } else if (b instanceof COSName) {
> if(((COSName) b).getName().charAt(0) > 256)
> throw new RuntimeException(((COSName) b).getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-2785) Support filling in landscape oriented AcroForms
[
https://issues.apache.org/jira/browse/PDFBOX-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-2785.
Resolution: Fixed
This was fixed in PDFBox version 2.0.2 as part of PDFBOX-
> Support filling in landscape oriented AcroForms
> ---
>
> Key: PDFBOX-2785
> URL: https://issues.apache.org/jira/browse/PDFBOX-2785
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Maruan Sahyoun
> Fix For: 2.0.2
>
> Attachments: LO_Labels210315.pdf, newPdfCodeBarre.pdf
>
>
> From the users mailing list
> {quote}
> Hello,
> when you add an AcroForm to a document that has a 90 degree orientation, does
> the form automatically have a 90 degree orientation?
> What about it fields?
> My problem with the code below is that the fields' data are printed
> vertically instead of horizontally.
> {quote}
> And another description on stackoverflow
> http://stackoverflow.com/questions/16952710/filling-landscape-pdf-with-pdfbox
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-2785) Support filling in landscape oriented AcroForms
[
https://issues.apache.org/jira/browse/PDFBOX-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-2785:
---
Fix Version/s: 2.0.2
> Support filling in landscape oriented AcroForms
> ---
>
> Key: PDFBOX-2785
> URL: https://issues.apache.org/jira/browse/PDFBOX-2785
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Maruan Sahyoun
> Fix For: 2.0.2
>
> Attachments: LO_Labels210315.pdf, newPdfCodeBarre.pdf
>
>
> From the users mailing list
> {quote}
> Hello,
> when you add an AcroForm to a document that has a 90 degree orientation, does
> the form automatically have a 90 degree orientation?
> What about it fields?
> My problem with the code below is that the fields' data are printed
> vertically instead of horizontally.
> {quote}
> And another description on stackoverflow
> http://stackoverflow.com/questions/16952710/filling-landscape-pdf-with-pdfbox
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Closed] (PDFBOX-2761) Casting error for PDRadioButton when trying to exportFDF
[ https://issues.apache.org/jira/browse/PDFBOX-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun closed PDFBOX-2761. -- Resolution: Cannot Reproduce [~jasonmackin] I've tried with 2.0.0, 2.0.1, 2.0.2, 2.0.4 and trunk and can't reproduce the issue. If that is still valid please reopen together with a small test to reproduce the issue. > Casting error for PDRadioButton when trying to exportFDF > > > Key: PDFBOX-2761 > URL: https://issues.apache.org/jira/browse/PDFBOX-2761 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.0 >Reporter: Jason Mackin > Attachments: az101-1.15.0.pdf > > > When trying to exportFDF() in PDAcroForm.java, there is a ClassCastException > thrown when addFieldAndChilden(PDFieldTreeNode docField, List > fdfFields) is called and the docField is a PDRadioButton that has kids and > one is a PDWidget. > PDRadioButton.getKids() says: > "This will get all the kids of this field. The values in the list will either > be PDWidget or PDField. Normally they will be PDWidget objects unless this is > a non-terminal field and they will be child PDField objects." > But when kids are returned in the addFieldAndChilden method and one is a > PDWidget (PDAnnotationWidget in my case), it tries to cast it as a > PDFieldTreeNode and throws the exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Closed] (PDFBOX-3325) Whitespace gets "wider" in PDTextField when setting value
[ https://issues.apache.org/jira/browse/PDFBOX-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun closed PDFBOX-3325. -- Resolution: Cannot Reproduce [~dapam] I'm closing that issue as there was no further feedback from you. It might be related to PDFBOX-3332 which is fixed now. Feel free to reopen if the issue persists but please attach a sample PDF and sample code to reproduce the issue. > Whitespace gets "wider" in PDTextField when setting value > - > > Key: PDFBOX-3325 > URL: https://issues.apache.org/jira/browse/PDFBOX-3325 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.0 > Environment: Any >Reporter: Pasi-Markus Mäkelä > Attachments: Screen Shot 2016-04-21 at 11.58.28.png > > > When reading pdf template / document and setting value to textfield, the > whitespaces are wider than in "static" text. See attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) OpenType Shaping
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-3550:
Summary: OpenType Shaping (was: Unicode Letters fail to join)
> OpenType Shaping
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626063#comment-15626063
]
John Hewson commented on PDFBOX-3550:
-
Parsing the OpenType tables is the tip of the iceberg. Many complex scripts
(such as Arabic) require shaping engines which require deep knowledge of the
languages in order to follow the rules in the OpenType tables.
Looking into FOP's shaping engine, it doesn't support many scripts and in
general doesn't look particularly great.
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626063#comment-15626063
]
John Hewson edited comment on PDFBOX-3550 at 11/1/16 5:25 PM:
--
Parsing the OpenType tables is the tip of the iceberg. Many complex scripts
(such as Arabic) require shaping engines which require deep knowledge of the
languages in order to follow the rules in the OpenType tables.
Looking into FOP's shaping engine, it doesn't support many scripts and in
general doesn't look particularly great. Right now Harfbuzz is the only game in
town, but that's C++.
was (Author: jahewson):
Parsing the OpenType tables is the tip of the iceberg. Many complex scripts
(such as Arabic) require shaping engines which require deep knowledge of the
languages in order to follow the rules in the OpenType tables.
Looking into FOP's shaping engine, it doesn't support many scripts and in
general doesn't look particularly great.
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Closed] (PDFBOX-2709) XFDF import fails when using a field with a "." in the name
[ https://issues.apache.org/jira/browse/PDFBOX-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun closed PDFBOX-2709. -- Resolution: Incomplete Closing as no further information was given. > XFDF import fails when using a field with a "." in the name > --- > > Key: PDFBOX-2709 > URL: https://issues.apache.org/jira/browse/PDFBOX-2709 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 1.8.8 > Environment: OpenJDK 7 >Reporter: Justin Rovang >Assignee: Maruan Sahyoun > > When trying to import an XFDF into a simple PDF form with a single field with > a decimal in the field name, e.g.: 'name.first', the PDF saved from importFDF > has a blank field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3549) Can't read embedded ICC 4 profile (Invalid profile sequence)
[ https://issues.apache.org/jira/browse/PDFBOX-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626050#comment-15626050 ] John Hewson commented on PDFBOX-3549: - According to the PDF spec V4 (a.k.a. ICC.1:2001-12) profiles have been supported since PDF 1.5. But this is a problem for Java's CMS, as PDFBox delegates all color profile code to Java. > Can't read embedded ICC 4 profile (Invalid profile sequence) > > > Key: PDFBOX-3549 > URL: https://issues.apache.org/jira/browse/PDFBOX-3549 > Project: PDFBox > Issue Type: Bug > Components: Parsing >Affects Versions: 2.0.3 > Environment: Ubuntu 12.04 AMD64, Java 8 >Reporter: Liu Huasong > Labels: ICC, icc4 > > 1) Goto this page: http://www.color.org/version4ready.xalter > 2) Download this file: http://www.color.org/version4pdf.pdf > 3) Run this command: > java -jar pdfbox-app-2.0.3.jar PDFToImage version4pdf.pdf > 4) PDFBox output error: > Can't read embedded ICC profile (Invalid profile sequence), using alternate > color space: DeviceRGB > 5) Open the output file: version4pdf1.jpg, you will found there is a > rendering error. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625248#comment-15625248
]
Tilman Hausherr commented on PDFBOX-3550:
-
Yes I copied the code from FOP and did some intermediate code to read
structures (read bytes, words, integers whatever) and the stuff parses, but I
didn't try generation. I haven't had the time to understand how the FOP
structures work, I don't know if FOP needs additional font structures and in a
different way than we do, and if yes it would mean that fonts would have to be
parsed twice.
I didn't research this further, mostly because I don't know any of the target
languages / alphabets.
The work to be done is probably several weeks, and there's no reward except a
"thank you" from us and the feeling of having done something great.
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625207#comment-15625207
]
Maruan Sahyoun commented on PDFBOX-3550:
we'd like to support that but there is currently no one working on that. I was
looking into that very quickly a while ago as to be able to fill form fields
using text with complex script and Tilman did a quick test to parse the needed
additional OpenType tables. So I think in principle we know whats needed but
non of us had the time to implement that as it's a fairly complex feature.
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625190#comment-15625190
]
Omid Pourhadi commented on PDFBOX-3550:
---
Hi Maruan,
Thank you for your consideration. are you going to support this feature in
future release almost all other PDF generator including iText supports it,
regardless of its complexity, I would be happy to help.
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only two things which are of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates which are later converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only two things which are of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > *Short*: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > *Details and background* > The current implementation for visible signatures always adds new signature > fields when signing documents. > In that case for that signature everything has to be definied (field > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations etc. The document creator defines his intend with the > "Usage rights" and may add a usage right signature. > Then
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only two things which are of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > *Short*: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > *Details and background* > The current implementation for visible signatures always adds new signature > fields when signing documents. > In that case for that signature everything has to be definied (field > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations etc. The document creator defines his intend with the > "Usage rights" and may add a usage right
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (fields properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > *Short*: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > *Details and background* > The current implementation for visible signatures always adds new signature > fields when signing documents. > In that case for that signature everything has to be definied (field > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations about etc. The document creator defines his intend with > the "Usage rights" and may add
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (field properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > *Short*: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > *Details and background* > The current implementation for visible signatures always adds new signature > fields when signing documents. > In that case for that signature everything has to be definied (field > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations etc. The document creator defines his intend with the > "Usage rights" and may add a usage right
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds new signature fields when signing documents. In that case for that signature everything has to be definied (fields properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds for new signature fields when signing documents. In that case for that signature everything has to be definied (fields properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > *Short*: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > *Details and background* > The current implementation for visible signatures always adds new signature > fields when signing documents. > In that case for that signature everything has to be definied (fields > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations about etc. The document creator defines his intend with > the "Usage rights" and
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: *Short*: The handling of signing existing signature fields must be improved (and this patch is part of that effort). *Details and background* The current implementation for visible signatures always adds for new signature fields when signing documents. In that case for that signature everything has to be definied (fields properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was: Short: The handling of signing existing signature fields must be improved (and this patch is part of that effort). Details and background: The current implementation for visible signatures always adds for new signature fields when signing documents. In that case for that signature everything has to be definied (fields properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > *Short*: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > *Details and background* > The current implementation for visible signatures always adds for new > signature fields when signing documents. > In that case for that signature everything has to be definied (fields > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations about etc. The document creator defines his intend with > the "Usage rights"
[jira] [Comment Edited] (PDFBOX-3524) signatureField.setValue() not implemented
[
https://issues.apache.org/jira/browse/PDFBOX-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15624947#comment-15624947
]
Lonzak edited comment on PDFBOX-3524 at 11/1/16 10:23 AM:
--
[~msahyoun] Yes perfect that did the trick...
By the way how did you highlight the {{UnsupportedOperationException}} in your
post?
was (Author: teewetee):
[~msahyoun] Yes perfect that did the trick...
By the way how did you highlight the _UnsupportedOperationException_ in your
post?
> signatureField.setValue() not implemented
> -
>
> Key: PDFBOX-3524
> URL: https://issues.apache.org/jira/browse/PDFBOX-3524
> Project: PDFBox
> Issue Type: Sub-task
> Components: Signing
>Affects Versions: 2.0.3
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
> Fix For: 2.0.4, 2.1.0
>
>
> In the CreateEmptySignatureForm example, adding
> {code}
> signatureField.setValue(new PDSignature());
> {code}
> before saving brings this
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not
> implemented
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.constructAppearances(PDSignatureField.java:237)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:226)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.setValue(PDSignatureField.java:121)
> at
> org.apache.pdfbox.examples.signature.CreateEmptySignatureForm.main(CreateEmptySignatureForm.java:84)
> {code}
> Although there's nothing to construct, visual signing is a different area of
> PDFBox.
> What does work is this:
> {code}
> signatureField.getCOSObject().setItem(COSName.V, new PDSignature());
> {code}
> I wanted to add this line because this would make it possible to sign this
> specific field with PDFBox, due to the findSignatureField() method in
> PDDocument, which would allow to pre-fill a PDSignature object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3524) signatureField.setValue() not implemented
[
https://issues.apache.org/jira/browse/PDFBOX-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-3524.
Resolution: Fixed
setting to resolved per users feedback.
> signatureField.setValue() not implemented
> -
>
> Key: PDFBOX-3524
> URL: https://issues.apache.org/jira/browse/PDFBOX-3524
> Project: PDFBox
> Issue Type: Sub-task
> Components: Signing
>Affects Versions: 2.0.3
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
> Fix For: 2.0.4, 2.1.0
>
>
> In the CreateEmptySignatureForm example, adding
> {code}
> signatureField.setValue(new PDSignature());
> {code}
> before saving brings this
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not
> implemented
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.constructAppearances(PDSignatureField.java:237)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:226)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.setValue(PDSignatureField.java:121)
> at
> org.apache.pdfbox.examples.signature.CreateEmptySignatureForm.main(CreateEmptySignatureForm.java:84)
> {code}
> Although there's nothing to construct, visual signing is a different area of
> PDFBox.
> What does work is this:
> {code}
> signatureField.getCOSObject().setItem(COSName.V, new PDSignature());
> {code}
> I wanted to add this line because this would make it possible to sign this
> specific field with PDFBox, due to the findSignatureField() method in
> PDDocument, which would allow to pre-fill a PDSignature object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3524) signatureField.setValue() not implemented
[
https://issues.apache.org/jira/browse/PDFBOX-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625008#comment-15625008
]
Maruan Sahyoun commented on PDFBOX-3524:
Thanks for the feedback.
Regarding the highlight you'd need to enclose the text in double curly braces.
see https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all
> signatureField.setValue() not implemented
> -
>
> Key: PDFBOX-3524
> URL: https://issues.apache.org/jira/browse/PDFBOX-3524
> Project: PDFBox
> Issue Type: Sub-task
> Components: Signing
>Affects Versions: 2.0.3
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
> Fix For: 2.0.4, 2.1.0
>
>
> In the CreateEmptySignatureForm example, adding
> {code}
> signatureField.setValue(new PDSignature());
> {code}
> before saving brings this
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not
> implemented
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.constructAppearances(PDSignatureField.java:237)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:226)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.setValue(PDSignatureField.java:121)
> at
> org.apache.pdfbox.examples.signature.CreateEmptySignatureForm.main(CreateEmptySignatureForm.java:84)
> {code}
> Although there's nothing to construct, visual signing is a different area of
> PDFBox.
> What does work is this:
> {code}
> signatureField.getCOSObject().setItem(COSName.V, new PDSignature());
> {code}
> I wanted to add this line because this would make it possible to sign this
> specific field with PDFBox, due to the findSignatureField() method in
> PDDocument, which would allow to pre-fill a PDSignature object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3524) signatureField.setValue() not implemented
[
https://issues.apache.org/jira/browse/PDFBOX-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15624947#comment-15624947
]
Lonzak commented on PDFBOX-3524:
[~msahyoun] Yes perfect that did the trick...
By the way how did you highlight the _UnsupportedOperationException_ in your
post?
> signatureField.setValue() not implemented
> -
>
> Key: PDFBOX-3524
> URL: https://issues.apache.org/jira/browse/PDFBOX-3524
> Project: PDFBox
> Issue Type: Sub-task
> Components: Signing
>Affects Versions: 2.0.3
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
> Fix For: 2.0.4, 2.1.0
>
>
> In the CreateEmptySignatureForm example, adding
> {code}
> signatureField.setValue(new PDSignature());
> {code}
> before saving brings this
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not
> implemented
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.constructAppearances(PDSignatureField.java:237)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:226)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDSignatureField.setValue(PDSignatureField.java:121)
> at
> org.apache.pdfbox.examples.signature.CreateEmptySignatureForm.main(CreateEmptySignatureForm.java:84)
> {code}
> Although there's nothing to construct, visual signing is a different area of
> PDFBox.
> What does work is this:
> {code}
> signatureField.getCOSObject().setItem(COSName.V, new PDSignature());
> {code}
> I wanted to add this line because this would make it possible to sign this
> specific field with PDFBox, due to the findSignatureField() method in
> PDDocument, which would allow to pre-fill a PDSignature object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3547) [Patch]Improved signing of existing signature fields
[ https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lonzak updated PDFBOX-3547: --- Description: Short: The handling of signing existing signature fields must be improved (and this patch is part of that effort). Details and background: The current implementation for visible signatures always adds for new signature fields when signing documents. In that case for that signature everything has to be definied (fields properties, coordinates etc.). Another quite common use case is the use of an existing signature field which should be signed. There are basically two different roles: The *document creator* who creates the document with all its texts, graphics and form fields. The creator knows best where everything should be positioned and is even sometimes bound by certain regulations about etc. The document creator defines his intend with the "Usage rights" and may add a usage right signature. Then later a *document user* e.g. a customer fills out form fields and signs those predefined signature fields. In that case the coordinates and a lot of attributes are alrady defined and there is no need (and sometimes it is even forbidden) to change the physical attributes of those signature fields. The only things which is of interest is to set the signature dictionary and to recreate the appearance. In the current implementation however one needs to define the coordinates of an existing signature field again. But not enough since the screen coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a different origin one must convert those existing PDF coordinates to screen coordinates so that later those coordinates can be converted to PDF coordinates again. This is cumbersome, error prone and totally unecessary... With the supplied patch there is no conversion of coordinates anymore. was:Improved handling when a user wants to sign a document with existing (empty) signature fields. > [Patch]Improved signing of existing signature fields > > > Key: PDFBOX-3547 > URL: https://issues.apache.org/jira/browse/PDFBOX-3547 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.4 >Reporter: Lonzak > Attachments: CreateVisibleSignature.patch, PDDocument.patch > > > Short: The handling of signing existing signature fields must be improved > (and this patch is part of that effort). > Details and background: > The current implementation for visible signatures always adds for new > signature fields when signing documents. > In that case for that signature everything has to be definied (fields > properties, coordinates etc.). > Another quite common use case is the use of an existing signature field which > should be signed. > There are basically two different roles: The *document creator* who creates > the document with all its texts, graphics and form fields. The creator knows > best where everything should be positioned and is even sometimes bound by > certain regulations about etc. The document creator defines his intend with > the "Usage rights" and may add a usage right signature. > Then later a *document user* e.g. a customer fills out form fields and signs > those predefined signature fields. > In that case the coordinates and a lot of attributes are alrady defined and > there is no need (and sometimes it is even forbidden) to change the physical > attributes of those signature fields. The only things which is of interest is > to set the signature dictionary and to recreate the appearance. > In the current implementation however one needs to define the coordinates of > an existing signature field again. But not enough since the screen > coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF > coordinates have a different origin one must convert those existing PDF > coordinates to screen coordinates so that later those coordinates can be > converted to PDF coordinates again. This is cumbersome, error prone and > totally unecessary... With the supplied patch there is no conversion of > coordinates anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3549) Can't read embedded ICC 4 profile (Invalid profile sequence)
[ https://issues.apache.org/jira/browse/PDFBOX-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-3549: Labels: ICC icc4 (was: ICC) > Can't read embedded ICC 4 profile (Invalid profile sequence) > > > Key: PDFBOX-3549 > URL: https://issues.apache.org/jira/browse/PDFBOX-3549 > Project: PDFBox > Issue Type: Bug > Components: Parsing >Affects Versions: 2.0.3 > Environment: Ubuntu 12.04 AMD64, Java 8 >Reporter: Liu Huasong > Labels: ICC, icc4 > > 1) Goto this page: http://www.color.org/version4ready.xalter > 2) Download this file: http://www.color.org/version4pdf.pdf > 3) Run this command: > java -jar pdfbox-app-2.0.3.jar PDFToImage version4pdf.pdf > 4) PDFBox output error: > Can't read embedded ICC profile (Invalid profile sequence), using alternate > color space: DeviceRGB > 5) Open the output file: version4pdf1.jpg, you will found there is a > rendering error. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3549) Can't read embedded ICC profile (Invalid profile sequence)
[ https://issues.apache.org/jira/browse/PDFBOX-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15624661#comment-15624661 ] Tilman Hausherr commented on PDFBOX-3549: - The text has the title "Is Your System ICC Version 4 Ready?" - I guess the answer is "no". The fatal error goes away when not using the option mentioned in https://pdfbox.apache.org/2.0/getting-started.html although the file is still not rendered properly. LittleCMS brings other problems. > Can't read embedded ICC profile (Invalid profile sequence) > -- > > Key: PDFBOX-3549 > URL: https://issues.apache.org/jira/browse/PDFBOX-3549 > Project: PDFBox > Issue Type: Bug > Components: Parsing >Affects Versions: 2.0.3 > Environment: Ubuntu 12.04 AMD64, Java 8 >Reporter: Liu Huasong > Labels: ICC > > 1) Goto this page: http://www.color.org/version4ready.xalter > 2) Download this file: http://www.color.org/version4pdf.pdf > 3) Run this command: > java -jar pdfbox-app-2.0.3.jar PDFToImage version4pdf.pdf > 4) PDFBox output error: > Can't read embedded ICC profile (Invalid profile sequence), using alternate > color space: DeviceRGB > 5) Open the output file: version4pdf1.jpg, you will found there is a > rendering error. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3549) Can't read embedded ICC 4 profile (Invalid profile sequence)
[ https://issues.apache.org/jira/browse/PDFBOX-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-3549: Summary: Can't read embedded ICC 4 profile (Invalid profile sequence) (was: Can't read embedded ICC profile (Invalid profile sequence)) > Can't read embedded ICC 4 profile (Invalid profile sequence) > > > Key: PDFBOX-3549 > URL: https://issues.apache.org/jira/browse/PDFBOX-3549 > Project: PDFBox > Issue Type: Bug > Components: Parsing >Affects Versions: 2.0.3 > Environment: Ubuntu 12.04 AMD64, Java 8 >Reporter: Liu Huasong > Labels: ICC > > 1) Goto this page: http://www.color.org/version4ready.xalter > 2) Download this file: http://www.color.org/version4pdf.pdf > 3) Run this command: > java -jar pdfbox-app-2.0.3.jar PDFToImage version4pdf.pdf > 4) PDFBox output error: > Can't read embedded ICC profile (Invalid profile sequence), using alternate > color space: DeviceRGB > 5) Open the output file: version4pdf1.jpg, you will found there is a > rendering error. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15624582#comment-15624582
]
Maruan Sahyoun commented on PDFBOX-3550:
Dear Omid - there is no support for complex script at the moment in PDFBox. In
addition there is no support for complex script in FontBox i.e. some special
tables are not parsed. If you need to create PDFs from scratch I suggest you
take a look at Apache FOP which is able to handle languages with complex script
to some extend.
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-3550:
---
Issue Type: New Feature (was: Bug)
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-3550:
---
Component/s: (was: Rendering)
FontBox
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omid Pourhadi updated PDFBOX-3550:
--
Attachment: BYekan.ttf
font to be used in sample code
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel, Rendering
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
> Attachments: BYekan.ttf
>
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omid Pourhadi updated PDFBOX-3550:
--
Description:
the problem is, in some languages letters need to be joined together for
example, consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
{color:red}
سلام
{color}
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SampleCode.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
was:
the problem is, in some languages letters need to be joined together for
example, consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
{color:red}
سلام
{color}
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel, Rendering
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SampleCode.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omid Pourhadi updated PDFBOX-3550:
--
Description:
the problem is, in some languages letters need to join together for example,
consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
{color:red}
سلام
{color}
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
was:
the problem is, in some languages letters need to join together for example,
consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
*سلام*
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel, Rendering
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
>
> the problem is, in some languages letters need to join together for example,
> consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3550) Unicode Letters fail to join
[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omid Pourhadi updated PDFBOX-3550:
--
Description:
the problem is, in some languages letters need to be joined together for
example, consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
{color:red}
سلام
{color}
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
was:
the problem is, in some languages letters need to join together for example,
consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
{color:red}
سلام
{color}
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
> Unicode Letters fail to join
>
>
> Key: PDFBOX-3550
> URL: https://issues.apache.org/jira/browse/PDFBOX-3550
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel, Rendering
> Environment: All
>Reporter: Omid Pourhadi
> Labels: unicode
>
> the problem is, in some languages letters need to be joined together for
> example, consider this word
> {color:red}
> سلام
> {color}
> but after creating a pdf it contorts to
> {color:red}
> سلام
> {color}
> with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
> related to font.
> {code:title=SampleCode.java|borderStyle=solid}
> public class SampleCode
> {
> public static void main(String[] args) throws IOException
> {
>
> PDDocument document = new PDDocument();
> //this font perfectly works in iText and JasperReport with the same text
> PDFont titleFont = PDType0Font.load(document,
> SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
> PDPage page = new PDPage(PDRectangle.A4);
> document.addPage(page);
> PDPageContentStream contentStream = new PDPageContentStream(document,
> page);
> contentStream.beginText();
> contentStream.setFont(titleFont, 12);
> contentStream.newLineAtOffset(0, 100);
> contentStream.showText("سلام");
> contentStream.endText();
> contentStream.close();
>
>
> document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
> document.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3550) Unicode Letters fail to join
Omid Pourhadi created PDFBOX-3550:
-
Summary: Unicode Letters fail to join
Key: PDFBOX-3550
URL: https://issues.apache.org/jira/browse/PDFBOX-3550
Project: PDFBox
Issue Type: Bug
Components: PDModel, Rendering
Environment: All
Reporter: Omid Pourhadi
the problem is, in some languages letters need to join together for example,
consider this word
{color:red}
سلام
{color}
but after creating a pdf it contorts to
*سلام*
with extra semi-spaces. I think this is a bug in pdfbox and definetly is not
related to font.
{code:title=SampleCode.java|borderStyle=solid}
public class SampleCode
{
public static void main(String[] args) throws IOException
{
PDDocument document = new PDDocument();
//this font perfectly works in iText and JasperReport with the same text
PDFont titleFont = PDType0Font.load(document,
SimpleUsage.class.getResourceAsStream("/BYekan.ttf"));
PDPage page = new PDPage(PDRectangle.A4);
document.addPage(page);
PDPageContentStream contentStream = new PDPageContentStream(document,
page);
contentStream.beginText();
contentStream.setFont(titleFont, 12);
contentStream.newLineAtOffset(0, 100);
contentStream.showText("سلام");
contentStream.endText();
contentStream.close();
document.save(new File("/home/omidp/temp/htmltopdf/output.pdf"));
document.close();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
