date:20141023

[jira] [Updated] (PDFBOX-2450) RenderingHints of PageDrawer should be customizable

2014-10-23 Thread Pei-Tang Huang (JIRA)


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

Pei-Tang Huang updated PDFBOX-2450:
---
Description: 
RenderingHints defaults are hard-coded in 
[PageDrawer|https://github.com/apache/pdfbox/blob/54037862e4c55ab45eb8aecc44b79afbfbcd8dd9/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L143-L151]
 now.

However, the defaults are not always valid for every situation. For example, I 
have a PDF file containing barcodes, which will be printed out using a low 
resolution dot matrix printer. The {{RenderingHints.VALUE_ANTIALIAS_ON}}  
default confuses all of our barcode reader!

A dirty workaround I had is to extend {{PDFPrinter}}, use reflection to set the 
{{protected}} but {{final}} {{super.renderer}} field with following extension:

{code:java}
@Override
public void renderPageToGraphics(int pageIndex, Graphics2D graphics, float 
scale) throws IOException {
// proxy graphics, applying hints immediately, suppress all subsequent 
setRenderingHint request
Graphics2D hintsAppliedGraphics = new HintsAppliedGraphics2D(graphics, 
hints);

super.renderPageToGraphics(pageIndex, hintsAppliedGraphics, scale);
}
{code}

It will be nice if there exist a more elegant way to specify {{RenderHint}} s.

  was:
RenderingHints defaults are hard-coded in 
[PageDrawer|https://github.com/apache/pdfbox/blob/54037862e4c55ab45eb8aecc44b79afbfbcd8dd9/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L143-L151]
 now.

However, the defaults are not always valid for every situation. For example, I 
have a PDF file containing barcodes, which will be printed out using a low 
resolution dot matrix printer. The {{RenderingHints.VALUE_ANTIALIAS_ON}}  
default confuses all of our barcode reader!

A dirty workaround I had is to extend {{PDFPrinter}}, use reflection to set the 
{{protected}} but {{final}} {{super.renderer}} field with following extension:

{code:java}
@Override
public void renderPageToGraphics(int pageIndex, Graphics2D graphics, float 
scale)
throws IOException {
Graphics2D hintsAppliedGraphics = new HintsAppliedGraphics2D(graphics, 
hints);

super.renderPageToGraphics(pageIndex, hintsAppliedGraphics, scale);
}
{code}

Where the HintsPredefinedGraphics2D is a proxy to the original Graphics2D, 
applying the given {{RenderingHints}} immediately and will suppress all 
subsequent {{setRenderingHints}} / {{setRenderingHint}} request from 
{{PageDrawer}}.

I will be appreciated if there is a more elegant way to specify {{RenderHint}} 
s.


> RenderingHints of PageDrawer should be customizable
> ---
>
> Key: PDFBOX-2450
> URL: https://issues.apache.org/jira/browse/PDFBOX-2450
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Pei-Tang Huang
>Priority: Minor
>  Labels: PageDrawer, RenderingHints,
>
> RenderingHints defaults are hard-coded in 
> [PageDrawer|https://github.com/apache/pdfbox/blob/54037862e4c55ab45eb8aecc44b79afbfbcd8dd9/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L143-L151]
>  now.
> However, the defaults are not always valid for every situation. For example, 
> I have a PDF file containing barcodes, which will be printed out using a low 
> resolution dot matrix printer. The {{RenderingHints.VALUE_ANTIALIAS_ON}}  
> default confuses all of our barcode reader!
> A dirty workaround I had is to extend {{PDFPrinter}}, use reflection to set 
> the {{protected}} but {{final}} {{super.renderer}} field with following 
> extension:
> {code:java}
> @Override
> public void renderPageToGraphics(int pageIndex, Graphics2D graphics, float 
> scale) throws IOException {
> // proxy graphics, applying hints immediately, suppress all subsequent 
> setRenderingHint request
> Graphics2D hintsAppliedGraphics = new HintsAppliedGraphics2D(graphics, 
> hints);
> super.renderPageToGraphics(pageIndex, hintsAppliedGraphics, scale);
> }
> {code}
> It will be nice if there exist a more elegant way to specify {{RenderHint}} s.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PDFBOX-2450) RenderingHints of PageDrawer should be customizable

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson commented on PDFBOX-2450:
-

It's not clear where the problem is, are you saying that setting the anti-alias 
hint to on causes issues with the dot matrix printer driver? If the driver 
doesn't support anti-aliasing then it should ignore the hint.

Could you attach a sample PDF? (More > Attach Files). If I can examine how the 
barcodes are embedded then it might be more clear what the best solution is.

> RenderingHints of PageDrawer should be customizable
> ---
>
> Key: PDFBOX-2450
> URL: https://issues.apache.org/jira/browse/PDFBOX-2450
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Pei-Tang Huang
>Priority: Minor
>  Labels: PageDrawer, RenderingHints,
>
> RenderingHints defaults are hard-coded in 
> [PageDrawer|https://github.com/apache/pdfbox/blob/54037862e4c55ab45eb8aecc44b79afbfbcd8dd9/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L143-L151]
>  now.
> However, the defaults are not always valid for every situation. For example, 
> I have a PDF file containing barcodes, which will be printed out using a low 
> resolution dot matrix printer. The {{RenderingHints.VALUE_ANTIALIAS_ON}}  
> default confuses all of our barcode reader!
> A dirty workaround I had is to extend {{PDFPrinter}}, use reflection to set 
> the {{protected}} but {{final}} {{super.renderer}} field with following 
> extension:
> {code:java}
> @Override
> public void renderPageToGraphics(int pageIndex, Graphics2D graphics, float 
> scale)
> throws IOException {
> Graphics2D hintsAppliedGraphics = new HintsAppliedGraphics2D(graphics, 
> hints);
> super.renderPageToGraphics(pageIndex, hintsAppliedGraphics, scale);
> }
> {code}
> Where the HintsPredefinedGraphics2D is a proxy to the original Graphics2D, 
> applying the given {{RenderingHints}} immediately and will suppress all 
> subsequent {{setRenderingHints}} / {{setRenderingHint}} request from 
> {{PageDrawer}}.
> I will be appreciated if there is a more elegant way to specify 
> {{RenderHint}} s.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PDFBOX-2450) RenderingHints of PageDrawer should be customizable

2014-10-23 Thread Pei-Tang Huang (JIRA)

Pei-Tang Huang created PDFBOX-2450:
--

 Summary: RenderingHints of PageDrawer should be customizable
 Key: PDFBOX-2450
 URL: https://issues.apache.org/jira/browse/PDFBOX-2450
 Project: PDFBox
  Issue Type: Improvement
  Components: Rendering
Affects Versions: 2.0.0
Reporter: Pei-Tang Huang
Priority: Minor


RenderingHints defaults are hard-coded in 
[PageDrawer|https://github.com/apache/pdfbox/blob/54037862e4c55ab45eb8aecc44b79afbfbcd8dd9/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L143-L151]
 now.

However, the defaults are not always valid for every situation. For example, I 
have a PDF file containing barcodes, which will be printed out using a low 
resolution dot matrix printer. The {{RenderingHints.VALUE_ANTIALIAS_ON}}  
default confuses all of our barcode reader!

A dirty workaround I had is to extend {{PDFPrinter}}, use reflection to set the 
{{protected}} but {{final}} {{super.renderer}} field with following extension:

{code:java}
@Override
public void renderPageToGraphics(int pageIndex, Graphics2D graphics, float 
scale)
throws IOException {
Graphics2D hintsAppliedGraphics = new HintsAppliedGraphics2D(graphics, 
hints);

super.renderPageToGraphics(pageIndex, hintsAppliedGraphics, scale);
}
{code}

Where the HintsPredefinedGraphics2D is a proxy to the original Graphics2D, 
applying the given {{RenderingHints}} immediately and will suppress all 
subsequent {{setRenderingHints}} / {{setRenderingHint}} request from 
{{PageDrawer}}.

I will be appreciated if there is a more elegant way to specify {{RenderHint}} 
s.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PDFBOX-2447) "Cannot save a document which has been closed" when encrypting

2014-10-23 Thread Tilman Hausherr (JIRA)


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

Tilman Hausherr commented on PDFBOX-2447:
-

With your change, it would no longer do what the javadoc says: "This will get 
the document CATALOG. This is guaranteed to not return null"

> "Cannot save a document which has been closed" when encrypting
> --
>
> Key: PDFBOX-2447
> URL: https://issues.apache.org/jira/browse/PDFBOX-2447
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
> Environment: java7 deb7
>Reporter: Ralf Hauser
> Attachments: patch2447.txt, patch2447a.txt, patch2447b.txt
>
>
> InputStream content = ...;
> int keyLength = 256;
> AccessPermission ap = new AccessPermission();
> StandardProtectionPolicy spp = new 
> StandardProtectionPolicy(
> symmPw, symmPw, ap);
> spp.setEncryptionKeyLength(keyLength);
> document.protect(spp);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> document.save(baos);
> in the save() the above mentioned exception is thrown (wasn't with the 
> 2013-11 snapshot)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-2447) "Cannot save a document which has been closed" when encrypting

2014-10-23 Thread Ralf Hauser (JIRA)


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

Ralf Hauser updated PDFBOX-2447:

Attachment: patch2447b.txt

Fine, order changed in patch2447b.txt

Please committ

> "Cannot save a document which has been closed" when encrypting
> --
>
> Key: PDFBOX-2447
> URL: https://issues.apache.org/jira/browse/PDFBOX-2447
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
> Environment: java7 deb7
>Reporter: Ralf Hauser
> Attachments: patch2447.txt, patch2447a.txt, patch2447b.txt
>
>
> InputStream content = ...;
> int keyLength = 256;
> AccessPermission ap = new AccessPermission();
> StandardProtectionPolicy spp = new 
> StandardProtectionPolicy(
> symmPw, symmPw, ap);
> spp.setEncryptionKeyLength(keyLength);
> document.protect(spp);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> document.save(baos);
> in the save() the above mentioned exception is thrown (wasn't with the 
> 2013-11 snapshot)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-2449) Character missing in text extraction

