[jira] [Created] (PDFBOX-2373) Rendering at 72 dpi crashes java
Tilman Hausherr created PDFBOX-2373: --- Summary: Rendering at 72 dpi crashes java Key: PDFBOX-2373 URL: https://issues.apache.org/jira/browse/PDFBOX-2373 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 1.8.7, 1.8.8, 2.0.0 Environment: W7 64bit 1.7.0_65 Reporter: Tilman Hausherr Rendering the attached file crashes java. It happens only at 72 dpi. It can be reproduced with the PDFToImage cmd app. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PDFBOX-2373) Rendering at 72 dpi crashes java
[ https://issues.apache.org/jira/browse/PDFBOX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-2373: Attachment: 228-228597-p19-crash.pdf > Rendering at 72 dpi crashes java > > > Key: PDFBOX-2373 > URL: https://issues.apache.org/jira/browse/PDFBOX-2373 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 1.8.7, 1.8.8, 2.0.0 > Environment: W7 64bit 1.7.0_65 >Reporter: Tilman Hausherr > Labels: crash > Attachments: 228-228597-p19-crash.pdf > > > Rendering the attached file crashes java. It happens only at 72 dpi. It can > be reproduced with the PDFToImage cmd app. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2360) PDFont had methods removed
[
https://issues.apache.org/jira/browse/PDFBOX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142410#comment-14142410
]
Maruan Sahyoun commented on PDFBOX-2360:
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good. The information returned is also available
within the spec but is part of the different font definitions. So what about
something like PDFontCommonProperties.
> PDFont had methods removed
> --
>
> Key: PDFBOX-2360
> URL: https://issues.apache.org/jira/browse/PDFBOX-2360
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> Add back methods or provide a equivalent to pdfbox so it easier to upgrade to
> PDFBox 2
> PDFont
> public int getFirstChar()
> public int getLastChar()
> public Encoding getFontEncoding()
> public CMap getToUnicodeCMap()
> public String encode(byte[] c, int offset, int length) throws IOException
> PDCIDFont
> public long getDefaultWidth()
> Encoding
> public String getCharacter(int code) throws IOException
> CFFFont
> public Object getProperty(String name)
> public Map getCharStringsDict()
> public CFFEncoding getEncoding()
> CFFCharset
> public List getEntries()
> CFFEncoding
> public List getEntries()
> Cmap
> public String lookup( int code, int length )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
Maruan Sahyoun created PDFBOX-2374: -- Summary: Make JavaDocs for trunk builds available via our website Key: PDFBOX-2374 URL: https://issues.apache.org/jira/browse/PDFBOX-2374 Project: PDFBox Issue Type: Improvement Components: Documentation Affects Versions: 2.0.0 Reporter: Maruan Sahyoun Fix For: 2.0.0 In order to help people using the latest trunk versions of PDFBox the JavaDocs for the main project and the sub projects shall be made available on our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2373) Rendering at 72 dpi crashes java
[
https://issues.apache.org/jira/browse/PDFBOX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142416#comment-14142416
]
Tilman Hausherr commented on PDFBOX-2373:
-
last thing before crash was a StrokePath() operation:
{code}
Op SCN: [COSInt{0}, COSFloat{0.667}, COSFloat{0.31}]
Op m: [COSFloat{135.35}, COSFloat{462.191}]
Op c: [COSFloat{135.37}, COSFloat{462.214}, COSFloat{135.381},
COSFloat{462.242}, COSFloat{135.381}, COSFloat{462.272}]
Op c: [COSFloat{135.381}, COSFloat{462.306}, COSFloat{135.366},
COSFloat{462.339}, COSFloat{135.34}, COSFloat{462.362}]
Op m: [COSFloat{135.52}, COSFloat{462.2}]
Op c: [COSFloat{135.499}, COSFloat{462.22}, COSFloat{135.47},
COSFloat{462.231}, COSFloat{135.44}, COSFloat{462.231}]
Op c: [COSFloat{135.406}, COSFloat{462.231}, COSFloat{135.373},
COSFloat{462.216}, COSFloat{135.35}, COSFloat{462.191}]
Op m: [COSFloat{135.462}, COSFloat{462.09}]
Op c: [COSFloat{135.457}, COSFloat{462.095}, COSFloat{135.449},
COSFloat{462.098}, COSFloat{135.442}, COSFloat{462.098}]
Op c: [COSFloat{135.434}, COSFloat{462.098}, COSFloat{135.425},
COSFloat{462.094}, COSFloat{135.42}, COSFloat{462.087}]
Op m: [COSFloat{135.239}, COSFloat{462.249}]
Op c: [COSFloat{135.244}, COSFloat{462.255}, COSFloat{135.247},
COSFloat{462.262}, COSFloat{135.247}, COSFloat{462.269}]
Op c: [COSFloat{135.247}, COSFloat{462.279}, COSFloat{135.244},
COSFloat{462.286}, COSFloat{135.237}, COSFloat{462.292}]
Op S: -
{code}
> Rendering at 72 dpi crashes java
>
>
> Key: PDFBOX-2373
> URL: https://issues.apache.org/jira/browse/PDFBOX-2373
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 1.8.7, 1.8.8, 2.0.0
> Environment: W7 64bit 1.7.0_65
>Reporter: Tilman Hausherr
> Labels: crash
> Attachments: 228-228597-p19-crash.pdf
>
>
> Rendering the attached file crashes java. It happens only at 72 dpi. It can
> be reproduced with the PDFToImage cmd app.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PDFBOX-2350) Type1 Parser hangs indefinitely
[
https://issues.apache.org/jira/browse/PDFBOX-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-2350:
Attachment: PDFBOX-2350-289451-endless.pdf
The attached file PDFBOX-2350-289451-endless.pdf of the digitalcorpora site has
the same problem.
> Type1 Parser hangs indefinitely
> ---
>
> Key: PDFBOX-2350
> URL: https://issues.apache.org/jira/browse/PDFBOX-2350
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 2.0.0
> Environment: Windows 7, JDK 1.7.0_51-b13
>Reporter: Daniel Scheibe
> Attachments: PDFBOX-2350-289451-endless.pdf
>
>
> When rendering the first page of my pdf document the Type1Parser
> (org.apache.fontbox.type1.Type1Parser) hangs in a loop in
> {{parseBinary(byte[] bytes) throws IOException}}
> and "kills" our rendering pipeline. Please find the loop that hangs below:
> // find /Private dict
> while (!lexer.peekToken().getText().equals("Private"))
> {
> lexer.nextToken();
> }
> There is no token named "Private" ever in the list of returned tokens
> (they're empty all the time).
> Furthermore going deeper into the source code it seems the class reading the
> tokens (Type1Lexer) does never finally advance the buffer position and always
> returns an empty name token in the readToken(Token prevToken) method.
> Looking at the decrypted buffer i cannot get something useful out of it based
> on my current understanding.
> Unfortunately i cannot provide the pdf in question as it contains confidental
> data.
> Acrobat Reader XI Version 11.0.08 renders the document just fine.
> In addition it seems the pdf was encrypted (40-Bit RC4) with an empty
> password and says it's pdf version 1.5.
> Does this provide enough information or can i do anything else to help
> nailing this one down?
> I guess this might be a pdf document structure/feature that is not yet
> supported completely but at least pdfbox should throw an exception instead of
> failing "silently"...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2350) Type1 Parser hangs indefinitely
[
https://issues.apache.org/jira/browse/PDFBOX-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142461#comment-14142461
]
Tilman Hausherr commented on PDFBOX-2350:
-
{quote}Looking at the decrypted buffer i cannot get something useful out of it
based on my current understanding.{quote}
Same here. The contents before and after Type 1 "Decryption" are just binary
stuff.
> Type1 Parser hangs indefinitely
> ---
>
> Key: PDFBOX-2350
> URL: https://issues.apache.org/jira/browse/PDFBOX-2350
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 2.0.0
> Environment: Windows 7, JDK 1.7.0_51-b13
>Reporter: Daniel Scheibe
> Attachments: PDFBOX-2350-289451-endless.pdf
>
>
> When rendering the first page of my pdf document the Type1Parser
> (org.apache.fontbox.type1.Type1Parser) hangs in a loop in
> {{parseBinary(byte[] bytes) throws IOException}}
> and "kills" our rendering pipeline. Please find the loop that hangs below:
> // find /Private dict
> while (!lexer.peekToken().getText().equals("Private"))
> {
> lexer.nextToken();
> }
> There is no token named "Private" ever in the list of returned tokens
> (they're empty all the time).
> Furthermore going deeper into the source code it seems the class reading the
> tokens (Type1Lexer) does never finally advance the buffer position and always
> returns an empty name token in the readToken(Token prevToken) method.
> Looking at the decrypted buffer i cannot get something useful out of it based
> on my current understanding.
> Unfortunately i cannot provide the pdf in question as it contains confidental
> data.
> Acrobat Reader XI Version 11.0.08 renders the document just fine.
> In addition it seems the pdf was encrypted (40-Bit RC4) with an empty
> password and says it's pdf version 1.5.
> Does this provide enough information or can i do anything else to help
> nailing this one down?
> I guess this might be a pdf document structure/feature that is not yet
> supported completely but at least pdfbox should throw an exception instead of
> failing "silently"...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2359) Lines show on top of image
[
https://issues.apache.org/jira/browse/PDFBOX-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142485#comment-14142485
]
Tilman Hausherr commented on PDFBOX-2359:
-
I did some more tests to find out the next time the line appears, if the BBox
handling is ignored. It is rev 1621640, the first time the rendering hints
handling was changed. The removal of this line in PageDrawer.shadingFill()
{code}
graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_OFF);
{code}
is the cause.
> Lines show on top of image
> --
>
> Key: PDFBOX-2359
> URL: https://issues.apache.org/jira/browse/PDFBOX-2359
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Priority: Minor
> Attachments: 3.pdf
>
>
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage
> 3.pdf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler updated PDFBOX-2298: --- Description: The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. It worked well before merging the no-awt branch into the trunk was: The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. It worked well before the before merging the no-awt branch into the trunk > Wrong scaling of embedded type 1 font > - > > Key: PDFBOX-2298 > URL: https://issues.apache.org/jira/browse/PDFBOX-2298 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler > Attachments: PDFBOX935-data_not_extracted_1.png > > > The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded > type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. > It worked well before merging the no-awt branch into the trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142493#comment-14142493 ] Andreas Lehmkühler commented on PDFBOX-2298: It looks like the glyphs of the embedded fonts are bigger than expected. If I activate the automatic scretching in drawGlyph2D (by commenting the if clause for not embedded fonts) everything works fine. But we have to do the streching for both directions (horizontal and vertical). So, it would be easy to disable the uf clause, but what about the scaling itself. For PDFBOX-870 the horizontal scaling is needed only, but for this one both are required. How can we determine which is needed or not? Any Ideas? > Wrong scaling of embedded type 1 font > - > > Key: PDFBOX-2298 > URL: https://issues.apache.org/jira/browse/PDFBOX-2298 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler > Attachments: PDFBOX935-data_not_extracted_1.png > > > The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded > type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. > It worked well before merging the no-awt branch into the trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142493#comment-14142493 ] Andreas Lehmkühler edited comment on PDFBOX-2298 at 9/21/14 4:58 PM: - It looks like the glyphs of the embedded fonts are bigger than expected. If I activate the automatic scretching in drawGlyph2D (by commenting the if clause for not embedded fonts) everything works fine. But we have to do the streching for both directions (horizontal and vertical). So, it would be easy to disable the if clause, but what about the scaling itself. For PDFBOX-870 the horizontal scaling is needed only, but for this one both are required. How can we determine which is needed or not? Any Ideas? was (Author: lehmi): It looks like the glyphs of the embedded fonts are bigger than expected. If I activate the automatic scretching in drawGlyph2D (by commenting the if clause for not embedded fonts) everything works fine. But we have to do the streching for both directions (horizontal and vertical). So, it would be easy to disable the uf clause, but what about the scaling itself. For PDFBOX-870 the horizontal scaling is needed only, but for this one both are required. How can we determine which is needed or not? Any Ideas? > Wrong scaling of embedded type 1 font > - > > Key: PDFBOX-2298 > URL: https://issues.apache.org/jira/browse/PDFBOX-2298 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler > Attachments: PDFBOX935-data_not_extracted_1.png > > > The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded > type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. > It worked well before merging the no-awt branch into the trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PDFBOX-1094) Pattern colorspace support
[ https://issues.apache.org/jira/browse/PDFBOX-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hewson updated PDFBOX-1094: Attachment: (was: v2_tiling_patterns.patch) > 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 >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, > PDFBOX-1094-118358-Step-32767.pdf, PDFBOX-1094-PDFBOX-269.pdf, > PDFBOX-1094-tiling_pattern.pdf-1-broken-tiles-with-ceil.png, > PDFBOX-1861-tracemonkey13.png, PDFStreamEngine.patch, PageDrawer.patch, > _pdfbox-1094-tiling_pattern.pdf-1-blurry.png, bugzilla8677511.jpg, > gs-bugzilla693653.pdf, 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-pdfbox-269.pdf-2.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.3.4#6332)
[jira] [Updated] (PDFBOX-1094) Pattern colorspace support
[ https://issues.apache.org/jira/browse/PDFBOX-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hewson updated PDFBOX-1094: Attachment: v2_tiling_patterns_v2.patch I've updated the patch, hopefully it works for you now. > 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 >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, > PDFBOX-1094-118358-Step-32767.pdf, PDFBOX-1094-PDFBOX-269.pdf, > PDFBOX-1094-tiling_pattern.pdf-1-broken-tiles-with-ceil.png, > PDFBOX-1861-tracemonkey13.png, PDFStreamEngine.patch, PageDrawer.patch, > _pdfbox-1094-tiling_pattern.pdf-1-blurry.png, bugzilla8677511.jpg, > gs-bugzilla693653.pdf, 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-pdfbox-269.pdf-2.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, > v2_tiling_patterns_v2.patch > > > PDFBox doesn't support PDPattern colorspaces -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
[ https://issues.apache.org/jira/browse/PDFBOX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142581#comment-14142581 ] John Hewson commented on PDFBOX-2374: - Could we have an entire "2.0" section (or branch?) of our website? So that we can start developing guides/tutorials for 2.0. Probably with a giant red banner at the top which says "This is pre-release documentation for version 2.0 of PDFBox, which is still in development". > Make JavaDocs for trunk builds available via our website > > > Key: PDFBOX-2374 > URL: https://issues.apache.org/jira/browse/PDFBOX-2374 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 >Reporter: Maruan Sahyoun > Fix For: 2.0.0 > > > In order to help people using the latest trunk versions of PDFBox the > JavaDocs for the main project and the sub projects shall be made available on > our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2373) Rendering at 72 dpi crashes java
[ https://issues.apache.org/jira/browse/PDFBOX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142586#comment-14142586 ] John Hewson commented on PDFBOX-2373: - I get a crash on JDK 1.7 but not 1.6, the crash report on OS X looks like a stack overflow due to recursive calls to "processCubic" in "libdcpr.dylib", which would appear to be this JVM bug: https://bugs.openjdk.java.net/browse/JDK-6996336 > Rendering at 72 dpi crashes java > > > Key: PDFBOX-2373 > URL: https://issues.apache.org/jira/browse/PDFBOX-2373 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 1.8.7, 1.8.8, 2.0.0 > Environment: W7 64bit 1.7.0_65 >Reporter: Tilman Hausherr > Labels: crash > Attachments: 228-228597-p19-crash.pdf > > > Rendering the attached file crashes java. It happens only at 72 dpi. It can > be reproduced with the PDFToImage cmd app. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2373) Rendering at 72 dpi crashes java
[ https://issues.apache.org/jira/browse/PDFBOX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142586#comment-14142586 ] John Hewson edited comment on PDFBOX-2373 at 9/21/14 7:28 PM: -- I get a crash on JDK 1.7 but not 1.6, the crash report on OS X looks like a stack overflow due to recursive calls to "processCubic" in "libdcpr.dylib", which would appear to be this JVM bug: https://bugs.openjdk.java.net/browse/JDK-6996336 Problem seems to be due to dashed lines? was (Author: jahewson): I get a crash on JDK 1.7 but not 1.6, the crash report on OS X looks like a stack overflow due to recursive calls to "processCubic" in "libdcpr.dylib", which would appear to be this JVM bug: https://bugs.openjdk.java.net/browse/JDK-6996336 > Rendering at 72 dpi crashes java > > > Key: PDFBOX-2373 > URL: https://issues.apache.org/jira/browse/PDFBOX-2373 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 1.8.7, 1.8.8, 2.0.0 > Environment: W7 64bit 1.7.0_65 >Reporter: Tilman Hausherr > Labels: crash > Attachments: 228-228597-p19-crash.pdf > > > Rendering the attached file crashes java. It happens only at 72 dpi. It can > be reproduced with the PDFToImage cmd app. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] move documentation and examples to git
> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, > Apache Cordova to mention some can handle it we should be smart enough to > handle it too. None of those projects make use of file attachments for issues the way that we do. > I can’t see the issues tab for these projects but pull requests. Is exactly my point - we’re forced to use GitHub issues for pull requests, which is a problem because then we don’t get to manage these via JIRA. Looking at these projects all of them have had pull requests which do not contain any references to JIRA issues but have been merged in, so it seems certain that we would loose JIRA as a central point of information. -- John On 20 Sep 2014, at 04:24, Maruan Sahyoun wrote: > I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, > Apache Cordova to mention some can handle it we should be smart enough to > handle it too. And I can’t see the issues tab for these projects but pull > requests. > > BR > Maruan > > Am 20.09.2014 um 04:22 schrieb John Hewson : > >>> Issue tracking would still be done using Jira. Same as for most other >>> Apache projects >> >> The problem with that approach is that GitHub’s pull requests can only be >> managed via GitHub’s issues interface, so we’re forced to use it. There’s no >> way to prevent GitHub users from opening and discussing issues in pull >> requests rather than on JIRA. >> >> -- John >> >> On 17 Sep 2014, at 21:58, Maruan Sahyoun wrote: >> >>> >>> >>> Maruan Sahyoun >>> Am 18.09.2014 um 02:03 schrieb John Hewson : I agree with Tilman on this point, the examples need to stay in the trunk where they can be built along with it. It’s very common to modify an example to take into account API changes. They’re also currently distributed along with the main PDFBox source bundle, which is a good thing. I’d be surprised if anybody outside of the project wanted to contribute to the documentation, almost nobody seems to like writing it. Perhaps we could do this as a trial - see if it really increases contributions or not? It would be great if it did. >>> >>> OK so lets try with the docs. >>> >>> To mention it for completness - the build process for the web site and the >>> documentation contained within will still be done by the Apache CMS. >>> It’s worth adding that I’m (reluctantly) against moving PDFBox trunk over to GitHub because GitHub Issues is not powerful enough for our needs (e.g. no file attachments), which is really a shame. >>> >>> Issue tracking would still be done using Jira. Same as for most other >>> Apache projects >>> -- John > On 17 Sep 2014, at 10:26, Tilman Hausherr wrote: > > Hi Maruan, > > The examples only. > > With "the docs" I assume you mean the website. I've never touched it > (although I might in the future), it isn't part of the project, so I > don't mind. > > Tilman > >> Am 17.09.2014 um 19:01 schrieb Maruan Sahyoun: >> is that because of the examples, the docs or both? >> >> BR >> >> Maruan >> >>> Am 17.09.2014 um 18:46 schrieb Tilman Hausherr : >>> >>> It is a "I don't like it, but I can live with it but I think it might >>> be a pain". A "soft -1". >>> >>> Tilman >>> Am 17.09.2014 um 08:40 schrieb Andreas Lehmkühler: Hi, > Tilman Hausherr hat am 16. September 2014 um > 18:03 > geschrieben: > > > -1, I don't like the idea to have different repository types. Hmmm, is this just a "I don't like it, but I can live with it" or is it a clear veto? In a case of a veto, how about starting with moving parts of the docs to a new git repo? IMO sooner or later the project will move from svn to git and that would be a good opertunity to get used to the general usage of git and of course to the special processes used here at the ASF so that we are not thrown in at the deep end after the migration. > Tilman BR Andreas >> Am 16.09.2014 um 10:21 schrieb Maruan Sahyoun: >> Hi there, >> >> in order to make it easier for people to contribute to the >> documentation and >> examples I thought about the potential benefits of moving these to a >> git >> based repository instead of svn. The main idea behind that is to >> allow >> people to contribute via github opening another channel of >> communication and >> making it easier to contribute. >> >> Proposed names are pdfbox-docs and pdfbox-examples. Take a look at >> https://github.com/apache/cordova-docs for
[jira] [Comment Edited] (PDFBOX-2304) square glyphs missing
[ https://issues.apache.org/jira/browse/PDFBOX-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142099#comment-14142099 ] John Hewson edited comment on PDFBOX-2304 at 9/21/14 7:55 PM: -- Sorry, I tested this on the wrong file, I had another file with similar problems. was (Author: jahewson): Sorry, I tested this on the wrong file, I had enough file with similar problems. > square glyphs missing > - > > Key: PDFBOX-2304 > URL: https://issues.apache.org/jira/browse/PDFBOX-2304 > Project: PDFBox > Issue Type: Bug > Components: FontBox, Rendering >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr >Assignee: John Hewson > Fix For: 2.0.0 > > > In the file PDFBOX-2294-TaroUTR50SortedList112.pdf e.g. on page 17 (but some > others too) the squares and the X-ed squares are missing in the rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2373) Rendering at 72 dpi crashes java
[
https://issues.apache.org/jira/browse/PDFBOX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142416#comment-14142416
]
Tilman Hausherr edited comment on PDFBOX-2373 at 9/21/14 8:14 PM:
--
last thing before crash was a StrokePath() operation:
{code}
Op d: [COSArray{[COSFloat{0.024}, COSFloat{0.012}]}, COSInt{0}]
Op m: [COSFloat{126.446}, COSFloat{455.027}]
Op l: [COSFloat{126.527}, COSFloat{455.118}]
Op S: -
Op SCN: [COSFloat{0.922}, COSFloat{0.176}, COSFloat{0.18}]
Op d: [COSArray{[]}, COSInt{0}]
Op m: [COSFloat{128.325}, COSFloat{454.945}]
Op l: [COSFloat{129.014}, COSFloat{455.863}]
Op m: [COSFloat{129.702}, COSFloat{455.173}]
Op l: [COSFloat{129.014}, COSFloat{454.255}]
Op m: [COSFloat{129.932}, COSFloat{455.404}]
Op l: [COSFloat{129.014}, COSFloat{455.863}]
Op m: [COSFloat{130.161}, COSFloat{454.945}]
Op l: [COSFloat{128.784}, COSFloat{456.092}]
Op m: [COSFloat{130.161}, COSFloat{454.945}]
Op l: [COSFloat{129.932}, COSFloat{455.404}]
Op m: [COSFloat{128.784}, COSFloat{456.322}]
Op l: [COSFloat{129.014}, COSFloat{455.863}]
Op m: [COSFloat{129.932}, COSFloat{454.715}]
Op l: [COSFloat{130.161}, COSFloat{454.945}]
Op m: [COSFloat{128.554}, COSFloat{456.092}]
Op l: [COSFloat{128.784}, COSFloat{456.322}]
Op m: [COSFloat{128.554}, COSFloat{456.092}]
Op l: [COSFloat{129.014}, COSFloat{455.863}]
Op m: [COSFloat{129.702}, COSFloat{455.173}]
Op l: [COSFloat{129.014}, COSFloat{455.863}]
Op m: [COSFloat{129.702}, COSFloat{455.173}]
Op l: [COSFloat{129.932}, COSFloat{454.715}]
Op S: -
Op SCN: [COSFloat{0.137}, COSFloat{0.122}, COSFloat{0.125}]
Op m: [COSFloat{140.032}, COSFloat{461.601}]
Op l: [COSFloat{137.966}, COSFloat{463.438}]
Op m: [COSFloat{139.573}, COSFloat{462.979}]
Op l: [COSFloat{140.032}, COSFloat{463.438}]
Op m: [COSFloat{137.966}, COSFloat{463.438}]
Op l: [COSFloat{138.425}, COSFloat{463.897}]
Op m: [COSFloat{132.227}, COSFloat{456.781}]
Op l: [COSFloat{136.129}, COSFloat{460.912}]
Op m: [COSFloat{130.161}, COSFloat{458.388}]
Op l: [COSFloat{134.063}, COSFloat{462.749}]
Op m: [COSFloat{130.161}, COSFloat{458.388}]
Op l: [COSFloat{132.227}, COSFloat{456.781}]
Op m: [COSFloat{132.916}, COSFloat{463.667}]
Op l: [COSFloat{137.048}, COSFloat{459.994}]
Op S: -
Op d: [COSArray{[COSFloat{0.024}, COSFloat{0.012}]}, COSInt{0}]
Op m: [COSFloat{134.057}, COSFloat{463.512}]
Op l: [COSFloat{135.34}, COSFloat{462.362}]
Op m: [COSFloat{133.977}, COSFloat{463.422}]
Op l: [COSFloat{135.237}, COSFloat{462.292}]
Op m: [COSFloat{133.977}, COSFloat{463.422}]
Op l: [COSFloat{134.057}, COSFloat{463.512}]
Op m: [COSFloat{136.723}, COSFloat{460.961}]
Op l: [COSFloat{136.804}, COSFloat{461.05}]
Op S: -
Op SCN: [COSInt{0}, COSFloat{0.667}, COSFloat{0.31}]
Op m: [COSFloat{135.209}, COSFloat{462.034}]
Op l: [COSFloat{135.35}, COSFloat{462.191}]
Op m: [COSFloat{135.118}, COSFloat{462.114}]
Op l: [COSFloat{135.239}, COSFloat{462.249}]
Op m: [COSFloat{135.299}, COSFloat{461.952}]
Op l: [COSFloat{135.42}, COSFloat{462.087}]
Op S: -
Op SCN: [COSFloat{0.137}, COSFloat{0.122}, COSFloat{0.125}]
Op m: [COSFloat{135.462}, COSFloat{462.09}]
Op l: [COSFloat{136.723}, COSFloat{460.961}]
Op S: -
Op SCN: [COSInt{0}, COSFloat{0.667}, COSFloat{0.31}]
Op m: [COSFloat{135.35}, COSFloat{462.191}]
Op c: [COSFloat{135.37}, COSFloat{462.214}, COSFloat{135.381},
COSFloat{462.242}, COSFloat{135.381}, COSFloat{462.272}]
Op c: [COSFloat{135.381}, COSFloat{462.306}, COSFloat{135.366},
COSFloat{462.339}, COSFloat{135.34}, COSFloat{462.362}]
Op m: [COSFloat{135.52}, COSFloat{462.2}]
Op c: [COSFloat{135.499}, COSFloat{462.22}, COSFloat{135.47},
COSFloat{462.231}, COSFloat{135.44}, COSFloat{462.231}]
Op c: [COSFloat{135.406}, COSFloat{462.231}, COSFloat{135.373},
COSFloat{462.216}, COSFloat{135.35}, COSFloat{462.191}]
Op m: [COSFloat{135.462}, COSFloat{462.09}]
Op c: [COSFloat{135.457}, COSFloat{462.095}, COSFloat{135.449},
COSFloat{462.098}, COSFloat{135.442}, COSFloat{462.098}]
Op c: [COSFloat{135.434}, COSFloat{462.098}, COSFloat{135.425},
COSFloat{462.094}, COSFloat{135.42}, COSFloat{462.087}]
Op m: [COSFloat{135.239}, COSFloat{462.249}]
Op c: [COSFloat{135.244}, COSFloat{462.255}, COSFloat{135.247},
COSFloat{462.262}, COSFloat{135.247}, COSFloat{462.269}]
Op c: [COSFloat{135.247}, COSFloat{462.279}, COSFloat{135.244},
COSFloat{462.286}, COSFloat{135.237}, COSFloat{462.292}]
Op S: -
{code}
was (Author: tilman):
last thing before crash was a StrokePath() operation:
{code}
Op SCN: [COSInt{0}, COSFloat{0.667}, COSFloat{0.31}]
Op m: [COSFloat{135.35}, COSFloat{462.191}]
Op c: [COSFloat{135.37}, COSFloat{462.214}, COSFloat{135.381},
COSFloat{462.242}, COSFloat{135.381}, COSFloat{462.272}]
Op c: [COSFloat{135.381}, COSFloat{462.306}, COSFloat{135.366},
COSFloat{462.339}, COSFloat{135.34}, COSFloat{462.362}]
Op m: [COSFloat{135.52}, COSFloat{462.2}]
Op c: [COSFloat{135.499}, COSFloat{462.22}, COSFloat{135.47},
COSFloat{462.231}, COS
[jira] [Commented] (PDFBOX-2373) Rendering at 72 dpi crashes java
[ https://issues.apache.org/jira/browse/PDFBOX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142671#comment-14142671 ] Tilman Hausherr commented on PDFBOX-2373: - I've edited my text above to include the last dash pattern. > Rendering at 72 dpi crashes java > > > Key: PDFBOX-2373 > URL: https://issues.apache.org/jira/browse/PDFBOX-2373 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 1.8.7, 1.8.8, 2.0.0 > Environment: W7 64bit 1.7.0_65 >Reporter: Tilman Hausherr > Labels: crash > Attachments: 228-228597-p19-crash.pdf > > > Rendering the attached file crashes java. It happens only at 72 dpi. It can > be reproduced with the PDFToImage cmd app. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142676#comment-14142676 ] John Hewson commented on PDFBOX-2372: - Yes, the file from PDFBOX-2251 has missing glyphs which are correctly rendered as rectangles. The files from PDFBOX-2245 and PDFBOX-563 do have missing glyphs, and rendering GID 0 is the correct thing to do but both these PDFs are using external "Standard 14" fonts. I think what's happening is that the original Adobe versions of the "Standard 14" fonts have an empty glyph as GID 0, whereas the Microsoft fonts which are substituted on our systems have a rectangle as GID 0. In that case the fix will be to not draw GID 0 for "Standard 14" fonts. However, the PDFBOX-1735 file contains only embedded fonts and renders fine for me, we really shouldn't be seeing any differences. > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] move documentation and examples to git
e.g. Apache Camel does use JIRA for issue tracking. They are not using GitHubs issue management. And they do accept pull requests. And from the infra blog https://blogs.apache.org/infra/entry/improved_integration_between_apache_and Any Pull Request that gets opened, closed, reopened or commented on now gets recorded on the project's mailing list If a project has a JIRA instance, any PRs or comments on PRs that include a JIRA ticket ID will trigger an update on that specific ticket I don’t get your point. BR Maruan Am 21.09.2014 um 21:42 schrieb John Hewson : >> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, >> Apache Cordova to mention some can handle it we should be smart enough to >> handle it too. > > None of those projects make use of file attachments for issues the way that > we do. > >> I can’t see the issues tab for these projects but pull requests. > > Is exactly my point - we’re forced to use GitHub issues for pull requests, > which is a problem because then we don’t get to manage these via JIRA. > Looking at these projects all of them have had pull requests which do not > contain any references to JIRA issues but have been merged in, so it seems > certain that we would loose JIRA as a central point of information. > > -- John > > On 20 Sep 2014, at 04:24, Maruan Sahyoun wrote: > >> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, >> Apache Cordova to mention some can handle it we should be smart enough to >> handle it too. And I can’t see the issues tab for these projects but pull >> requests. >> >> BR >> Maruan >> >> Am 20.09.2014 um 04:22 schrieb John Hewson : >> Issue tracking would still be done using Jira. Same as for most other Apache projects >>> >>> The problem with that approach is that GitHub’s pull requests can only be >>> managed via GitHub’s issues interface, so we’re forced to use it. There’s >>> no way to prevent GitHub users from opening and discussing issues in pull >>> requests rather than on JIRA. >>> >>> -- John >>> >>> On 17 Sep 2014, at 21:58, Maruan Sahyoun wrote: >>> Maruan Sahyoun > Am 18.09.2014 um 02:03 schrieb John Hewson : > > I agree with Tilman on this point, the examples need to stay in the trunk > where they can be built along with it. > It’s very common to modify an example to take into account API changes. > They’re also currently distributed along with the main PDFBox source > bundle, which is a good thing. > > I’d be surprised if anybody outside of the project wanted to contribute > to the documentation, almost nobody seems to like writing it. Perhaps we > could do this as a trial - see if it really increases contributions or > not? It would be great if it did. > OK so lets try with the docs. To mention it for completness - the build process for the web site and the documentation contained within will still be done by the Apache CMS. > It’s worth adding that I’m (reluctantly) against moving PDFBox trunk over > to GitHub because GitHub Issues is not powerful enough for our needs > (e.g. no file attachments), which is really a shame. > Issue tracking would still be done using Jira. Same as for most other Apache projects > -- John > >> On 17 Sep 2014, at 10:26, Tilman Hausherr wrote: >> >> Hi Maruan, >> >> The examples only. >> >> With "the docs" I assume you mean the website. I've never touched it >> (although I might in the future), it isn't part of the project, so I >> don't mind. >> >> Tilman >> >>> Am 17.09.2014 um 19:01 schrieb Maruan Sahyoun: >>> is that because of the examples, the docs or both? >>> >>> BR >>> >>> Maruan >>> Am 17.09.2014 um 18:46 schrieb Tilman Hausherr : It is a "I don't like it, but I can live with it but I think it might be a pain". A "soft -1". Tilman > Am 17.09.2014 um 08:40 schrieb Andreas Lehmkühler: > Hi, > >> Tilman Hausherr hat am 16. September 2014 um >> 18:03 >> geschrieben: >> >> >> -1, I don't like the idea to have different repository types. > Hmmm, is this just a "I don't like it, but I can live with it" or is > it a clear > veto? > > In a case of a veto, how about starting with moving parts of the docs > to a new > git repo? IMO sooner or later the project will move from svn to git > and that > would be a good opertunity to get used to the general usage of git > and of course > to the special processes used here at the ASF so that we are not > thrown in at > the deep end after the migration. > >>
[jira] [Commented] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
[ https://issues.apache.org/jira/browse/PDFBOX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142682#comment-14142682 ] Maruan Sahyoun commented on PDFBOX-2374: Part of this and PDFBOX-2340 is to better represent 2.0 (and future versions) on the website but allow to get the older docs too. You’ll be able to switch to the docs of the version you are interested in (see the mockup in PDFBOX-2340). What we could do in addition is teaser 2.0 with a prominent start point on the website like „Learn about the next release“ or so. If you have guides/tutorial I’m happy to make sure that they are in. > Make JavaDocs for trunk builds available via our website > > > Key: PDFBOX-2374 > URL: https://issues.apache.org/jira/browse/PDFBOX-2374 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 >Reporter: Maruan Sahyoun > Fix For: 2.0.0 > > > In order to help people using the latest trunk versions of PDFBox the > JavaDocs for the main project and the sub projects shall be made available on > our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142696#comment-14142696 ] ASF subversion and git services commented on PDFBOX-2372: - Commit 1626630 from [~jahewson] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1626630 ] PDFBOX-2372: Standard 14 simple fonts should have empty .notdef glyph > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142697#comment-14142697 ] ASF subversion and git services commented on PDFBOX-2372: - Commit 1626631 from [~jahewson] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1626631 ] PDFBOX-2372: Standard 14 simple fonts should have empty .notdef glyph (only when substituted) > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142698#comment-14142698 ] John Hewson commented on PDFBOX-2372: - The last two commits fix the issue with PDFBOX-2245 for "Standard 14" fonts by faking an empty .notdef glyph when external fonts are substituted. > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142699#comment-14142699 ] John Hewson commented on PDFBOX-2372: - The file from PDFBOX-563 has a similar issue related to "Standard 14" fonts, only in this case the font is a Type 0 font, which shouldn't be eligible to be treated as a "Standard 14", yet it is anyway. A simple experiment of changing "Arial" for "Xrial" in the PDF file causes Acrobat to render the missing glyphs which means it is treating the name "Arial" in a special manner. (Note that the Adobe supplement specifies Arial as an alias for Helvetica). > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142699#comment-14142699 ] John Hewson edited comment on PDFBOX-2372 at 9/21/14 8:57 PM: -- The file from PDFBOX-563 has a similar issue related to "Standard 14" fonts, only in this case the font is a Type 0 font, which shouldn't be eligible to be treated as a "Standard 14", yet it is anyway. A simple experiment of changing "Arial" for "Xrial" in the PDF file causes Acrobat to render the missing glyphs which means it is treating the name "Arial" in a special manner. (Note that the Adobe supplement specifies Arial as an alias for Helvetica). Because we're not expecting a Type0 font to have any special "Standard 14" handling, the fix will be more complex. was (Author: jahewson): The file from PDFBOX-563 has a similar issue related to "Standard 14" fonts, only in this case the font is a Type 0 font, which shouldn't be eligible to be treated as a "Standard 14", yet it is anyway. A simple experiment of changing "Arial" for "Xrial" in the PDF file causes Acrobat to render the missing glyphs which means it is treating the name "Arial" in a special manner. (Note that the Adobe supplement specifies Arial as an alias for Helvetica). > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142701#comment-14142701 ] ASF subversion and git services commented on PDFBOX-2372: - Commit 1626632 from [~jahewson] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1626632 ] PDFBOX-2372: Standard 14 Type 0 fonts should have empty .notdef glyph > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2372) Regressions 19.9.2014
[ https://issues.apache.org/jira/browse/PDFBOX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142704#comment-14142704 ] John Hewson commented on PDFBOX-2372: - The last commit fixes the rendering of PDFBOX-563, as the use of a "Standard 14" font name in a Type 0 font is now recognised. > Regressions 19.9.2014 > - > > Key: PDFBOX-2372 > URL: https://issues.apache.org/jira/browse/PDFBOX-2372 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Labels: regression > > There are several regressions from the changes done on the evening of > 19.9.2014. Because I can't map these to one single change, I had to open a > new issue. > PDFBOX-563-acroform.pdf: trash glyphs at the bottom > PDFBOX-1735-confidential.pdf p7: trash glyphs on the left > PDFBOX-2245-052567.pdf: trash glyphs > PDFBOX-2251-070075.pdf: trash glyphs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2360) PDFont had methods removed
[
https://issues.apache.org/jira/browse/PDFBOX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142717#comment-14142717
]
John Hewson commented on PDFBOX-2360:
-
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
No, you've misread the spec, a Type 0 font is not itself a CIDFont, it is
*obtained from* a CIDFont, i.e. it wraps a descendant CIDFont.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
> PDFont had methods removed
> --
>
> Key: PDFBOX-2360
> URL: https://issues.apache.org/jira/browse/PDFBOX-2360
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> Add back methods or provide a equivalent to pdfbox so it easier to upgrade to
> PDFBox 2
> PDFont
> public int getFirstChar()
> public int getLastChar()
> public Encoding getFontEncoding()
> public CMap getToUnicodeCMap()
> public String encode(byte[] c, int offset, int length) throws IOException
> PDCIDFont
> public long getDefaultWidth()
> Encoding
> public String getCharacter(int code) throws IOException
> CFFFont
> public Object getProperty(String name)
> public Map getCharStringsDict()
> public CFFEncoding getEncoding()
> CFFCharset
> public List getEntries()
> CFFEncoding
> public List getEntries()
> Cmap
> public String lookup( int code, int length )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2360) PDFont had methods removed
[
https://issues.apache.org/jira/browse/PDFBOX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142717#comment-14142717
]
John Hewson edited comment on PDFBOX-2360 at 9/21/14 9:17 PM:
--
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
No, you've misread the spec, a Type 0 font is not itself a CIDFont, it is
*obtained from* a CIDFont, i.e. it wraps a descendant CIDFont.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
was (Author: jahewson):
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
No, you've misread the spec, a Type 0 font is not itself a CIDFont, it is
*obtained from* a CIDFont, i.e. it wraps a descendant CIDFont.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
> PDFont had methods removed
> --
>
> Key: PDFBOX-2360
> URL: https://issues.apache.org/jira/browse/PDFBOX-2360
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> Add back methods or provide a equivalent to pdfbox so it easier to upgrade to
> PDFBox 2
> PDFont
> public int getFirstChar()
> public int getLastChar()
> public Encoding getFontEncoding()
> public CMap getToUnicodeCMap()
> public String encode(byte[] c, int offset, int length) throws IOException
> PDCIDFont
> public long getDefaultWidth()
> Encoding
> public String getCharacter(int code) throws IOException
> CFFFont
> public Object getProperty(String name)
> public Map getCharStringsDict()
> public CFFEncoding getEncoding()
> CFFCharset
> public List getEntries()
> CFFEncoding
> public List getEntries()
> Cmap
> public String lookup( int code, int length )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2360) PDFont had methods removed
[
https://issues.apache.org/jira/browse/PDFBOX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142717#comment-14142717
]
John Hewson edited comment on PDFBOX-2360 at 9/21/14 9:20 PM:
--
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
A Type 0 font is not itself a CIDFont, it is *obtained from* a CIDFont, i.e. it
wraps a descendant CIDFont. It's true that a CIDFont is a font-like object, but
a font-like object is not always a CIDFont, it may be a normal Font.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
was (Author: jahewson):
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
No, you've misread the spec, a Type 0 font is not itself a CIDFont, it is
*obtained from* a CIDFont, i.e. it wraps a descendant CIDFont.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
> PDFont had methods removed
> --
>
> Key: PDFBOX-2360
> URL: https://issues.apache.org/jira/browse/PDFBOX-2360
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> Add back methods or provide a equivalent to pdfbox so it easier to upgrade to
> PDFBox 2
> PDFont
> public int getFirstChar()
> public int getLastChar()
> public Encoding getFontEncoding()
> public CMap getToUnicodeCMap()
> public String encode(byte[] c, int offset, int length) throws IOException
> PDCIDFont
> public long getDefaultWidth()
> Encoding
> public String getCharacter(int code) throws IOException
> CFFFont
> public Object getProperty(String name)
> public Map getCharStringsDict()
> public CFFEncoding getEncoding()
> CFFCharset
> public List getEntries()
> CFFEncoding
> public List getEntries()
> Cmap
> public String lookup( int code, int length )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2360) PDFont had methods removed
[
https://issues.apache.org/jira/browse/PDFBOX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142717#comment-14142717
]
John Hewson edited comment on PDFBOX-2360 at 9/21/14 9:20 PM:
--
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
A Type 0 font is not itself a CIDFont, it is *obtained from* a CIDFont, i.e. it
wraps a descendant CIDFont. It's true that a CIDFont is a font-like object, but
a font-like object is not always a CIDFont, it may be a normal Font.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's a "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
was (Author: jahewson):
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
A Type 0 font is not itself a CIDFont, it is *obtained from* a CIDFont, i.e. it
wraps a descendant CIDFont. It's true that a CIDFont is a font-like object, but
a font-like object is not always a CIDFont, it may be a normal Font.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
> PDFont had methods removed
> --
>
> Key: PDFBOX-2360
> URL: https://issues.apache.org/jira/browse/PDFBOX-2360
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> Add back methods or provide a equivalent to pdfbox so it easier to upgrade to
> PDFBox 2
> PDFont
> public int getFirstChar()
> public int getLastChar()
> public Encoding getFontEncoding()
> public CMap getToUnicodeCMap()
> public String encode(byte[] c, int offset, int length) throws IOException
> PDCIDFont
> public long getDefaultWidth()
> Encoding
> public String getCharacter(int code) throws IOException
> CFFFont
> public Object getProperty(String name)
> public Map getCharStringsDict()
> public CFFEncoding getEncoding()
> CFFCharset
> public List getEntries()
> CFFEncoding
> public List getEntries()
> Cmap
> public String lookup( int code, int length )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2360) PDFont had methods removed
[
https://issues.apache.org/jira/browse/PDFBOX-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142717#comment-14142717
]
John Hewson edited comment on PDFBOX-2360 at 9/21/14 9:22 PM:
--
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
A Type 0 font is not itself a CIDFont, it is *obtained from* a CIDFont, i.e. it
wraps a descendant CIDFont. It's true that a CIDFont is a font-like object, but
a font-like object is not always a CIDFont, it may be a normal Font.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's a "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used. The spec tells us that a CIDFont is
"font-like" and a Font is by definition already "font-like".
was (Author: jahewson):
{quote}
You are correct that fontlike is used with the PDF spec but it has been given a
name there which is CIDFont
{quote}
{code}
PDF Spec:
A composite font, also called a Type 0 font, is one whose glyphs are obtained
from a fontlike object called a CIDFont
{code}
A Type 0 font is not itself a CIDFont, it is *obtained from* a CIDFont, i.e. it
wraps a descendant CIDFont. It's true that a CIDFont is a font-like object, but
a font-like object is not always a CIDFont, it may be a normal Font.
{quote}
Now with the new interface you are wrapping common information for different
font types which is very good.
{quote}
Technically this is incorrect, these are not "different font types" because a
*CIDFont is not a font*. It's a "font-like object".
{quote}
So what about something like PDFontCommonProperties.
{quote}
As a CIDFont is not a font this name would be wrong. There's already a name in
the spec for the common features of both Fonts and CIDFonts, it's "font-like
object" which is what I've used.
> PDFont had methods removed
> --
>
> Key: PDFBOX-2360
> URL: https://issues.apache.org/jira/browse/PDFBOX-2360
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: simon steiner
>Assignee: John Hewson
>
> Add back methods or provide a equivalent to pdfbox so it easier to upgrade to
> PDFBox 2
> PDFont
> public int getFirstChar()
> public int getLastChar()
> public Encoding getFontEncoding()
> public CMap getToUnicodeCMap()
> public String encode(byte[] c, int offset, int length) throws IOException
> PDCIDFont
> public long getDefaultWidth()
> Encoding
> public String getCharacter(int code) throws IOException
> CFFFont
> public Object getProperty(String name)
> public Map getCharStringsDict()
> public CFFEncoding getEncoding()
> CFFCharset
> public List getEntries()
> CFFEncoding
> public List getEntries()
> Cmap
> public String lookup( int code, int length )
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [DISCUSS] move documentation and examples to git
The problem is that PRs can be opened without JIRA ticket IDs attached to them, and the projects you linked to show this happening on many occasions. The integration you mention looks pretty good though - linking PRs to JIRA issues is what we want. But we need to have some way to prevent PRs from being opened which don’t have JIRA issue IDs attached. -- John On 21 Sep 2014, at 13:31, Maruan Sahyoun wrote: > e.g. Apache Camel does use JIRA for issue tracking. They are not using > GitHubs issue management. And they do accept pull requests. > > And from the infra blog > https://blogs.apache.org/infra/entry/improved_integration_between_apache_and > > Any Pull Request that gets opened, closed, reopened or commented on now gets > recorded on the project's mailing list > If a project has a JIRA instance, any PRs or comments on PRs that include a > JIRA ticket ID will trigger an update on that specific ticket > > I don’t get your point. > > BR > > Maruan > > Am 21.09.2014 um 21:42 schrieb John Hewson : > >>> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache >>> Tomee, Apache Cordova to mention some can handle it we should be smart >>> enough to handle it too. >> >> None of those projects make use of file attachments for issues the way that >> we do. >> >>> I can’t see the issues tab for these projects but pull requests. >> >> Is exactly my point - we’re forced to use GitHub issues for pull requests, >> which is a problem because then we don’t get to manage these via JIRA. >> Looking at these projects all of them have had pull requests which do not >> contain any references to JIRA issues but have been merged in, so it seems >> certain that we would loose JIRA as a central point of information. >> >> -- John >> >> On 20 Sep 2014, at 04:24, Maruan Sahyoun wrote: >> >>> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache >>> Tomee, Apache Cordova to mention some can handle it we should be smart >>> enough to handle it too. And I can’t see the issues tab for these projects >>> but pull requests. >>> >>> BR >>> Maruan >>> >>> Am 20.09.2014 um 04:22 schrieb John Hewson : >>> > Issue tracking would still be done using Jira. Same as for most other > Apache projects The problem with that approach is that GitHub’s pull requests can only be managed via GitHub’s issues interface, so we’re forced to use it. There’s no way to prevent GitHub users from opening and discussing issues in pull requests rather than on JIRA. -- John On 17 Sep 2014, at 21:58, Maruan Sahyoun wrote: > > > Maruan Sahyoun > >> Am 18.09.2014 um 02:03 schrieb John Hewson : >> >> I agree with Tilman on this point, the examples need to stay in the >> trunk where they can be built along with it. >> It’s very common to modify an example to take into account API changes. >> They’re also currently distributed along with the main PDFBox source >> bundle, which is a good thing. >> >> I’d be surprised if anybody outside of the project wanted to contribute >> to the documentation, almost nobody seems to like writing it. Perhaps we >> could do this as a trial - see if it really increases contributions or >> not? It would be great if it did. >> > > OK so lets try with the docs. > > To mention it for completness - the build process for the web site and > the documentation contained within will still be done by the Apache CMS. > >> It’s worth adding that I’m (reluctantly) against moving PDFBox trunk >> over to GitHub because GitHub Issues is not powerful enough for our >> needs (e.g. no file attachments), which is really a shame. >> > > Issue tracking would still be done using Jira. Same as for most other > Apache projects > >> -- John >> >>> On 17 Sep 2014, at 10:26, Tilman Hausherr wrote: >>> >>> Hi Maruan, >>> >>> The examples only. >>> >>> With "the docs" I assume you mean the website. I've never touched it >>> (although I might in the future), it isn't part of the project, so I >>> don't mind. >>> >>> Tilman >>> Am 17.09.2014 um 19:01 schrieb Maruan Sahyoun: is that because of the examples, the docs or both? BR Maruan > Am 17.09.2014 um 18:46 schrieb Tilman Hausherr > : > > It is a "I don't like it, but I can live with it but I think it might > be a pain". A "soft -1". > > Tilman > >> Am 17.09.2014 um 08:40 schrieb Andreas Lehmkühler: >> Hi, >> >>> Tilman Hausherr hat am 16. September 2014 >>> um 18:03 >>> geschrieben: >>> >>> >>> -1, I don't like the idea to have different repository types. >> Hmmm,
[jira] [Commented] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
[ https://issues.apache.org/jira/browse/PDFBOX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142740#comment-14142740 ] John Hewson commented on PDFBOX-2374: - As the plan is to strongly discourage use of 1.8 after 2.0 is released, we wouldn't want anything like the "choose your API version" menu in the mockup, we'd want to archive the old 1.8 site in a branch somewhere and make it available at a URL such as https://pdfbox.apache.org/1.8 with a message at the top saying that it is no longer under development. Then somewhere on the new 2.0 site we would provide a link for users who are looking for the old 1.8 website. There's no point wasting any energy on 1.8 documents which will be deprecated in a few months time. > Make JavaDocs for trunk builds available via our website > > > Key: PDFBOX-2374 > URL: https://issues.apache.org/jira/browse/PDFBOX-2374 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 >Reporter: Maruan Sahyoun > Fix For: 2.0.0 > > > In order to help people using the latest trunk versions of PDFBox the > JavaDocs for the main project and the sub projects shall be made available on > our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
[
https://issues.apache.org/jira/browse/PDFBOX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142740#comment-14142740
]
John Hewson edited comment on PDFBOX-2374 at 9/21/14 10:16 PM:
---
As the plan is to strongly discourage use of 1.8 after 2.0 is released, we
wouldn't want anything like the "choose your API version" menu in the mockup,
we'd want to archive the old 1.8 site in a branch somewhere and make it
available at a URL such as https://pdfbox.apache.org/1.8 with a message at the
top saying that it is no longer under development. Then somewhere on the new
2.0 site we would provide a link for users who are looking for the old 1.8
website.
There's no point wasting any energy on 1.8 documents which will be deprecated
in a few months time.
{quote}
What we could do in addition is teaser 2.0 with a prominent start point on the
website like „Learn about the next release“ or so.
{quote}
We should do this, but make sure to include the word "unstable".
was (Author: jahewson):
As the plan is to strongly discourage use of 1.8 after 2.0 is released, we
wouldn't want anything like the "choose your API version" menu in the mockup,
we'd want to archive the old 1.8 site in a branch somewhere and make it
available at a URL such as https://pdfbox.apache.org/1.8 with a message at the
top saying that it is no longer under development. Then somewhere on the new
2.0 site we would provide a link for users who are looking for the old 1.8
website.
There's no point wasting any energy on 1.8 documents which will be deprecated
in a few months time.
> Make JavaDocs for trunk builds available via our website
>
>
> Key: PDFBOX-2374
> URL: https://issues.apache.org/jira/browse/PDFBOX-2374
> Project: PDFBox
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 2.0.0
>Reporter: Maruan Sahyoun
> Fix For: 2.0.0
>
>
> In order to help people using the latest trunk versions of PDFBox the
> JavaDocs for the main project and the sub projects shall be made available on
> our website.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[
https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142794#comment-14142794
]
John Hewson commented on PDFBOX-2298:
-
{quote}
If I activate the automatic scretching in drawGlyph2D (by commenting the if
clause for not embedded fonts) everything works fine.
{quote}
Glyphs in embedded fonts do not need to be stretched, Acrobat always uses the
embedded font widths and ignores the Widths dictionary. Removing the if clause
would result in incorrect rendering of any PDF files which have incorrect
values in their Widths dictionary (a fairly common problem).
> Wrong scaling of embedded type 1 font
> -
>
> Key: PDFBOX-2298
> URL: https://issues.apache.org/jira/browse/PDFBOX-2298
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Andreas Lehmkühler
> Attachments: PDFBOX935-data_not_extracted_1.png
>
>
> The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded
> type1 fonts have the wrong scaling. All glyphs are to big and are overlapping.
> It worked well before merging the no-awt branch into the trunk
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[
https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142794#comment-14142794
]
John Hewson edited comment on PDFBOX-2298 at 9/22/14 12:38 AM:
---
{quote}
If I activate the automatic scretching in drawGlyph2D (by commenting the if
clause for not embedded fonts) everything works fine.
{quote}
Glyphs in embedded Type 1 fonts do not need to be stretched, Acrobat always
uses the embedded font widths and ignores the Widths dictionary. Removing the
if clause would result in incorrect rendering of any PDF files which have
incorrect values in their Widths dictionary (a fairly common problem).
was (Author: jahewson):
{quote}
If I activate the automatic scretching in drawGlyph2D (by commenting the if
clause for not embedded fonts) everything works fine.
{quote}
Glyphs in embedded fonts do not need to be stretched, Acrobat always uses the
embedded font widths and ignores the Widths dictionary. Removing the if clause
would result in incorrect rendering of any PDF files which have incorrect
values in their Widths dictionary (a fairly common problem).
> Wrong scaling of embedded type 1 font
> -
>
> Key: PDFBOX-2298
> URL: https://issues.apache.org/jira/browse/PDFBOX-2298
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Andreas Lehmkühler
> Attachments: PDFBOX935-data_not_extracted_1.png
>
>
> The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded
> type1 fonts have the wrong scaling. All glyphs are to big and are overlapping.
> It worked well before merging the no-awt branch into the trunk
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142802#comment-14142802 ] John Hewson commented on PDFBOX-2298: - I've taken a look at the PDF file and the embedded font, the cause of the problem is that the embedded Type 1 font specifies a FontMatrix which uses a scale other than 1000, in fact it's roughly half that. This isn't permitted in PDF but we already handle cases where Type1C fonts have the same problem. The solution is to force PDType1Font to use the FontMatrix in the font file if one is specified. > Wrong scaling of embedded type 1 font > - > > Key: PDFBOX-2298 > URL: https://issues.apache.org/jira/browse/PDFBOX-2298 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler > Attachments: PDFBOX935-data_not_extracted_1.png > > > The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded > type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. > It worked well before merging the no-awt branch into the trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142806#comment-14142806 ] ASF subversion and git services commented on PDFBOX-2298: - Commit 1626652 from [~jahewson] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1626652 ] PDFBOX-2298: Use FontMatrix from embedded Type 1 fonts > Wrong scaling of embedded type 1 font > - > > Key: PDFBOX-2298 > URL: https://issues.apache.org/jira/browse/PDFBOX-2298 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler > Fix For: 2.0.0 > > Attachments: PDFBOX935-data_not_extracted_1.png > > > The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded > type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. > It worked well before merging the no-awt branch into the trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PDFBOX-2298) Wrong scaling of embedded type 1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hewson resolved PDFBOX-2298. - Resolution: Fixed Fix Version/s: 2.0.0 > Wrong scaling of embedded type 1 font > - > > Key: PDFBOX-2298 > URL: https://issues.apache.org/jira/browse/PDFBOX-2298 > Project: PDFBox > Issue Type: Bug > Components: Rendering >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler > Fix For: 2.0.0 > > Attachments: PDFBOX935-data_not_extracted_1.png > > > The file attached to PDFBOX-935 is rendered wrong. It seems that all embedded > type1 fonts have the wrong scaling. All glyphs are to big and are overlapping. > It worked well before merging the no-awt branch into the trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
[ https://issues.apache.org/jira/browse/PDFBOX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142809#comment-14142809 ] Maruan Sahyoun commented on PDFBOX-2374: I’m not in favor of this approach. I’d like to rather make it easy for users of PDFBox to find the documentation for the version of the library they are using in a consistent way with the latests stable version being the default to be displayed when the site comes up but with the ability to switch to older versions or the trunk version if they choose to do so. > Make JavaDocs for trunk builds available via our website > > > Key: PDFBOX-2374 > URL: https://issues.apache.org/jira/browse/PDFBOX-2374 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 >Reporter: Maruan Sahyoun > Fix For: 2.0.0 > > > In order to help people using the latest trunk versions of PDFBox the > JavaDocs for the main project and the sub projects shall be made available on > our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] move documentation and examples to git
Am 21.09.2014 um 23:57 schrieb John Hewson : > The problem is that PRs can be opened without JIRA ticket IDs attached to > them, and the projects you linked to show this happening on many occasions. > Now, that’s a different issue and I don’t know if there is a solution to prevent that. It may or may not be an issue in practice. Apache Camel and other projects are accepting this situation and for PDFBox is might also be acceptable. It’s not a show stopper in my opinion. BR Maruan > The integration you mention looks pretty good though - linking PRs to JIRA > issues is what we want. But we need to have some way to prevent PRs from > being opened which don’t have JIRA issue IDs attached. > > -- John > > On 21 Sep 2014, at 13:31, Maruan Sahyoun wrote: > >> e.g. Apache Camel does use JIRA for issue tracking. They are not using >> GitHubs issue management. And they do accept pull requests. >> >> And from the infra blog >> https://blogs.apache.org/infra/entry/improved_integration_between_apache_and >> >> Any Pull Request that gets opened, closed, reopened or commented on now gets >> recorded on the project's mailing list >> If a project has a JIRA instance, any PRs or comments on PRs that include a >> JIRA ticket ID will trigger an update on that specific ticket >> >> I don’t get your point. >> >> BR >> >> Maruan >> >> Am 21.09.2014 um 21:42 schrieb John Hewson : >> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, Apache Cordova to mention some can handle it we should be smart enough to handle it too. >>> >>> None of those projects make use of file attachments for issues the way that >>> we do. >>> I can’t see the issues tab for these projects but pull requests. >>> >>> Is exactly my point - we’re forced to use GitHub issues for pull requests, >>> which is a problem because then we don’t get to manage these via JIRA. >>> Looking at these projects all of them have had pull requests which do not >>> contain any references to JIRA issues but have been merged in, so it seems >>> certain that we would loose JIRA as a central point of information. >>> >>> -- John >>> >>> On 20 Sep 2014, at 04:24, Maruan Sahyoun wrote: >>> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, Apache Cordova to mention some can handle it we should be smart enough to handle it too. And I can’t see the issues tab for these projects but pull requests. BR Maruan Am 20.09.2014 um 04:22 schrieb John Hewson : >> Issue tracking would still be done using Jira. Same as for most other >> Apache projects > > The problem with that approach is that GitHub’s pull requests can only be > managed via GitHub’s issues interface, so we’re forced to use it. There’s > no way to prevent GitHub users from opening and discussing issues in pull > requests rather than on JIRA. > > -- John > > On 17 Sep 2014, at 21:58, Maruan Sahyoun wrote: > >> >> >> Maruan Sahyoun >> >>> Am 18.09.2014 um 02:03 schrieb John Hewson : >>> >>> I agree with Tilman on this point, the examples need to stay in the >>> trunk where they can be built along with it. >>> It’s very common to modify an example to take into account API changes. >>> They’re also currently distributed along with the main PDFBox source >>> bundle, which is a good thing. >>> >>> I’d be surprised if anybody outside of the project wanted to contribute >>> to the documentation, almost nobody seems to like writing it. Perhaps >>> we could do this as a trial - see if it really increases contributions >>> or not? It would be great if it did. >>> >> >> OK so lets try with the docs. >> >> To mention it for completness - the build process for the web site and >> the documentation contained within will still be done by the Apache CMS. >> >>> It’s worth adding that I’m (reluctantly) against moving PDFBox trunk >>> over to GitHub because GitHub Issues is not powerful enough for our >>> needs (e.g. no file attachments), which is really a shame. >>> >> >> Issue tracking would still be done using Jira. Same as for most other >> Apache projects >> >>> -- John >>> On 17 Sep 2014, at 10:26, Tilman Hausherr wrote: Hi Maruan, The examples only. With "the docs" I assume you mean the website. I've never touched it (although I might in the future), it isn't part of the project, so I don't mind. Tilman > Am 17.09.2014 um 19:01 schrieb Maruan Sahyoun: > is that because of the examples, the docs or both? > > BR > > Maruan > >> Am 17.09.2014 um 18:46 schrieb Tilman Hausherr
[jira] [Commented] (PDFBOX-2350) Type1 Parser hangs indefinitely
[
https://issues.apache.org/jira/browse/PDFBOX-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142821#comment-14142821
]
John Hewson commented on PDFBOX-2350:
-
Yep, the binary portion of the font is corrupt, the data meaningless, even
Acrobat cannot read this font. PDFBox is getting stuck in a loop trying to read
tokens because it mishandles the case where there are no valid tokens to read.
> Type1 Parser hangs indefinitely
> ---
>
> Key: PDFBOX-2350
> URL: https://issues.apache.org/jira/browse/PDFBOX-2350
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 2.0.0
> Environment: Windows 7, JDK 1.7.0_51-b13
>Reporter: Daniel Scheibe
> Attachments: PDFBOX-2350-289451-endless.pdf
>
>
> When rendering the first page of my pdf document the Type1Parser
> (org.apache.fontbox.type1.Type1Parser) hangs in a loop in
> {{parseBinary(byte[] bytes) throws IOException}}
> and "kills" our rendering pipeline. Please find the loop that hangs below:
> // find /Private dict
> while (!lexer.peekToken().getText().equals("Private"))
> {
> lexer.nextToken();
> }
> There is no token named "Private" ever in the list of returned tokens
> (they're empty all the time).
> Furthermore going deeper into the source code it seems the class reading the
> tokens (Type1Lexer) does never finally advance the buffer position and always
> returns an empty name token in the readToken(Token prevToken) method.
> Looking at the decrypted buffer i cannot get something useful out of it based
> on my current understanding.
> Unfortunately i cannot provide the pdf in question as it contains confidental
> data.
> Acrobat Reader XI Version 11.0.08 renders the document just fine.
> In addition it seems the pdf was encrypted (40-Bit RC4) with an empty
> password and says it's pdf version 1.5.
> Does this provide enough information or can i do anything else to help
> nailing this one down?
> I guess this might be a pdf document structure/feature that is not yet
> supported completely but at least pdfbox should throw an exception instead of
> failing "silently"...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2350) Type1 Parser hangs indefinitely
[
https://issues.apache.org/jira/browse/PDFBOX-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142822#comment-14142822
]
ASF subversion and git services commented on PDFBOX-2350:
-
Commit 1626656 from [~jahewson] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1626656 ]
PDFBOX-2350: Correctly handle and warn about damaged Type 1 font streams
> Type1 Parser hangs indefinitely
> ---
>
> Key: PDFBOX-2350
> URL: https://issues.apache.org/jira/browse/PDFBOX-2350
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 2.0.0
> Environment: Windows 7, JDK 1.7.0_51-b13
>Reporter: Daniel Scheibe
> Attachments: PDFBOX-2350-289451-endless.pdf
>
>
> When rendering the first page of my pdf document the Type1Parser
> (org.apache.fontbox.type1.Type1Parser) hangs in a loop in
> {{parseBinary(byte[] bytes) throws IOException}}
> and "kills" our rendering pipeline. Please find the loop that hangs below:
> // find /Private dict
> while (!lexer.peekToken().getText().equals("Private"))
> {
> lexer.nextToken();
> }
> There is no token named "Private" ever in the list of returned tokens
> (they're empty all the time).
> Furthermore going deeper into the source code it seems the class reading the
> tokens (Type1Lexer) does never finally advance the buffer position and always
> returns an empty name token in the readToken(Token prevToken) method.
> Looking at the decrypted buffer i cannot get something useful out of it based
> on my current understanding.
> Unfortunately i cannot provide the pdf in question as it contains confidental
> data.
> Acrobat Reader XI Version 11.0.08 renders the document just fine.
> In addition it seems the pdf was encrypted (40-Bit RC4) with an empty
> password and says it's pdf version 1.5.
> Does this provide enough information or can i do anything else to help
> nailing this one down?
> I guess this might be a pdf document structure/feature that is not yet
> supported completely but at least pdfbox should throw an exception instead of
> failing "silently"...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2350) Type1 Parser hangs indefinitely
[
https://issues.apache.org/jira/browse/PDFBOX-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142825#comment-14142825
]
John Hewson commented on PDFBOX-2350:
-
That last commit should fix the problem, we now correctly handle the
zero-good-tokens case and print a warning that the font is damaged.
> Type1 Parser hangs indefinitely
> ---
>
> Key: PDFBOX-2350
> URL: https://issues.apache.org/jira/browse/PDFBOX-2350
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 2.0.0
> Environment: Windows 7, JDK 1.7.0_51-b13
>Reporter: Daniel Scheibe
> Attachments: PDFBOX-2350-289451-endless.pdf
>
>
> When rendering the first page of my pdf document the Type1Parser
> (org.apache.fontbox.type1.Type1Parser) hangs in a loop in
> {{parseBinary(byte[] bytes) throws IOException}}
> and "kills" our rendering pipeline. Please find the loop that hangs below:
> // find /Private dict
> while (!lexer.peekToken().getText().equals("Private"))
> {
> lexer.nextToken();
> }
> There is no token named "Private" ever in the list of returned tokens
> (they're empty all the time).
> Furthermore going deeper into the source code it seems the class reading the
> tokens (Type1Lexer) does never finally advance the buffer position and always
> returns an empty name token in the readToken(Token prevToken) method.
> Looking at the decrypted buffer i cannot get something useful out of it based
> on my current understanding.
> Unfortunately i cannot provide the pdf in question as it contains confidental
> data.
> Acrobat Reader XI Version 11.0.08 renders the document just fine.
> In addition it seems the pdf was encrypted (40-Bit RC4) with an empty
> password and says it's pdf version 1.5.
> Does this provide enough information or can i do anything else to help
> nailing this one down?
> I guess this might be a pdf document structure/feature that is not yet
> supported completely but at least pdfbox should throw an exception instead of
> failing "silently"...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [DISCUSS] move documentation and examples to git
> Now, that’s a different issue Actually, it’s what I said 5 emails back in this thread: >> The problem with that approach is that GitHub’s pull requests can only be >> managed via GitHub’s issues interface, so we’re forced to use it. There’s no >> way to prevent GitHub users from opening and discussing issues in pull >> requests rather than on JIRA. > It may or may not be an issue in practice I cited examples of this happening in existing Apache projects on GitHub to show that this is an issue in practice. It happens. > It’s not a show stopper in my opinion. It would be something which we’d have to police very strictly and ideally should be automated. There’s a certain amount of administrative hassle which this creates which is unavoidable. There’s another potential issue too, thinking about it: currently all commit messages are prefixed with a JIRA issue number but commits made by GitHub users in PRs are likely to forget this, which would require all commits in the PR to be modified. Additionally GitHub users often open PRs with dozens of small commits which in most cases we’d want to be “squashed” into a single commit - we’ll need a strong policy on handling this and enough knowledge to help users get their PRs up to our quality standards. -- John On 21 Sep 2014, at 18:19, Maruan Sahyoun wrote: > Am 21.09.2014 um 23:57 schrieb John Hewson : > >> The problem is that PRs can be opened without JIRA ticket IDs attached to >> them, and the projects you linked to show this happening on many occasions. >> > > Now, that’s a different issue and I don’t know if there is a solution to > prevent that. It may or may not be an issue in practice. Apache Camel and > other projects are accepting this situation and for PDFBox is might also be > acceptable. It’s not a show stopper in my opinion. > > BR > Maruan > > >> The integration you mention looks pretty good though - linking PRs to JIRA >> issues is what we want. But we need to have some way to prevent PRs from >> being opened which don’t have JIRA issue IDs attached. >> >> -- John >> >> On 21 Sep 2014, at 13:31, Maruan Sahyoun wrote: >> >>> e.g. Apache Camel does use JIRA for issue tracking. They are not using >>> GitHubs issue management. And they do accept pull requests. >>> >>> And from the infra blog >>> https://blogs.apache.org/infra/entry/improved_integration_between_apache_and >>> >>> Any Pull Request that gets opened, closed, reopened or commented on now >>> gets recorded on the project's mailing list >>> If a project has a JIRA instance, any PRs or comments on PRs that include a >>> JIRA ticket ID will trigger an update on that specific ticket >>> >>> I don’t get your point. >>> >>> BR >>> >>> Maruan >>> >>> Am 21.09.2014 um 21:42 schrieb John Hewson : >>> > I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache > Tomee, Apache Cordova to mention some can handle it we should be smart > enough to handle it too. None of those projects make use of file attachments for issues the way that we do. > I can’t see the issues tab for these projects but pull requests. Is exactly my point - we’re forced to use GitHub issues for pull requests, which is a problem because then we don’t get to manage these via JIRA. Looking at these projects all of them have had pull requests which do not contain any references to JIRA issues but have been merged in, so it seems certain that we would loose JIRA as a central point of information. -- John On 20 Sep 2014, at 04:24, Maruan Sahyoun wrote: > I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache > Tomee, Apache Cordova to mention some can handle it we should be smart > enough to handle it too. And I can’t see the issues tab for these > projects but pull requests. > > BR > Maruan > > Am 20.09.2014 um 04:22 schrieb John Hewson : > >>> Issue tracking would still be done using Jira. Same as for most other >>> Apache projects >> >> The problem with that approach is that GitHub’s pull requests can only >> be managed via GitHub’s issues interface, so we’re forced to use it. >> There’s no way to prevent GitHub users from opening and discussing >> issues in pull requests rather than on JIRA. >> >> -- John >> >> On 17 Sep 2014, at 21:58, Maruan Sahyoun wrote: >> >>> >>> >>> Maruan Sahyoun >>> Am 18.09.2014 um 02:03 schrieb John Hewson : I agree with Tilman on this point, the examples need to stay in the trunk where they can be built along with it. It’s very common to modify an example to take into account API changes. They’re also currently distributed along with the main PDFBox source bundle, which is a good thing. I’d be surprised if anybody outside
[jira] [Commented] (PDFBOX-2374) Make JavaDocs for trunk builds available via our website
[ https://issues.apache.org/jira/browse/PDFBOX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142833#comment-14142833 ] John Hewson commented on PDFBOX-2374: - But then we have to update all our existing 1.8 documentation to fit into the new website, this is really wasted effort. Just archive the existing site and link to it. We've already decided to push users strongly away from 1.8 after 2.0 is released, presenting 1.8's documentation alongside 2.0 in the same menu is not in keeping with this approach. > Make JavaDocs for trunk builds available via our website > > > Key: PDFBOX-2374 > URL: https://issues.apache.org/jira/browse/PDFBOX-2374 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.0.0 >Reporter: Maruan Sahyoun > Fix For: 2.0.0 > > > In order to help people using the latest trunk versions of PDFBox the > JavaDocs for the main project and the sub projects shall be made available on > our website. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2350) Type1 Parser hangs indefinitely
[
https://issues.apache.org/jira/browse/PDFBOX-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142945#comment-14142945
]
Tilman Hausherr commented on PDFBOX-2350:
-
[~daniel.scheibe] please give feedback whether your problem has been solved.
> Type1 Parser hangs indefinitely
> ---
>
> Key: PDFBOX-2350
> URL: https://issues.apache.org/jira/browse/PDFBOX-2350
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 2.0.0
> Environment: Windows 7, JDK 1.7.0_51-b13
>Reporter: Daniel Scheibe
> Attachments: PDFBOX-2350-289451-endless.pdf
>
>
> When rendering the first page of my pdf document the Type1Parser
> (org.apache.fontbox.type1.Type1Parser) hangs in a loop in
> {{parseBinary(byte[] bytes) throws IOException}}
> and "kills" our rendering pipeline. Please find the loop that hangs below:
> // find /Private dict
> while (!lexer.peekToken().getText().equals("Private"))
> {
> lexer.nextToken();
> }
> There is no token named "Private" ever in the list of returned tokens
> (they're empty all the time).
> Furthermore going deeper into the source code it seems the class reading the
> tokens (Type1Lexer) does never finally advance the buffer position and always
> returns an empty name token in the readToken(Token prevToken) method.
> Looking at the decrypted buffer i cannot get something useful out of it based
> on my current understanding.
> Unfortunately i cannot provide the pdf in question as it contains confidental
> data.
> Acrobat Reader XI Version 11.0.08 renders the document just fine.
> In addition it seems the pdf was encrypted (40-Bit RC4) with an empty
> password and says it's pdf version 1.5.
> Does this provide enough information or can i do anything else to help
> nailing this one down?
> I guess this might be a pdf document structure/feature that is not yet
> supported completely but at least pdfbox should throw an exception instead of
> failing "silently"...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
