I've come across a weird problem whilst trying to optimise the following image:
It should have a little shadow down each of the left and right hand sides. However, in webkit (tried mac safari and chrome) the right hand edge loses its little shadow entirely. I've used multiple utilities to create the image and even tried copying a flipped version of the left hand side to the right, all to no avail.
Have I generated the png incorrectly or does webkit have a problem? It looks as it should in Firefox, IE etc.
This may have been a bug with the WebKit rendering engine, but it appears to render correctly now.
Related
Here, I have tried a various approach for loading a PDF to the canvas. First thing is I used the library PDF.JS to load the PDF in canvas. The problem I faced with PDF.JS is that when I try to zoom in to the PDF - [
I tried two approaches
Zooming in to the object and the canvas - which made browser crash in a certain point in scaling
Converting the image as a object and loading it to canvas using Fabric JS and zooming in to the object - which made the pixel to break while zooming in (scaling was not proper to a certain point while zooming in)]
So, suggest me some best way to upload a PDF in canvas with perfect scaling while zooming in without any crash to the browser when I upload some bigger size PDF.
Thanks In advance! :)
I don't know if you still need this, but I stumbled upon a tutorial a few days ago that exactly shows how to do your use case (if I understand it correctly and you're trying to zoom in). You can check it here:
tutorial
It looks like there is a bug in Bootstrap. If you change resolution, for example with ctrl + (+/-) in your browser the addons are not properly adjusted. It looks like this:
Notice the wrong sizes of addons.
Is there a simple way to fix this?
No, there is no simple way (and quite possibly no way period) to fix problems related to the type of zooming that you're referring to (as opposed to the viewport-width-based zooming that you get when using the pinch gesture on touch-based devices).
Per Bootstrap's documentation:
Page zooming inevitably presents rendering artifacts in some components, both in Bootstrap and the rest of the web. [... these issues] often have no direct solution other than hacky workarounds.
Zooming in and out is not changing the resolution at all its zooming and is completely different from changing the view port's aspect ratio and dimensions.
Give the input area a fixed width like input {width:100px}
macos 10.7.5
chrome Version 32.0.1700.107
Version 32.0.1700.107
and the simple "single.html" helpfully provided by gcpdev:
live code examples: cytoscape.js initialization -- incomplete?
Any movement by the mouse in the canvas makes the nodes disappear. zooming and and out (with middle mouse roller button, for instance) makes them visible.
This problem is only on Chrome. Firefox and Safari work fine.
Any suggestions?
Thanks!
Paul Shannon
I can't reproduce this on Mac OS 10.9 with Chrome 32, which probably indicates this is a problem with Chrome rendering canvas on that version of Mac OS.
I notice that the linked demo is using v2.0.2. Have you tried an updated v2.0.x release or v2.1.0?
Try using pinch-zoom to set the zoom level for the webpage (not for the Cytoscape canvas element, which has its own separate zooming operated by scrolling with two fingers on the trackpad) to 100%. This fixed it for me, based on this question and this github issue, both about an almost identical issue in Firefox.
I just got to test IE10 on a Surface Pro with 1920*1080 display resolution where "make text and other items larger or smaller" has been set to Large.
On my website I have added the CSS+JS viewport fix in addition to the viewport meta tag, all asking for width: device-width (plus I added a "min-width: 320px;" to the #-ms-viewport definition to ensure it never gets smaller than that).
I added some javascript to display the value of window.screen.width and $(window).width to see what the browser ended up using for viewport in IE10, and to my surprise the screen size of a 1920*1080 resolution display was reported as 1280x720!
Now, I can live with with that (just like small phone screens report 320px width no matter their actual resolution, since it is a good size to make stuff human readable across devices for the same font size), but when the 'Metro IE10' is snapped to the side of the screen, the problem comes: IE10 tries to make a 320px rendering of the website, but it zooms in so the right side of it is hidden.
I tried Microsofts own test page: http://ie.microsoft.com/testdrive/Graphics/MakeItSnappy/
It does the same thing - on the Surface Pro the right side is hidden, and you need to drag left/right to see it, and you cannot even zoom out to view the full width!
But when trying the same thing on my laptop with a 'normal' 1366x768 display (rendered as 100%), the snapped IE10 display has the perfect size.
Ok, I guess this is a Microsoft Windows scaling bug - but my question is: Has anybody else experimented with changing the "make text and other items larger or smaller" to 125% or 150% and making websites adapt correctly?
Check out this fix from developer Matt Stow
http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html
I've been trying to render the entire canvas in an IWebBrowser2 control to a bitmap. IViewObject::Draw seems to be the most promising approach, but I can't get it to render anything that would requires a scroll to show. While I could automate the scrolling and stitch the images together, this would look weird with any fixed position elements. Is this even doable?
Additionally, I've tried to set the controller's size to one that would allow the entire contents to display without needing to scroll, but Windows caps the max size to the current screen resolution, so that only gets me partially there.
Any help would be much appreciated. I'm currently doing this in the context of Win7 and IE8, but I don't think that should matter much.
Sorry it took so long for me to follow up with the answer to this.
I wrote up an article detailing how to trick Windows into allowing you to resize a window larger than the virtual screen resolution, allowing functions like PrintWindow or IViewObject::Draw to capture the entire client area (i.e., the browser canvas).
http://nirvdrum.com/2010/03/25/how-to-take-full-page-or-full-canvas-screenshots-in-windows.html
An actual implementation of the technique can be found in my SnapsIE repository on GitHub (username: nirvdrum). Unfortunately I don't have enough karma to post two hyperlinks. The repository is linked from the article though.
It is very likely an IE optimisation that avoid to draw more than required. You might be able to scroll the window and call IViewObject::Draw in a loop without any animation occuring ?
I'm surprised that Windows caps the max size to the current screen resolution. Are you sure about that ?