2014-10-23 Thread Tilman Hausherr (JIRA)


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

Tilman Hausherr updated PDFBOX-2449:

Description: 
The attached file brings this text extraction:

1.8.6:
For safe! clean! abundant water?in our homes!
rivers! lakes! and streams?is one of our

1.8.7:
For safe! clean! abundant water?in our homes!
rivers! lakes! and streams?is one of our

1.8.8:
For safe! clean! abundant water?n our homes!
rivers! lakes! and streams?s one of our

2.0:
For safe! clean! abundant waterin our homes!
rivers! lakes! and streamsis one of our

AR:
For safe! clean! abundant waterin our homes!
rivers! lakes! and streamsis one of our

So the "i" has been lost in the 1.8.8 version. (2.0 and AR have a character 
that is invisible when viewing this issue, but can be seen when editing)

  was:
The attached file brings this text extraction:

1.8.6:
For safe! clean! abundant water?in our homes!
rivers! lakes! and streams?is one of our

1.8.7:
For safe! clean! abundant water?in our homes!
rivers! lakes! and streams?is one of our

1.8.8:
For safe! clean! abundant water?n our homes!
rivers! lakes! and streams?s one of our

2.0:
For safe! clean! abundant waterin our homes!
rivers! lakes! and streamsis one of our

