Chilkat v220.127.116.11 Release Notes
Previous Version: https://cknotes.com/chilkat-v9-5-0-92-release-notes/
Chilkat v18.104.22.168 Release Notes
- PDF: Fixed more issues with LTV signatures, where sometimes Acrobat DC did not consider the signed PDF Long Term Validation enabled.
- PDF: Added the AddVerificationInfo method. This is performs the same function as in Adobe Acrobat when right-clicking on a signature and selecting “Add Verification Information”.
- MailMan: Fixed office365.com TLS connection problems.
- Chilkat .NET Core NuGet package now built for .NET 6 or higher.
- Added Chilkat .NET Core 3.1 NuGet package at https://www.nuget.org/packages/ChilkatDnCore31 for apps still using .NET Core 3.1 or higher.
- PureBasic on MacOS M1 – Some problems fixed, but still remains unusable on this MacOS architecture. Will fix remaining problems ASAP.
- Zip: Fixed: Updating and entry’s comment did not work correctly. This is when a .zip is opened, the entry within the .zip is found, the comment updated, and zip re-saved.
- PDF: Fixed Brasil ICP signature problems to make the signed PDF pass the verifier at https://verificador.iti.gov.br/verifier-2.10/
Note: The signed PDF produced by Chilkat was technically valid, but did not have the optional features and/or did not do things in the specific way desired by Brasil ICP.
- PDF: Fixed signing to produce signed PDF’s conforming to the needs of EU requirements and validated at https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation
Note: The signed PDF produced by Chilkat was technically valid, but did not have the optional features and/or did not do things in the specific way desired by EU validator.
Also important: A signed PDF produced for the EU validator’s needs would likely not satisfy the Brasil ICP’s needs, and vice-versa.
If the signed PDF does not satisfy your government’s validator, contact Chilkat and we can determine what is needed by comparing a signed PDF that satisfies a particular validator vs one produced by Chilkat. Also, it may be that (in your particular case) Chilkat still does not produce signed PDF’s that satisfy the above validators. This means that Chilkat did not auto-recognize the need to produce the signed PDF in that way, and the solution is to set special JSON config options, or contact Chilkat so we can add your case for auto-recognition.
- Ftp2: Fixed MGetFiles with wildcard input for certain FTP servers that don’t allow for the LIST command with wildcards.
- MinGW: Added builds for the latest MinGW versions: 9 and 10. Removed older builds that are most likely never used. (If the build you need was removed, you can contact Chilkat and we can re-establish it.)
- Go Lang: Added the corresponding MinGW-w64 version 9 and 10 native “C” libs for Go.
- Ssh: Programs that called ssh.QuickCommand many times in a loop would accumulate memory. The memory would be deallocated if the Chilkat SSH object was destructed, so it wasn’t technically a leak. This was fixed so that memory consumption does not accumulate.
- PDF: Fixed problems loading certain rarely encountered PDF’s using internal compression with non-standard settings.
- StringBuilder: Added the AppendUuid method for convenience.
- Python 3.11: Now supported.
- CkCache: Fixed a problem with the CkCache.UpdateExpirationDt method.
- Twitter: Fixed OAuth1 authentication problems.
- SFTP: Fixed problems with “Window size is running low” when communicating with old SSH-2.0-CoreFTP-0.3.2 servers.
- CSV: Found that for CSV’s using utf-8, the utf-8 BOM (byte order mark) must be present for Microsoft Excel to recognize the utf-8 encoding. Added an uncommon option to tell Chilkat to emit the BOM:
- CkDateTime: The GetAsIso8601 method did not return the ISO-8601 formatted date/time correctly for dates before the UNIX epoch (before Jan 1, 1970)
- Ftp2: When using implicit TLS connections (i.e. port 990), if the same object instance is used for multiple connections, then for the 2nd and subsequent connections, Chilkat failed to send the “PROT P” command and the server refuses the connection. This is fixed.
Post v22.214.171.124 Problem/Fix
Soon after v126.96.36.199 was released, several developers reported that HTTP path parts in GET, POST, PUT requests became URL-encoded for special chars, such as “#”, “:”, etc. For example:https://example.com/v2/token/session/:create?consumerToken=ey...
was sent as:https://example.com/v2/token/session/%3Acreate?consumerToken=ey...
Chilkat reverted back to the old behavior of NOT URL encoding the path parts. You’ll need a post-v188.8.131.52 build with this hotfix if you encounter problems relating to it. I would think most servers should accept both. After all, the SPACE char certainly needs URL encoding.