A major advantage of GroupDocs.Comparison for .NET is its ability to tightly integrate with any .NET project. This integration gives an extra mark to your application or project. GroupDocs.Comparison for .NET 19.9 comes with a lot of breaking changes. The legacy API have been moved into Legacy namespace. So, when you update to this version it is required to make project-wide replacement of namespace usages from GroupDocs.Comparison. to GroupDocs.Comparison.Legacy to resolve build issues.
Below are the key reasons to use the new updated API since version 19.9:
Comparer class introduced as a single entry point to compare documents of any supported file format with various options and ability to accept/reject found differences in resultant document
Overall document related classes are unified to common
API architecture is redesigned from scratch in order to simplify passing options and classes to manipulate comparison
Document information and preview generation procedures are simplified
How to migrate?
Lets see briefly that how much things have been changed. Below is the code snippet that we used to write for documents comparison in older versions:
And given below is the most recent/updated code:
Is there any updated support material?
Yes, we have updated GitHub examples and documentation as well. Please download or clone latest example project and observe the difference yourself.
If you would face any issue while using or upgrading to the latest release, just post it on our forum and we will assist you.
Hello everyone! We have recently released version 19.9 of GroupDocs.Viewer for .NET with the support of new file formats as well as a number of bug fixes. So in this post, I am going to write about what is new in this release particularly for those who are interested in viewing Microsoft Project files (.mpp) using .NET API.
Microsoft Project is a famous project management software that is proved to be helpful for the managers as well as the other stakeholders in making, organizing, tracking and analyzing their project plans. The MS Project uses the MPP file format to store the data or information related to project management. Since MPP is the proprietary file format of Microsoft, you need to have MS Project installed to view .mpp files. However, if you want to view .mpp files in your web or desktop application without installing MS Project or if you are interested in creating your online MPP viewer then you can easily do it using our .NET document viewer API.
GroupDocs.Viewer for .NET supports viewing MPP format and the big news is that we have now extended this support for .mpp files created in MS Project 2019. So now you can view .mpp files without worrying about their versions. Also, there is no pubic API change for this, so you don’t need to change anything in the code if you have already embedded this feature in your application. If you are new and want to get more details on it along with the code samples, please visit Rendering MS Project Documents.
In addition, we have also added the support of viewing following file formats in v19.9:
OpenXPS (.oxps)
OpenDocument Flat XML Spreadsheet (.fods)
Not only this, but you can also avail the following bug fixes after upgrading to the latest release.
Incorrect links to resources when rendering into HTML
Failed to render password-protected ODP/OTP presentations
Styles are embedded when rendering XLSX into HTML with external resources
Incorrect page count for EPUB document
Page order ignored when rendering MS Project document into PDF
JpegQuality option of PdfFileOptions not works when rendering ODP presentation
HTML representation of PPTX document takes too much time
Misplaced characters when rendering Word document into HTML or image
So if you are interested in getting the above-mentioned features and fixes, just download and integrate GroupDocs.Viewer for .NET 19.9 in your application. If you haven’t used the API before, have a look at the documentation of the API. In order to evaluate API features, download or clone the examples project from GitHub repository.
As always, do write to us on our forum in case you would have any questions or queries.
We have added a lot of new options and features in this major release/update of GroupDocs.Editor for .NET 19.9. All public methods/classes have been moved to Legacy namespace and they are marked as obsolete. Now, when you update to this latest version, it is required to make project-wide replacement of namespace usages from GroupDocs.Editor. to GroupDocs.Editor.Legacy to resolve build issues. Access release notes here.
Why to migrate?
Editor class introduced as a single entry point to manage the document editing process to any supported file format (instead of EditorHander class from previous versions)
Architecture is redesigned to decrease memory usage
Simplified document editing and saving options
See difference in code This was supported in old API
We have simplified and optimized code to this much in the new version
What’s new? We have added a new GetDocumentInfo method using this method you can get a document’s metadata information without editing it. What information exactly?
Family format and exact document format
Encryption flag
Number or pages/tabs
Size
How it works? The new Editor class, which supersedes deprecated EditorHandler, contains this method. Once the document is loaded into the Editor class, this method can be called to obtain meta information about the loaded document without opening it for the editing purpose.
Text Save Options
Previously, there was no direct option to save edited document in a plain text format. We used WordProcessing save options for this purpose but that didn’t allow to configure parameters while saving into text format.
GroupDocs.Editor for .NET version 19.9 contains a new TextSaveOptions class that is actually implemented to save edited document to the plain text. TextSaveOptions contains following settings:
Ability to specify whether to add bi-directional marks before each BiDi run when exporting in plain text format
Ability to specify whether the program should attempt to preserve layout of tables when saving in the plain text format
Implementation The Options namespace contains TextSaveOptions class.
As there are a lot of public API changes. Before getting started, we’d recommend you to go through API references and example project.
Watermarking is a popular technique to indicate that the content or data inside a document is copyrighted. On the other hand, it is also used to place the company’s logo or some kind of label in the documents before they are shared within or outside the company. However, it is quite hard to apply the watermark to a bunch of documents one by one. It becomes harder if you have documents of various formats such as PDF, DOCX, PPTX, XLSX, EML, JPG, PNG, etc. So in order to make this process easier, we need some automation.
In this article, I will show you how you can apply a watermark to a batch of documents and images in one go using GroupDocs.Watermark API. So you don’t need to add watermark to each document manually. Also, you don’t need to worry about if you have or not the software or application that supports adding watermark to the document of a particular format.
Before we proceed, let me tell you the reasons why GroupDocs.Watermark is a suitable API for watermarking. This is because it supports:
GroupDocs.Comparison is a document comparison API that correlates content and style, it detects number of inserted/deleted or style changed items and generates a summary.
How GroupDocs.Comparison works for Image Comparison? The comparison starts with the upper left corner and compares the entire image pixel by pixel. If the pixels are the same, it moves on to the next one and so on until it finds a difference. The changed pixels are given an ID. It is defined as dabbed, deleted or changed. They are highlighted in a specific color (blue, red or green according to the standard settings).
Source Image
Target Image is same as source image except it has some extra objects on the table and some new code lines in the text editor.
Comparison Result
API successfully detects the changes and highlights them in the output/resultant image. In this case it highlighted the inserted items (e.g glasses, mug and some changes in the code). This is how you do image comparison using GroupDocs.Comparison for .NET
And using GroupDocs.Comparison for Java
Get access to the API resources. Post your concerns on forum.
As most of the businesses are going green, the need for paperless environment is increasing day by day. This also brings in the need for establishing the authenticity of the documents by signing them electronically. Therefore, eSigning is the very basic requirement and could be considered as the first step towards the paper free world.
Even in the scenarios where you can print the documents out, you may still have to send that back after signing the same. That may also leave you to figure out how you are going to do so, considering the scanners and fax machines going extinct, it is quite likely that your office may not have one either. And that will make eSigning a useful option in this case as well.
Other than these obvious solutions, eSigning is also a cost-effective and time-saving option. It does not need you to print dozens of pages just to sign one of those and send them back through some post taking days.
The GroupDocs.Signature As eSigning Tool
The GroupDocs.Signature for .NET and Java makes this task of signing your documents electronically extremely easy and could be integrated into almost all of the commonly available famous document formats. Currently, you can sign your documents with Stamp, Barcode, QR Code, Text, Image, Metadata, Form Field and Digital signatures, using just a few lines of code along with the GroupDocs.Signature APIs.
Using the GroupDiocs.Signature APIs you can sign all the pages of a document in one go. It also allows you to save custom data securely encrypted in it along with the useful feature of setting the alignment and appearance of the signature. Apart from signing the documents, these APIs also allows you to search for the signature and verify it.
eSign Your Documents with QR Code
Here, in this article, we will discuss how the documents can be signed electronically with QR Code. A QR Code consists of black squares arranged in a square grid on a white background, which could be read by an image capturing device such as a camera. The QR Code could be used to store bank information, contact information, addresses and all kinds of private information that you do not want to be tempered with.
Following code represents how a document can be signed with QR Code in C#:
The code in Java will look like this:
A signed document will look like the following screenshot:
You can also get the complete ready to run code samples at GitHub.
Markdown is a well known and one of the popular markup languages these days. The appearance of the text in Markdown is controlled using the syntax instead of using rich text editors or applications such as MS Word. The best thing is, it is a lightweight language and can be written in the plain text editors such as Notepad. As far as its usage is concerned, Markdown is popular in writing wikis, readme files, and others. This is the reason why we added the support of Markdown (.md) files in our document automation API – GroupDocs.Assembly.
The following is a glimpse of the Markdown syntax:
And this is how the text will be formatted:
Although the syntax of Markdown is simple, still you could find it difficult to remember when writing the templates for longer reports. So how could you make this process easier for you? Let me tell you one possible workaround for this.
Create a Word template with required text formatting
Populate the template with data
Save the generated report as Markdown (.md) file
Now, let’s come to point on how you can automate the above-mentioned steps. The solution is simple and uses a few lines of code but only if you are using GroupDocs.Assembly. Yes, you can now use the Word template to generate the report and then save the generated report as a Markdown file. So let me show you how this could be done.
Just assume that you need to dynamically generate a report in Markdown format (.md). For this, instead of creating the Markdown template, you can create the Word template and format the text as you need. Once the template is ready, just populate the data and save the generated report as a Markdown file. For the demonstration, I have created ReadMe.docx template for you that will be used in the following code samples.
C#
Java
The resultant Markdown file that you will get from these code samples is ReadMe_Out.md.
You can see how easy it is to save the assembled report as a Markdown file by just changing the extension of the output file from “.docx” to “.md”. In addition to this feature, we have also added support for:
Saving assembled Markdown document as Word Processing formats
Saving assembled email as a Markdown document
At the moment, the following Markdown features are supported:
Headings
Blockquotes
Horizontal rules
Bold emphasis
Italic emphasis
But no need to worry because we shall keep extending the supported features in the upcoming releases of GroupDocs.Assembly.
In case you want to use these features in your application, just download the latest release (v19.8) of GroupDocs.Assembly for .NET or Java. For the ready-to-run source code examples, download or clone the examples project from GitHub repository.
As always, we welcome you on our forum in case you would have any suggestions or queries.
Before going in depth to Metadata management, let’s discuss what the metadata is? The Metadata summarizes basic information about data. In other words, it’s an information which describes the data that contained in something like a web page, document, or file. Another way to think of metadata is as a short explanation or summary of what the data is.
A simple example of metadata for a document might include a collection of information like the author, file size, date the document was created, and keywords to describe the document. Metadata for a music file might include the artist’s name, the album, and the year it was released.
Types of Metadata
Metadata comes in several types and is used for a variety of broad purposes that can be roughly categorized as business, technical, or operational.
Descriptive: Metadata properties include title, subject, genre, author, and creation date, for example.
Rights: Metadata might include copyright status, rights holder, or license terms.
Technical: Metadata properties include file types, size, creation date and time, and type of compression. Technical metadata is often used for digital object management and interoperability.
Preservation: Metadata is used in navigation. Example preservation metadata properties include an item’s place in a hierarchy or sequence.
Markup languages: Include metadata used for navigation and interoperability. Properties might include heading, name, date, list, and paragraph.
Metadata in files helps to find and working with various types of files. Writing meaningful metadata saves a lot of time in future work. Having the ability to filter through that metadata makes it much easier for someone to locate a specific document.
The GroupDocs.Metadata API As Management Tool
Keeping above in mind, The GroupDocs.Metadata API is developed to make the life easier while working with metadata. It is a very powerful and easy to use API that provides all basic metadata operations (i-e view, add, modify, remove) for a number of file formats. API gets the file as an input and makes its metadata accessible to the user. Now, it’s up to the user to perform any of his operations on this metadata.
lets discuss a business case regarding metadata management by using GroupDocs.Metadata API.
Finding Photos Made on Specific Camera
Digital Images may contain some useful information in the form of metadata. As soon as we capture a digital photograph, the camera generates a wide range of information about the image i-e camera’s information, author’s information, GPS information and much more.
We can manually access the image details/metadata by going to images’ properties to find:
Images that were taken on a specific camera
Images with a specific subject
Images of a specific artist/author
Images that were taken at a specific place/location
But what if we are dealing with a huge number of images just, like, for example, Flicker does? It’s the mother of thousands of directories containing millions of images. Even a superhuman will require a considerable amount of time and effort to find the images matching some certain metadata property (as mentioned above). It is a serious problem, but only when we do not have GroupDocs.Metadata API.
Below is an easy example of API usage in the implementation of this use case.
Let’s write a PhotoParser class in C#:
Java guys will write as follows:
Suppose, an image collection may contain JPEG images captured by a Sony Camera. Its metadata looks like following screenshot:
It’s time to call the PhotoParser methods to get the list of images which were captured by a Sony camera:
Java guys will call the methods like:
The output will be appeared like the following screenshot:
The complete ready to run code sample is available on GitHub.
You might be looking for a software component or API using that an excel sheet could be converted to PDF/Word or any other supported format partially.
What is the difference? Many of us are just concerned with the output. Process an excel spreadsheet and get the right PDF/output. A simple conversion (Complete spreadsheet to PDF) is ideal until the source file has limited number of rows.
Partial Conversion – Usability
If you have a spreadsheet with more than 10,000 rows and your data or concerned rows are somewhere between 5,000 to 8,000. Wouldn’t you prefer to get PDF of rows 5,000 to 8,000 only? This is useful because:
Fast and to the point conversion
Less resources consumption
Easy to define conversion range
Let’s have a look at the implementation: C#
Java
“G7:I10” is the cells range (convert from row G7 to I10). Below are the screenshots of source and output files.
API allows you to set sheet/page number to convert using PageNumber property. For example you have an Excel file with 10 sheets. You can easily convert from G7 to I10 on page 6.
Download GroupDocs.Conversion API and try out this feature. Below are some helpful resources:
Why change is considered as a hard but yet good thing to occur? Why the updates are important? This is because if there is no change there is no progress and staying the same over the time makes the things die. The updates in the software components are also similar when a new version of the same software replaces the old one. A software that remains the same and doesn’t introduce any improvements or new features becomes obsolete. This is the reason the updates are always welcomed. And today, I am going to tell you about some major updates we have provided for our electronic signature API – GroupDocs.Signature for .NET.
After a having gap of approx. two months, we have now released an improved and more simplified version of API – v19.8. The primary objective behind this release was to make the usage of API’s features simpler and introduce a unified approach to handle all the supported document formats. The revamping of the architecture and the major optimizations have made the API more efficient in terms of resource consumption, especially memory utilization.
Let’s dig it further and check out what are the key reasons to upgrade to the latest release.
In the previous versions of the API, we had a separate class to deal with each supported document format. Since it was difficult to work with multiple classes, we have now introduced a unified approach. The signature options, verification options, and search options are now related to signature types only and not the document formats. For example, PdfSignTextOptions and WordsSignTextOptions were used to specify different options for text signatures in PDF and Word Processing document respectively. Now, a single class, TextSignOptionswill be used for both the document formats.
The single Signature class is introduced to sing the document with various signature types and perform verification and search operations for all the supported document formats.
The overall document related classes which were used to deal with different document formats have been unified to common classes.
The API’s architecture is redesigned from scratch in order to simplify the usage of options and classes to manipulate all the signature types.
The procedures of getting the document’s information and generating the previews for the documents are also simplified.
Let me now show you how these updates have affected and optimized the code. The following is the code sample that signs the PDF document with a text signature using the previous version of the API.
Now, have a look at how you would perform the same operation after upgrading to the latest release.
See, the code is more simplified as well as optimized in the new API. Not only this, but it also consumes fewer resources as compared to the previous versions.
So if you are already using GroupDocs.Signature for .NET then it is the right time to upgrade to the latest release. In case you are afraid of the breaking changes that you may face after upgrading to a version with major changes, we have made the things much easier for you. In the latest version, the legacy API has been moved into the Legacy namespace. Therefore, after you upgrade to version 19.8, it is required to make project-wide replacement of namespaces only. This means that the namespaces will be changed from GroupDocs.Signature.* to GroupDocs.Signature.Legacy.* to resolve build issues. And that’s it!
Just have a look at our documentation to check out how easy we have made the document signing process. Download or clone the new source code samples from the GitHub repository to know about the working of the API.
If you would face any issue while using or upgrading to the latest release, just post it on our forum and we would love to assist you.