AR:
For safe! clean! abundant waterin our homes!
rivers! lakes! and streamsis one of our

So the "i" has been lost in the 1.8.8 version.


> Character missing in text extraction
> 
>
> Key: PDFBOX-2449
> URL: https://issues.apache.org/jira/browse/PDFBOX-2449
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 1.8.8
>Reporter: Tilman Hausherr
> Attachments: 267739.pdf
>
>
> The attached file brings this text extraction:
> 1.8.6:
> For safe! clean! abundant water?in our homes!
> rivers! lakes! and streams?is one of our
> 1.8.7:
> For safe! clean! abundant water?in our homes!
> rivers! lakes! and streams?is one of our
> 1.8.8:
> For safe! clean! abundant water?n our homes!
> rivers! lakes! and streams?s one of our
> 2.0:
> For safe! clean! abundant waterin our homes!
> rivers! lakes! and streamsis one of our
> AR:
> For safe! clean! abundant waterin our homes!
> rivers! lakes! and streamsis one of our
> So the "i" has been lost in the 1.8.8 version. (2.0 and AR have a character 
> that is invisible when viewing this issue, but can be seen when editing)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PDFBOX-2439) ArrayIndexOutOfBoundsException in multithreaded system

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson commented on PDFBOX-2439:
-

Good point, that's a bug, it should be.

> ArrayIndexOutOfBoundsException in multithreaded system
> --
>
> Key: PDFBOX-2439
> URL: https://issues.apache.org/jira/browse/PDFBOX-2439
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: TestPDFBox.java
>
>
> When it loads replacement font from OS i sometimes get:
> Exception in thread "Thread-27" java.lang.ArrayIndexOutOfBoundsException: 
> 40036
>   at 
> org.apache.fontbox.ttf.GlyfSimpleDescript.readFlags(GlyfSimpleDescript.java:197)
>   at 
> org.apache.fontbox.ttf.GlyfSimpleDescript.(GlyfSimpleDescript.java:78)
>   at org.apache.fontbox.ttf.GlyphData.initData(GlyphData.java:58)
>   at org.apache.fontbox.ttf.GlyphTable.getGlyph(GlyphTable.java:161)
>   at 
> org.apache.pdfbox.rendering.font.TTFGlyph2D.getPathForGID(TTFGlyph2D.java:140)
>   at 
> org.apache.pdfbox.rendering.font.TTFGlyph2D.getPathForCharacterCode(TTFGlyph2D.java:92)
>   at 
> org.apache.pdfbox.rendering.PageDrawer.drawGlyph2D(PageDrawer.java:392)
>   at org.apache.pdfbox.rendering.PageDrawer.showGlyph(PageDrawer.java:372)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.showText(PDFStreamEngine.java:411)
>   at org.apache.pdfbox.rendering.PageDrawer.showText(PageDrawer.java:346)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.showTextStrings(PDFStreamEngine.java:322)
>   at 
> org.apache.pdfbox.contentstream.operator.text.ShowTextAdjusted.process(ShowTextAdjusted.java:38)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:482)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processSubStream(PDFStreamEngine.java:236)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processSubStream(PDFStreamEngine.java:201)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:155)
>   at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:177)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:228)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:160)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:109)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PDFBOX-2448) ligatures and some glyphs missing

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson reassigned PDFBOX-2448:
---

