search

OpenClinica / enketo-oc

OpenClinica's fork of the Enketo web forms monorepo
Apache License 2.0
0 stars 1 forks source link

Overlapping DN history on PDF #88

Open theywa opened 2 years ago

theywa commented 2 years ago

Describe the bug Overlapping DN history show on PD that created using API.

like this overlapping history Participant_OC-15060-001_Casebook_2022-02-01-042446492+0800.pdf

MartijnR commented 2 years ago

If this issue is limited to the DN query history, is it possible to fix this in enketo-express-oc instead?

I did look briefly at the PR in enketo-core, but I don't think we can make a case to fix it there if it is purely related to DN query history. (Fwiw, also (1) there was already a variable called delay which makes it hard to read, and (2) not clear why the delay should increment for each element).

theywa commented 2 years ago

@MartijnR ~ yes, currently this issue is limited to DN query history. Maybe you have any idea or thought why this issue happen? Usually, it works fine if DN query history is not much or if the form is small. But the issue will show if the form is large, especially if multiple forms are combined in a single pdf using API(oc/api/v1/instance/view/pdf). Is there is a way to debug it(check the style file before it printed using API)? I did comment on some code in API to make sure the file that was printed is not from the cache when testing.

I did look briefly at the PR in enketo-core, but I don't think we can make a case to fix it there if it is purely related to DN query history. (Fwiw, also (1) there was already a variable called delay which makes it hard to read, and (2) not clear why the delay should increment for each element).

1) Yes you're right, sorry I don't see it. I guess these works is not correct then. 2) I thought since the overlapping is not happening for all the DN history, maybe the timing is the problem, not the CSS that's why I think to add delay to give each element more time to resize.

MartijnR commented 2 years ago

I think you're right about the timing. It sounds like this happens because the DN history HTML is dynamically added to the DOM. It looks like the MutationsTracker in fixGrid in enketo-core's print.js is not working for this.

However, it seems like you might be able to use a similar solution before calling fixGrid (in printOcForm or printGrid in gui.js in the fork). E.g. by tracking a class change that the dynamically-added history items have (I believe they are added by the DN widget).

Would be nice if we could avoid adding a fixed delay.

dduval11 commented 2 years ago

Hi @MartijnR is it possible to investigate further in enketo please, it appears @theywa is still unable to find the root cause and a long term fix for this