[jira] [Created] (PDFBOX-5689) Many new warnings "newGlyph ... newValue: ... is trying to override the oldValue" after upgrade to V3.0.0
Jorge moraleda created PDFBOX-5689:
--
Summary: Many new warnings "newGlyph ... newValue: ... is trying
to override the oldValue" after upgrade to V3.0.0
Key: PDFBOX-5689
URL: https://issues.apache.org/jira/browse/PDFBOX-5689
Project: PDFBox
Issue Type: Bug
Components: FontBox
Affects Versions: 3.0.0 PDFBox
Reporter: Jorge moraleda
I upgraded a maven project from PDFBox 2.x to 3.0.0. I am running Linux Debian
stable up to date.
Now on initialization, many (hundreds, thousands?) warnings lines appear of the
form:
{{o.a.f.t.g.GlyphSubstitutionDataExtractor : For the newGlyph: 573, newValue:
[556, 600, 563] is trying to override the oldValue: 573}}
The actual numbers are different in each warning.
The severity is low, since the application still works, but I wonder if
thousands of these warnings is really a desirable behavior. I assume the
problem is with some font(s) I have installed in my system but even so, the
warnings did not appear on PDFBox 2.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5689) Many new warnings "newGlyph ... newValue: ... is trying to override the oldValue" after upgrade to V3.0.0
[
https://issues.apache.org/jira/browse/PDFBOX-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770762#comment-17770762
]
Jorge moraleda commented on PDFBOX-5689:
Thank you! Impressive speed!
> Many new warnings "newGlyph ... newValue: ... is trying to override the
> oldValue" after upgrade to V3.0.0
> -
>
> Key: PDFBOX-5689
> URL: https://issues.apache.org/jira/browse/PDFBOX-5689
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
>Affects Versions: 3.0.0 PDFBox
>Reporter: Jorge moraleda
>Assignee: Tilman Hausherr
>Priority: Minor
> Fix For: 3.0.1 PDFBox, 4.0.0
>
>
> I upgraded a maven project from PDFBox 2.x to 3.0.0. I am running Linux
> Debian stable up to date.
> Now on initialization, many (hundreds, thousands?) warnings lines appear of
> the form:
> {{o.a.f.t.g.GlyphSubstitutionDataExtractor : For the newGlyph: 573, newValue:
> [556, 600, 563] is trying to override the oldValue: 573}}
> The actual numbers are different in each warning.
> The severity is low, since the application still works, but I wonder if
> thousands of these warnings is really a desirable behavior. I assume the
> problem is with some font(s) I have installed in my system but even so, the
> warnings did not appear on PDFBox 2.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5807) JPEGFactory. Reduce logging severity when no image metadata is present
Jorge moraleda created PDFBOX-5807: -- Summary: JPEGFactory. Reduce logging severity when no image metadata is present Key: PDFBOX-5807 URL: https://issues.apache.org/jira/browse/PDFBOX-5807 Project: PDFBox Issue Type: Improvement Components: FontBox Affects Versions: 3.0.2 PDFBox, 2.0.31 Reporter: Jorge moraleda -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5807) JPEGFactory. Reduce logging severity when no image metadata is present
[
https://issues.apache.org/jira/browse/PDFBOX-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge moraleda updated PDFBOX-5807:
---
Description:
Currently when the image size cannot retrieved from metadata we issue:
`LOG.warn("No image metadata, will decode image and use raster size");` and
`LOG.warn("Error reading image metadata, will decode image and use raster
size", ex);` both at the warning level, but since these are recoverable errors
(by using the raster size, as the messages indicate, I think their priority
should be reduced to `info` or `debug`. This is particularly important in the
second message since we actually go ahead and print the full stack trace, which
heavily pollutes log files.
I use JPEGFactory inside a server side application without control from which
files the user uploads, and it is irksome to get all those irelevant stack
traces.
Thank you.
> JPEGFactory. Reduce logging severity when no image metadata is present
> --
>
> Key: PDFBOX-5807
> URL: https://issues.apache.org/jira/browse/PDFBOX-5807
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox
>Affects Versions: 2.0.31, 3.0.2 PDFBox
>Reporter: Jorge moraleda
>Priority: Minor
>
> Currently when the image size cannot retrieved from metadata we issue:
> `LOG.warn("No image metadata, will decode image and use raster size");` and
> `LOG.warn("Error reading image metadata, will decode image and use raster
> size", ex);` both at the warning level, but since these are recoverable
> errors (by using the raster size, as the messages indicate, I think their
> priority should be reduced to `info` or `debug`. This is particularly
> important in the second message since we actually go ahead and print the full
> stack trace, which heavily pollutes log files.
> I use JPEGFactory inside a server side application without control from which
> files the user uploads, and it is irksome to get all those irelevant stack
> traces.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5807) JPEGFactory. Reduce logging severity when no image metadata is present
[
https://issues.apache.org/jira/browse/PDFBOX-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorge moraleda updated PDFBOX-5807:
---
Description:
Currently when the image size cannot retrieved from metadata we issue:
{code:java}
LOG.warn("No image metadata, will decode image and use raster size");
{code}
and
{code:java}
LOG.warn("Error reading image metadata, will decode image and use raster size",
ex);{code} both at the *{{warn}}* level, but since these are recoverable errors
(by using the raster size, as the messages indicate), I think their log
priority should be reduced to *{{info}}* or *{{debug}}*. This is particularly
important in the second message since it actually prints the full stack trace,
which heavily pollutes log files.
I use JPEGFactory inside a server side application without control from which
files the user uploads, and these stack traces are useless and distracting.
Thank you.
was:
Currently when the image size cannot retrieved from metadata we issue:
`LOG.warn("No image metadata, will decode image and use raster size");` and
`LOG.warn("Error reading image metadata, will decode image and use raster
size", ex);` both at the warning level, but since these are recoverable errors
(by using the raster size, as the messages indicate, I think their priority
should be reduced to `info` or `debug`. This is particularly important in the
second message since we actually go ahead and print the full stack trace, which
heavily pollutes log files.
I use JPEGFactory inside a server side application without control from which
files the user uploads, and it is irksome to get all those irelevant stack
traces.
Thank you.
> JPEGFactory. Reduce logging severity when no image metadata is present
> --
>
> Key: PDFBOX-5807
> URL: https://issues.apache.org/jira/browse/PDFBOX-5807
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox
>Affects Versions: 2.0.31, 3.0.2 PDFBox
>Reporter: Jorge moraleda
>Priority: Minor
>
> Currently when the image size cannot retrieved from metadata we issue:
> {code:java}
> LOG.warn("No image metadata, will decode image and use raster size");
> {code}
> and
> {code:java}
> LOG.warn("Error reading image metadata, will decode image and use raster
> size", ex);{code} both at the *{{warn}}* level, but since these are
> recoverable errors (by using the raster size, as the messages indicate), I
> think their log priority should be reduced to *{{info}}* or *{{debug}}*. This
> is particularly important in the second message since it actually prints the
> full stack trace, which heavily pollutes log files.
> I use JPEGFactory inside a server side application without control from which
> files the user uploads, and these stack traces are useless and distracting.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5807) JPEGFactory. Reduce logging severity when no image metadata is present
[
https://issues.apache.org/jira/browse/PDFBOX-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840468#comment-17840468
]
Jorge moraleda commented on PDFBOX-5807:
[~tilman] Thank you. I would be happy with keeping the second message at the
warning but removing the stack trace.
> JPEGFactory. Reduce logging severity when no image metadata is present
> --
>
> Key: PDFBOX-5807
> URL: https://issues.apache.org/jira/browse/PDFBOX-5807
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox
>Affects Versions: 2.0.31, 3.0.2 PDFBox
>Reporter: Jorge moraleda
>Priority: Minor
>
> Currently when the image size cannot retrieved from metadata we issue:
> {code:java}
> LOG.warn("No image metadata, will decode image and use raster size");
> {code}
> and
> {code:java}
> LOG.warn("Error reading image metadata, will decode image and use raster
> size", ex);{code} both at the *{{warn}}* level, but since these are
> recoverable errors (by using the raster size, as the messages indicate), I
> think their log priority should be reduced to *{{info}}* or *{{debug}}*. This
> is particularly important in the second message since it actually prints the
> full stack trace, which heavily pollutes log files.
> I use JPEGFactory inside a server side application without control from which
> files the user uploads, and these stack traces are useless and distracting.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