Assignee: John Hewson

> ligatures and some glyphs missing
> -
>
> Key: PDFBOX-2448
> URL: https://issues.apache.org/jira/browse/PDFBOX-2448
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
>Assignee: John Hewson
>  Labels: type1
> Fix For: 2.0.0
>
> Attachments: 115258.pdf, 1152581.jpg
>
>
> Ligatures are missing in the attached file ("filter", "identification") and 
> some glyphs (on first page, below "BAT Observations" a glyph is missing after 
> the italic "T".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-2448) ligatures and some glyphs missing

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson updated PDFBOX-2448:

Fix Version/s: 2.0.0

> ligatures and some glyphs missing
> -
>
> Key: PDFBOX-2448
> URL: https://issues.apache.org/jira/browse/PDFBOX-2448
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
>  Labels: type1
> Fix For: 2.0.0
>
> Attachments: 115258.pdf, 1152581.jpg
>
>
> Ligatures are missing in the attached file ("filter", "identification") and 
> some glyphs (on first page, below "BAT Observations" a glyph is missing after 
> the italic "T".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-2449) Character missing in text extraction

2014-10-23 Thread Tilman Hausherr (JIRA)


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

Tilman Hausherr updated PDFBOX-2449:

Attachment: 267739.pdf

> Character missing in text extraction
> 
>
> Key: PDFBOX-2449
> URL: https://issues.apache.org/jira/browse/PDFBOX-2449
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 1.8.8
>Reporter: Tilman Hausherr
> Attachments: 267739.pdf
>
>
> The attached file brings this text extraction:
> 1.8.6:
> For safe! clean! abundant water?in our homes!
> rivers! lakes! and streams?is one of our
> 1.8.7:
> For safe! clean! abundant water?in our homes!
> rivers! lakes! and streams?is one of our
> 1.8.8:
> For safe! clean! abundant water?n our homes!
> rivers! lakes! and streams?s one of our
> 2.0:
> For safe! clean! abundant waterin our homes!
> rivers! lakes! and streamsis one of our
> AR:
> For safe! clean! abundant waterin our homes!
> rivers! lakes! and streamsis one of our
> So the "i" has been lost in the 1.8.8 version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PDFBOX-2449) Character missing in text extraction

2014-10-23 Thread Tilman Hausherr (JIRA)

Tilman Hausherr created PDFBOX-2449:
---

 Summary: Character missing in text extraction
 Key: PDFBOX-2449
 URL: https://issues.apache.org/jira/browse/PDFBOX-2449
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.8
Reporter: Tilman Hausherr


The attached file brings this text extraction:

1.8.6:
For safe! clean! abundant water?in our homes!
rivers! lakes! and streams?is one of our

1.8.7:
For safe! clean! abundant water?in our homes!
rivers! lakes! and streams?is one of our

1.8.8:
For safe! clean! abundant water?n our homes!
rivers! lakes! and streams?s one of our

2.0:
For safe! clean! abundant waterin our homes!
rivers! lakes! and streamsis one of our

AR:
For safe! clean! abundant waterin our homes!
rivers! lakes! and streamsis one of our

So the "i" has been lost in the 1.8.8 version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PDFBOX-2439) ArrayIndexOutOfBoundsException in multithreaded system

2014-10-23 Thread simon steiner (JIRA)


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

simon steiner commented on PDFBOX-2439:
---

I couldnt see a place where GlyphTable.cache is populated

> ArrayIndexOutOfBoundsException in multithreaded system
> --
>
> Key: PDFBOX-2439
> URL: https://issues.apache.org/jira/browse/PDFBOX-2439
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: TestPDFBox.java
>
>
> When it loads replacement font from OS i sometimes get:
> Exception in thread "Thread-27" java.lang.ArrayIndexOutOfBoundsException: 
> 40036
>   at 
> org.apache.fontbox.ttf.GlyfSimpleDescript.readFlags(GlyfSimpleDescript.java:197)
>   at 
> org.apache.fontbox.ttf.GlyfSimpleDescript.(GlyfSimpleDescript.java:78)
>   at org.apache.fontbox.ttf.GlyphData.initData(GlyphData.java:58)
>   at org.apache.fontbox.ttf.GlyphTable.getGlyph(GlyphTable.java:161)
>   at 
> org.apache.pdfbox.rendering.font.TTFGlyph2D.getPathForGID(TTFGlyph2D.java:140)
>   at 
> org.apache.pdfbox.rendering.font.TTFGlyph2D.getPathForCharacterCode(TTFGlyph2D.java:92)
>   at 
> org.apache.pdfbox.rendering.PageDrawer.drawGlyph2D(PageDrawer.java:392)
>   at org.apache.pdfbox.rendering.PageDrawer.showGlyph(PageDrawer.java:372)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.showText(PDFStreamEngine.java:411)
>   at org.apache.pdfbox.rendering.PageDrawer.showText(PageDrawer.java:346)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.showTextStrings(PDFStreamEngine.java:322)
>   at 
> org.apache.pdfbox.contentstream.operator.text.ShowTextAdjusted.process(ShowTextAdjusted.java:38)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:482)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processSubStream(PDFStreamEngine.java:236)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processSubStream(PDFStreamEngine.java:201)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:155)
>   at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:177)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:228)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:160)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:109)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-2448) ligatures and some glyphs missing

