Copying the word content adds two lines above/below the bullet points

[Senthil]

Copy the content from the attached word doc and paste it directly(Ctrl+c) or using the "PasteFromWord". Now compare the formating between the word doc and editor's format. You will see a big gap "above the bullet point" and "below/end the bullet point"(verify the screen shot attached). This has been reported as a critical issue by our customer and hence please provide high priority.

[Senthil]

CKEditor formating issue_doc

[Senthil]

ckeditor_bullet_formating_screenshot

[Jakub Ś]

If you look at this word document you will see that your client inserted paragraphs between list and text.

Please also have a look at FF_html.txt file. This is how Firefox sees pasted code from word. You can clearly see that there are empty paragraphs between text and lists (lists are also represented by paragraphs here).

If a browser sees this extra space between list and text as paragraph (which is correct) then there is nothing CKEditor can do here.
CKEditor does not know that this is the part of code that client does not wish to see. What your client can do here is either delete these empty paragraphs after pasting or not put them in word document.

[Senthil]

Customer is getting the word doc and uploading it into our system. In this process, the end user doesn't know whether it is a paragraph or new line. But they wanted to see the same formatting after the content is copied from the word doc. And removing the paragraphs inside the document is not an easy job and they are not going to accept it.

Here the question is, why the ckeditor is not retaining the formatting of the content which is copied from the word doc? Whether it is a paragraph or new line, it should retain the formatting right? Please let me know.

[Jakub Ś]

In all cases, the editor privileges semantics over formatting, so the end results will never look like the original. CKEditor makes it best to translate the information send from Word through the clipboard and many times it needs to come to an agreement. In those cases we prioritize semantics instead of formatting.

But there might be something that can be done. Please have a look at attached margins.jpg.
As you can see there are some default margins applied by browser to paragraphs and list. That is why gap is so big.
What you can go her is add styles for lists and paragraphs (margin-top:0; or margin:0;) in contents.css or if you are using fullpage mode in style tag in head section.
If this content is to be saved and used as external page then the same styles should be applied there.

[Senthil]

Fred/Swiderski - Technically the above update might be correct but for an end user it is not acceptable. Meaning when they are copying the word content and seeing different formatting which is not readable or un-formatted and asking them to edit the word content before copying is not advisable. So please consider this use case from the end user's perspective and provide the solution. Or if you can provide a configurable workaround(in config file) then i can discuss with my customer to consider. And i am reopening the ticket, since the issue is not yet resolved.

[Senthil]

Swiderski - Since i am not able reopen the ticket, please reopen it.

[Jakub Ś]

Or if you can provide a configurable workaround(in config file) then i can discuss with my customer to consider.

Have you read my last post?

But there might be something that can be done. Please have a look at attached margins.jpg. As you can see there are some default margins applied by browser to paragraphs and list. That is why gap is so big. What you can go her is add styles for lists and paragraphs (margin-top:0; or margin:0;) in contents.css or if you are using fullpage mode in style tag in head section. If this content is to be saved and used as external page then the same styles should be applied there.

This is the solution - putting default styles in contents.css. Browser adds some default styles so what you can do is tell it not to do that through contents.css.

[Jakub Ś]

Please also have a look at margins.png

[Senthil]

Basically your workaround sets the margin at run time(dom) and removing the spaces above the bullet points. But it is not actually adding this margins to the ul/p elements (as an inline style), so when we show this html content in any other places we will loose the formatting again(as per your update). So this solution is not going to help us and what we need is, by configuring the content.css or config.js file editor should be inserting the inline margins as per my custom configuration. This way we can workaround the issue but i still recommend to fix it from the editor's side since it is a common use case for the end users.

[Jakub Ś]

The better option would if you were attaching imports of css files (held in one place) when content of CKEditor is saved. That way you wouldn't have problems with displaying these contents in various locations.
You could also use fullPage mode and specify these imports there.

Apart from that... I have noticed is that browser sees something like:

style="margin: 0cm 0cm 0.0001pt 21.3pt;

Perhaps this could be used? CKSource any comments?

[Senthil]

Right now we are closer to the release and hence we cannot add any new changes to the ckeditor integration code to include the css files in all the pages(will be a big impact). So we have only two options now, either CKeditor can fix this issue or provide a configurable workaround which should add these margins to the actual html elements as an inline style. Please let me know.

[Frederico Caldeira Knabben]

There is nothing to be done here. There is no way for the editor to retrieve and maintain the original formatting in this case. Even pasting in ​a plain contenteditable area gives similar results. So, setting config.pasteFromWordRemoveStyles = false, which would be the only possible solution to this, will not help either.