Re: rev 1616895

[Andreas Lehmkühler]

Hi,

> Tilman Hausherr  hat am 9. August 2014 um 00:59
> geschrieben:
>
>
> I got it to work, by using svn.us.apache.org instead of svn.apache.org.
> This suggests that the eu mirror is taking a nap.
Unfortunately this happens sometimes.

I'm not sure if everybody is aware of the ASF status page for all infra
services.
It was relaunched some days ago and is available here:

http://status.apache.org/

It provides some very useful information.

> Tilman
>
> Am 09.08.2014 00:50, schrieb Tilman Hausherr:
> > Something seems to be rotten with svn... I did
> > commithttp://svn.apache.org/r1616895, but the link doesn't work, and I
> > can't update my other project to the newest source.
> >
> > Tilman
> >


BR
Andreas Lehmkühler

[jira] [Commented] (PDFBOX-2274) Decoding issue in PDImageXObject

[Dominic Tubach (JIRA)]

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

Dominic Tubach commented on PDFBOX-2274:


Yes, you are right. I've now looked why the code works with 1.8, but not 2.0. 
This is what I found out:
The DCT decode filter is removed by the application through setItem() -- that's 
missing in the example code. (Yeah, that's stupid and getFilteredStream() 
should be used.) It worked in 1.8 because the attribute unfilteredStream in 
COSStream is null at that point. However in 2.0 it is not because in
{code}
PDImageXObject(PDStream stream, Map colorSpaces)
{code}
getDecodeResult() is called and the stream is decoded then. That's happening 
when getting the XObjects through PDResources. I've not investigated it 
further, but I'm wondering whether it is really necessary to decode the image 
at that point.

Another thing I thought about when looking at the code: Should it be ensured in 
COSStream.setFilters() that unfilteredStream is not null by decoding the stream 
before setting the filter? Otherwise the stream's content is lost and a call of 
getFilteredStream() or getUnfilteredStream() would trigger a 
NullPointerException.

> Decoding issue in PDImageXObject
> 
>
> Key: PDFBOX-2274
> URL: https://issues.apache.org/jira/browse/PDFBOX-2274
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
>
> I'm using JpegFactory to create an PDImageXObject from a content stream. 
> There the constrcutor
> {code}
> PDImageXObject(PDDocument document, InputStream filteredStream, 
> COSBase cosFilter, int width, int height, int bitsPerComponent, 
> PDColorSpace initColorSpace)
> {code}
> is used.
> I've found the following issue:
> The method getUnfilteredStream() of the COSStream in the PDImageXObject 
> returns an input stream containing a RandomAccessFileInputStream with
> {{currentPosition = 50814}} and {{endPosition = 144}} and my following 
> operation fails.
> If the method doDecode() of the COSStream is called before the filter is set 
> in the COSStream the input stream returned by getUnfilteredStream() contains 
> a RandomAccessFileInputStream with {{currentPosition = 0}} and {{endPosition 
> = 50814}} and the result is as expected.
> I've achieved this by adding
> {code}
> getStream().getStream().getDecodeResult();
> {code}
> before
> {code}
> getCOSStream().setItem(COSName.FILTER, cosFilter);
> {code}
> in the PDImageXObject contructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2275) ClassCastException in PDResources

[Dominic Tubach (JIRA)]

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

Dominic Tubach commented on PDFBOX-2275:


Yes, that fixes the problem. I've temporarily done more or less the same at my 
copy of pdfbox. I think the second instanceof in your code is not necessary.

> ClassCastException in PDResources
> -
>
> Key: PDFBOX-2275
> URL: https://issues.apache.org/jira/browse/PDFBOX-2275
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
> Attachments: PDResources.diff
>
>
> The code (added in revision 1606860)
> {code}
> COSObject cosObject = (COSObject)dict.getItem(objName);
> {code} in the method getXObjects() in PDResources fails with a 
> ClassCastException:
> bq. org.apache.pdfbox.cos.COSStream cannot be cast to 
> org.apache.pdfbox.cos.COSObject
> The document issuing this exception is created using the following code:
> {code}
> PDDocument doc = new PDDocument();
> PDPage page = new PDPage();
> doc.addPage(page);
> PDImageXObject image = JPEGFactory.createFromStream(doc, imageStream);
> try (PDPageContentStream contentStream = new PDPageContentStream(doc, page, 
> false, false)) {
> contentStream.drawImage(image, 20, 20);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2281) Yellow box shown

[simon steiner (JIRA)]

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

simon steiner updated PDFBOX-2281:
--

Attachment: image.pdf

> Yellow box shown
> 
>
> Key: PDFBOX-2281
> URL: https://issues.apache.org/jira/browse/PDFBOX-2281
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
> Attachments: image.pdf
>
>
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> image.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-2281) Yellow box shown

[simon steiner (JIRA)]

simon steiner created PDFBOX-2281:
-

 Summary: Yellow box shown
 Key: PDFBOX-2281
 URL: https://issues.apache.org/jira/browse/PDFBOX-2281
 Project: PDFBox
  Issue Type: Bug
  Components: Rendering
Affects Versions: 2.0.0
Reporter: simon steiner
 Attachments: image.pdf

java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
image.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2274) Decoding issue in PDImageXObject

[Dominic Tubach (JIRA)]

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