2014-10-23 Thread Tilman Hausherr (JIRA)


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

Tilman Hausherr updated PDFBOX-2448:

Attachment: 1152581.jpg
115258.pdf

> ligatures and some glyphs missing
> -
>
> Key: PDFBOX-2448
> URL: https://issues.apache.org/jira/browse/PDFBOX-2448
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
>  Labels: type1
> Attachments: 115258.pdf, 1152581.jpg
>
>
> Ligatures are missing in the attached file ("filter", "identification") and 
> some glyphs (on first page, below "BAT Observations" a glyph is missing after 
> the italic "T".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PDFBOX-2448) ligatures and some glyphs missing

2014-10-23 Thread Tilman Hausherr (JIRA)

Tilman Hausherr created PDFBOX-2448:
---

 Summary: ligatures and some glyphs missing
 Key: PDFBOX-2448
 URL: https://issues.apache.org/jira/browse/PDFBOX-2448
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox
Affects Versions: 2.0.0
Reporter: Tilman Hausherr


Ligatures are missing in the attached file ("filter", "identification") and 
some glyphs (on first page, below "BAT Observations" a glyph is missing after 
the italic "T".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PDFBOX-2439) ArrayIndexOutOfBoundsException in multithreaded system

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson commented on PDFBOX-2439:
-

Thanks, but please attach patches as files, not comments, they cannot be copy + 
pasted from comments correctly due to JIRA markup. I can't apply the patch from 
your comment.

{quote}Is GlyphTable.cache used?{quote}
Yes, by GlyphTable#getGlyph

{quote}
I also get
Exception LCMS error 13: Couldn't link the profiles
{quote}

Please open a new issue for that, it's related to ICC Profiles.

> ArrayIndexOutOfBoundsException in multithreaded system
> --
>
> Key: PDFBOX-2439
> URL: https://issues.apache.org/jira/browse/PDFBOX-2439
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: TestPDFBox.java
>
>
> When it loads replacement font from OS i sometimes get:
> Exception in thread "Thread-27" java.lang.ArrayIndexOutOfBoundsException: 
> 40036
>   at 
> org.apache.fontbox.ttf.GlyfSimpleDescript.readFlags(GlyfSimpleDescript.java:197)
>   at 
> org.apache.fontbox.ttf.GlyfSimpleDescript.(GlyfSimpleDescript.java:78)
>   at org.apache.fontbox.ttf.GlyphData.initData(GlyphData.java:58)
>   at org.apache.fontbox.ttf.GlyphTable.getGlyph(GlyphTable.java:161)
>   at 
> org.apache.pdfbox.rendering.font.TTFGlyph2D.getPathForGID(TTFGlyph2D.java:140)
>   at 
> org.apache.pdfbox.rendering.font.TTFGlyph2D.getPathForCharacterCode(TTFGlyph2D.java:92)
>   at 
> org.apache.pdfbox.rendering.PageDrawer.drawGlyph2D(PageDrawer.java:392)
>   at org.apache.pdfbox.rendering.PageDrawer.showGlyph(PageDrawer.java:372)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.showText(PDFStreamEngine.java:411)
>   at org.apache.pdfbox.rendering.PageDrawer.showText(PageDrawer.java:346)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.showTextStrings(PDFStreamEngine.java:322)
>   at 
> org.apache.pdfbox.contentstream.operator.text.ShowTextAdjusted.process(ShowTextAdjusted.java:38)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:482)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processSubStream(PDFStreamEngine.java:236)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processSubStream(PDFStreamEngine.java:201)
>   at 
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:155)
>   at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:177)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:228)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:160)
>   at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:109)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-2409) got the wrong result from Arabic text extraction

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson updated PDFBOX-2409:

Attachment: TextEdit-Arial.png

I'm able to get the same rendering if I use TextEdit on my Mac with Arial as 
the font, I've attached a screenshot. Looking at the text I think that the 
diacritics are being placed on the wrong character, one character too late? 
(i.e. to the left). What do you think? This could well be a PDFBox text 
encoding issue with combining diacritics.

