Print preview svg rendering incorrectly with css scaling
Reported by
nchadw...@p2es.com,
May 26 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Open web page located here https://neisha.github.io/chromeprintingbug/ (also attached) 2. Press CTRL + P to print preview 3. Ensure your page settings are on Landscape orientation What is the expected behavior? The print preview (and printed material) should look the same as the browser renders. What went wrong? Some of the svg elements are out of alignment. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 58.0.3029.110 Channel: stable OS Version: 6.3 Flash Version: I have tested this in Chrome, Chrome Canary and Opera with the same issue. It works in IE 11. I have put a blue border around the grid cells to show where the svg elements should be contained. This is quite critical for our software (which only supports Chrome and IE 11). The example I have provided is a simple test case, but our software uses D3 charts and svgs to render visualisations, which are getting cut off because they are out of alignment when printed. Our css seems correct, as in it renders correctly when we emulate print mode using the Chrome developer tools, however when the print preview is shown, the svgs are out of alignment. This leads me to think that the problem is occurring when turning the page into a pdf for print/print preview. Our app is quite complex and uses dynamic layout code written in javascript to determine the sizes of grid cells. The pages are then scaled for printing to the page size. The code I have provided is literally just copied from the end result to be able to show an example of what is happening. If you play around with the page sizes/orientation then different svgs get offset, but I believe it would all be connected to the same bug. I have tried all sorts of css changes to get it to render correctly. The only thing that seems to make a difference so far is to make svg elements position:absolute, which also breaks some of our visualisations. A pretty terrible workaround, but slightly better than what we have now.
,
May 26 2017
+Blink>Layout for input as this looks like it could be a layout issue. This also reproduces on Linux. Can't test in print browser mode as the error only occurs when you set landscape orientation for letter paper; in portrait the right hand side gets cut off. Interestingly, moving the bottom margin around changes this quite a bit. The bottom set of lines seem to track it for values > ~2.1in and the middle set of lines move as soon as the bottom lines start pushing into the second row. Can also reproduce this in Portrait orientation if you set A3 paper and set the bottom margin to something like 8.4", so it isn't unique to landscape PDF orientation, just seems to be an issue when the entire grid width fits on the page and the bottom margin is relatively close to the bottom of the grid.
,
May 29 2017
Thanks for looking into this. Your observations match what I'm seeing. I originally saw the bug when scaling a portrait aspect page on my vertical monitor down to an A4 portrait printing page. So not unique to landscape or page size. I am also seeing the middle row move sometimes instead, and can reproduce this in our software with different number of columns/rows in the grid. Hope this info helps, let me know if there's anything else I can provide.
,
May 30 2017
,
May 31 2017
Interesting problem. We seem to be moving things around based on the bottom and right margins, rather than referencing everything from top left. Given it's only printing we should be able to work this out (though maybe if you resize the viewport it happens in regular painting too). Printing includes pagination code, which may also be important.
,
Jun 1 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2018
Still broken.
,
Jun 2 2018
Yes still waiting on a fix for this. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by nyerramilli@chromium.org
, May 26 2017Labels: Needs-Triage-M58