When presenting Microsoft Word with long field names it internally truncates them and numerates similar field names where necessary before displaying them to the user to place onto the page.
Now wioth Microsoft Word I can still supply the data with the original long field name and it will map them for me to its’ shortened version without any effort on my part. It also happens to remove ‘.’ and ‘/’ and maybe some others not tested, but again I don’t normally have to worry about that as Word takes care of it.
However Aspose.Word doesn’t take care of these field names like Microsoft Word does so the template expects a truncated field name which Word handles during the mail merge but Aspose doesn’t. Therefore all the long merge fields don’t get set in the mail merge.
It appears the fields get truncated at about 37 characters. It also strips out ‘.’ and ‘/’ and probably some others we haven’t tested. I think Aspose.Word should handle the fields in the same way Microsoft word handles them when creating the template or the templates will never be sure to work.
This is a problem seen at a customer site as they have some very long field names with ‘.’ and ‘/’ in them too, and we would like to see Aspose.Word corrected to treat them the same way as Microsoft Word does.
Do you follow that, and can you update Aspose.Word to do this please?
As I understand you want Aspose.Word to understand shortened version of the field name rather than full name as it happens now?
I see how Word truncates the field name and removes special characters, but I do not see how it numerates similar field names. Do you mean it appends number at the end of the field?
I don’t mind Aspose.Word supporting this feature, I will add it as an option (set to on as default to mimic Word behaviour closely), but I need to figure out details of the algorithm Word uses to shorten the field name to do exactly the same thing.
Numerating seems to be the only question left. Can you please email your document to email@example.com and explain what did you do to get Word to numerate field names?
Thank you for considering this. I have attached a sample Word template where Word has shortened the field name and numbers the similar fields. I have looked into it more and as you said it just appends a number to the end to make the shortened field name unique.
Word also removes special characters when creating the short field name. The ones we have noticed so far are “.” and “/” but I’m sure many other characters will also be stripped out too. This feature will be great as nobody will have to be concerned about long field names any more as Aspose can map them internally to the appropriate short field names to match what Word expects. It is a shame Word does this - I think it is a flaw in Word but unfortunately we all have to live with it and if Aspose.Word can work in the same way that would be ideal - an option to set it in this mode would be fine thanks It seems that the right place for this code to be implemented would be in Aspose.Word and everyone can benefit from it as I’m sure others will start to notice this sometime soon.
It seems to strip out the special characters, then truncate to 37 characters then for any short names that end up the same it appends the next available number to the end to make it unique. I think that is all there is to it but need to try all the characters on the keyboard to see what it removes (inc GBP ￡). Thank you.
I understand that MS Word strips special characters from field names and I can implement support for this, but only if I understand why anyone wants to put special characters into field names in the first place?
The numeration issue I think cannot be resolved. There is no way Aspose.Word can reliably shorten long field names into numerated field names because you could have them out of order in the document. I don’t understand how it could possibly work and also my Word XP does not numerate fields, it just truncates their names.
Can you change your field names?
We are using Word XP too. When presenting it with logn field names that have the first 37 characters the same and the last few different, it truncates to 37 characters and realizes that they are no longer unique so puts a unique number on the end of the duplicates in the order they are given to Word.
We present Word with the merge fields in the same order as we present the field data so getting them in the wrong order is not going to happen for us at least.
As for why we may have long field names and special characters - the special characters depend on what the database field names have and also how long the field names are in the database. Some customers have some really long fields with some non-alphanumeric characters and this is what causes the problems.
Also with having duplicate short field names, this is caused when 2 or more fields have the same long prefix but with just a little bit at the end that distinguish one from another. It happens.
I figured that although MS has caused this problem by truncating and stripping out characters in MS Word, if you want your Mail Merge to work reliably with Word templates then you would want to imitate this behaviour as MS Word handles it fine - it truncates and renumbers as necessary in the same order. It does not seem all that difficult to me and would logically be handled in the Aspose.Word component so people can switch to Aspose.Word from MS Word automation without finding these differences when installed on customer sites.
I agree and I’ll do it as an option on MailMerge object. Checkback in the next couple of days.
I don’t like that if you move fields around in the document after they’ve been numbered data will be inserted in wrong places by Aspose.Word. It would be very confusing, but you seem to be okay with that.
Maybe it will be better to allow you explicitly define mapping from long to short field names. i.e. put responsibility for establishing mappings onto the client rather than Aspose.Word trying to automatically figure them out and getting it wrong from time to time?
Ah I don’t think you quiote understood what I was explaining…
Basically our product adds the merge fields to a Word template programatically so they are added to the template in exactly the same order as the columns are in the DataTable. I don’t mean actually placing the fields on the page (as of course they will get moved around) but actually specifying the Merge Fields that are available in the template.
I believe that when specifying the fields in the order they appear in the DataTable is sufficient for Aspose.Word to be able to number them in the correct order as it seems Word must number them in that order - the same order the fields appear in the data. So if numbering the truncated similar fields in the order they appear in the DataTable.Columns that should do it.
If you don’t want to implement this functionality that is fine by me - I can always do it myself but it just seemed logical to me that Aspose.Word ought to do this to keep in line with the way Word sets up the templates.
I hope this makes sense
If you are happy then of course I’m not going to implement it.