Dominic Tubach commented on PDFBOX-2274:


I have to correct my last comment. The removal of the DCT filter and the call 
of getUnfilteredStream() is done to get the DCT stream if there are also other 
filters set such as ASCII85.

> Decoding issue in PDImageXObject
> 
>
> Key: PDFBOX-2274
> URL: https://issues.apache.org/jira/browse/PDFBOX-2274
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
>
> I'm using JpegFactory to create an PDImageXObject from a content stream. 
> There the constrcutor
> {code}
> PDImageXObject(PDDocument document, InputStream filteredStream, 
> COSBase cosFilter, int width, int height, int bitsPerComponent, 
> PDColorSpace initColorSpace)
> {code}
> is used.
> I've found the following issue:
> The method getUnfilteredStream() of the COSStream in the PDImageXObject 
> returns an input stream containing a RandomAccessFileInputStream with
> {{currentPosition = 50814}} and {{endPosition = 144}} and my following 
> operation fails.
> If the method doDecode() of the COSStream is called before the filter is set 
> in the COSStream the input stream returned by getUnfilteredStream() contains 
> a RandomAccessFileInputStream with {{currentPosition = 0}} and {{endPosition 
> = 50814}} and the result is as expected.
> I've achieved this by adding
> {code}
> getStream().getStream().getDecodeResult();
> {code}
> before
> {code}
> getCOSStream().setItem(COSName.FILTER, cosFilter);
> {code}
> in the PDImageXObject contructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2275) ClassCastException in PDResources

[JIRA]

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

Andreas Lehmkühler commented on PDFBOX-2275:


I'm not happy with the patch as it fixes the symptom only but not the real 
cause.

The problem is, that the situation after parsing and after creating a pdf 
without saving can't be compared. All the information about direct/indirect 
objects, objects numbers etc. is generated when saving the pdf. There are a lot 
of parts in the code expecting all these information, like the one in 
PDResources.
So, the question is, should we somehow improve the creation process to produce 
all needed objects or just patch those parts which are affected because of 
expecting things which aren't there.

> ClassCastException in PDResources
> -
>
> Key: PDFBOX-2275
> URL: https://issues.apache.org/jira/browse/PDFBOX-2275
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
> Attachments: PDResources.diff
>
>
> The code (added in revision 1606860)
> {code}
> COSObject cosObject = (COSObject)dict.getItem(objName);
> {code} in the method getXObjects() in PDResources fails with a 
> ClassCastException:
> bq. org.apache.pdfbox.cos.COSStream cannot be cast to 
> org.apache.pdfbox.cos.COSObject
> The document issuing this exception is created using the following code:
> {code}
> PDDocument doc = new PDDocument();
> PDPage page = new PDPage();
> doc.addPage(page);
> PDImageXObject image = JPEGFactory.createFromStream(doc, imageStream);
> try (PDPageContentStream contentStream = new PDPageContentStream(doc, page, 
> false, false)) {
> contentStream.drawImage(image, 20, 20);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (PDFBOX-2277) Text overlap

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2277:


Comment: was deleted

(was: I can't find where the rendering of field appearances is done in the 
code. My bet is on an ignored clipping path.)

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2277) Text overlap

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2277:


Attachment: PDFBOX-563-acroform.pdf-1.png
PageDrawer.patch

The cause of the bug is an ignored BBox, see attached patch which fixes this 
(with the known clipping side effects at low resolutions that we have observed 
elsewhere).

@John Hewson I can't see how this is related to PDFBOX-2262. You didn't change 
anything in the PageDrawer class.

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2277) Text overlap

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr edited comment on PDFBOX-2277 at 8/20/14 6:41 PM:
--

The cause of the bug is an ignored BBox, see attached patch which fixes this 
(with the known clipping side effects at low resolutions that we have observed 
elsewhere).

[~jahewson] I can't see how this is related to PDFBOX-2262. You didn't change 
anything in the PageDrawer class.


was (Author: tilman):
The cause of the bug is an ignored BBox, see attached patch which fixes this 
(with the known clipping side effects at low resolutions that we have observed 
elsewhere).

@John Hewson I can't see how this is related to PDFBOX-2262. You didn't change 
anything in the PageDrawer class.

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2276) Remove Jempbox subproject

[ASF subversion and git services (JIRA)]

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

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

Commit 1619208 from [~lehmi] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1619208 ]

PDFBOX-2276: removed jempbox from ant build

> Remove Jempbox subproject
> -
>
> Key: PDFBOX-2276
> URL: https://issues.apache.org/jira/browse/PDFBOX-2276
> Project: PDFBox
>  Issue Type: New Feature
>  Components: JempBox
>Affects Versions: 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.0
>
>
> Following up PDFBOX-2107 I'm finally going to remove the Jempbox subproject.
> We discussed that topic several times, IMHO always with the same result: 
> discontinue Jempbox in favor of XMPBox.
> Those users who still prefer Jempbox might use the 1.8.x version, which still 
> should work even in combination with 2.0



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2276) Remove Jempbox subproject

[JIRA]

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

Andreas Lehmkühler commented on PDFBOX-2276:


I've started with removing Jempbox from the ant build

