-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/dash-preview: Fix window size #250
Conversation
@antoinerg or @etpinard Please review. |
If I understand correctly, the idea is to have the size of the viewport match the size of the page so that when printing to PDF, figures are already appropriately sized. For this to work properly, we need to know the DPI of the screen. Right now, it is hardcoded to 96: orca/src/component/plotly-dash-preview/constants.js Lines 1 to 2 in 1d56807
This will not always be the case. I imagine that xvfb defaults to 96 so this is why this fix works in the Docker image. We should probably specify this DPI value in case the default changes in the future. It should also be noted that the current fix will not work for desktop users with a high-density display.
Finally, although I understand this needs to be fixed urgently, I am getting a bit uneasy about merging things that aren't tested on CI. |
Dockerfile: add package-lock.json before npm install, copy Orca last 🐎
132c944
to
88f3c3d
Compare
If that's the case, we should also round off the window size if the user specifies pageSize as a string: orca/src/component/plotly-dash-preview/parse.js Lines 39 to 40 in 5c1f71d
|
I don't think commit f2a2bad is necessary. It would be much cleaner and DRY to round off the numbers on line 59 just after the following block just before passing them to the renderer: orca/src/component/plotly-dash-preview/parse.js Lines 39 to 60 in 574241a
|
* `enableLargerThanScreen`: Allows us to specify height/width larger than the max screen size. * `useContentSize`: Does not count the "top bar" in the size. Only the web-content size is taken into account.
640x480 seems to cause issues with some dash apps, so I am reverting it to the default value (which works) until we figure out a better way to handle page sizes.
574241a
to
f5a736f
Compare
@@ -40,7 +40,7 @@ pkill -9 Xvfb | |||
pkill -9 node | |||
pkill -9 electron | |||
|
|||
xvfb-run --auto-servernum --server-args '-screen 0 640x480x24' /var/www/image-exporter/bin/orca.js serve $REQUEST_LIMIT --safe-mode --verbose $PLOTLYJS_ARG $ORCA_IGNORECERTERRORS_ARG $@ & | |||
xvfb-run --auto-servernum --server-args '-screen 0 1024x768x24' /var/www/image-exporter/bin/orca.js serve $REQUEST_LIMIT --safe-mode --verbose $PLOTLYJS_ARG $ORCA_IGNORECERTERRORS_ARG $@ & |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really necessary? I thought this line: createBrowserWindowOpts['enableLargerThanScreen'] = true
would make the result independent of the screen resolution 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was under the same impression, but apparently it doesn't. Should I remove that option, or let it be there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is unfortunate... I wonder if that is fixed in recent versions of electron
(see branch pr-bump-electron-6
).
Anyway, changing the resolution of the screen seems like a short-term solution: what if a user needs a bigger browser size than 1024 by 768... We're essentially putting a limit on how big a page we can print. If so, it should be clearly stated somewhere. By the way, what do you mean when you say it "works" (ie. how/what are you testing exactly)?
Okay so I can see that with your latest commit we go from a PDF with a figure not filling the page (before.pdf) to one that does (after.pdf). |
This is related to (another) issue: https://github.com/plotly/dash-snapshots/issues/62 . Looking at Please test that for the 4 possible input body:
|
I have changed the base to |
@tarzzz By the way, I can confirm that this component mishandles 2 of the 4 scenarios described in #250 (comment) |
e53bb42
to
0943a79
Compare
With commit 0943a79 I introduced new tests that enabled me to discover bugs in the way we used to parge It fixes:
|
@etpinard I'm taking over this PR so I might need you to review it. |
If this doesn't go into 3.3, this means that snapshots will have figures that are not sized appropriately. I am pretty sure that @chriddyp and @ycaokris want this in. I will let them confirm whether this is the case or not. cc @tarzzz |
I'd like to know what's further steps we need to do in order to merge this into |
💃 thanks for taking care of this! I made one non-blocking #250 (comment) |
Detailed explanation in: https://github.com/plotly/streambed/issues/13458#issuecomment-534274326