Hi Tilman!

So, it develops that the fax service has an upper limit of 4 Mb per
individual uploaded file. So I will probably try to implement your PDFSplit
solution (I tried compressing the file but was unable to get it under 4 Mb).

I am concerned about memory and processing time for the PDFSplit but the
fax service seems unwilling to contemplate fixing this on their end (their
actual render works fine with the form, it is just their API layer that
imposes the limit).

I will tell you how it works out and follow up with any questions that I
might have.

Thank you so much for taking the time to respond with your excellent
suggestion.

On Fri, Mar 3, 2017 at 12:35 PM, Tilman Hausherr <[email protected]>
wrote:

> Am 03.03.2017 um 14:31 schrieb Evan Williams:
>
>> The first sign of trouble is, various PDF renderers in browsers were
>> displaying fields that had been filled in as blank (intermittently).
>> Chrome's PDF viewer was one such culprit. Need Appearances was set to true
>> with this form, so I set it to False and refreshed the appearances, which
>> may or may not have fixed it (if it doesn't I will do a full flatten on
>> it).
>>
>> More seriously, the faxing service that we use chokes on this form. They
>> are unable to render it even if I don't fill it out and send them the
>> original PDF. They are investigating this on their end, but since this is
>> the only PDF that has ever had this issue and because of its previous
>> suspicious behavior, I believe that it might be corrupt in some subtle way
>> that I don't understand. PDFBox seems to have no trouble working with it,
>> and it is viewable and printable in Acrobat and in third party viewers.
>> But
>> I am uncertain.
>>
>
> It would be useful to have a version of this PDF with entries and then see
> what happens with Chrome. And then pass that one there.
>
> Re that fax service, try PDFSplit to split it in single pages, and then
> try with every single page. That should narrow the problem.
>
> PDF is a complex format... there are many (including us) that don't
> implement all. Normally this shouldn't lead to a crash.
>
> Tilman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


-- 
*Evan Williams*
Sr. Software Engineer
[email protected]

*www.ZappRx.com <http://www.zapprx.com/>*

Reply via email to