> Remove Jempbox subproject
> -
>
> Key: PDFBOX-2276
> URL: https://issues.apache.org/jira/browse/PDFBOX-2276
> Project: PDFBox
>  Issue Type: New Feature
>  Components: JempBox
>Affects Versions: 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.0
>
>
> Following up PDFBOX-2107 I'm finally going to remove the Jempbox subproject.
> We discussed that topic several times, IMHO always with the same result: 
> discontinue Jempbox in favor of XMPBox.
> Those users who still prefer Jempbox might use the 1.8.x version, which still 
> should work even in combination with 2.0



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2262) Remove usage of AWT fonts

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr edited comment on PDFBOX-2262 at 8/20/14 7:08 PM:
--

PDFBOX-427 - bullets missing
PDFBOX-239 - width ignored
PDFBOX-1770 - "Y" and (C) and ° missing
PDFBOX-2198-014936.pdf - p20 and p44, some glyphs missing, e.g. the "1" on the 
Y axis
PDFBOX-1809, the spaces or the font are too wide, see e.g. "railroad 
commissioner - unexpired Term" which is larger than the column
PDFBOX-191, this did already have problems before (PDFBOX-2220), but now it is 
significantly worse

Exceptions:
PDFBOX-1283.pdf
PDFBOX-1422.pdf
freesanstest.pdf

and two other files



was (Author: tilman):
PDFBOX-427 - bullets missing
PDFBOX-239 - width ignored
PDFBOX-1770 - "Y" and (C) and ° missing
PDFBOX-2198-014936.pdf - p20 and p44, some glyphs missing, e.g. the "1" on the 
Y axis
PDFBOX-1809, the spaces or the font are too wide, see e.g. "railroad 
commissioner - unexpired Term" which is larger than the column

Exceptions:
PDFBOX-1283.pdf
PDFBOX-1422.pdf
freesanstest.pdf

and two other files


> Remove usage of AWT fonts
> -
>
> Key: PDFBOX-2262
> URL: https://issues.apache.org/jira/browse/PDFBOX-2262
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel, Rendering
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
> Attachments: ELVIA-Reiserucktritt-Vollschutz.pdf-1.png, 
> FreeSansTest.pdf, PDFBOX-1094-094730.pdf-1.png, PDFBOX-1770.pdf-1.png, 
> bugzilla886049.pdf, bugzilla886049.pdf-1.png
>
>
> We're still using AWT fonts to render the "standard 14" built-in fonts, which 
> causes rendering problems and encoding issues (see  PDFBOX-2140). We're also 
> using AWT for some fallback fonts.
> Removal of these AWT fonts isn't too difficult, we need to load the fonts 
> using the existing PDFFontManager mechanism which has recently been added. 
> All missing TrueType fonts loaded from disk have been using SystemFontManager 
> for a number of weeks now. 
> We should ship some sensible default fonts with PDFBox, such as the 
> Liberation fonts (see PDFBOX-2169, PDFBOX-2263), in case PDFFontManager can't 
> find anything suitable, rather than falling back to the default TTF font, but 
> by default we'll probe the system for suitable fonts.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2274) Decoding issue in PDImageXObject

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2274:
-

{quote}
Another thing I thought about when looking at the code: Should it be ensured in 
COSStream.setFilters() that unfilteredStream is not null by decoding the stream 
before setting the filter? Otherwise the stream's content is lost and a call of 
getFilteredStream() or getUnfilteredStream() would trigger a 
NullPointerException.
{quote}
Can't tell... you're welcome to provide some new code that fails (but open a 
new issue).

> Decoding issue in PDImageXObject
> 
>
> Key: PDFBOX-2274
> URL: https://issues.apache.org/jira/browse/PDFBOX-2274
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
>
> I'm using JpegFactory to create an PDImageXObject from a content stream. 
> There the constrcutor
> {code}
> PDImageXObject(PDDocument document, InputStream filteredStream, 
> COSBase cosFilter, int width, int height, int bitsPerComponent, 
> PDColorSpace initColorSpace)
> {code}
> is used.
> I've found the following issue:
> The method getUnfilteredStream() of the COSStream in the PDImageXObject 
> returns an input stream containing a RandomAccessFileInputStream with
> {{currentPosition = 50814}} and {{endPosition = 144}} and my following 
> operation fails.
> If the method doDecode() of the COSStream is called before the filter is set 
> in the COSStream the input stream returned by getUnfilteredStream() contains 
> a RandomAccessFileInputStream with {{currentPosition = 0}} and {{endPosition 
> = 50814}} and the result is as expected.
> I've achieved this by adding
> {code}
> getStream().getStream().getDecodeResult();
> {code}
> before
> {code}
> getCOSStream().setItem(COSName.FILTER, cosFilter);
> {code}
> in the PDImageXObject contructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2277) Text overlap

[John Hewson (JIRA)]

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

John Hewson edited comment on PDFBOX-2277 at 8/20/14 7:29 PM:
--

[~tilman] I've made many changes to the PageDrawer in PDFBOX-2262.


was (Author: jahewson):
I've made many changes to the PageDrawer in PDFBOX-2262.

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2277) Text overlap

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2277:
-

I've made many changes to the PageDrawer in PDFBOX-2262.

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2274) Decoding issue in PDImageXObject

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2274:
-

{quote}
getDecodeResult() is called and the stream is decoded then. That's happening 
when getting the XObjects through PDResources. I've not investigated it 
further, but I'm wondering whether it is really necessary to decode the image 
at that point.
{quote}

