Good Day -

According to the documentation, a single line of email.content can accomodate 1024 chars.

In our various testing, it seems that the outbound email is getting chopped at 502 chars. Looking at the raw file, it is correct (has all characters). So either PDFX is chopping it OR could it be that email services cannot accomdate a single wrapped line of 1024? Other appended lines of content, such as the added disclaimer line of "Please do not reply to this email..." is in the email, so i know it's not a problem of total message (32K).

I can email you the actual raw file to look at Jack, and/or even use PDFX to send you the example if that helps.

TIA

Hey Frank...

The good news is that I can confirm your observation/condition: when I print a very long line of body content in the email message, it is chopped of at, in my case, 492 characters. It will require some more digging to find out why that is--i.e., is the documentation wrong? is something interfering with normal processing? etc.

I assume that you actually need more than 500 characters per line. Given that we use a third-party library for PDFX, finding and fixing the problem may not be easy or even possible. What's the chance of you limiting body content lines to ~500 characters?

Hey Ty -

Thanks for the reply.

Glad you can concur on the findings. I would think 500 chars is acceptable here. If not, i could add a second content line, or i guess i can even parse the input line manually and if it's more than 500 add another content line. So it's not worth Jack burning too many brain cells... just wanted to determine if i was doing anything wrong, or right, for that matter

In the meantime i will just restrict the message line to 500 chars until somebody complains that it's not sufficient!

Good solution, Frank; thanks. If the 500 char limit is not an inconvenience for you, then great; problem solved. And let's go with that for now.

More testing reveals that the retail version of the library prints 1000+ characters without chopping. So it's possible that we're seeing an A-Shell or print directive issue which we can remedy. Will keep you posted. Thanks for the observation.

No worries, appreciate the feedback!

After a bit of poking around, I see that the approximately 512 byte limitation is not in the Email.Content, but in the length of the individual //GDI directives. As noted in the PDFX Email.Content documentation, multiple instances of the Email.Content directive are allowed, with which you can accumulate up to 32K of content. By default each Email.Content line will be a new line in the email, but you can also concatenate them to allow the email agent to format long paragraphs by ending each line with a backslash.

To confirm, I just sent my self this message containing over 5K of content text which arrived with all of the content intact ...

Sorry, got distracted from the original complaint about the 512 limit of individual Email.Content statements not matching the documentation. (The limitation applied to all // GDI directives, and wasn't specific to Email.Content or PDFX.)

In the next update I'll fix the code to increase that limit, either to match the documentation, or maybe exceed it (2048? 4096?).

The documentation should then probably be updated to note the change.

Gotit, thanks.

Thanks for the update... to followup is this a server or client side update?

Also per this documentation below you point out the the email.content can go > 1024... i wasn't sure if this is still the case... just want to verify, and get the new max.

Thanks.


============================================================================
A-Shell Release Notes Version 6.5.1665.1 (26 August 2019)
============================================================================
1. (Windows) GDI/PDFX bug fix/refinement: Remove the 512 byte limit on the
overall length of individual //GDI (including //PDFX) directives.

Note that this affects only the overall length of a single //GDI directive; it
does not affect any existing limits on the length of individual parameters.
Also note that previously the PDFX doc indicated (incorrectly) that the limit
on an Email.Content directive was 1024.

Good day -

No hurry just reminding myself to get an answer to the above.

Thanks.

The new max for individual //PDFX,Email.Content lines is ... unlimited. Although the overall maximum for the combined Email.Content is 32K.

(I realize that doesn't make much logical sense, but the recent patch only addressed the 512 byte limit on the individual lines. I'd need to do some more research to determine whether that 32K limit was being imposed by the driver, or whether it still exists. Offhand though, it seems more than sufficient for a typical email message. Beyond that, you'd probably want to handle it as an attachment. But you be the judge...)

Thanks - no i get it... not addressing the 32K message limit, just the limit on an individual content line.

I have to followup however, in that the PDFX documentation itself says the limit is 1024 bytes. Ty says it might be 2048 i think per the developer specs?

Either way i just want to map out my line properly. If you say its unlimited, i might opt for a limit of 2048 which is fairly long for a message.

Also - server side? or just client / ATE?

We determined that the PDFX documentation was wrong. As of 6.5.1665.1 you can go with 2048 if you like, at least for the Email.Content lines. (It's possible, and indeed likely, that there are smaller limits on some of the other directives, but this is probably the only one where you would be tempted to pass more than a couple hundred characters.)

PDFX directives can only be interpreted under Windows, so it's primarily client-side. (The one server-side scenario would be ATE to an ATSD Windows server, where the server had direct access to a PDFX printer.)

Thanks.