[
https://issues.apache.org/jira/browse/PDFBOX-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14550836#comment-14550836
]
ASF subversion and git services commented on PDFBOX-2805:
---------------------------------------------------------
Commit 1680354 from [~jahewson] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1680354 ]
PDFBOX-2805: Restore original field size
> Incorrect CapHeight calculation and usage in form fields
> --------------------------------------------------------
>
> Key: PDFBOX-2805
> URL: https://issues.apache.org/jira/browse/PDFBOX-2805
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm, PDModel
> Affects Versions: 2.0.0
> Reporter: John Hewson
>
> I discovered that the CapHeight value was being incorrectly calculated by
> TrueTypeEmbedder. Fixing this has a knock-on effect for CreateFormField,
> which uses that value for vertical text positioning, after the fix, it no
> longer works correctly.
> I took a look at this and the problem is that CapHeight isn't the right value
> to use when calculating text positioning for form fields. I've never seen the
> CapHeight used in a typographical setting and its use is unorthodox. I did an
> experiment by modifying the embedded CapHeight and I can confirm that Acrobat
> *does not* use it when calculating the position of form field text.
> The natural choice for text positioning in form fields would be to use either
> the depth of the font's bbox or the descender. Some experiments with Acrobat
> show that the bbox's depth yield the best results. There's still a slight
> difference of around 0.02pt which is unaccounted for when compared to
> Acrobat, but this is still an improvement on the previous, now broken code
> which used the CapHeight.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
