Closed jojoob closed 9 years ago
Which theme are you using? It might be worth trying some of hte Moodle standard themes, just to see if the problem is theme-specific.
Another thing to look at is whether there is any CSS that takes effect only when you try to print.
Basically, I think you are going to have to debug this a bit.
It is not suprising that ddmarker shows the same problems. The two share a lot of code.
The problem seems not theme specific. I have tested many standard themes (standard, magazine, nimble, clean). Also changing the page layout (standard, print, base, embedded) has no effect.
I can't find any specific CSS that takes effect only when printing (media=print).
For testing I'm using a blank Moodle installation with just ddmarker, ddimageortext, ddwtos and gapselect installed.
Can you give me further advice to troubleshooting this?
My assumption seems to be right: "I suppose this is due to wrong values for page width and height the JavaScript uses to placing the items."
I figured out that window.innerWidth
is used to place the drag items by JavaScript with little delay after changing window size. Page print resizes relative html/css elements but drag items are placed absolutely. Maybe page print does not execute any JS or just the specific function to place the items is not triggered.
When I'm on browser I could change the viewport size near to the print area first and then print the page. But when I use wkhtmltopdf the drag items are still shifted vertical. @timhunt can you tell me how the vertical placement works?
Sorry, don't know. I have not looked at the drag-drop javascript in ages.
Is there some JavaScript event that is fired when the page is resized ready for printing?
Do all web browsers behave the same way?
I haven't found such an event yet.
Same problem in all browsers I have tested: Chrome, Firefox, Safari. But the problem with wkhtmltopdf bothers me the most at the moment.
I assume you are using the --enable-javascript and --javascript-delay options to wkhtmltopdf http://wkhtmltopdf.org/usage/wkhtmltopdf.txt. I wonder why that is not sufficient?
I know nothing about , but looking at the docs, the --run-script
Since this works in Chrome and Safar, and since wkhtmltopdf uses the webkit rendering engine + JavaScript, fundamentally this should work.
--enable-javascript
and --javascript-delay
are essential. But --debug-javascript
gives no additional information in this case.
With --run-script
it's possible to set window.innerWidth
and window.innerHeight
but with no affect of placing the drag items.
--viewport-size
has also no affect in this case.
Drag items are still shifted vertical:
I was assuming you would edit the JavaScritp, to make it output more debugging informatino until you could work out what was, or was not, happening. Sorry, I don't have time to look into this myself. I hope you manage to work it out.
I think this is related to issue #27, repairing JS code solved me that problem too.
Thanks for diagnosing this Pau. Closing.
The drag items get shifted (items not in origin position but shifted horizontal and vertical over the page, sometimes even out off the drop zone) when printing the review page. This behavior also appears on printing preview or export to pdf. I suppose this is due to wrong values for page width and height the JavaScript uses to placing the items.
Is there a chance to easily fix this or maybe a workaround? Maybe wrapping the drop area in a box and positioning the items relative to the box instead absolute on page? I seen YUI Library is used for rendering the question type... I never worked with this before but anyway I also disposed to help working on this problem. In my greenness I think render the question with CSS would be a better solution - but probably to much work to change.
By the way I'm working on a moodle report plugin for quiz attempt export to pdf for archiving purposes.
Edit: same problem with ddmarker qtype: https://github.com/moodleou/moodle-qtype_ddmarker