I'm creating a Office Word add-in that needs to fetch text and show it in the task pane. Since it would be preferred to show the text with the same formatting as in the host document, I'm using the getSelectedDataAsync() function and specifying Office.CoercionType.Html as coercion type. This works very well in Word online; but unfortunately not in Word 2013 and 2016 clients.
Looking at the documentation (http://dev.office.com/reference/add-ins/shared/document.getselecteddataasync), it says Office.CoercionType.Html is supported for Word but does not explicitly mention Word online. Judging from behaviour, it seems that the documentation is maybe faulty and should say the other way around.
But maybe I'm just missing something. Any ideas on why it's not working or how I can proceed to get it working? I would prefer to do minimal processing after getting the selection, which is why fetching it in HTML seemed to be the best solution. Fetching plain text does not even seem to take paragraphs into account which is a absolute minimum requirement of formatting.
The only really similar question I've found, Apps for Office 365 - Return selected text with styling and formatted, is related but does not answer my question.
This proved to be a problem not with Office.CoercionType.Html itself being unavailable, but rather it returning slightly different HTML in the Word clients and Word online. This made things break later in the code while applying some simple filters to the HTML which in turn made it look like the function did not return anything.
Like stated in the question the documentation is not completely obvious about the coercion type working in both Word clients and Word online, but I can hereby confirm that it does indeed work in both variants of Word.
Related
I have actually spent a lot of time looking for a solution for this. Stackoverflow is my last resort. Before I dive in I would like to describe my requirements.
My requirements,
I need an editor like slack that automatically converts markdown to relevant TextStyle or html. For example if I type, ## Hello and press enter. it is styled as H2 styled text.
Moreover, I also need to show a dropdown whenever I press # or # to select from a list of options.
In short, I need something like quip, slite or medium.
I was hoping that this will be easy in flutter, given half of these features are already there in Google's Gmail and other apps by google by havent yet found a single library that meets these requirements.
What I have already tried?
Quil: I found out by flutter_quill but for that I have to stick to a toolbar on the top. And no mentions support.
Zefyr and html_editor: I have tried these, but they are very buggy and slow. Moreover, they have very limited documentations.
Custom Flutter: Medium-like Text Editor. This is the most promising solution but it is lacking one essential feature of text editor. The article proposes that I divide the entire input field into multiple text fields which I can control using state. But this has one big problem that is, what if I want to select the entire body of text. Any hacks on this will be well appreciated.
If you have any questions and if the question isn't clear enough, please free to comment down below.
I'm developing an add-in for MSWord using Microsoft web add-in API. I'd like to underline or highlight some given words, but only in the scope of that session. I don't want to change the document's state. In other words, I don't want to persist the new text formatting when the document is saved.
I know how to format text, but the document's state is changed. I have this code at the moment:
word_range.font.underline = Word.UnderlineType.wave;
I want to achieve a behavior similar to Grammarly plug-in, where the underline is only to point out something is wrong with those words, but again, without persisting the underlining.
I found a similar question (word - highlight search results without permanently changing document formatting), but it was asked a few years ago and the solution is not exactly what I'm looking for.
I'm afraid that there is no way to highlight that will automatically disappear if the user saves the document. The answer that you linked to, or this one is the best that can be done in Office.js right now. It is a good idea, however, so please suggest it at Office Developer Suggestion Box.
I get the following errors from the Google Rich Snippet Tool for my website http://iancrowther.co.uk/
hcard
Warning: This information will not appear as a rich snippet in search results results, because it seems to describe an organization. Google does not currently display organization information in rich snippets
Warning: At least one field must be set for Hcard.
Warning: Missing required field "name (fn)".
Im experimenting with vcard and Schema.org and am wondering if I'm missing something or the validator is playing up. I have added vcard and Schema.org markup to the body which may be causing confusion. Also, I am making the assumption I can use both methods to markup my code.
Update:
I guess with the body tag, I'm just trying to let Google discover the elements which make up the schema object within the page. I'm not sure if this is a good / bad way to approach things? However it lets my markup be free of specific blocks of markup. I guess this is open to discussion but I like the idea of having a natural flow to the content that's decorated in the background. Do you think there is any negative impact? I'm undecided.
I am in favour of the Person structure, this was a good call as this is more representative of the current site content. I am a freelance developer and as such use this page as my Organisation landing page, so I guess I have to make a stronger decision of the sites goals and tailor the content accordingly, ie Organisation or Person.
I understand that there is no immediate rich snippet gains, but im a web guy so have a keen interest in these kind of things.
With schema testing, I find it easiest to start from the most obvious problem, and try to work our way deeper from there. Note, I have zero experience with hcard, but I don't believe the error you mentioned actually has anything to do with your hcard properties.
The most obvious problem I see, is that your body tag has an itemtype of schema.org\Organization. When you set an itemtype on a dom element, you are saying that everything inside of that element is going to help describe that itemtype. Since you've placed this on your body element, you are quite literally telling Google that your entire page is about an organization.
From the content of your page, I would recommend changing that itemtype to schema.org\Person. This would seem to be a more accurate description. Once you make that change and run the scanner again, you may see more errors relating to the schema and we can work through those too (for example, you'll probably need to set familname and givenName).
With all of that said, you should know that currently there are no rich snippets that you will gain from adding this schema data. Properly setting this up on your page, is only good to do, especially since we don't know what rich snippets Google or others will expose in the future, but currently you won't see any additional rich snippets in Google search results from adding these tags. I don't want to discourage you from setting this up properly but I just want to set your expectations.
After years of experience with custom made CMS systems, I come to this conclusion:
Clients really want to copy and paste information from word processors into their website CMS. They don't like to create large texts in a website box, and prefer to do so from their good old word processor. Or they simply have their text already prepared for other purposes, and therefore want to copy and paste.
Clients do not like to lose their format. They've spent time on their boldface text, headings, etc, and they do not like to do this all over again.
Rich Text Format fields (TinyMCE, CKEditor, etc) are not yet able to properly convert all formatted text into the right HTML. I do not blame them; this has to be very difficult given the odd 'source code' that word processors put in the clipboard. But reading all SO topics about richttext related issues, I feel this is a known limitation.
What do you do in such cases? I've tried the following:
Explain the client beforehand that this is not a word processor we are implementing, and it has limitations. They can understand, but still want to copy and paste.
Only show very few buttons for formatting (bold, italic, links). That way, we can strip the tags and clean this up quite well, and this limits issues. Works better, but clients keep asking for font options, more colors, headers, etc.
So not a really good solution in sight. Are there others who have tackled this issue successfully?
One solution (and probably the best I've come up with) is to post-process the pasted content. So, catch the publish event and correct all the crappy HTML -- catch all the "mso-normal" styles, for instance, and remove them. You'd have a set of rules which clean stuff coming out of, say, MS Word.
Though, this is not just a word processing problem. You're pasting from one rich text editor to another, and styles just don't transfer between rich editing environments. This is not so much a technical problem as it is a logical problems.
Update: Someone pointed me to this: Copy-Pasting Word to your Web CMS. No real solutions, but just confirmation that it's a sticky problem.
I totally agree with you:
Last week I did a very interesting test with a customer for which I had to prepare some demo's of .NET based CMS systems (Umbraco, Sitefinity, DNN, Composite C1 ect). The customer himself had a Drupal based site and I was ashamed none of my CMS demo's did a 100% job with a complicated Word table (Ceteris paribus: I did not do some CMS fine-tuning, used every CMS out of the box). The worst part was his Drupal CMS did a 100% good job! It was exactly the same as it was in Word. For a client working a lot with Word my CMS-ses were a showstopper. Of course there are a lot of discussions on the web about 'you should not copy from Word' or 'do NOT use Word for CMS things'. Fact is: clients work with Word so we should deal with it.
I am thinking of converting my forum input textarea exclusively to TinyMCE HTML editor. I already have both options but it is a pain maintaining both and inserting images in textarea needs preview etc...
This is more of a general question. Do you think it is safe to include HTML editor (with all the safety measures like paste only text, filter for html not allowed etc...) as the only kind of editor on a forum? It's 2011 and machines are generally fast, connection are better.
What are the downsides of using HTMl editor instead of text field? I can not imagine a blog CMS to have "normal" textarea for input.
But for some reason on forums I do not see many html editors... Even the TinyMCE site has a textarea for their editor. So is there really something to watch out for and a no go...?
I know it is more of a phylosophical question, but I guess you have experience with forums, blogs, etc...
My site is about cooking and beeing able to insert pictures (and upload them) the easy way seems to be a big plus for our home cooks ;-)
If you don't consider security (you'll need to filter the HTML input on the server side so it won't contain anything dangerous), there's only the user experience left for consideration. On a forum you write text most of the time. There's seldom any use for more functionality than bold, italics and images. The solution used here on Stack Overflow addresses this by having a very limited set of functions, and applying it in the textarea with a sane markup language.
Other forums either use old software or didn't think the improved user experience was worth the effort. The textarea-only solution fits most forums well enough since most of the input is text-only anyway.
I do think you would benefit from HTML input. Make sure that only allowed HTML can be sent though, since the user can circumvent everything on the client side.
TinyMCE uses Javascript to add functionality to an existing textarea. If Javascript is disabled, then the user will be presented with a normal textarea anyway.
I would say it's relatively safe, as long as all input from the user is validated on the server before it's used for anything.