> got the wrong result from Arabic text extraction
> 
>
> Key: PDFBOX-2409
> URL: https://issues.apache.org/jira/browse/PDFBOX-2409
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.7, 2.0.0
> Environment: Ubuntu 14.04 64bit
> java version "1.8.0_20"
>Reporter: EugenePig
>Assignee: John Hewson
> Attachments: THESSALONIANS.pdf, THESSALONIANS.txt, 
> THESSALONIANS_win7_firefox.jpg, TextEdit-Arial.png, jahewson.mac.png
>
>
> java -jar pdfbox-app-1.8.7.jar ExtractText -sort -encoding UTF-8 
> THESSALONIANS.pdf
> java -jar pdfbox-app-2.0.0-SNAPSHOT.jar ExtractText -sort -encoding UTF-8 
> THESSALONIANS.pdf
> Please compare THESSALONIANS.txt.jpg with THESSALONIANS.pdf. There are a lot 
> of differences. I just marked a few differences with red circles.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PDFBOX-2447) "Cannot save a document which has been closed" when encrypting

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson edited comment on PDFBOX-2447 at 10/23/14 6:50 PM:
---

Some feedback: please don't use backwards conditionals in patches, e.g. in the 
PDFBox source we don't write:

{{if (null == getDocumentCatalog())}}

but always:

{{if (getDocumentCatalog() == null)}}

The same applies to {{null != document}}.


was (Author: jahewson):
Some feedback: please don't use backwards conditionals in patches, e.g. in the 
PDFBox source we don't write:

{{if (null == getDocumentCatalog())}}

but always:

{{if (getDocumentCatalog() == null)}}

> "Cannot save a document which has been closed" when encrypting
> --
>
> Key: PDFBOX-2447
> URL: https://issues.apache.org/jira/browse/PDFBOX-2447
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
> Environment: java7 deb7
>Reporter: Ralf Hauser
> Attachments: patch2447.txt, patch2447a.txt
>
>
> InputStream content = ...;
> int keyLength = 256;
> AccessPermission ap = new AccessPermission();
> StandardProtectionPolicy spp = new 
> StandardProtectionPolicy(
> symmPw, symmPw, ap);
> spp.setEncryptionKeyLength(keyLength);
> document.protect(spp);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> document.save(baos);
> in the save() the above mentioned exception is thrown (wasn't with the 
> 2013-11 snapshot)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PDFBOX-2447) "Cannot save a document which has been closed" when encrypting

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson edited comment on PDFBOX-2447 at 10/23/14 6:49 PM:
---

Some feedback: please don't use backwards conditionals in patches, e.g. in the 
PDFBox source we don't write:

{{if (null == getDocumentCatalog())}}

but always:

{{if (getDocumentCatalog() == null)}}


was (Author: jahewson):
Some feedback: Please don't use backwards conditionals in patches, e.g. in the 
PDFBox source we don't write:

{{if (null == getDocumentCatalog())}}

but always:

{{if (getDocumentCatalog() == null)}}

> "Cannot save a document which has been closed" when encrypting
> --
>
> Key: PDFBOX-2447
> URL: https://issues.apache.org/jira/browse/PDFBOX-2447
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
> Environment: java7 deb7
>Reporter: Ralf Hauser
> Attachments: patch2447.txt, patch2447a.txt
>
>
> InputStream content = ...;
> int keyLength = 256;
> AccessPermission ap = new AccessPermission();
> StandardProtectionPolicy spp = new 
> StandardProtectionPolicy(
> symmPw, symmPw, ap);
> spp.setEncryptionKeyLength(keyLength);
> document.protect(spp);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> document.save(baos);
> in the save() the above mentioned exception is thrown (wasn't with the 
> 2013-11 snapshot)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PDFBOX-2447) "Cannot save a document which has been closed" when encrypting

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson commented on PDFBOX-2447:
-

Some feedback: Please don't use backwards conditionals in patches, e.g. in the 
PDFBox source we don't write:

{{if (null == getDocumentCatalog())}}

but always:

{{if (getDocumentCatalog() == null)}}

> "Cannot save a document which has been closed" when encrypting
> --
>
> Key: PDFBOX-2447
> URL: https://issues.apache.org/jira/browse/PDFBOX-2447
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
> Environment: java7 deb7
>Reporter: Ralf Hauser
> Attachments: patch2447.txt, patch2447a.txt
>
>
> InputStream content = ...;
> int keyLength = 256;
> AccessPermission ap = new AccessPermission();
> StandardProtectionPolicy spp = new 
> StandardProtectionPolicy(
> symmPw, symmPw, ap);
> spp.setEncryptionKeyLength(keyLength);
> document.protect(spp);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> document.save(baos);
> in the save() the above mentioned exception is thrown (wasn't with the 
> 2013-11 snapshot)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PDFBOX-1372) NullPointerException with loadDescriptorDictionary

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson updated PDFBOX-1372:

Fix Version/s: 2.0.0

