GroupDocs Editor Not Working with Kendo

GroupDocs.Editor Product Family
, ,
49

Please explain this.

50

@Niteen_Jadhav

I want to check the backward conversion (from edited HTML to resultant DOCX) on my side in order to reproduce your issue. So I need a value of the editedHtmlContent variable. The easiest way of doing that for you is to debug your code, put a breakpoint on the EditableDocument afterEdit = EditableDocument.FromMarkup line of code, copy the value of the editedHtmlContent variable, paste it into some new *.txt document and then send this document to me through attachment in this forum topic.

With best regards,
Denis

51

shared both the files with you please check and update me.

corrupted file.zip (3.0 MB)

Working File.zip (3.0 MB)

also, what is the update on the alignment issue which I raised today?

we are still stuck on the editor issue since December

52

Hello Team,

Do we have any updates on these issues?

53

Hello team,

Any updates?

54

Hi @Niteen_Jadhav

Sorry for the long delay, it took some time to investigate all of these and prepare answer.

  1. Regarding the attached corrupted file.zip (3.0 MB) - I’ve checked this and confirm an exception, it was already reported by you some time ago, I confirmed that, it is logged as EDITORNET-2879 in our tracking system and we plan to fix it in the next release.

  2. Regarding the attached “Editor table.PNG” screenshot and the truncation and alignment issue. I believe this is because a width of your viewport is too small for this specific document. The table, which seems to be truncated from the right side in your web-app and which you’ve demonstrated on the screenshot, has a fixed width of 18.44 centimeters - I’ve checked this in MS Word table settings in the “CMES KA GCOA Termsheet DocPro template.docx” file. And it seems that the width of the viewport on your web-page is too small for this size. Table columns also cannot be narrowed, because they also have the fixed width: 1st one is 3.24cm, 2nd - 15.2cm. MS Word program and Office Open XML format allows to create tables with automatic sizes, which can fit into the page, but in this case the table is fixed.

  3. Regarding the response time. This is a free forum and we follow the free support policies. We cannot process your requests on real-time basics. If you need the more priority support, there is a Paid support with a dedicated team, which handles your requests. Also we provide the Paid Consulting, when our dedicated developer works with you and helps to integrate the GroupDocs products into your application.

Once more, sorry for the delay, and have a good day.

With best regards,
Denis Gvardionov

55

What can be done to fix this

56

@Niteen_Jadhav

In general, if your web app is designed to process different WordProcessing documents, created by different users, and you do not control how these documents are created, edited and formatted, you cannot predict the correct viewport width. Even in a single DOCX document may be different sections, where 1st one, for example, is standard portrait A4, 2nd is landscape A3, and 3rd is a some custom gigantic page with no borders. So the best way from my point of view is to make a horizontal scroll bar in your viewport. Or make the resizable width of the viewport. Or, maybe, auto-fittable width, but this will be more complex, I guess.

With best regards,
Denis

57

Can you please help me with some working example?

59

Hi @Niteen_Jadhav

I’m afraid I cannot help you with working example, because this requires studying and investigating Kendo editor, integrating in your project and pipeline, what is out of my competence. But as I said before, the GroupDocs offers a Paid Consulting, which was created especially for such cases - our dedicated developer joins your team and integrates the GroupDocs.Editor into your application.

I can here only suggest you an approach how to solve the issue and here is my advice:

  1. As I said before, a single WordProcessing document may have multiple sections, and every section may have its own page size (including page width) and orientation. From my point of view, if you want to get rid of content truncating and horizontal scroll bar in the viewport, you should fit your viewport width to the largest possible page width in the given WordProcessing document.
  2. I suggest you to convert the document to the HTML and vice versa in the paginal mode, as I has demonstrated above.
  3. When the document is converted to HTML format in paginal mode, its HTML markup has a central MAIN element, and there are a distinct SECTION element per each section of the document as a child of MAIN element. For example, a document with 3 sections will be converted to the HTML, where one MAIN element will have 3 child SECTION elements.
  4. Each SECTION element has an appropriate CSS ruleset, where its actual width is stored. For example, a SECTION element looks like <section class="section" data-page-type="A4_Portrait" style="background-color: transparent;"> and it is connected with the CSS ruleset section[data-page-type="A4_Portrait"] { width: 595pt; min-height: 842pt; }.
  5. What you actually need is to get all SECTION elements within output HTML document, get all their “width” CSS properties, and featch the biggest one.
  6. So the final approach looks like the next. You convert the input WordProcessing document to the HTML document using GroupDocs.Editor in paginal format; send this HTML document to the client-side; there parse HTML document with JavaScript, find the root MAIN element, iterates over all its child SECTION elements, and for each you grab the value of the “width” CSS property; then you select the largest “width” value and use it as a final width of your viewport.

Hope this helps.

With best regards,
Denis Gvardionov

60

Hello Team,

still waiting for the solution on the above point

61

Hi @Niteen_Jadhav

Sorry for the delay. We’re still working on both issues: the The document appears to be corrupted and cannot be loaded exception and content truncation from the right side. We will notify you when it will be fixed and released.

Sorry for the inconvenince.

With best regards,
Denis Gvardionov

62

when can I expect a fixed on this?

63

