Text Tag Extraction feature

Hi Alex, Are you using the document provided in the example or are you using your own? If it's the latter, can you share that document please?

Hi Haris, We are using the document provided in sdk. Of course, we've tried our own but it doesn't work as well..

Are you on the classic or new environment?

We are on the new environment. Btw, thank you for quick replies! We really appreciate it!

Np. And what is the error you are getting?

There are no any errors. Packages created/sent successfully but "text tags" are not replaced..

Can you share a package id so I can have a look? I'm curious because if the text tags weren't replaced, then you wouldn't have been able to send the package. And as an fyi, I just ran the code from https://developer.esignlive.com/guides/feature-guides/text-tags-extraction/ and it worked flawlessly for me. The text tags were replaced by the appropriate signatures and fields.

Sure, these are most recent packages: Draft: b2UzNPdLwVnN0saBiVGVKB76-08= Sent: EDsXoJ2MmZeG3QpO1tA6ZnqJD8M= Please note that both these packages created in sandbox.e-signlive.ca environment. I still think that it might not work because of “integrators only” note in release notes but support says that our accounts shouldn't have issues with it..

Again, it works for me on sandbox.e-signlive.ca. I looked at the two packages and I see signatures on the documents. You are an integrator so the release note should not be of concern to you :) I'm not sure however what the problem is here... If you access the package through the web ui, do you not see the signatures on the documents?

Heh, after your last reply, I decided to do something different and to not use .net sdk from github (including examples from it) and just create a new app. And looks like now it WORKS!!!! So, I'm assuming that github project is broken at the moment and that was the reason why we had so strange behavior. Btw, I'm not sure who is maintaining github project but there are quite a few issues with it. For example, I wasn't able to build it once I've cloned it. There are some missing references and broken code.. Also, do you guys plan to release a nuget package with .net sdk? Because right now there are different links in different places. For example, if you will start from Getting started page then you will get to the SDK Downloads page and you will see only v.11 sdk.. It can be little bit misleading..

And BIG THANK YOU for your help! : )

Unfortunately, we don't plan to release SDKs on nugget. It also seems that you are getting redirected to the old documentation site. I would advise you to look at these two resources: https://developer.esignlive.com/guides/feature-guides/ http://docs.esignlive.com/content/c_integrator_s_guide/introduction/integrator_s_guide.htm I will update the link on the getting started page. Thanks! :)

Thank you! Just curious, is there any particular reason why you don't plan to publish it on nuget? As far as I know, it doesn't take much time to create a nuget package and it will allow all of your clients to find sdk in one place (i.e. all links in documentation will always point to the right place)!

I believe we did for a while but stopped because we want everyone to get the SDK from our doc site. In your case, you found the one place where the link wasn't updated to the new documentation site :)

Ok, I see your point. But if your team will decide to evaluate this option one more time then you can check the following use case: in our team, the person who receives notifications about new versions is not the same who will update the project. As a result, the dev team might receive information about the new release with a delay. Plus, it is just easier to manage external references in one place than going to multiple sites and checking version numbers (we integrate with many systems, so we have quite a few references). Another reason is Newtonsoft.Json.dll. Right now you need to include it into the archive and it is an old version there. At the same time, your team will be able to just reference it in nuget package. And if you tried nuget many years ago, then it might work better for you now.. Hope I'm not too pushy on this : ) And thanks again for your help!

No worries.

Hello again, We are doing some final testing of this feature before pushing it to live version and we've found one issue: it is highly possible that text tag will be too long to fit on the line. For example, our users use fields in table cells and if we have something like {{?esl:signer1:textfield:size(80,30),offset(0,-15)}} then it is almost guaranteed that some part of this tag will go to a next line. Is there any solution to this issue? In addition, we've tested last week this feature with word document and it worked without issues. Unfortunately, looks like now it works only with pdf docs. Of course, we can convert docx to pdf, just curious why it was working before and doesn't work now.

Hi Alex, I just had a go using text tags with a word document and it worked fine on my end. Do you sharing your word document so I can run some tests? As for the text tags not fitting on the line, I can suggest the following two things: 1. make the font-size of the text tags smaller 2. with the flexibility of the offset parameter, you could put your text tag on the next line and use the offset to adjust it back to where you want your signature/field to be.

Hi Haris, > docx We've just tried it and it works again. The most strange thing is that we didn't change anything in code or document itself.. and now it works. I still attached the word document to this post. Do you have some kind of monitoring system to confirm that this feature reliable? Or maybe we just need to convert it to pdf just to be safe? > 1. make the font-size of the text tags smaller Hm, that is a good idea! I think we will use this suggestion! We will change font size to "1pt" and this should work in most cases. > 2. with the flexibility of the offset parameter, you could put your text tag on the next line and use the offset to adjust it back to where you want your signature/field to be. The issue is that we don't control documents. Our users create templates with special keywords and then the system replaces keywords with data or esl keywords. As you understand, this happens automatically, so we don't know when esl keyword will be too long..

We did many more tests and we've found that minimum font size is 3pt. If we set it to 1 then it ignores esl keywords.. And that is quite sad because font size 3 is not small enough to cover most of the cases. Do you think that there is another workaround for this issue? Btw, we still receive errors sometimes for docx documents but converting them to pdf works.

I still haven't gotten around to test your word document. I will do so tomorrow morning. As for other workarounds, I can't think of any. I mean depending on the font-type you choose, a font size 3 should be sufficient. If it isn't, then I would suggest putting a restriction on how long the key word would be so it doesn't get too long.

Don't worry about word document. It looks like it is not related to document. It is more like a random error because sometimes this doc works and sometimes it doesn't. As a result, we've decided that we can't trust to word documents and we will convert them to pdf. Regarding to font: after even more tests we've found that Parchment font with font size 4 works. Strangely enough, font size 3 doesn't work for this font. It is still only "workaround" for us because we can't control how much space end user left to the keyword and keywords can be big because of size, offset, value parameters. In fact, it makes almost impossible to use "value" parameter because it makes it very long. As an alternative solution, it would be nice if your team will add a small improvement to "TextAnchor". If you will just have a parameter like "ReplaceText" then it would be so amazing! Because in this case, we can have something like "anchor1" in the document and specify offset and other parameters via code. This would totally resolve all issues related to size, font and configuration. Hope your team will consider this feature..