The stream has to be passed to the super constructor for PDXObject, and it 
needs to be repaired before it is used, which is why it's read at that point. 
Perhaps we could do this lazily by overriding getCOSObject(), getCOSStream(), 
getPDStream() in PDImageXObject().

> Decoding issue in PDImageXObject
> 
>
> Key: PDFBOX-2274
> URL: https://issues.apache.org/jira/browse/PDFBOX-2274
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
>
> I'm using JpegFactory to create an PDImageXObject from a content stream. 
> There the constrcutor
> {code}
> PDImageXObject(PDDocument document, InputStream filteredStream, 
> COSBase cosFilter, int width, int height, int bitsPerComponent, 
> PDColorSpace initColorSpace)
> {code}
> is used.
> I've found the following issue:
> The method getUnfilteredStream() of the COSStream in the PDImageXObject 
> returns an input stream containing a RandomAccessFileInputStream with
> {{currentPosition = 50814}} and {{endPosition = 144}} and my following 
> operation fails.
> If the method doDecode() of the COSStream is called before the filter is set 
> in the COSStream the input stream returned by getUnfilteredStream() contains 
> a RandomAccessFileInputStream with {{currentPosition = 0}} and {{endPosition 
> = 50814}} and the result is as expected.
> I've achieved this by adding
> {code}
> getStream().getStream().getDecodeResult();
> {code}
> before
> {code}
> getCOSStream().setItem(COSName.FILTER, cosFilter);
> {code}
> in the PDImageXObject contructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2277) Text overlap

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr edited comment on PDFBOX-2277 at 8/20/14 7:37 PM:
--

The cause of the bug is an ignored BBox, see attached patch which fixes this 
(with the known clipping side effects at low resolutions that we have observed 
elsewhere).

[~jahewson] I can't see how this is related to PDFBOX-2262. -You didn't change 
anything in the PageDrawer class.-


was (Author: tilman):
The cause of the bug is an ignored BBox, see attached patch which fixes this 
(with the known clipping side effects at low resolutions that we have observed 
elsewhere).

[~jahewson] I can't see how this is related to PDFBOX-2262. You didn't change 
anything in the PageDrawer class.

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2262) Remove usage of AWT fonts

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2262:
-

Thanks for all your testing, I'll take a look at these soon. I'm currently 
knee-deep in multibyte CMaps :(

> Remove usage of AWT fonts
> -
>
> Key: PDFBOX-2262
> URL: https://issues.apache.org/jira/browse/PDFBOX-2262
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel, Rendering
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
> Attachments: ELVIA-Reiserucktritt-Vollschutz.pdf-1.png, 
> FreeSansTest.pdf, PDFBOX-1094-094730.pdf-1.png, PDFBOX-1770.pdf-1.png, 
> bugzilla886049.pdf, bugzilla886049.pdf-1.png
>
>
> We're still using AWT fonts to render the "standard 14" built-in fonts, which 
> causes rendering problems and encoding issues (see  PDFBOX-2140). We're also 
> using AWT for some fallback fonts.
> Removal of these AWT fonts isn't too difficult, we need to load the fonts 
> using the existing PDFFontManager mechanism which has recently been added. 
> All missing TrueType fonts loaded from disk have been using SystemFontManager 
> for a number of weeks now. 
> We should ship some sensible default fonts with PDFBox, such as the 
> Liberation fonts (see PDFBOX-2169, PDFBOX-2263), in case PDFFontManager can't 
> find anything suitable, rather than falling back to the default TTF font, but 
> by default we'll probe the system for suitable fonts.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2275) ClassCastException in PDResources

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2275:
-

That's a very good question Andreas. Because there's only a small minority of 
code which requires such object id information, I think we're better off 
patching the affected parts. Unless there's a clear systematic problem which 
can't be overcome?

> ClassCastException in PDResources
> -
>
> Key: PDFBOX-2275
> URL: https://issues.apache.org/jira/browse/PDFBOX-2275
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
> Attachments: PDResources.diff
>
>
> The code (added in revision 1606860)
> {code}
> COSObject cosObject = (COSObject)dict.getItem(objName);
> {code} in the method getXObjects() in PDResources fails with a 
> ClassCastException:
> bq. org.apache.pdfbox.cos.COSStream cannot be cast to 
> org.apache.pdfbox.cos.COSObject
> The document issuing this exception is created using the following code:
> {code}
> PDDocument doc = new PDDocument();
> PDPage page = new PDPage();
> doc.addPage(page);
> PDImageXObject image = JPEGFactory.createFromStream(doc, imageStream);
> try (PDPageContentStream contentStream = new PDPageContentStream(doc, page, 
> false, false)) {
> contentStream.drawImage(image, 20, 20);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2280) Text not italic

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2280:
-

Yep, I have a todo comment regarding "smart fallback" in ExternalFonts.java in 
my no-awt branch.

> Text not italic
> ---
>
> Key: PDFBOX-2280
> URL: https://issues.apache.org/jira/browse/PDFBOX-2280
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> PDF from PDFBOX-448
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> WBPaper3120.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2279) Text with gradient not shown

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2279:
-

"Add text to path for clipping" should of course be invisible, but "Fill text 
and add to path for clipping" should be visible.