Hi @Niteen_Jadhav

We plan to fix the issue with a content, truncated from the right side in a paged mode, in the GroupDocs.Editor for .NET 25.3, that will be released at the end of March.
Regarding the exception during backward conversion — we expect it will be fixed in the following version of the GroupDocs.Editor for .NET, maybe 25.4.

With best regards,
Denis Gvardionov

64

Thank you for the update, please update me once 24.3 update get’s rolled out

65

Hi @Niteen_Jadhav ,

The GroupDocs.Editor for .NET version 25.3 is released. In it we’ve fixed the bug with truncated document on the right side: GroupDocs.Editor for .NET 25.3 Release Notes. You can download it on Nuget or GroupDocs.Downloads.

Regarding the 2nd bug with the The document appears to be corrupted and cannot be loaded exception — it is still under work.

With best regards,
Denis Gvardionov

66

The above mentioned bug is not fixed yet.

I am still facing the issue where after saving the file it is getting shifted to right side

sharing the file for your reference.

CMES KA GCOA Termsheet DocPro template.docx (3.8 MB)

CMES KA GCOA Termsheet DocPro template [2].docx (2.8 MB)

I also noticed that the size of the file also changed.

I am stuck on the same Editor issue since last December and still the issue is not fixed, the timeline provided by your team was communicated to our client by us and now the issue still appearing. these things ends up impacting our commitments with the clients.

67

Hi @Niteen_Jadhav

I’ve checked both attached files “CMES KA GCOA Termsheet DocPro template.docx” (3.8 MB) and “CMES KA GCOA Termsheet DocPro template [2].docx” (2.8 MB) in both float and paginal modes using a tiny sample project with few lines of code, it is attached, you can check it on your side, if you want (“SampleConsoleEditorAppSolution.7z”). With this project I’ve obtained the next results.

File “CMES KA GCOA Termsheet DocPro template.docx” (3.8 MB) is rendered to the both paginal and float modes fully correct, without truncations.

File “CMES KA GCOA Termsheet DocPro template [2].docx” (2.8 MB) is truncated “by design”, when you open it is MS Word, you will see a truncation from the right side, see screenshot “Truncation.png” below. When converting it to HTML format in paginal mode, this truncation persists, because the GroupDocs.Editor tries to mimic the MS Word behavior. If you want to see the whole content without truncation, please enable the float mode.

I’m attaching 4 HTML files in 7z archive “Converted-to-HTML.7z”; they were produced with attached sample project in both paginal and float modes for both attached files. With them you can check that truncation is present only in the “CMES KA GCOA Termsheet DocPro template [2]-paged.html”, but, as I said earlier, it is because GroupDocs.Editor tries to mimic the MS Word behavior.

Hope this will help.

With best regards,
Denis Gvardionov

Truncation.png (310.7 KB)
SampleConsoleEditorAppSolution.7z (8.3 KB)
Converted-to-HTML.7z (1.4 MB)

68

The document with 3.8 MB size is the original document and the document with 2.8 MB size is the same document which I saved after editing in the editor.

I am executing the below API

[HttpPost]
        [Route("api/GroupDocsApi/SaveWordFile")]
        public SPResponse SaveWordFile(DocPro.DMS.BusinessEntities.Request.GroupDocs.GetDocumentInfoRequest request)
        {
            SPResponse sp = new SPResponse() { ReturnStatus = "-1" };
            string editedHtmlContent = request.EditorData;

            string inputFilePath = Path.Combine(request.StoragePath, request.GUID);
            string guid = Guid.NewGuid().ToString();
            string extension = Path.GetExtension(request.GUID);
            string outputFilePath = Path.Combine(request.StoragePath, guid + "." + extension);

            EditableDocument afterEdit = EditableDocument.FromMarkup($"<body>{editedHtmlContent}</body>", new List<IHtmlResource>());
            GroupDocs.Editor.Options.WordProcessingSaveOptions saveOptions = new GroupDocs.Editor.Options.WordProcessingSaveOptions();

            using (Editor editor = new Editor(inputFilePath))
            {
                editor.Save(afterEdit, outputFilePath, saveOptions);
            }
            sp.ReturnStatus = "0";
            sp.Ref1 = guid;
            return sp;
        }

after file is being saved from this api the file is being truncated and the 2.8 MB file is a result of this

69

Hi @Niteen_Jadhav

Thanks, now it is clear for me - file 3.8 MB is input and file 2.8 MB size is output and it is corrupted. I was managed to reproduce your issue and with your code obtained the same result.

In order to fix it you should do the next:

  1. For the WordProcessingSaveOptions saveOptions set the EnablePagination flag to true:
GroupDocs.Editor.Options.WordProcessingSaveOptions saveOptions = new GroupDocs.Editor.Options.WordProcessingSaveOptions();
saveOptions.EnablePagination = true;//here
  1. Remove the unnecessary $"<body>{editedHtmlContent}</body>", just pass the editedHtmlContent variable directly to the EditableDocument.FromMarkup:
EditableDocument afterEdit = EditableDocument.FromMarkup(editedHtmlContent, new List<IHtmlResource>());
  1. About decreased DOCX file size - it is Okay.

This should help.

With best regards,
Denis Gvardionov