-
Notifications
You must be signed in to change notification settings - Fork 15
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
feat: use highchart offline export for downloads #3135
base: master
Are you sure you want to change the base?
feat: use highchart offline export for downloads #3135
Conversation
🚀 Deployed on https://pr-3135--dhis2-data-visualizer.netlify.app |
3822611
to
41e6cf4
Compare
I have had a meeting with team-platform and we discussed the problem from two angles: The general inability of specifying a script in a DB locale stringWhile considering the problem from this angle it became apparent that how we deal with locales in general needs some structural decisions. Is having multiple scripts per locale a use-case we want to support on a single instance, since it introduces a level of complexity? Do we need to keep distinguishing between UI and DB locale and that also introduces a level ambiguity? Etc, etc.... So this turned out this is a very broad topic which needs to be discussed and investigated thoroughly, and as such it will be a long time until this is resolved. At the same the fact that our DB locales do not support script sections is also a practical problem in the field that the Uzbek instance is working around using bit of a hack.... They now use The inability to generate PDFs correctly for non-ASCII scriptsViet brought it to my attention that the sever-side PDF generation endpoint is not just being used by the data-visualizer-app, but also by the reports-app. I already knew that the client-side solution in this PR only partially solved the problem because the single-value visualisations would still rely on the server side PDF generation endpoint, but now I realise that the problem is more widespread. ConsequencesThe points above makes me think that a fix to the server side endpoint would be more suitable than the client-side solution I have implemented in this PR:
I have some outstanding questions with Viet about the server side solution, but if what I mention about the combined Noto font is possible, then I would be in favour of closing this PR completely in favour of a server side fix. |
abea112
to
0b434bf
Compare
Implements DHIS2-17722 and also fixes DHIS2-12103.
Requires dhis2/analytics#1688
Key features
Description
Switching from server-side to client-side file exporting itself didn't require much work, but I then found that specific languages needed specific Noto font bundles. The majority of the work went into researching which bundles are needed for which scripts/languages and discussing the of "selecting the correct font". Some of these discussions are still ongoing, and may actually impact my implementation.
TODO
Known issues
script
section. However it is currently not possible to add a script to a DB locale (see last TODO).Screenshots