[
https://issues.apache.org/jira/browse/PDFBOX-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxime Veron updated PDFBOX-3841:
---------------------------------
Description:
I'm creating this bug report because I observed a particular behavior in PDFBox
parsing of text positions.
I used the command line tool (PrintTextPositions) to generate the text
positions and remove any code logic our application could have over PDFBox and
here is an extract of the result :
String[17.279999,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
width=3.9960938]-
String[21.6,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
width=5.999998]*
String[28.08,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
width=3.9960918]-
String[31.679998,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
width=3.000002]
The font size is reported as 50.0 (which is indeed contained in the PDF as 50)
but Adobe and other PDF viewers do not seem to take into account this font of
size 50 to render the text selection. Should we rely on another metric from the
text position, or could this font size be reported relative to the correct
appearance the text should have?
Best regards
was:
I'm creating this bug report because I observed a particular behavior in PDFBox
parsing of text positions.
I used the command line tool (PrintTextPositions) to generate the text
positions and remove any code logic our application could have over PDFBox and
here is an extract of the result :
String[17.279999,18.800049 fs=*50.0 *xscale=12.0 height=6.918 space=3.0
width=3.9960938]-
String[21.6,18.800049 fs=*50.0 *xscale=12.0 height=6.918 space=3.0
width=5.999998]*
String[28.08,18.800049 fs=*50.0 *xscale=12.0 height=6.918 space=3.0
width=3.9960918]-
String[31.679998,18.800049 fs=*50.0 *xscale=12.0 height=6.918 space=3.0
width=3.000002]
The font size is reported as 50.0 (which is indeed contained in the PDF as 50)
but Adobe and other PDF viewers do not seem to take into account this font of
size 50 to render the text selection. Should we rely on another metric from the
text position, or could this font size be reported relative to the correct
appearance the text should have?
Best regards
> OpenText - Exstream PDFs textual informations are recognized with erroneous
> font size
> -------------------------------------------------------------------------------------
>
> Key: PDFBOX-3841
> URL: https://issues.apache.org/jira/browse/PDFBOX-3841
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 1.8.12, 1.8.13
> Environment: Windows/Linux
> Reporter: Maxime Veron
> Priority: Minor
> Attachments: 436bc378-aa42-43e5-a4de-a0bbaf233f79-4.PDF vII.PDF
>
>
> I'm creating this bug report because I observed a particular behavior in
> PDFBox parsing of text positions.
> I used the command line tool (PrintTextPositions) to generate the text
> positions and remove any code logic our application could have over PDFBox
> and here is an extract of the result :
> String[17.279999,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
> width=3.9960938]-
> String[21.6,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
> width=5.999998]*
> String[28.08,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
> width=3.9960918]-
> String[31.679998,18.800049 fs=*50.0* xscale=12.0 height=6.918 space=3.0
> width=3.000002]
> The font size is reported as 50.0 (which is indeed contained in the PDF as
> 50) but Adobe and other PDF viewers do not seem to take into account this
> font of size 50 to render the text selection. Should we rely on another
> metric from the text position, or could this font size be reported relative
> to the correct appearance the text should have?
> Best regards
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