> NullPointerException with loadDescriptorDictionary
> --
>
> Key: PDFBOX-1372
> URL: https://issues.apache.org/jira/browse/PDFBOX-1372
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 1.6.0, 2.0.0
> Environment: Windows 7, WebLogic 10.3.2, jdk160_14_R27.6.5-32.
>Reporter: wentao
>Assignee: John Hewson
> Fix For: 2.0.0
>
> Attachments: CODE128.TTF, FRE3OF9X.TTF, index128.jsp
>
>
> I downloaded a ttf from http://www.jtbarton.com/Barcodes/code128.ttf and 
> tried to use this with pdfbox 1.6.0 in my jsp.
> it returns below error
> java.lang.NullPointerException
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:339)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadTTF(PDTrueTypeFont.java:164)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadTTF(PDTrueTypeFont.java:140)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadTTF(PDTrueTypeFont.java:127)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PDFBOX-1372) NullPointerException with loadDescriptorDictionary

2014-10-23 Thread John Hewson (JIRA)


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

John Hewson reassigned PDFBOX-1372:
---

Assignee: John Hewson

> NullPointerException with loadDescriptorDictionary
> --
>
> Key: PDFBOX-1372
> URL: https://issues.apache.org/jira/browse/PDFBOX-1372
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 1.6.0, 2.0.0
> Environment: Windows 7, WebLogic 10.3.2, jdk160_14_R27.6.5-32.
>Reporter: wentao
>Assignee: John Hewson
> Fix For: 2.0.0
>
> Attachments: CODE128.TTF, FRE3OF9X.TTF, index128.jsp
>
>
> I downloaded a ttf from http://www.jtbarton.com/Barcodes/code128.ttf and 
> tried to use this with pdfbox 1.6.0 in my jsp.
> it returns below error
> java.lang.NullPointerException
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:339)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadTTF(PDTrueTypeFont.java:164)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadTTF(PDTrueTypeFont.java:140)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadTTF(PDTrueTypeFont.java:127)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 2.0

2014-10-23 Thread John Hewson

That’s very good news!

-- John

> On 23 Oct 2014, at 11:40, Tilman Hausherr  wrote:
> 
> This is now obsolete, thanks to Andreas having resolved PDFBOX-2250.
> 
> Tilman
> 
> Am 23.10.2014 um 09:33 schrieb John Hewson:
>> Do we have a JIRA issue for these, or shall I create one?
>> 
>> -- John
>> 
>> On 14 Oct 2014, at 09:18, Tilman Hausherr > > wrote:
>> 
>>> Here are some:
>>> 
>>> 055/055794.pdf
>>> 082/082463.pdf
>>> 108/108362.pdf
>>> 113/113223.pdf
>>> 115/115458.pdf
>>> 115/115463.pdf
>>> 122/122393.pdf
>>> 129/129416.pdf
>>> 133/133423.pdf
>>> 148/148020.pdf
>>> 152/152012.pdf
>>> 161/161466.pdf
>>> 
>>> to be found here:
>>> http://digitalcorpora.org/corp/nps/files/govdocs1/zipfiles/ 
>>> 
>>> 
>>> Tilman
>>> 
>>> Am 14.10.2014 um 21:06 schrieb John Hewson:
 Unless somebody provides us with a list of those files, then I think this 
 is an unreasonable request. As long as we continue to leave the old parser 
 in PDFBox, we won’t get the bug reports which we need to fix the new 
 parser, and the situation will never resolve itself. Falling back to the 
 old parser is just as bad - we won’t get bug reports.
 
 -- John
 
 On 14 Oct 2014, at 07:39, Tilman Hausherr >>> > wrote:
 
> I prefer that the "old" parser not be removed, because there are many 
> files that can only be parsed by the old parser. This came out in a  
> large scale test with TIKA.
> 
> The best idea (in my current opinion) is to use the nonSeq parser first, 
> and the old parser if there is an exception.
> 
> Tilman
> 
> Am 14.10.2014 um 09:45 schrieb Timo Boehme:
>> Hi,
>> 
>> Am 14.10.2014 um 07:22 schrieb John Hewson:
>>> Hi,
> John Hewson mailto:j...@jahewson.com>> hat am 10. 
> Oktober 2014 um 20:05 geschrieben:
> 
> 
>- Parsing (Andreas?)
 I guess we won't get a complete new parser in 2.0, but I try to 
 improve the XRef
 and the COSStream stuff
>>> It would be great if we could get rid of the old parser and switch to 
>>> the non-sequential
>>> parser, WDYT?
>> I would also propose to completely remove the old parser. That way we 
>> are more flexible in parsing streams etc. since parts of the 
>> non-sequential parser are a compromise to work side-by-side with the old 
>> parser.
>> Possibly there are a small number of functions for which the old parser 
>> is still needed - e.g. signing?
>> 
>> 
>> Best,
>> Timo
>> 
>> 
>> 
>