> Text with gradient not shown
> 
>
> Key: PDFBOX-2279
> URL: https://issues.apache.org/jira/browse/PDFBOX-2279
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>
> From pdf from PDFBOX-678
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> example_026.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (PDFBOX-2279) Text with gradient not shown

[John Hewson (JIRA)]

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

John Hewson reassigned PDFBOX-2279:
---

Assignee: John Hewson

> Text with gradient not shown
> 
>
> Key: PDFBOX-2279
> URL: https://issues.apache.org/jira/browse/PDFBOX-2279
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> From pdf from PDFBOX-678
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> example_026.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2273) Make PDInlineImage non-final

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2273:
-

[~tilman], because it wouldn't be meaningful to override any of its public 
methods, as far as I can tell. [~dnt], what was your use case for subclassing 
it?

> Make PDInlineImage non-final
> 
>
> Key: PDFBOX-2273
> URL: https://issues.apache.org/jira/browse/PDFBOX-2273
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Dominic Tubach
>
> PDInlineImage is final in the current trunk. This prevents from extending the 
> class as it was possible in 1.8.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (PDFBOX-2272) Can't extract text in 90ms-RKSJ-V

[John Hewson (JIRA)]

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

John Hewson reassigned PDFBOX-2272:
---

Assignee: John Hewson

> Can't extract text in 90ms-RKSJ-V
> -
>
> Key: PDFBOX-2272
> URL: https://issues.apache.org/jira/browse/PDFBOX-2272
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.6
>Reporter: Biligsaikhan Batjargal
>Assignee: John Hewson
> Attachments: test.pdf, test.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2262) Remove usage of AWT fonts

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr edited comment on PDFBOX-2262 at 8/20/14 8:17 PM:
--

PDFBOX-427 - bullets missing
PDFBOX-239 - width ignored
PDFBOX-1770 - "Y" and (C) and ° missing
PDFBOX-2198-014936.pdf - p20 and p44, some glyphs missing, e.g. the "1" on the 
Y axis
PDFBOX-1809, the spaces or the font are too wide, see e.g. "railroad 
commissioner - unexpired Term" which is larger than the column
PDFBOX-191, this did already have problems before (PDFBOX-2220), but now it is 
significantly worse

Exceptions:
PDFBOX-1283.pdf
PDFBOX-1422.pdf
freesanstest.pdf
FOP-2252.pdf

and two other files



was (Author: tilman):
PDFBOX-427 - bullets missing
PDFBOX-239 - width ignored
PDFBOX-1770 - "Y" and (C) and ° missing
PDFBOX-2198-014936.pdf - p20 and p44, some glyphs missing, e.g. the "1" on the 
Y axis
PDFBOX-1809, the spaces or the font are too wide, see e.g. "railroad 
commissioner - unexpired Term" which is larger than the column
PDFBOX-191, this did already have problems before (PDFBOX-2220), but now it is 
significantly worse

Exceptions:
PDFBOX-1283.pdf
PDFBOX-1422.pdf
freesanstest.pdf

and two other files


> Remove usage of AWT fonts
> -
>
> Key: PDFBOX-2262
> URL: https://issues.apache.org/jira/browse/PDFBOX-2262
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel, Rendering
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
> Attachments: ELVIA-Reiserucktritt-Vollschutz.pdf-1.png, 
> FreeSansTest.pdf, PDFBOX-1094-094730.pdf-1.png, PDFBOX-1770.pdf-1.png, 
> bugzilla886049.pdf, bugzilla886049.pdf-1.png
>
>
> We're still using AWT fonts to render the "standard 14" built-in fonts, which 
> causes rendering problems and encoding issues (see  PDFBOX-2140). We're also 
> using AWT for some fallback fonts.
> Removal of these AWT fonts isn't too difficult, we need to load the fonts 
> using the existing PDFFontManager mechanism which has recently been added. 
> All missing TrueType fonts loaded from disk have been using SystemFontManager 
> for a number of weeks now. 
> We should ship some sensible default fonts with PDFBox, such as the 
> Liberation fonts (see PDFBOX-2169, PDFBOX-2263), in case PDFFontManager can't 
> find anything suitable, rather than falling back to the default TTF font, but 
> by default we'll probe the system for suitable fonts.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2272) Can't extract text in 90ms-RKSJ-V

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2272:
-

[~lehmi], I can extract the text using Acrobat XI Pro. You might need the 
Japanese font pack installed?  90ms-RKSJ-V should map to Adobe-Japan1 for 
Unicode text extraction - I might have a fix for this in my working copy as 
part of PDFBOX-2262 as I'm having to do some CMap refactoring.

> Can't extract text in 90ms-RKSJ-V
> -
>
> Key: PDFBOX-2272
> URL: https://issues.apache.org/jira/browse/PDFBOX-2272
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.6
>Reporter: Biligsaikhan Batjargal
> Attachments: test.pdf, test.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1094) Pattern colorspace support

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-1094:
-

{quote}
A possible reason for the "blocky" patterns is that the size of the 
BufferedImage in which the pattern is drawn is calculated without taking the 
graphics transform into account. The solution that existed in February did use 
the graphics transform. The solution for the transparency groups also writes in 
a BufferedImage and does use the graphics transform.
{quote}

Do you mean the graphics transform from Graphics2D#getTransform()? That 
transform represents the CTM, however patterns are not drawn using the CTM they 
are drawn using the parent stream's initial matrix, see my comment from March:

