Hi,

I'm feeling a little stupid here trying to figure out what comma is out of the place that makes some of my //PDFX commands being interpreted as literal text instead of PDFX commands.

Here are the code snippet where I use them:
The commands between the -----> marks are not interpreted as PDFX commands so, are printed as literal text, the commands above and after those marks are ok.

Can it be any outdated module or PDFX driver?
I'm at 6.4.154.2 A-Shell version, I have ashnet.dll in the bin folder and the current PDFX driver.

Any tip?

Thanks

Hi Jorge,

The short answer is that it has nothing to do with quotes. But if you change "Email.Method,4" to "Email.Type,4" I think it will work.

The long answer is: I'm not sure why it doesn't like "Method" (which is the new name for the old "Type" attribute), but it's either a documentation bug or a software bug; in either case I'm investigating...

After through all of my PDFX examples and all of my source code, I can't find any reference to "Email.Method" anywhere. (Everything is "Email.Type".) So it looks to me like a planned change that was documented but never implemented. And apparently no one noticed because they've all been using the same syntax and programs developed previously.

I need to review it all before deciding if it makes more sense to update the code to match the documentation or vice versa.

Outch!!!!
Incredible how I didn't notice that slight difference, I was so focused in following the documentation that didn't realize what I've done using other Method/Type.
For me, it would be fine to just change documentation to .Type instead of .Method and thank you for noticing the detail

Waking this thread back up...

I fell into the same trap as Jorge. I had to change method to type. But just as an FYI 99.9% of the documentation including the examples refer to it as method. The only reference to type (that i saw) was in the Email Directives Summary under the PDFXv3 column (which i thought we were running v5?)

So i guess the question/point is, is the documentation wrong? Or is method just not working?

A brief history...

For whatever reason, the underlying PDFX driver terminology changed in the v5 update. (Worse, the entire architecture of the driver changed.) So it was an unexpectedly large project upgrading to it and maintaining compatibility with the older version. But it seemed important to do the upgrade in order to maintain forward compatibility.

In trying to sort out the changes in the underlying features and terminology, for better or worse we decided to migrate to the new terminology so that our implementation could be as transparently compatible as possible with the third-party API documentation. But that created the problem of having to support both the old and new terminology (converting the old to the new when applicable), which resulted in everything getting more complicated. And then to add insult to injury, in the case of the Types/Methods, not only did the name change, but the numbers did too, resulting in documentation pages like this.

Jorge's post above revealed that although internally the attribute is named "Email.Method", the GDI printing interface wasn't recognizing the new name. Realizing that was a software bug, I fixed it shortly thereafter, posting a 6.4.1548.1 update with the following in the ash64notes.txt ...
Obviously I failed to note that in this thread, which might have been helpful, because I suspect that you may not have been aware of the update/fix and may still be running an earlier version. If so, then the solution is either to update or to make a mental note that the documentation is misleading when dealing with versions prior to 1548.1.

In addition, it would be helpful if Ty added a note to the Email Methods topic clarifying this detail.

If you are running a newer version and it still appears that Email.Method is not being recognized, then either there is still a mixup in the code or some other misunderstanding that we should get to the bottom of.

Thanks for the reply.

It figures that i am running 6.4.1547.5 (ATE)

(Guessing this is an client-side update?)

It's a Windows-side update, which in your case means client-side. (In a Windows server environment, the PDFX operation could be taking place on the server or the client.)

But, you can get by without the update, at least in this respect, by sticking with Email.Type.

Didn't want to open a thread just for this public service announcement...

So:

Apparently if you add a colon (:) in the subject line, it truncates everything prior to the colon. I have remedied it on this side but just in case someone else comes along in say 20 or 30 years, they can wake this thread up and learn something

Appreciate the concern for your programming descendants, but I'm not sure I concur with you on the existing of the problem. I sent myself a message using this subject line:

//PDFX,Email.Subject,Test colon : long stuff : another colon

And it appears like this in my inbox:

I know the eyesight is going in my old age (no comment Herman) but didn't you just prove my point??

Where is the "Test colon : " in your actual inbox?

It did truncate everything prior to your first colon, did it not?

I'm not sure if I can blame this on failing eyesight, fatigue, or mere cognitive dissonance, but it appears that I got snookered by your use of truncated into thinking it was chopping off everything after the colon (when in fact if was everything prior to the first colon).

Unfortunately our in-house grammarian/etymologist is on the road today and I'm unable to come up with a better word than truncate to use for trimming something off the beginning rather than the end (left-truncate?).

For now let's leave it at: "Good observation on your part!"
Or "Look at the picture and ignore the words".

I'll see if I can figure out a workaround, and if not will at add a note to the doc.

Lol - well i never said how many colons i had in the subject line... Perhaps if you just tested with a single colon you would have seen the results!

No worries on this end, i just took off the colon.

FWIW: In this case, "...drops everything prior to the colon" might have been clearer.

To beat the dead horse... this was the orginal quote:

Apparently if you add a colon (:) in the subject line, it truncates everything prior to the colon.

Perhaps Truncate is only used with cutting off the "end" of something, however it can also mean to "shorten"

As much as it pains me to admit it, I'm afraid Frank is actually right here (even if the English language deserves part of the blame, and despite Stephen's wording being much less prone to misinterpretation by careless readers).

There really needs to be another word for cutting off the beginning, rather than the end, of something.

My ever-helpful daughter offers this brilliant suggestion, which I'm willing to pass on to anyone with the gumption to act on it:

"Well Dad, the solution is obvious -- all you need to do is come up with a word, and submit it to the dictionary!"

Not sure if that is a compliment or i should be offended (funny how often i ask myself that same question...)

Agreed - lets all create a new word. It can be our lasting gift to humankind...