Thank you again.
I looked at MultilineFields.pdf in a text editor but it seems to be
linearized with all the streams compressed -- I can't make much sense
of it. Is there some convenient tool to emit a "human-readable"
version with all the streams decompressed, without altering any of the
object IDs or anything?
I recall once before using some kind of PDF analysis tool that dumped
out a lot of information, but it produced sort of a diagnostic log.
What I'd really like is a tool that produces a completely legitimate
PDF -- pretty much the same as the original file, just with no
compression.
Thanks,
Aaron
On Sun, Jul 24, 2016 at 10:34 AM, Maruan Sahyoun <sahy...@fileaffairs.de> wrote:
> Hi Aaron,
>
>> Am 24.07.2016 um 16:24 schrieb Aaron Mulder <ammul...@gmail.com>:
>>
>> OK, thanks. The font is just the standard Helvetica so it should not
>> need to be embedded;
>
> If you need to support languages other than western text Arial (or Arial
> Unicode for a much larger coverage) might be a better option as they support
> more characters.
>
>> I just need to specify the appropriate point size
>> in order for the text to fit in the available space.
>
> If you specify the font size then this should be taken. If you'd like to fit
> the text into the form field specify a font size of 0 (zero) for auto scaling.
>
>>
>> Some of the fields are multiline text fields ("text areas"). For
>> those fields, do I need to manually line-break the text that I'm going
>> to put in those fields in order to lay out the text in the appearance
>> stream appropriately?
>
> that shouldn't be necessary - but include line-breaks where you'd like to
> have new paragraphs.
>
> You can take a look at the AlignmentTest.pdf and MultilineFields.pdf
> documents in
> pdfbox/src/test/resources/org/apache/pdfbox/pdmodel/interactive/form/. The
> lower half is prefilled by Adobe Acrobat to see how a filled out form should
> look like. If you run the unit tests you'll also see how PDFBox fills these
> fields (the upper half).
>
>> I guess I am assuming that I will need to do
>> that, though I suppose I'll find out shortly. :)
>
> BR
> Maruan
>
>>
>> Thanks,
>> Aaron
>>
>> On Sun, Jul 24, 2016 at 10:16 AM, Maruan Sahyoun <sahy...@fileaffairs.de>
>> wrote:
>>> Hi,
>>>
>>>> Am 24.07.2016 um 14:35 schrieb Aaron Mulder <ammul...@gmail.com>:
>>>>
>>>> I am filling out a form on an existing PDF document. The base
>>>> document has /NeedAppearances true and the result is that the text
>>>> looks different on every viewer. For instance, on some the text is
>>>> offset vertically or the text is cut off when using a font that works
>>>> fine on a different viewer.
>>>>
>>>> I gather the solution to this is to set /NeedAppearances to false and
>>>> provide an appearance stream for every field. I don't know much about
>>>> appearance streams.
>>>>
>>>> In looking at the output of the PDFBox examples, it seems that the
>>>> appearance stream actually writes the field's value as text, e.g. for
>>>> the form containing the text "Sample field" the appearance stream is:
>>>>
>>>> /Tx BMC
>>>> q
>>>> 1 1 198 48 re
>>>> W
>>>> n
>>>> BT
>>>> /Helv 12 Tf
>>>> 2 20.692 Td
>>>> (Sample field) Tj
>>>> ET
>>>> Q
>>>> EMC
>>>>
>>>> Is there a way to not include the specific text in the appearance
>>>> stream such that if the user changes the value in the field then the
>>>> appearance stream will still work?
>>>
>>> If the field has a value then this value will be part of the appearance
>>> stream. But that doesnÄt mean that the value can not change. When the user
>>> enters new text then the viewer will recalculate the appearance stream and
>>> the new text will replace the old one.
>>>
>>>>
>>>> Really all I want from the appearance stream is to specify the font
>>>> and bounds and offset such that the text is in exactly the same place
>>>> on every viewer and the same font size fits into the available space
>>>> on every viewer.
>>>
>>> The font (/Helv in your example) and font size (12 in your example) are
>>> part of the fields properties and specified in the default appearance
>>> string. This will make it into the appearance stream. Unfortunately setting
>>> such as bounds and offset are not part of the PDF specification but
>>> implementation specific. So you might get different results with different
>>> viewers.
>>>
>>> One thing you should also ensure is that the fonts used for forms filling
>>> are embedded in the PDF so that all viewers can use the same font.
>>>
>>>
>>>>
>>>> And one more question -- the document has let's say 200 fields, and I
>>>> only populate maybe 50 of them. If I specify appearance streams for
>>>> *only* the ones I populate, will that work? If that's the case,
>>>> should /NeedAppearances be set to true or false?
>>>
>>> If the appearance stream for the filled out fields is defined then you
>>> should set /NeedAppearances to false (or remove the key completely).
>>>
>>> BR
>>> Maruan
>>>
>>>>
>>>> Thanks,
>>>> Aaron
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
>>>> For additional commands, e-mail: users-h...@pdfbox.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
>>> For additional commands, e-mail: users-h...@pdfbox.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
>> For additional commands, e-mail: users-h...@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: users-h...@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