{quote}
Conceptually, the pattern is drawn over the entire page at the very beginning 
and when we fill a shape with a pattern we are filling it with a "window" 
through to the pattern which covers the page (that's not actually what happens 
but it helps to think that way to understand).
{quote}

> Pattern colorspace support
> --
>
> Key: PDFBOX-1094
> URL: https://issues.apache.org/jira/browse/PDFBOX-1094
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 1.6.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>Priority: Minor
> Attachments: ColoredTilingPaint.patch, PATTYP1.pdf, PATTYP2.pdf, 
> PDF32000_2008_pg737.pdf, PDFBOX-1094-065514-XStep32767.pdf, 
> PDFBOX-1094-094730.pdf, PDFBOX-1094-096213-p18.pdf, PDFStreamEngine.patch, 
> PageDrawer.patch, _pdfbox-1094-tiling_pattern.pdf-1-blurry.png, 
> jagpdf_doc_patterns.pdf, jagpdf_doc_patterns.pdf-1.png, 
> pdfbox-1094-pdf32000_2008_pg737.pdf-1.png, 
> pdfbox-1094-pdf32000_2008_pg737.pdf-1.png, 
> pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1094-tiling_pattern.pdf-1.png, 
> pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1861-tracemonkey.pdf-13.png, 
> pdfbox-1861-tracemonkey.pdf-13.png, tiling_pattern.pdf
>
>
> PDFBox doesn't support PDPattern colorspaces



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1915) Implement shading with Coons and tensor-product patch meshes

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-1915:
-

Does this mean we can now follow up on PDFBOX-1991?

> Implement shading with Coons and tensor-product patch meshes
> 
>
> Key: PDFBOX-1915
> URL: https://issues.apache.org/jira/browse/PDFBOX-1915
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Shaola Ren
>  Labels: graphical, gsoc2014, java, math, shading
> Fix For: 1.8.7, 2.0.0
>
> Attachments: CIB-coons-vs-tensormesh.pdf, CIB-coonsmesh.pdf, 
> CONICAL.pdf, DECAHED.pdf, GWG060_Shading_x1a.pdf, GWG060_Shading_x1a_1.png, 
> HSBWHEEL.pdf, Kommunikationsbedingungen-Einlagen_FIDOR-Bank.pdf, 
> LATTICE1.pdf, LATTICE2.pdf, McAfee-ShadingType7.pdf, 
> Shading2Function2LargeDomain.pdf, Shading2Function2LargeDomain.pdf-1-bad.png, 
> Shading2Function2LargeDomain.pdf-1-good.png, Shading2Function2LargeDomain.ps, 
> Shadingtype6week1.pdf, TENSOR.pdf, TRITYP4.pdf, XYZsweep.pdf, 
> _gwg060_shading_x1a.pdf-1.png, _mcafee-shadingtype7.pdf-1.png, 
> asy-coons-but-really-tensor.pdf, asy-tensor-rainbow.pdf, asy-tensor.pdf, 
> axsh02.pdf, axsh02_1_withBBox.png, axsh02_1_withoutBBox.png, ch14.pdf, 
> coons-function.pdf, coons-function.ps, coons-nofunction-CMYK.pdf, 
> coons-nofunction-CMYK.ps, coons-nofunction-Duotone.pdf, 
> coons-nofunction-Duotone.ps, coons-nofunction-Gray.pdf, 
> coons-nofunction-Gray.ps, coons-nofunction-RGB.pdf, coons-nofunction-RGB.ps, 
> coons2-function.pdf, coons2-function.ps, coons4-function.ps, crestron-p9.pdf, 
> eci_1-old.png, eci_1.png, eci_altona-test-suite-v2_technical_H.pdf, 
> example_030.pdf, failedTest.rar, lamp_cairo.pdf, lamp_cairo7_0.png, 
> lamp_cairo7_1.png, lamp_cairo7_1.png, lineRasterization.jpg, mcafeeU5.pdf, 
> mcafeeU5_1.png, mcafeeu5.pdf-1.png, pass4FlagTest.rar, patchCases.jpg, 
> patchMap.jpg, pattern-shading-2-4-idMatrix.pdf, shading6ContourTest.rar, 
> shading6Done.rar, shading7.rar, tensor-nofunction-RGB.pdf, 
> tensor-nofunction-RGB.ps, tensor-nofunction-RGB_1.png, 
> tensor4-nofunction.pdf, tensor4-nofunction.ps, tensor4-nofunction_1.png, 
> type45.pdf, updateshading6ContourTest.rar
>
>
> Of the seven shading methods described in the PDF specification, type 6 
> (Coons patch meshes) and type 7 (Tensor-product patch meshes) haven't been 
> implemented. I have done type 1, 4 and 5, but I don't know the math for type 
> 6 and 7. My math days are decades away.
> Knowledge prerequisites: 
> - java, although you don't have to be a java ace, just feel confortable
> - math: you should know what "cubic Bézier curves", "Degenerate Bézier 
> curves", "bilinear interpolation", "tensor-product", "affine transform 
> matrix" and "Bernstein polynomials" are, or be able to learn it
> - maven (basic)
> - svn (basic)
> - an IDE like Netbeans or Eclipse or IntelliJ (basic)
> - ideally, you are either a math student who likes to program, or a computer 
> science student who is specializing in graphics.
> A first look at PDFBOX: try the command utility here:
> https://pdfbox.apache.org/commandline/#pdfToImage
> and use your favorite PDF, or the PDFs mentioned in PDFBOX-615, these have 
> the shading types that are already implemented.
> Some simple source code to convert to images:
> String filename = "blah.pdf";
> PDDocument document = PDDocument.loadNonSeq(new File(filename), null);
> List pdPages = document.getDocumentCatalog().getAllPages();
> int page = 0;
> for (PDPage pdPage : pdPages)
> {
> ++page;
> BufferedImage bim = RenderUtil.convertToImage(pdPage, 
> BufferedImage.TYPE_BYTE_BINARY, 300);
> ImageIO.write(bim, "png", new File(filename+page+".png"));
> }
> document.close();
> You are not starting from scratch. The implementation of type 4 and 5 shows 
> you how to read parameters from the PDF and set the graphics. You don't have 
> to learn the complete PDF spec, only 15 pages related to the two shading 
> types, and 6 pages about shading in general. The PDF specification is here:
> http://www.adobe.com/devnet/pdf/pdf_reference.html
> The tricky parts are:
> - decide whether a point(x,y) is inside or outside a patch
> - decide the color of a point within the patch
> To get an idea about the code, look at the classes GouraudTriangle, 
> GouraudShadingContext, Type4ShadingContext and Vertex here
> https://svn.apache.org/viewvc/pdfbox/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/shading/
> or download the whole project from the repository.
> https://pdfbox.apache.org/downloads.html#scm
> If you want to see the existing code in the debugger with a Gouraud shading, 
> try this file:
> http:/