Re: 2.0

2014-10-23 Thread Tilman Hausherr

This is now obsolete, thanks to Andreas having resolved PDFBOX-2250.

Tilman

Am 23.10.2014 um 09:33 schrieb John Hewson:

Do we have a JIRA issue for these, or shall I create one?

-- John

On 14 Oct 2014, at 09:18, Tilman Hausherr mailto:thaush...@t-online.de>> wrote:

Here are some:

055/055794.pdf
082/082463.pdf
108/108362.pdf
113/113223.pdf
115/115458.pdf
115/115463.pdf
122/122393.pdf
129/129416.pdf
133/133423.pdf
148/148020.pdf
152/152012.pdf
161/161466.pdf

to be found here:
http://digitalcorpora.org/corp/nps/files/govdocs1/zipfiles/

Tilman

Am 14.10.2014 um 21:06 schrieb John Hewson:

Unless somebody provides us with a list of those files, then I think this is an
unreasonable request. As long as we continue to leave the old parser in PDFBox,
we won’t get the bug reports which we need to fix the new parser, and the
situation will never resolve itself. Falling back to the old parser is just as
bad - we won’t get bug reports.

-- John

On 14 Oct 2014, at 07:39, Tilman Hausherr mailto:thaush...@t-online.de>> wrote:

I prefer that the "old" parser not be removed, because there are many files
that can only be parsed by the old parser. This came out in a large scale test with TIKA.

The best idea (in my current opinion) is to use the nonSeq parser first, and
the old parser if there is an exception.

Tilman

Am 14.10.2014 um 09:45 schrieb Timo Boehme:

Hi,

Am 14.10.2014 um 07:22 schrieb John Hewson:

Hi,

John Hewson mailto:j...@jahewson.com>> hat am 10. Oktober
2014 um 20:05 geschrieben:

- Parsing (Andreas?)

I guess we won't get a complete new parser in 2.0, but I try to improve the XRef
and the COSStream stuff

It would be great if we could get rid of the old parser and switch to the
non-sequential
parser, WDYT?

I would also propose to completely remove the old parser. That way we are more
flexible in parsing streams etc. since parts of the non-sequential parser are a
compromise to work side-by-side with the old parser.
Possibly there are a small number of functions for which the old parser is
still needed - e.g. signing?

Best,
Timo

Re: 2.0

2014-10-23 Thread John Hewson

Do we have a JIRA issue for these, or shall I create one?

-- John

On 14 Oct 2014, at 09:18, Tilman Hausherr mailto:thaush...@t-online.de>> wrote:

> Here are some:
> 
> 055/055794.pdf
> 082/082463.pdf
> 108/108362.pdf
> 113/113223.pdf
> 115/115458.pdf
> 115/115463.pdf
> 122/122393.pdf
> 129/129416.pdf
> 133/133423.pdf
> 148/148020.pdf
> 152/152012.pdf
> 161/161466.pdf
> 
> to be found here:
> http://digitalcorpora.org/corp/nps/files/govdocs1/zipfiles/ 
> 
> 
> Tilman
> 
> Am 14.10.2014 um 21:06 schrieb John Hewson:
>> Unless somebody provides us with a list of those files, then I think this is 
>> an unreasonable request. As long as we continue to leave the old parser in 
>> PDFBox, we won’t get the bug reports which we need to fix the new parser, 
>> and the situation will never resolve itself. Falling back to the old parser 
>> is just as bad - we won’t get bug reports.
>> 
>> -- John
>> 
>> On 14 Oct 2014, at 07:39, Tilman Hausherr > > wrote:
>> 
>>> I prefer that the "old" parser not be removed, because there are many files 
>>> that can only be parsed by the old parser. This came out in a  large scale 
>>> test with TIKA.
>>> 
>>> The best idea (in my current opinion) is to use the nonSeq parser first, 
>>> and the old parser if there is an exception.
>>> 
>>> Tilman
>>> 
>>> Am 14.10.2014 um 09:45 schrieb Timo Boehme:
 Hi,
 
 Am 14.10.2014 um 07:22 schrieb John Hewson:
> Hi,
>>> John Hewson mailto:j...@jahewson.com>> hat am 10. 
>>> Oktober 2014 um 20:05 geschrieben:
>>> 
>>> 
>>>- Parsing (Andreas?)
>> I guess we won't get a complete new parser in 2.0, but I try to improve 
>> the XRef
>> and the COSStream stuff
> It would be great if we could get rid of the old parser and switch to the 
> non-sequential
> parser, WDYT?
 I would also propose to completely remove the old parser. That way we are 
 more flexible in parsing streams etc. since parts of the non-sequential 
 parser are a compromise to work side-by-side with the old parser.
 Possibly there are a small number of functions for which the old parser is 
 still needed - e.g. signing?
 
 
 Best,
 Timo
 
 
>> 
>

69 matches

Mail list logo