EDIT 2: An even better solution, for me, was to just use offsetWidth and offsetHeight as that will return the width without the transformation applied. But getBoundingClientRect() was used for a reason, as there is a comment next to that part mentioning a bug with Gecko and resizing tables with captions. The application I am working on is quite cutting edge, and is only required to work on Google Chrome as it is an internal application, so this fix is better for me, but still not ideal.
EDIT 1: I have found a way to fix this, but it required changing the TinyMCE source code, since the application I'm working on keeps track of the scaling applied to the contenteditable area, I was able to just insert my scaling multiplier as a divisor and apply it to the targetWidth and targetHeight variables in the function showResizeRect() on lines 14,197 and 14,198 of the unminified tinymce.js file (as of v4.2.6).
This is not an ideal fix, so I preferably like to do this a better way, so if anybody knows of a better way that does not including changing the TinyMCE source, then please enlighten me.
You can see the bug report I filed here.
I'm having an issue with TinyMCE, I am working on a web application, and we are using an inline TinyMCE instance to edit content that is inside a scaled contenteditable container. However, when going to resize an image, the resize handles are smaller than the image. Here is a demonstrative image:
I have searched on Google, but did not find anything relevant. Is there a plugin, or perhaps a workaround that deals with this already?
Thanks in advance.
Related
This is perhaps a more general question as I'm looking for ideas on how to approach a problem working with PDFView/PDFKit. I have a small sample application that allows you to display a page, select a range of text and then associate a comment with that text. Once the comment is saved the comment is displayed on the PDFView page in the margin via an overridden draw() function for PDFView.
Problem is that with very small margins the comments can be very squished. I've been looking for a straight-forward solution and would very much appreciate ideas on how to address it.
The obvious (ie, easy) solution is to change the actual "page size" in the PDFView and have wider margins, but of course PDFKit has no support for that (I don't think). Another thought was to go to a custom PDFView library but the only ones I found when I last looked were iOS (not Cocoa) based.
Last idea was to instead of drawing directly on the page have some sort of pop-up window (like a sticky-note) contain the note but then it would need to be moved dynamically with the scrolling of the page. And of course one other was to recreate the PDF dynamically for viewing and make all the pages larger... but I've not dug into how much of a performance hit / effort that would entail.
Maybe there's a simple/obvious solution that I've missed?
I created a simple sample app in gitHub which shows the basic functionality for people to play with if that's of help. https://github.com/jcnolan/PDFMarginTextView
I know I can get the whole body of a document with context.document.body.getOoxml() and the current selection with context.document.getSelection(), however I can't find a way to establish what is currently on screen and what is not...
Is there a method in the Word Office JS api to retrieve only the content currently displayed on the screen?
There isn't a solution for this. The way some of the JavaScript libraries in web pages are able figure out this problem is through the view port.
Example here: https://www.customd.com/articles/13/checking-if-an-element-is-visible-on-screen-using-jquery
See another helpful SO answer here: Get the browser viewport dimensions with JavaScript
Now - Word however uses HTML as a way of formatting - and not as a way of directly displaying things. So even if you could run the same library on the HTML - it wouldn't have the same context.
The best you could do is to get the height of the visible space (which should be the same height as your add-in frame) and attempt to do some mapping. You would have some weird edge cases though, like if the font-size is different, or you have a page-break in the view etc...
I also have this issue. I am using Ubuntu and just completed the Hello world tutorial. I wrote some more text and I am unable to scroll. I can see where the words keep going but nothing I have tried lets it scroll. I have not made any HTML/CSS edits. I have only added more text to the <p> tag.
There is some default CSS applied for chrome packaged apps. Putting the following in your CSS should re-enable scrolling:
html {
overflow-y:scroll;
}
Someone is putting together a cool guide which might have some more tips. See https://gist.github.com/maicki/7622137#scrolling
Chrome apps have a default stylesheet applied to them, to help the web "page" be more of an "app" by default.
For Chrome Apps on Mobile, we also include this (well, a nearly identical) default stylesheet.
So that is the reason for that behavior. Scrolling is absolutely useful in very many contexts, and is absolutely supported in any DOM element by adding overflow-y: auto;.
It was simply deemed to be the wrong default for packaged apps which live inside a dedicated window of set bounds and where we encourage not having full page content overflow (very much the opposite of the web). Most apps usually surround a main scrolling element with fixed navigational elements (but not always).
FYI, there is also another open issue for Chrome Apps on Mobile to replicate yet more of the Chrome for Desktop default styles.
I'm using FusionCharts in my webpage. i'm rendering the same portlet with fusioncharts twice in the page. Sometimes i'm getting a big Exclamation Mark (!) in a grey circle in the place of charts.
And it happens only sometimes, so i'm not sure how to replicate this scenario or why this happens.
Has anyone faced similar issue?
Note: the div id for the fusioncharts is different in the page. So same div id is not whats causing this.
If anyone can give me any solution, it will be great.
Screenshot:
Unfortunately, i cannot share the code base in the forum. I'm sure there is nothing wrong in the code because the chart renders almost always. This happens very rarely but still is a problem.
Without a code or sample that can reproduce this, my answer would be based on checking the best practices
Ensure you do not have duplicate chart id
Ensure you either re-render existing chart or update data - at least ensure to dispose unneeded charts if you are re-rendering
Ensure that the div where chart is being rendered is "visible" during the rendered process.
If you have many interactive activities with the charts - like tab change, etc... ensure you sync them with chart events such as rendered, disposed, etc (this will avoid issues with errors in partial rendering of charts)
Check your JS console for errors when this (!) things happen.
I am curious though ... something is rendering the (!) ... if you are rendering Flash based charts, it maybe due to Flash plugin crashing. Try forcing JS rendering of charts.
I try to migrate our custom plugins from TinyMCE 3 to 4.
In some cases there is some text in the plugin's window to describe how to use it.
Fiddle example: http://fiddle.tinymce.com/Hndaab/1
So if the text is very long, the window width increases until some parts are out of the viewport.
How can i tell the WindowManager to use automatic word wrapping for my labels?
I already tried to define a width for the window. And in another plugin i found a param "multiline". Both didn't solve my problem.
Any ideas? Thank you
I've been trying to accomplish something similar for mobile commpability where the windows are to large for the viewport and so far the closest i've gotten is to set the css for .mce-window to
.mce-window {... max-width:100%;max-height:100%;}
maybe that will be enought to fix your specific problem, even if I still have some ways to go for it to fluidly only fill out the available viewport space on all other windows.