[jira] [Commented] (PDFBOX-1915) Implement shading with Coons and tensor-product patch meshes

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-1915:
-

Yes

> Implement shading with Coons and tensor-product patch meshes
> 
>
> Key: PDFBOX-1915
> URL: https://issues.apache.org/jira/browse/PDFBOX-1915
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Shaola Ren
>  Labels: graphical, gsoc2014, java, math, shading
> Fix For: 1.8.7, 2.0.0
>
> Attachments: CIB-coons-vs-tensormesh.pdf, CIB-coonsmesh.pdf, 
> CONICAL.pdf, DECAHED.pdf, GWG060_Shading_x1a.pdf, GWG060_Shading_x1a_1.png, 
> HSBWHEEL.pdf, Kommunikationsbedingungen-Einlagen_FIDOR-Bank.pdf, 
> LATTICE1.pdf, LATTICE2.pdf, McAfee-ShadingType7.pdf, 
> Shading2Function2LargeDomain.pdf, Shading2Function2LargeDomain.pdf-1-bad.png, 
> Shading2Function2LargeDomain.pdf-1-good.png, Shading2Function2LargeDomain.ps, 
> Shadingtype6week1.pdf, TENSOR.pdf, TRITYP4.pdf, XYZsweep.pdf, 
> _gwg060_shading_x1a.pdf-1.png, _mcafee-shadingtype7.pdf-1.png, 
> asy-coons-but-really-tensor.pdf, asy-tensor-rainbow.pdf, asy-tensor.pdf, 
> axsh02.pdf, axsh02_1_withBBox.png, axsh02_1_withoutBBox.png, ch14.pdf, 
> coons-function.pdf, coons-function.ps, coons-nofunction-CMYK.pdf, 
> coons-nofunction-CMYK.ps, coons-nofunction-Duotone.pdf, 
> coons-nofunction-Duotone.ps, coons-nofunction-Gray.pdf, 
> coons-nofunction-Gray.ps, coons-nofunction-RGB.pdf, coons-nofunction-RGB.ps, 
> coons2-function.pdf, coons2-function.ps, coons4-function.ps, crestron-p9.pdf, 
> eci_1-old.png, eci_1.png, eci_altona-test-suite-v2_technical_H.pdf, 
> example_030.pdf, failedTest.rar, lamp_cairo.pdf, lamp_cairo7_0.png, 
> lamp_cairo7_1.png, lamp_cairo7_1.png, lineRasterization.jpg, mcafeeU5.pdf, 
> mcafeeU5_1.png, mcafeeu5.pdf-1.png, pass4FlagTest.rar, patchCases.jpg, 
> patchMap.jpg, pattern-shading-2-4-idMatrix.pdf, shading6ContourTest.rar, 
> shading6Done.rar, shading7.rar, tensor-nofunction-RGB.pdf, 
> tensor-nofunction-RGB.ps, tensor-nofunction-RGB_1.png, 
> tensor4-nofunction.pdf, tensor4-nofunction.ps, tensor4-nofunction_1.png, 
> type45.pdf, updateshading6ContourTest.rar
>
>
> Of the seven shading methods described in the PDF specification, type 6 
> (Coons patch meshes) and type 7 (Tensor-product patch meshes) haven't been 
> implemented. I have done type 1, 4 and 5, but I don't know the math for type 
> 6 and 7. My math days are decades away.
> Knowledge prerequisites: 
> - java, although you don't have to be a java ace, just feel confortable
> - math: you should know what "cubic Bézier curves", "Degenerate Bézier 
> curves", "bilinear interpolation", "tensor-product", "affine transform 
> matrix" and "Bernstein polynomials" are, or be able to learn it
> - maven (basic)
> - svn (basic)
> - an IDE like Netbeans or Eclipse or IntelliJ (basic)
> - ideally, you are either a math student who likes to program, or a computer 
> science student who is specializing in graphics.
> A first look at PDFBOX: try the command utility here:
> https://pdfbox.apache.org/commandline/#pdfToImage
> and use your favorite PDF, or the PDFs mentioned in PDFBOX-615, these have 
> the shading types that are already implemented.
> Some simple source code to convert to images:
> String filename = "blah.pdf";
> PDDocument document = PDDocument.loadNonSeq(new File(filename), null);
> List pdPages = document.getDocumentCatalog().getAllPages();
> int page = 0;
> for (PDPage pdPage : pdPages)
> {
> ++page;
> BufferedImage bim = RenderUtil.convertToImage(pdPage, 
> BufferedImage.TYPE_BYTE_BINARY, 300);
> ImageIO.write(bim, "png", new File(filename+page+".png"));
> }
> document.close();
> You are not starting from scratch. The implementation of type 4 and 5 shows 
> you how to read parameters from the PDF and set the graphics. You don't have 
> to learn the complete PDF spec, only 15 pages related to the two shading 
> types, and 6 pages about shading in general. The PDF specification is here:
> http://www.adobe.com/devnet/pdf/pdf_reference.html
> The tricky parts are:
> - decide whether a point(x,y) is inside or outside a patch
> - decide the color of a point within the patch
> To get an idea about the code, look at the classes GouraudTriangle, 
> GouraudShadingContext, Type4ShadingContext and Vertex here
> https://svn.apache.org/viewvc/pdfbox/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/shading/
> or download the whole project from the repository.
> https://pdfbox.apache.org/downloads.html#scm
> If you want to see the existing code in the debugger with a Gouraud shading, 
> try this file:
> http://asymptote.sourceforge.net/gallery/Goura

