When copying text from word to the wysihtml5 editor, the text gets messed up (both in term of formatting and in terms of additional added characters). Is there an easy fix for this? The correct behavior I am looking for would be the way Stack Overflow's rich-text editor works - the text copied and pasted from word looked identical to the word document.
Thank you!
Update:
To solve the problems observed with the formatting of the pasted word text, I added the line "p": {}, in the used wysihtml5-0.30_rc2.js file. The line was added in the declaration of the defaultOptions[parserRules][tags] (see used resource).
Still, now I can see at the beginning of the pasted text a "Font Definitions" paragraph:
<!-- /* Font Definitions */ #font-face {font-family:Arial; panose-1:2 11 6 4 2 2 2 2 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} #font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin-top:0cm; margin-right:0cm; margin-bottom:10.0pt; margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; mso-hyphenate:none; font-size:11.0pt; font-family:Arial; mso-fareast-font-family:Arial; mso-bidi-font-family:Arial; color:black; mso-fareast-language:HI; mso-bidi-language:HI;} a:link, span.MsoHyperlink {mso-style-unhide:no; mso-style-parent:""; color:navy; mso-ansi-language:#00FF; mso-fareast-language:#00FF; mso-bidi-language:#00FF; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {mso-style-noshow:yes; mso-style-priority:99; color:purple; mso-themecolor:followedhyperlink; text-decoration:underline; text-underline:single;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} #page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt
90.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->
This only happens when I use Firefox, and does not happen in Chrome. Any ideas on how to get rid of this problem?
wysihtml5 includes a parser that analyses all text that gets pasted in its text area and applies the filter rules that are defined in the parserRules config object. Adding "style": { "remove": 1 } to your parserRules should do the trick.
To understand the Firefox problem, you have to see the raw clipboard HTML content (originating from Word) that gets pasted into the text area. Just copying some Word text and pasting it into a text editor won’t help because the text editor requests a text-only variant of the clipboard content.
If you’re on a Mac you can see this raw clipboard content with the help of the ClipboardViewer tool that you have to compile yourself with XCode. The desired HTML content should be in the public.html or Apple HTML pasteboard type fields. Maybe there exist other tools that don’t need to be compiled and/or that work on other operating systems.
Now you should see that your clipboard content from Word actually looks something like
<span>
<!--
/* Font Definitions */
...
div.WordSection1 {page:WordSection1;}
...
-->
</span>
So by removing the style tag (with all of its content) the font definition junk disappears.
Have a look at wysihtml5’s parserRule demo to see some more advanced configuration options.
I've solved this by overriding wysihtml5.dom.getPastedHtml. Just add this after you've loaded wysihtml5:
wysihtml5.dom.getPastedHtml = function(event) {
var html;
if (event.clipboardData) {
html = event.clipboardData.getData('text/plain');
}
return html;
};
Related
I'm having an issue with the auto comments in my .scss files. By auto comments I mean 'CTRL + /' to comment out the selected code. When I'm in my scss file and I do this, it adds the JS comments '//'. So the output looks like this:
body {
font-size: 1rem;
line-height: 1.4;
// overflow-x: hidden;
}
When it should be:
body {
font-size: 1rem;
line-height: 1.4;
/* overflow-x: hidden; */
}
If I rename the .scss file to .css then the auto comments work correctly. I'm guessing this has to do with a setting inside of VSCode, either user or workspace setting?
I believe this is working as expected, as SCSS supports both ways to comment, and I do not think there are any settings in Visual Studio Code you can change to change how the comment style works.
Ctrl + / is "Toggle Line Comment", which is the // way. If you want to comment using the multi-line comment format, you can instead highlight what it is you want to comment, and perform Shift + Alt + A.
However, there is another way to change how the Line Comments work:
Find where Visual Studio Code is installed on your system, and go to resources → app → extensions → scss
In the scss folder should be a "language-configurations.json" file. Open it.
Change the lineComment property to be either a blank string, or delete it outright.
"lineComment": ""
Save the file, and restart Visual Studio Code. Now when you perform Ctrl + /, it should comment using the style you prefer.
Please see the comments to #Timothy's answer. I have previously written an extension to deal with these issues, Custom Language Properties, that allows you to easily change things like line or block comments for many languages.
But setting lineComment to the OP's desired ["/*","*/"] did not work. In looking at the scss language configuration file, an array of values is not allowed for line comment values. But it works to delete the lineComment key or setting it to the empty string "".
However, although probably rare, any language configuration file can be overwritten whenever vscode updates and you would have to go back and change the file again. Hence the extension.
With this setting:
"custom-language-properties": {
"scss.comments.lineComment": ""
}
this accomplishes the same thing as editing the underlying language-configuration file. And fortunately, at least in this case, apparently vscode will apply the blockComment value when the lineComment value is missing or inappropriate. And fortunately that blockCcomment style is what the OP wanted.
That is valid comment syntax for SCSS, and it's probably the correct default.
Single-line comments (which start with //) are always removed from the compiled output, which is usually what you want.
Multi-line comments (/* comment */) are only removed in compressed mode.
Source: Sass: Comments
We have a SAPUI5 timeline control, where we are showing the comments coming from server.
The issue is, if the comments contain a newline \n, then the Timeline control is not able to display the text in newline. Instead, it introduces space wherever \n is present.
We have tried formatting \n to unicode character also but that also didn't worked. Timeline control aggregates TimelineItem.
The control we are using is: https://ui5.sap.com/#/api/sap.suite.ui.commons.TimelineItem
Code snippet can be found at:
https://jsbin.com/kuluyehilu/edit?html,output
I inspected your example and came up with the following solution.
Since the text is embedded in a <span>, all unnecessary whitespace will be trimmed. What you can do is telling the span (via CSS) that it should display the whitespace anyway.
If you don't have a CSS file in your project yet, create one. Then add the following lines
div.sapSuiteUiCommonsTimelineItemShellBody>span {
white-space: pre;
}
This should do the trick.
JSBin: https://jsbin.com/feladeneso/1/edit?html,output
If you inspect the rendered element, you will see it actually put in the break:
<span id="__item0-realtext">x
y</span>
...but did not convert it to a <br/> tag. You cannot add the tag yourself since it will be escaped, either. Maybe you can try to override the renderer, and convert any line breaks to html breaks
In a js file, I can type comm and autocomplete will kick in prompting me for comment blocks. This functionality doesn't work in CSS files.
I thought this would be the answer for me but it is not.
"auto_complete_selector": "source, text"
This post also looked promising, but it was not either.
Sublime Text 2 code snippet not working in proper scope
Anyone know of a way to add it or to turn it on for CSS?
You need to add a snippet that whos scope has CSS files included. Example:
<snippet>
<content><![CDATA[
/* ----------------------------------------------------------------------------
* ${1:CSS Section}
* ------------------------------------------------------------------------- */
]]></content>
<!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
<tabTrigger>comm</tabTrigger>
<!-- Optional: Set a scope to limit where the snippet will trigger -->
<scope>source.css</scope>
</snippet>
Save this file with the .sublime-snippet extension in your User packages folder (Sublime Text -> Preferences -> Browse Packages) and you will be good to go.
In a CSS file, you would then type "comm" and hit tab.
NOTE: The folder location I mention above is for Mac users FYI
I have nicEdit implemented in the backend for uploading news items, and in the frontend each newsitem has a square in front of the beginning of the text body (image attached). This only occurs in the first paragraph of the text.
Due to the paragraph tags added by nicEdit, the text is displayed on a different line than the square. I have searched in the nicEdit docs and in previously answered questions on here but could not find a solution. Is there any way to change the paragraph formatting in nicEdit to use br at the end of a paragraph instead of having it wrap the text with p tags? Or if not, to have Nicdit automatically add the square to the beginning of each text?
Thank you in advance for any help!!
http://i.stack.imgur.com/dxxtu.png
Edit: Turns out the p tags were not caused by the nicedit but by the users copy-pasting the articles. I have used this to remove formatting from pasted text, but the tags are still there (it seems to only remove font properties).
As a temporary fix I have added the square to the nicedit wysiwyg as initial text, so that it is sent to the db along with the rest of the text and inside the same paragraph.
I realized there's a line in the code you modified that specifies all the unwanted tags. You should add the paragraph there.
Search for
/* remove undwanted tags */
newSnippet = newSnippet.replace(/<(div|span|style|meta|link){1}.*?>/gi,'');
in the nicEditorInstance class, and change it to
/* remove undwanted tags */
newSnippet = newSnippet.replace(/<(div|p|span|style|meta|link){1}.*?>/gi,'');
Notice the "p" has been added. That will prevent nicEdit to wrap the paragraphs in tags.
We are using Plone 4.1.3 and the default TinyMCE editor. When we press the Enter key in TinyMCE, it produces a double line spacing instead of single line. We found a few similar questions and answers on this issue in the forum but don't know and cannot find the TinyMCE configuration file to modify to make line break into single line spacing. There is also nothing in Site Setup or ZMI to configure this for TinyMCE.
We found this the forum but it is not pertaining to plone.
Decrease the line spacing in TinyMCE textarea
Thank you very much in anticipation
cmgui
CSS. These are just paragraph elements (<p> tags). -- style them!
http://plone.293351.n2.nabble.com/TinyMCE-Plone-4-customizing-the-styles-for-own-CSS-classes-td5954678.html
As sdupton pointed out, this is indeed on purpose; enter is supposed to be a paragraph break, and behaves the same way in applications like Word. You can insert line breaks by shift-enter, but it's not encouraged to do that on the web, since text flows differently depending on font size and window size (and OS!).
If you want paragraphs to have less spacing, use CSS to reduce the margin/padding.