[jira] [Commented] (PDFBOX-4157) Flatten ne positonne pas bien le 1er champs si Image avant
[ https://issues.apache.org/jira/browse/PDFBOX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404128#comment-16404128 ] Maruan Sahyoun commented on PDFBOX-4157: That part is based on files we got in the past - especially with "signature" images (PDFBOX-3396). So in order to change it we need a sample to verify what's happening in other tools and verify our result. > Flatten ne positonne pas bien le 1er champs si Image avant > -- > > Key: PDFBOX-4157 > URL: https://issues.apache.org/jira/browse/PDFBOX-4157 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.8 >Reporter: Chdeul >Priority: Minor > > Sur formulaire, avec une image et plusieurs champs textes, la méthode flatten > ne positionne pas bien le 1er champs de texte, car need translation est faux, > parce que la méthode RevolveNeedsTranslation trouve un Xobject, mais qui > est une Image, et pas un Xform. > Il faut donc modifier cette méthode pour prendre en compte aussi le cas des > images > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4157) Flatten ne positonne pas bien le 1er champs si Image avant
[
https://issues.apache.org/jira/browse/PDFBOX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404122#comment-16404122
]
Tilman Hausherr commented on PDFBOX-4157:
-
I think what he/she is meaning is that {{PDAcroForm.resolveNeedsTranslation}}
should return true if the field contains an image.
> Flatten ne positonne pas bien le 1er champs si Image avant
> --
>
> Key: PDFBOX-4157
> URL: https://issues.apache.org/jira/browse/PDFBOX-4157
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.8
>Reporter: Chdeul
>Priority: Minor
>
> Sur formulaire, avec une image et plusieurs champs textes, la méthode flatten
> ne positionne pas bien le 1er champs de texte, car need translation est faux,
> parce que la méthode RevolveNeedsTranslation trouve un Xobject, mais qui
> est une Image, et pas un Xform.
> Il faut donc modifier cette méthode pour prendre en compte aussi le cas des
> images
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4157) Flatten ne positonne pas bien le 1er champs si Image avant
[ https://issues.apache.org/jira/browse/PDFBOX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404120#comment-16404120 ] Tilman Hausherr commented on PDFBOX-4157: - Please attach your PDF / s'il vous plait, attachez votre PDF. > Flatten ne positonne pas bien le 1er champs si Image avant > -- > > Key: PDFBOX-4157 > URL: https://issues.apache.org/jira/browse/PDFBOX-4157 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.8 >Reporter: Chdeul >Priority: Minor > > Sur formulaire, avec une image et plusieurs champs textes, la méthode flatten > ne positionne pas bien le 1er champs de texte, car need translation est faux, > parce que la méthode RevolveNeedsTranslation trouve un Xobject, mais qui > est une Image, et pas un Xform. > Il faut donc modifier cette méthode pour prendre en compte aussi le cas des > images > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4157) Flatten ne positonne pas bien le 1er champs si Image avant
Chdeul created PDFBOX-4157: -- Summary: Flatten ne positonne pas bien le 1er champs si Image avant Key: PDFBOX-4157 URL: https://issues.apache.org/jira/browse/PDFBOX-4157 Project: PDFBox Issue Type: Bug Components: AcroForm Affects Versions: 2.0.8 Reporter: Chdeul Sur formulaire, avec une image et plusieurs champs textes, la méthode flatten ne positionne pas bien le 1er champs de texte, car need translation est faux, parce que la méthode RevolveNeedsTranslation trouve un Xobject, mais qui est une Image, et pas un Xform. Il faut donc modifier cette méthode pour prendre en compte aussi le cas des images -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2941) Improve PDFDebugger (2)
[
https://issues.apache.org/jira/browse/PDFBOX-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404073#comment-16404073
]
ASF subversion and git services commented on PDFBOX-2941:
-
Commit 1827147 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1827147 ]
PDFBOX-2941: don't lose benchmark result when mouse moves into PDF pane and out
> Improve PDFDebugger (2)
> ---
>
> Key: PDFBOX-2941
> URL: https://issues.apache.org/jira/browse/PDFBOX-2941
> Project: PDFBox
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
>Priority: Major
> Attachments: gs-bugzilla694570.pdf, keep_zoom.diff, osx-tabs.png,
> pdfdebugger-screenshot-reverted.png, pdfdebugger-screenshot-trunc.png,
> screenshot_debugger_new.png, screenshot_debugger_not_aligned.png,
> screenshot_debugger_old.png, screenshot_w7_fontsize.png,
> separate_filter_choice_from_text_hex_views.diff, sonar_qube_resolve.diff,
> sonar_qube_resolve_25_08.diff
>
>
> This is a follow-up issue to PDFBOX-2530 to implement extra ideas that came
> up in GSoC2015, ideas that were not implemented due to lack of time, and new
> ideas.
> *Viewing*
> - refactor PDFDebugger.java
> - render glyphs of fonts
> - ✓ refactor StreamPane to share stream filtering among Text view and hex view
> - ✓ password dialog when hitting protected PDF
> - show "pretty" XML
> - display filtered streams even if the unfiltered stream is corrupt
> (PDFBOX-2976)
> - ✓ display the "caused by" part exception stack trace (nested exceptions)
> - ✓ keep zoom
> - ✓ integrate DrawPrintTextLocations into rendering
> - integrate area text extraction with a mouse-created rectangle that shows
> the coordinates in a status line
> - ✓ show permission flags of {{Encrypt/P}} entry
> - ✓ show signature flags of {{Root/AcroForm/SigFlags}} entry, see Table 219
> in PDF spec
> - show page labels additional to page number (see file from TIKA-2121 as
> example)
> - ✓ "reopen" menu item (useful when editing an existing PDF to create a
> reduced PDF)
> - choose zoom automatically so that PDF page can be seen in full
> *Editing*
> - save modified PDFs
> - editing in hex viewer
> - remove nodes (e.g. elements from a COSDictionary)
> - delete array or dictionary elements
> - load content streams
> - edit & keep content streams
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4155) Password Security with Unicode needs SASLprep
[ https://issues.apache.org/jira/browse/PDFBOX-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-4155: Fix Version/s: (was: 2.0.9) > Password Security with Unicode needs SASLprep > - > > Key: PDFBOX-4155 > URL: https://issues.apache.org/jira/browse/PDFBOX-4155 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.8 >Reporter: Marc Kaufman >Priority: Minor > Labels: security > > Standard Security handler for Version 6 (AES256) handles Unicode passwords. > However the current handler is missing this part: > "The UTF-8 password string shall be generated from Unicode input by > processing the input string with the SASLprep (RFC 4013) profile of > stringprep (RFC 3454) using the Normalize and BiDi options, and then > converting to a UTF-8 representation." > SASLprep is required to normalize equivalent codings for complex glyphs (such > as those using umlauts, etc). > pdmodel/encryption/StandardSecurityHandler.java -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4156) Possible optimization of SampledImageReader.from8bit by using InterleavedRaster
Itai Shaked created PDFBOX-4156:
---
Summary: Possible optimization of SampledImageReader.from8bit by
using InterleavedRaster
Key: PDFBOX-4156
URL: https://issues.apache.org/jira/browse/PDFBOX-4156
Project: PDFBox
Issue Type: Improvement
Components: Rendering
Affects Versions: 2.0.8
Reporter: Itai Shaked
Attachments: interleaved_raster.patch
I noticed {{SampledImageReader.from8Bit}} assumed the source data to be
interleaved, which means if the target raster uses an interleaved sample model,
the data can by directly copied.
This can save 10-15% of total render time in files with large 8-bit images
(tested on samples from PDFBOX-2092 , PDFBOX-3791 and the file
"gs-bugzilla690022.pdf" from PDFBOX-4151).
In PDFBOX-2092 there is a discussion about how the sample model must be Banded,
but I couldn't find a place in the code that directly relies on this, and the
few tests I have run did not reveal problems. Perhaps the constraint is
obsolete, or else it means custom sample models cannot be used?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4071) Improve code quality (3)
[ https://issues.apache.org/jira/browse/PDFBOX-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403900#comment-16403900 ] ASF subversion and git services commented on PDFBOX-4071: - Commit 1827130 from [~msahyoun] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1827130 ] PDFBOX-4071: remove not needed intial assignment > Improve code quality (3) > > > Key: PDFBOX-4071 > URL: https://issues.apache.org/jira/browse/PDFBOX-4071 > Project: PDFBox > Issue Type: Task >Affects Versions: 2.0.8 >Reporter: Tilman Hausherr >Priority: Major > Attachments: pdfbox-screenshot-bad.png, pdfbox-screenshot-good.png > > > This is a longterm issue for the task to improve code quality, by using the > [SonarQube > report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor], > hints in different IDEs, the FindBugs tool and other code quality tools. > This is a follow-up of PDFBOX-2852, which was getting too long. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4134) Resolve floating point comparisons flagged by Sonar
[
https://issues.apache.org/jira/browse/PDFBOX-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403888#comment-16403888
]
ASF subversion and git services commented on PDFBOX-4134:
-
Commit 1827129 from [~msahyoun] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1827129 ]
PDFBOX-4134: fix typo leading to wrong comparison
> Resolve floating point comparisons flagged by Sonar
> ---
>
> Key: PDFBOX-4134
> URL: https://issues.apache.org/jira/browse/PDFBOX-4134
> Project: PDFBox
> Issue Type: Sub-task
>Affects Versions: 3.0.0 PDFBox
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
>
> Sonar is flagging floating point comparisons which are done using comparison
> operators. Using {{Float.compare}} this can be done in a standards way. In
> addition some comparisons might be done using a distance between two values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