[jira] [Commented] (PDFBOX-2277) Text overlap

[ASF subversion and git services (JIRA)]

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

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

Commit 1619223 from [~tilman] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1619223 ]

PDFBOX-2277: apply BBox clipping to appearance stream

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2277) Text overlap

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2277:
-

Ok, I'll wait and apply to 1.8 only for now.

> Text overlap
> 
>
> Key: PDFBOX-2277
> URL: https://issues.apache.org/jira/browse/PDFBOX-2277
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>  Labels: acroform
> Attachments: PDFBOX-563-acroform.pdf-1.png, PageDrawer.patch
>
>
> In pdf from PDFBOX-563
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> PDFBOX563-TestFax_merged.pdf



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[ASF subversion and git services (JIRA)]

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

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

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

PDFBOX-2250: skip empty xref table followed by trailer

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2250) Improve XRef self healing mechanism

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2250:


Attachment: PDFBOX-2250-107425-empty-xref.pdf

The attached file PDFBOX-2250-107425-empty-xref.pdf has
{code}
xref
trailer
{code}
The commit I just made fixes this.

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
> Attachments: PDFBOX-2250-107425-empty-xref.pdf
>
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is back to normal : PDFBox-ant #1502

[Apache Jenkins Server]

See 

Jenkins build is back to normal : PDFBox 1.8.x (JDK7) #62

[Apache Jenkins Server]

See 

[jira] [Commented] (PDFBOX-2262) Remove usage of AWT fonts

[ASF subversion and git services (JIRA)]

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

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

Commit 1619277 from [~jahewson] in branch 'pdfbox/branches/no-awt'
[ https://svn.apache.org/r1619277 ]

PDFBOX-2262: Fix error in div calculation

> Remove usage of AWT fonts
> -
>
> Key: PDFBOX-2262
> URL: https://issues.apache.org/jira/browse/PDFBOX-2262
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel, Rendering
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
> Attachments: ELVIA-Reiserucktritt-Vollschutz.pdf-1.png, 
> FreeSansTest.pdf, PDFBOX-1094-094730.pdf-1.png, PDFBOX-1770.pdf-1.png, 
> bugzilla886049.pdf, bugzilla886049.pdf-1.png
>
>
> We're still using AWT fonts to render the "standard 14" built-in fonts, which 
> causes rendering problems and encoding issues (see  PDFBOX-2140). We're also 
> using AWT for some fallback fonts.
> Removal of these AWT fonts isn't too difficult, we need to load the fonts 
> using the existing PDFFontManager mechanism which has recently been added. 
> All missing TrueType fonts loaded from disk have been using SystemFontManager 
> for a number of weeks now. 
> We should ship some sensible default fonts with PDFBox, such as the 
> Liberation fonts (see PDFBOX-2169, PDFBOX-2263), in case PDFFontManager can't 
> find anything suitable, rather than falling back to the default TTF font, but 
> by default we'll probe the system for suitable fonts.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is back to normal : PDFBox-trunk #1209

[Apache Jenkins Server]

See 

Jenkins build is back to normal : PDFBox 1.8.x #245

[Apache Jenkins Server]

See 

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[ASF subversion and git services (JIRA)]

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

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

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

PDFBOX-2250: include key for "Invalid object stream xref object reference" 
IOException

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
> Attachments: PDFBOX-2250-107425-empty-xref.pdf
>
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)