To ensure that your .pptx files render correctly and the images within them are visible on the UI, here’s a practical approach that aligns with your scenario:
Rendering .pptx Files in the UI
Backend Logic:
Use the GroupDocs.Editor library on the backend to process .pptx files and convert them into editable HTML. Referencing the example in the GroupDocs documentation, the library generates a fully formatted HTML document, including embedded images.
using GroupDocs.Editor;
using GroupDocs.Editor.Options;
// Load the presentation document
using (Editor editor = new Editor("sample.pptx"))
{
// Specify edit options for HTML
PresentationEditOptions editOptions = new PresentationEditOptions();
EditableDocument htmlDoc = editor.Edit(editOptions);
// Save the HTML content
File.WriteAllText("output.html", htmlDoc.GetEmbeddedHtml());
}
Store or directly send the resulting HTML (with embedded images) to the frontend.
Frontend Logic:
Ensure the HTML returned by the backend is correctly inserted into the DOM.
Here’s an improved and consolidated approach based on your code and the scenario you’ve described. It ensures proper handling of the content rendering in the textarea and resolves the issue of displaying PNG or other embedded elements.
Backend Code (Controller)
public IActionResult Index2()
{
using (Editor editor = new Editor(@"{PathToFile}\18cc8f2c-e5c5-4b5c-b06b-cbf60fe53445 (1).docx"))
{
WordProcessingEditOptions options = new WordProcessingEditOptions(true);
EditableDocument editableDocument = editor.Edit(options);
// Get the HTML with embedded styles
var resp = new HtmlResponse
{
Content = editableDocument.GetEmbeddedHtml()
};
return View(resp);
}
}
Moved inline JavaScript for editor initialization into a $(document).ready function for better readability and reliability.
Textarea Initialization:
Ensured textarea content is properly rendered with @Html.Raw(Model.Content) and not affected by encoding issues.
Error Handling:
If PNGs or images fail to load, ensure that image URLs are correctly encoded or resolved.
Test with files containing embedded media and debug the output HTML for missing or incorrect paths.
Steps to Debug and Validate:
Check the Content Property:
Ensure editableDocument.GetEmbeddedHtml() generates the correct HTML with embedded styles and media (base64 or URL-based).
Test with Various Files:
Test .docx files with varying complexity (e.g., multiple images, text styles).
Console Logging:
Add console.log to the script to debug any runtime issues in the browser.
By following these improvements and steps, you should have a robust implementation for rendering and editing .docx files with embedded elements in the Kendo Editor.
We’re currently working on providing a working example and appreciate your understanding as we handle support queries on a first-come, first-served basis.
Thank you for your patience. You can find a working example of integrating GroupDocs.Editor with the Kendo WYSIWYG Editor in the following repository: GroupDocs.Editor Kendo Sample
This example demonstrates how to load a document, render it as editable HTML, and use the Kendo Editor for modifications. Feel free to explore it and let us know if you have any further questions!
Thank you for the proposed solution, I check and it is appearing correctly, but only showing 1st 2 pages, below is the sample file for your reference, remaining pages are not appearing, what should we do here?
The issue you are describing, where only the first 2 pages are appearing, is likely due to the trial mode limitation of the GroupDocs.Viewer library. When a license is not applied, the library operates in trial mode and restricts the output to the first 2 pages of the document.
Solution: Apply a License
To resolve this, you need to ensure that a valid GroupDocs.Viewer license is applied in your code.
The Viewer updates form fields or SDTs (like date fields) to the current system date during rendering, while the Editor displays the saved state of the document without such updates. As seen in the Viewer screenshot, the date reflects the current system date, whereas the Editor (similar to MS Word) shows the last saved state of the document. image.png (44.7 KB)
Thank you for sharing the details and your code. Based on the provided implementation and the GroupDocs.Editor for .NET sample, it seems the issue might be related to handling the HTML content or saving the document. Here’s an updated explanation considering your use of embedded HTML without requiring external resources:
Client-Side JavaScript
Ensure the EditorData sent to the API contains the full HTML content of the edited document. Using $('#editor').html() should work correctly in this case:
$('#btnSave').click(function (e) {
e.preventDefault();
let SaveDetails = {
FileId: $('#FileId').val(),
GUID: $('#FileServerId').val(),
EditorData: $('#editor').html(), // Capture HTML content with embedded resources
};
ajaxCallFunction("POST", "/api/GroupDocsApi/SaveWordFile", JSON.stringify(SaveDetails), function (response) {
if (response.ReturnStatus === "0") {
alert('File saved successfully.');
window.close();
} else {
alert('Error while saving the file.');
}
});
});
Server-Side API
Since you’re working with embedded HTML, you can bypass the need for a ResourceDirectory. You only need to ensure the EditableDocument is created directly from the embedded HTML content.
Here’s the relevant code snippet:
string editedHtmlContent = request.EditorData;
// No need for resource directory since resources are embedded in the HTML
EditableDocument afterEdit = EditableDocument.FromMarkup($"<body>{editedHtmlContent}</body>");
This eliminates the dependency on any external resources and directly processes the embedded HTML content.
Saving the File
Your current approach to saving the file is correct. For clarity, you can specify the output format explicitly if needed, but otherwise, your implementation works well:
WordProcessingSaveOptions saveOptions = new WordProcessingSaveOptions
{
Format = WordProcessingFormats.Docx // Optional: Specify format if needed
};
using (Editor editor = new Editor(inputFilePath))
{
editor.Save(afterEdit, outputFilePath, saveOptions);
}
Ensure that:
inputFilePath points to the original document before editing.
outputFilePath is writable and correctly formatted for the saved file.
Additional Debugging Tips
Log editedHtmlContent before creating the EditableDocument to confirm it contains the correct embedded HTML.
Check the paths (inputFilePath and outputFilePath) to ensure they are valid and writable.
Key Points to Note
Since you’re using embedded HTML, there’s no need for a ResourceDirectory.
Ensure the HTML content in EditorData is valid and well-formed.
