[jira] [Commented] (PDFBOX-4110) PDF to JPG conversion is returning distorted images

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-4110:
-

The current 1.8 version is 1.8.13. (And there is a 2.0.8 version too) Please 
retest and post the image you got. Also post any log messages (did you use the 
jbig2 plugin?). To get a higher resolution, use convertToImage with a parameter.

> PDF to JPG conversion is returning distorted images
> ---
>
> Key: PDFBOX-4110
> URL: https://issues.apache.org/jira/browse/PDFBOX-4110
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 1.8.11
>Reporter: Avinash
>Priority: Blocker
> Attachments: 347254-111788-437553AC1B68331C9B04E6D099E39CB5.pdf
>
>
> Hello,
> We are using PDFBox-1.8.11 to convert PDFs to JPG images in our project.
> The conversion is working fine for some PDFs but for some of the PDFs, the 
> converted images in JPG format seems to be distorted (esp, flight itenary 
> PDFs).  An example of PDF is attached to this ticket for your reference 
> [347254-111788-437553AC1B68331C9B04E6D099E39CB5.pdf].
> When this PDF is converted to JPG using PDFbox API, the image returned seems 
> to be corrupted with weird characters.
>  
> Below is the code we are using for PDF to JPG conversion.
> Kindly help us to find out how this issue can be resolved. Thank you !
>  
> public String convertPDFtoJPG(String source , String filepath1, String 
> filePath2, IqiArInvoiceEventSourceVO arInvoiceEventSourceVO ) throws 
> BaseECapException{
>  
>  String newFile="";
>  
>  //IPM-5181
>  String filePathDelimiter = ";";
>  ArrayList filepaths = new ArrayList();
>  
>  {color:#FF}_try{_{color}
> {color:#FF} _PDDocument doc=PDDocument.load(new 
> FileInputStream(source));_{color}
> {color:#FF} _List 
> pages=doc.getDocumentCatalog().getAllPages();_{color}
> {color:#FF} _Iterator i= pages.iterator();_{color}
>  
> {color:#FF} _int count=1;_{color}
> {color:#FF} _while(i.hasNext()){_{color}
> {color:#FF} _PDPage page=i.next();_ {color}
> {color:#FF} _BufferedImage bi=page.convertToImage();_{color}
>  String saveFilePath = filepath1+filePath2;
>  
>  if (!new File(saveFilePath).exists()) {
>  new File(saveFilePath).mkdirs();
>  }
>  
> Thanks,
> Avinash



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

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

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

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-4106:
-

I think the easiest, so that this gets started, is to prepare a new patch. The 
JDK7 changes would still be useful later, so keep these somehow. Your proposal 
"What if I did the following instead" sounds good. I also agree that the 
example doesn't need to be changed. I'll just add a comment like "you will 
usually not need this" for "(3)". Your ICLA was received, we got an e-mail from 
Apache, thank you.

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

[jira] [Issue Comment Deleted] (PDFBOX-4106) Vertical text creation

2018-02-13 Thread JIRA 

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

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

(was: The iCLA is on file, thanks for the fast response :))

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

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

2018-02-13 Thread JIRA 

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

Andreas Lehmkühler commented on PDFBOX-4106:


The iCLA is on file, thanks for the fast response :)

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

[jira] [Created] (PDFBOX-4110) PDF to JPG conversion is returning distorted images

2018-02-13 Thread Avinash (JIRA) 
Avinash created PDFBOX-4110:
---

 Summary: PDF to JPG conversion is returning distorted images
 Key: PDFBOX-4110
 URL: https://issues.apache.org/jira/browse/PDFBOX-4110
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.11
Reporter: Avinash
 Attachments: 347254-111788-437553AC1B68331C9B04E6D099E39CB5.pdf

Hello,

We are using PDFBox-1.8.11 to convert PDFs to JPG images in our project.

The conversion is working fine for some PDFs but for some of the PDFs, the 
converted images in JPG format seems to be distorted (esp, flight itenary 
PDFs).  An example of PDF is attached to this ticket for your reference 
[347254-111788-437553AC1B68331C9B04E6D099E39CB5.pdf].

When this PDF is converted to JPG using PDFbox API, the image returned seems to 
be corrupted with weird characters.

 

Below is the code we are using for PDF to JPG conversion.

Kindly help us to find out how this issue can be resolved. Thank you !

 

public String convertPDFtoJPG(String source , String filepath1, String 
filePath2, IqiArInvoiceEventSourceVO arInvoiceEventSourceVO ) throws 
BaseECapException{
 
 String newFile="";
 
 //IPM-5181
 String filePathDelimiter = ";";
 ArrayList filepaths = new ArrayList();
 
 {color:#FF}_try{_{color}
{color:#FF} _PDDocument doc=PDDocument.load(new 
FileInputStream(source));_{color}
{color:#FF} _List 
pages=doc.getDocumentCatalog().getAllPages();_{color}
{color:#FF} _Iterator i= pages.iterator();_{color}
 
{color:#FF} _int count=1;_{color}
{color:#FF} _while(i.hasNext()){_{color}
{color:#FF} _PDPage page=i.next();_ {color}
{color:#FF} _BufferedImage bi=page.convertToImage();_{color}
 String saveFilePath = filepath1+filePath2;
 
 if (!new File(saveFilePath).exists()) {
 new File(saveFilePath).mkdirs();
 }

 

Thanks,

Avinash



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

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

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

2018-02-13 Thread Aaron Madlon-Kay (JIRA) 

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

Aaron Madlon-Kay commented on PDFBOX-4106:
--

ICLA is submitted.

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

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

2018-02-13 Thread Aaron Madlon-Kay (JIRA) 

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

Aaron Madlon-Kay commented on PDFBOX-4106:
--

[~tilman] Thanks for the comments.

{quote}I looked at the first patch; are you aware that UnicodeScript is a JDK7 
class? This would mean your improvement can't be used in PDFBox 2.*, only in 3. 
That one has no planned release date, it could be several months or several 
years.{quote}

I was aware of everything but the timeline for version 3. I have prepared an 
alternative implementation that can run on Java 6. Should I simply replace my 
patches?

{quote}I see you made an effort in patch 5 to make it non-breaking, but I 
suspect that in patch 4 the use of the new CmapLookup interface would be a 
breaking change, isn't it? That would be another reason it couldn't be used in 
2.*.{quote}

Yes, the way I added {{CmapLookup}} would be breaking. What if I did the 
following instead:
# Add new {{getUnicodeCmapLookup}} getters to {{TrueTypeFont}} that return 
{{CmapLookup}}
# Deprecate the existing {{getUnicodeCmap}} getters
# Almost all uses of {{CmapSubtable}} in other classes are local variables or 
private members that don't leak outside of the class; for these we simply move 
to {{CmapLookup}}
# The one exception is {{TrueTypeEmbedder}}, where it is a protected member. 
Here we mark the member deprecated and add {{CmapLookup}} as a separate member, 
which we use in all cases.

{quote}The sample code (...) is too difficult for an average user. I'd prefer 
to have something on a high level, e.g. an option in an additional vertical 
loader, or a method. The "natural" setting should be the default. (What would a 
newbie "vertical font user" expect? (2) or (3) in your sample PDF ?){quote}

Actually that is somewhat intentional: if you are using a vertical font you 
would always want vertical glyph substitution as far as I know (at least for 
Japanese, you always want (2) and never (3)). I added the 
{{disableGsubFeature}} method to complement the {{enable}} method, on the off 
chance that a power user (who would surely know which GSUB features they 
wanted) needed more control. 99% of the time you would not be finagling 
features manually at all.

 I will submit the ICLA shortly.

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr edited comment on PDFBOX-4106 at 2/13/18 9:15 PM:
--

[~amake] please read, print and sign this document:
http://community.apache.org/contributors/index.html
scan and send it to secretary at apache.org. More about this here: 
https://www.apache.org/licenses/#clas


was (Author: tilman):
[~amake] please read, print and sign this document:
http://community.apache.org/contributors/index.html
send it to secretary at apache.org. More about this here: 
https://www.apache.org/licenses/#clas

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

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

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-4106:
-

[~amake] please read, print and sign this document:
http://community.apache.org/contributors/index.html
send it to secretary at apache.org. More about here: 
https://www.apache.org/licenses/#clas

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr edited comment on PDFBOX-4106 at 2/13/18 9:09 PM:
--

[~amake] please read, print and sign this document:
http://community.apache.org/contributors/index.html
send it to secretary at apache.org. More about this here: 
https://www.apache.org/licenses/#clas


was (Author: tilman):
[~amake] please read, print and sign this document:
http://community.apache.org/contributors/index.html
send it to secretary at apache.org. More about here: 
https://www.apache.org/licenses/#clas

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

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

2018-02-13 Thread JIRA 

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

Andreas Lehmkühler commented on PDFBOX-4106:


{quote}[~lehmi] do we need an ICLA for this?
{quote}
Yes, we need one, it's a substantial addition.

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

[jira] [Commented] (PDFBOX-3698) Static Initialization Deadlock between COSNumber/COSInteger

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-3698:
-

On a closed issue, it means that it was fixed for that version. The reported 
bug was fixed. Your different code indicates that either that or a new problem 
wasn't fixed in 2.0.5. It works in the trunk because some initializers were 
removed.I am not removing the 2.0.5 because I can't without reopening.

> Static Initialization Deadlock between COSNumber/COSInteger
> ---
>
> Key: PDFBOX-3698
> URL: https://issues.apache.org/jira/browse/PDFBOX-3698
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
> Environment: Mac OSX 10.12.3, Java(TM) SE Runtime Environment (build 
> 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>Reporter: Sean Story
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.5, 3.0.0 PDFBox
>
>
> h3. Problem
> Using Tika 1.10 (PDF Box 1.8.10) to parse PDF documents in a multi-threaded 
> application, processing unexpectedly halted. Investigating the output of a 
> {{kill -3}}, we found:
> {noformat}
> "pool-2-thread-18" #50 prio=5 os_prio=0 tid=0x2af088a67000 nid=0xc9b9 in 
> Object.wait() [0x2af0dc803000]
>java.lang.Thread.State: RUNNABLE
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 15
> "pool-2-thread-13" #45 prio=5 os_prio=0 tid=0x2af0cf910800 nid=0xc9b4 in 
> Object.wait() [0x2af0dc2ff000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSDocument.getObjectFromPool(COSDocument.java:720)
>   at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:685)
> x 2
> "pool-2-thread-11" #43 prio=5 os_prio=0 tid=0x2af0cfba6000 nid=0xc9b2 in 
> Object.wait() [0x2af0dc0fc000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSNumber.(COSNumber.java:33)
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 1
> {noformat}
> Upon further investigation, it appears that there is a risk for deadlock when 
> BaseParser calls {{COSNumber.get()}} and COSDocument call 
> {{COSInteger.get()}}.
> I was able to semi-reliably replicate this issue with the below Spock test:
> {noformat}
> import org.apache.pdfbox.cos.COSInteger
> import org.apache.pdfbox.cos.COSNumber
> import spock.lang.Specification
> class ThreadingIssueSpec extends Specification{
> def "testy test"(){
> setup:
> Thread thread = new Thread(new Runnable(){
> @Override
> void run() {
> for (int i =0; i<100; i++){
> COSNumber.get("-")
> }
> }
> })
> thread.start()
> for(int i =0; i<100; i++) {
> COSInteger.get("-")
> }
> thread.join()
> expect:
> 1==1
> }
> }
> {noformat}
> (you'll likely need to run this several times before the test hangs, but it 
> does eventually hang)
> I updated my Tika dep to 1.14 (PDF Box 2.0.3) and was still able to replicate 
> this issue.



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

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

[jira] [Commented] (PDFBOX-3698) Static Initialization Deadlock between COSNumber/COSInteger

2018-02-13 Thread Joseph Smith (JIRA) 

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

Joseph Smith commented on PDFBOX-3698:
--

Was the intention to fix this is 2.0.5?  Based on the comments I was thinking 
that the intention is this can only be fixed in 3.0.  If that is true then I 
think it is fine.  I was just requesting that the fixed version field remove 
2.0.5 so that it isn't misleading.

> Static Initialization Deadlock between COSNumber/COSInteger
> ---
>
> Key: PDFBOX-3698
> URL: https://issues.apache.org/jira/browse/PDFBOX-3698
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
> Environment: Mac OSX 10.12.3, Java(TM) SE Runtime Environment (build 
> 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>Reporter: Sean Story
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.5, 3.0.0 PDFBox
>
>
> h3. Problem
> Using Tika 1.10 (PDF Box 1.8.10) to parse PDF documents in a multi-threaded 
> application, processing unexpectedly halted. Investigating the output of a 
> {{kill -3}}, we found:
> {noformat}
> "pool-2-thread-18" #50 prio=5 os_prio=0 tid=0x2af088a67000 nid=0xc9b9 in 
> Object.wait() [0x2af0dc803000]
>java.lang.Thread.State: RUNNABLE
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 15
> "pool-2-thread-13" #45 prio=5 os_prio=0 tid=0x2af0cf910800 nid=0xc9b4 in 
> Object.wait() [0x2af0dc2ff000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSDocument.getObjectFromPool(COSDocument.java:720)
>   at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:685)
> x 2
> "pool-2-thread-11" #43 prio=5 os_prio=0 tid=0x2af0cfba6000 nid=0xc9b2 in 
> Object.wait() [0x2af0dc0fc000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSNumber.(COSNumber.java:33)
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 1
> {noformat}
> Upon further investigation, it appears that there is a risk for deadlock when 
> BaseParser calls {{COSNumber.get()}} and COSDocument call 
> {{COSInteger.get()}}.
> I was able to semi-reliably replicate this issue with the below Spock test:
> {noformat}
> import org.apache.pdfbox.cos.COSInteger
> import org.apache.pdfbox.cos.COSNumber
> import spock.lang.Specification
> class ThreadingIssueSpec extends Specification{
> def "testy test"(){
> setup:
> Thread thread = new Thread(new Runnable(){
> @Override
> void run() {
> for (int i =0; i<100; i++){
> COSNumber.get("-")
> }
> }
> })
> thread.start()
> for(int i =0; i<100; i++) {
> COSInteger.get("-")
> }
> thread.join()
> expect:
> 1==1
> }
> }
> {noformat}
> (you'll likely need to run this several times before the test hangs, but it 
> does eventually hang)
> I updated my Tika dep to 1.14 (PDF Box 2.0.3) and was still able to replicate 
> this issue.



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

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

[jira] [Commented] (PDFBOX-3698) Static Initialization Deadlock between COSNumber/COSInteger

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-3698:
-

This issue is closed, I have created issue PDFBOX-4109.

> Static Initialization Deadlock between COSNumber/COSInteger
> ---
>
> Key: PDFBOX-3698
> URL: https://issues.apache.org/jira/browse/PDFBOX-3698
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
> Environment: Mac OSX 10.12.3, Java(TM) SE Runtime Environment (build 
> 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>Reporter: Sean Story
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.5, 3.0.0 PDFBox
>
>
> h3. Problem
> Using Tika 1.10 (PDF Box 1.8.10) to parse PDF documents in a multi-threaded 
> application, processing unexpectedly halted. Investigating the output of a 
> {{kill -3}}, we found:
> {noformat}
> "pool-2-thread-18" #50 prio=5 os_prio=0 tid=0x2af088a67000 nid=0xc9b9 in 
> Object.wait() [0x2af0dc803000]
>java.lang.Thread.State: RUNNABLE
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 15
> "pool-2-thread-13" #45 prio=5 os_prio=0 tid=0x2af0cf910800 nid=0xc9b4 in 
> Object.wait() [0x2af0dc2ff000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSDocument.getObjectFromPool(COSDocument.java:720)
>   at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:685)
> x 2
> "pool-2-thread-11" #43 prio=5 os_prio=0 tid=0x2af0cfba6000 nid=0xc9b2 in 
> Object.wait() [0x2af0dc0fc000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSNumber.(COSNumber.java:33)
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 1
> {noformat}
> Upon further investigation, it appears that there is a risk for deadlock when 
> BaseParser calls {{COSNumber.get()}} and COSDocument call 
> {{COSInteger.get()}}.
> I was able to semi-reliably replicate this issue with the below Spock test:
> {noformat}
> import org.apache.pdfbox.cos.COSInteger
> import org.apache.pdfbox.cos.COSNumber
> import spock.lang.Specification
> class ThreadingIssueSpec extends Specification{
> def "testy test"(){
> setup:
> Thread thread = new Thread(new Runnable(){
> @Override
> void run() {
> for (int i =0; i<100; i++){
> COSNumber.get("-")
> }
> }
> })
> thread.start()
> for(int i =0; i<100; i++) {
> COSInteger.get("-")
> }
> thread.join()
> expect:
> 1==1
> }
> }
> {noformat}
> (you'll likely need to run this several times before the test hangs, but it 
> does eventually hang)
> I updated my Tika dep to 1.14 (PDF Box 2.0.3) and was still able to replicate 
> this issue.



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

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

[jira] [Created] (PDFBOX-4109) Static Initialization Deadlock between COSNumber/COSInteger (2)

2018-02-13 Thread Tilman Hausherr (JIRA) 
Tilman Hausherr created PDFBOX-4109:
---

 Summary: Static Initialization Deadlock between 
COSNumber/COSInteger (2)
 Key: PDFBOX-4109
 URL: https://issues.apache.org/jira/browse/PDFBOX-4109
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.8, 2.0.5
Reporter: Tilman Hausherr


Written by [~jesmith3] in PDFBOX-3698:
{code:java}
public class PDFBox3698
{
public static void main(String[] args) throws ClassNotFoundException, 
InterruptedException
{
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
try {
Class.forName(COSNumber.class.getName(), true, 
COSNumber.class.getClassLoader());
} catch (ClassNotFoundException ex) {
//
}
}
});
thread.start();
Class.forName(COSInteger.class.getName(), true, 
COSInteger.class.getClassLoader());
thread.join();
}
}
{code}
I was able to reproduce in 2.0.5 with a few executions.

I downloaded 3.0.0-SNAPSHOT 453 and ran the test against it and I can no longer 
reproduce the issue.



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

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

[jira] [Commented] (PDFBOX-4095) Non Separable Blend Modes implementation(HUE, SATURATION, COLOR, LUMINOSITY)

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-4095:
-

thanks, wow

I did a very quick test by adding this to my rendering test
{code}
BufferedImage image = renderer.renderImageWithDPI(i, 96, ImageType.ARGB);
BufferedImage imageWhite = new BufferedImage(image.getWidth(), 
image.getHeight(), BufferedImage.TYPE_INT_RGB);
Graphics2D g = (Graphics2D) imageWhite.getGraphics();
g.setBackground(Color.WHITE);
g.clearRect(0, 0, image.getWidth(), image.getHeight());
g.drawImage(image, 0, 0, null);
g.dispose();
image = imageWhite;
// old code:
//BufferedImage image = renderer.renderImageWithDPI(i, 96); // Windows native 
DPI
{code}
and the differences are amazing... I'll have to check each one of them.

> Non Separable Blend Modes implementation(HUE, SATURATION, COLOR, LUMINOSITY)
> 
>
> Key: PDFBOX-4095
> URL: https://issues.apache.org/jira/browse/PDFBOX-4095
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.8
>Reporter: savan patel
>Priority: Major
> Attachments: BlendComposite.java.patch, BlendMode.java.patch, 
> COSName.java.patch, blendmodes.pdf, gs-bugzilla690477.pdf, 
> gs-bugzilla697433-1.pdf
>
>
> I have a patch for implementation of non separable blend modes...



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

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

[jira] [Commented] (PDFBOX-3698) Static Initialization Deadlock between COSNumber/COSInteger

2018-02-13 Thread Joseph Smith (JIRA) 

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

Joseph Smith commented on PDFBOX-3698:
--

[~tilman], the initial test using Spock is written in Groovy which internally 
uses Class.forName to initialize the class.  I have reproduced the issue 
starting with your Java code snippet by making the following change
{code:java}
public class PDFBox3698
{
public static void main(String[] args) throws ClassNotFoundException, 
InterruptedException
{
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
try {
Class.forName(COSNumber.class.getName(), true, 
COSNumber.class.getClassLoader());
} catch (ClassNotFoundException ex) {
//
}
}
});
thread.start();
Class.forName(COSInteger.class.getName(), true, 
COSInteger.class.getClassLoader());
thread.join();
}
}
{code}
I was able to reproduce in 2.0.5 with a few executions.

I downloaded 3.0.0-SNAPSHOT 453 and ran the test against it and I can no longer 
reproduce the issue.

Would you mind removing 2.0.5 from the fix version list?  It tricked me into 
attempting that first which didn't work out.

> Static Initialization Deadlock between COSNumber/COSInteger
> ---
>
> Key: PDFBOX-3698
> URL: https://issues.apache.org/jira/browse/PDFBOX-3698
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
> Environment: Mac OSX 10.12.3, Java(TM) SE Runtime Environment (build 
> 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>Reporter: Sean Story
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.5, 3.0.0 PDFBox
>
>
> h3. Problem
> Using Tika 1.10 (PDF Box 1.8.10) to parse PDF documents in a multi-threaded 
> application, processing unexpectedly halted. Investigating the output of a 
> {{kill -3}}, we found:
> {noformat}
> "pool-2-thread-18" #50 prio=5 os_prio=0 tid=0x2af088a67000 nid=0xc9b9 in 
> Object.wait() [0x2af0dc803000]
>java.lang.Thread.State: RUNNABLE
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 15
> "pool-2-thread-13" #45 prio=5 os_prio=0 tid=0x2af0cf910800 nid=0xc9b4 in 
> Object.wait() [0x2af0dc2ff000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSDocument.getObjectFromPool(COSDocument.java:720)
>   at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:685)
> x 2
> "pool-2-thread-11" #43 prio=5 os_prio=0 tid=0x2af0cfba6000 nid=0xc9b2 in 
> Object.wait() [0x2af0dc0fc000]
>java.lang.Thread.State: RUNNABLE
>   at org.apache.pdfbox.cos.COSNumber.(COSNumber.java:33)
>   at 
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 1
> {noformat}
> Upon further investigation, it appears that there is a risk for deadlock when 
> BaseParser calls {{COSNumber.get()}} and COSDocument call 
> {{COSInteger.get()}}.
> I was able to semi-reliably replicate this issue with the below Spock test:
> {noformat}
> import org.apache.pdfbox.cos.COSInteger
> import org.apache.pdfbox.cos.COSNumber
> import spock.lang.Specification
> class ThreadingIssueSpec extends Specification{
> def "testy test"(){
> setup:
> Thread thread = new Thread(new Runnable(){
> @Override
> void run() {
> for (int i =0; i<100; i++){
> COSNumber.get("-")
> }
> }
> })
> thread.start()
> for(int i =0; i<100; i++) {
> COSInteger.get("-")
> }
> thread.join()
> expect:
> 1==1
> }
> }
> {noformat}
> (you'll likely need to run this several times before the test hangs, but it 
> does eventually hang)
> I updated my Tika dep to 1.14 (PDF Box 2.0.3) and was still able to replicate 
> this issue.



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

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

[jira] [Resolved] (PDFBOX-4108) /Length1 not needed for /CIDToGIDMap

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr resolved PDFBOX-4108.
-
Resolution: Fixed

> /Length1 not needed for /CIDToGIDMap
> 
>
> Key: PDFBOX-4108
> URL: https://issues.apache.org/jira/browse/PDFBOX-4108
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.9, 3.0.0 PDFBox
>
>
> The /Length1 entry isn't needed, it isn't mentioned in the PDF specification, 
> so I am removing it. As an additional test, I checked a file created by us 
> with veraPDF and it passes.



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

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

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

2018-02-13 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-4071: partial revert

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



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

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

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

2018-02-13 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-4071: use try-with-resources; remove null check because input is never 
null here

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



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

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

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

2018-02-13 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-4071: add debugging hint

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



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

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

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

2018-02-13 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-4071: add debugging hint

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



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

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

[jira] [Commented] (PDFBOX-4108) /Length1 not needed for /CIDToGIDMap

2018-02-13 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-4108: /Length1 not needed for /CIDToGIDMap

> /Length1 not needed for /CIDToGIDMap
> 
>
> Key: PDFBOX-4108
> URL: https://issues.apache.org/jira/browse/PDFBOX-4108
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.9, 3.0.0 PDFBox
>
>
> The /Length1 entry isn't needed, it isn't mentioned in the PDF specification, 
> so I am removing it. As an additional test, I checked a file created by us 
> with veraPDF and it passes.



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

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

[jira] [Commented] (PDFBOX-4108) /Length1 not needed for /CIDToGIDMap

2018-02-13 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-4108: /Length1 not needed for /CIDToGIDMap

> /Length1 not needed for /CIDToGIDMap
> 
>
> Key: PDFBOX-4108
> URL: https://issues.apache.org/jira/browse/PDFBOX-4108
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.8
>Reporter: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.9, 3.0.0 PDFBox
>
>
> The /Length1 entry isn't needed, it isn't mentioned in the PDF specification, 
> so I am removing it. As an additional test, I checked a file created by us 
> with veraPDF and it passes.



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

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

[jira] [Created] (PDFBOX-4108) /Length1 not needed for /CIDToGIDMap

2018-02-13 Thread Tilman Hausherr (JIRA) 
Tilman Hausherr created PDFBOX-4108:
---

 Summary: /Length1 not needed for /CIDToGIDMap
 Key: PDFBOX-4108
 URL: https://issues.apache.org/jira/browse/PDFBOX-4108
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 2.0.8
Reporter: Tilman Hausherr
 Fix For: 2.0.9, 3.0.0 PDFBox


The /Length1 entry isn't needed, it isn't mentioned in the PDF specification, 
so I am removing it. As an additional test, I checked a file created by us with 
veraPDF and it passes.




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

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

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

2018-02-13 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-4106:
-

That looks interesting and is very welcome, of course. Some thoughts:

I looked at the first patch; are you aware that UnicodeScript is a JDK7 class? 
This would mean your improvement can't be used in PDFBox 2.*, only in 3. That 
one has no planned release date, it could be several months or several years.

I see you made an effort in patch 5 to make it non-breaking, but I suspect that 
in patch 4 the use of the new CmapLookup interface would be a breaking change, 
isn't it? That would be another reason it couldn't be used in 2.*.

The sample code
{code:java}
ttf.disableGsubFeature("vrt2");
ttf.disableGsubFeature("vert");
{code}
is too difficult for an average user. I'd prefer to have something on a high 
level, e.g. an option in an additional vertical loader, or a method. The 
"natural" setting should be the default. (What would a newbie "vertical font 
user" expect? (2) or (3) in your sample PDF ?)

[~lehmi] do we need an ICLA for this?

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



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

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

[jira] [Commented] (PDFBOX-4095) Non Separable Blend Modes implementation(HUE, SATURATION, COLOR, LUMINOSITY)

2018-02-13 Thread Jani Pehkonen (JIRA) 

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

Jani Pehkonen commented on PDFBOX-4095:
---

{quote}some blendmodes don't work properly against the page background
{quote}
The "unmarked space" simply means a raster buffer (like BufferedImage) that is 
initially fully transparent. This makes the blend modes work. No new graphics 
engine is needed.

See how Mozilla PDF.js has implemented it 
[here|https://github.com/mozilla/pdf.js/blob/ea3d8450d218dd53619c72c934547fe57f22530f/src/display/canvas.js#L731].
 If a PDF page uses any blend modes [other than 
Normal|https://github.com/mozilla/pdf.js/blob/ea3d8450d218dd53619c72c934547fe57f22530f/src/core/evaluator.js#L226],
 PDF.js renders everything on a fully transparent RGBA canvas. Finally when the 
page has been rendered, PDF.js draws the RGBA canvas on a white canvas.

When rendering graphics like this in a fully transparent buffer, you are 
actually implementing _page groups_, which are explained in the PDF 32000 
standard in section 11.4.7.

> Non Separable Blend Modes implementation(HUE, SATURATION, COLOR, LUMINOSITY)
> 
>
> Key: PDFBOX-4095
> URL: https://issues.apache.org/jira/browse/PDFBOX-4095
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.8
>Reporter: savan patel
>Priority: Major
> Attachments: BlendComposite.java.patch, BlendMode.java.patch, 
> COSName.java.patch, blendmodes.pdf, gs-bugzilla690477.pdf, 
> gs-bugzilla697433-1.pdf
>
>
> I have a patch for implementation of non separable blend modes...



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

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

Jenkins build is back to normal : PDFBox-Trunk-jdk9 #266

2018-02-13 Thread Apache Jenkins Server 
See 


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

Jenkins build is back to normal : PDFBox-sonar » Apache PDFBox tools #384

2018-02-13 Thread Apache Jenkins Server 
See 



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

Jenkins build is back to normal : PDFBox-sonar #384

2018-02-13 Thread Apache Jenkins Server 
See 


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

Jenkins build is back to normal : PDFBox-sonar » Apache PDFBox application #384

2018-02-13 Thread Apache Jenkins Server 
See 



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

Build failed in Jenkins: PDFBox-sonar #383

2018-02-13 Thread Apache Jenkins Server 
See 

--
Started by user tilman
[EnvInject] - Loading node environment variables.
Building remotely on H22 (ubuntu xenial) in workspace 

Cleaning up 
Deleting 
Deleting 
Deleting 
Deleting 
Deleting 
Deleting 
Deleting 
Deleting 

Updating http://svn.apache.org/repos/asf/pdfbox/trunk at revision 
'2018-02-13T08:05:59.013 +'
At revision 1824098

No changes for http://svn.apache.org/repos/asf/pdfbox/trunk since the previous 
build
Injecting SonarQube environment variables using the configuration: ASF Sonar 
Analysis
Parsing POMs
Established TCP socket on 41157
maven3-agent.jar already up to date
maven3-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[trunk] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx1g 
-XX:MaxPermSize=300m -cp 
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/tools/maven/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar
 org.jvnet.hudson.maven3.agent.Maven3Main 
/home/jenkins/tools/maven/apache-maven-3.0.4 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven3-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 41157
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=300m; 
support was removed in 8.0
<===[JENKINS REMOTING CAPACITY]===>   channel started
Executing Maven:  -B -f 
 
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 compile 
sonar:sonar -Dsonar.host.url=https://builds.apache.org/analysis 
-Dskip-bavaria=false
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] PDFBox parent
[INFO] Apache FontBox
[INFO] Apache XmpBox
[INFO] Apache PDFBox
[INFO] Apache Preflight
[INFO] Apache Preflight application
[INFO] Apache PDFBox Debugger
[INFO] Apache PDFBox tools
[INFO] Apache PDFBox application
[INFO] Apache PDFBox Debugger application
[INFO] Apache PDFBox examples
[INFO] Apache PDFBox
[INFO] 
[INFO] 
[INFO] Building PDFBox parent 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ pdfbox-parent 
---
[INFO] 
[INFO] 
[INFO] Building Apache FontBox 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ fontbox ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ fontbox 
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 91 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ fontbox ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 98 source files to 

[WARNING] bootstrap class path not set in conjunction with -source 1.7
[WARNING] 
:
 Some input files use unchecked or unsafe operations.
[WARNING] 
:
 Recompile with -Xlint:unchecked for details.
[INFO] 
[INFO] 
[INFO] Building Apache XmpBox 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ xmpbox ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ xmpbox ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory

Build failed in Jenkins: PDFBox-sonar » Apache PDFBox tools #383

2018-02-13 Thread Apache Jenkins Server 
See 


--
[INFO] 
[INFO] 
[INFO] Building Apache PDFBox tools 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ pdfbox-tools 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
pdfbox-tools ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ pdfbox-tools 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 23 source files to 

[INFO] -
[WARNING] COMPILATION WARNING : 
[INFO] -
[WARNING] bootstrap class path not set in conjunction with -source 1.7
[INFO] 1 warning
[INFO] -
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[27,14]
 error while writing org.apache.pdfbox.tools.PDFBox: No space left on device
[INFO] 1 error
[INFO] -

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