mdalmau
commented
3 years ago @wehooper could you verify how that help documentation should work?
Open mdalmau opened 3 years ago
mdalmau
commented
3 years ago @wehooper could you verify how that help documentation should work?
wehooper
commented
3 years ago (Apologies for writing an email on this issue instead of responding here.)
The LSA component has Help documentation put together that is a separate sub-application created in a user-help writing IDE. Newton_chymistry on possum must be calling the LSA component on maple, as I requested, because it's using the production mysql database. The LSA component on carbon uses the development database with the full set.
The Help document app is working normally from the current live P4 newton site and the newton-dev site, so something is causing a problem when possum tries to start the LSA Help component.
The console messages available in browser-developer tools point to a problem with font configuration:
downloadable font: sfnt size overflow (font-family: "Liberation Sans Alchemy" style:normal weight:400 stretch:100 src index:1) source: http://possum.dlib.indiana.edu:8197/newton/lsa/help/css/LiberationSansAlchemy-Regular.woff
downloadable font: rejected by sanitizer (font-family: "Liberation Sans Alchemy" style:normal weight:400 stretch:100 src index:1) source: http://possum.dlib.indiana.edu:8197/newton/lsa/help/css/LiberationSansAlchemy-Regular.woff
downloadable font: no supported format found (font-family: "Liberation Sans Alchemy" style:normal weight:400 stretch:100 src index:5) source: (end of source list)
A quick search of the forums suggests that people starting encountering this error after an upgrade to apache so it's a known issue.
Hypothesis: I think the Help app actually loads along with the new 2020 header, but the font is blocked, so no text appears.
In any event, would someone with access to possum please solve that font loading issue?
If it's an easy fix, great.
If it's not easy, I may be able to change the font that the Help app uses (unless there are symbols - - - I have to check).
wehooper
commented
3 years ago The LSA component component also wants to use the same font, "LiberationSansAlchemy-Regular," for its text, drop-downs, etc, and the side-by-side displays, but possum seems to be blocking that as well. The font loading problem affects both apps.
Unlike the single-font Help app, the LSA component does fall back to another font: the newer Newton project font, "Newton Sans Alchemy," so we get a display in a deceptively familiar font.
Background: I created the LSA component in 2009 before we submitted our Unicode proposal, so it uses a project font I had created in 2008, LiberationSansAlchemy-Regular. In 2009, I had to reorganize the symbols to support the Unicode proposal, and I created 'Newton Sans Alchemy' to accomplish that, and the Unicode Consortium actually uses our character set in its tables for the Alchemy plane.
Can the font-loading configuration be fixed?
I would have to translate the texts and lists in both the production and development mysql databases to move the whole LSA operation to Newton Sans Alchemy. In fact, it's on my job list for the next few months - - - I was hoping not to have to do it this week. : )
wehooper
commented
3 years ago The current LSA component on carbon responds to users calling from the old P4 webapp and from the new P5 webapp at 8220 but it was designed to use resources found in the P4 webapp (headers, the old Liberation Sans Alchemy font, and javascript), which needed to be corrected. While the P4 webapp is still available, P5 webapp users who open the LSA component face new https: security restrictions that block the font.
I rewrote the LSA component to include the necessary headers, the Newton Sans font replacing the Liberation Sans, and javascript resources, and the tested and completed component was uploaded to github/IUBLibTech by October.
I'd like to meet with Jim after the walk-through to take those steps. The revised component is working on sitehost-test and my own equipment, so I'm confident it's ready.
I also updated the MySQL database so it uses the Newton Sans font, so the dlib mysql databases need to be updated at the same time. I have EXPORTed a SQL copy of the updated database on HPC computers, and that can be IMPORTed, if that can also be arranged with whoever is serving as DLIB's mysql root.
Jan 12
randalldfloyd
commented
2 years ago This issue blocks being able to get the xproc app into full production and possibly being able to migrate all instances of Newton, legacy or xproc, off of RHEL 6/7 servers and onto new server infrastructure.
I have a lot of info from testing, but here's a quick summary to alleviate any confusion as to what works and what doesn't:
The intent in the new xproc app is to not directly link out externally to a version of the LSA tool, but to "proxy" the LSA tool from an external deployment, merge its HTML into the response, and bring it into the browser as if it is a part of the xproc app. As far as I can tell, this doesn't work in any permutation on our servers. It doesn't matter where the xproc app is deployed, or where it is trying to proxy the LSA tool from, the result is the same, which is the broken font issues described elsewhere in this issue. And by that I mean that not even proxying the LSA from older static PHP on legacy servers works, so as to not conclude that the issue is in a newer deployment of the LSA tool.
This ideal of proxying the LSA tool's responses through the xproc request cycle seems tenuous to me, and even if I have the ability to troubleshoot/fix this, any number of environmental conditions could break it again or create varying symptoms (already true, see below.) If this was done purely to keep the URL the same, there are better ways of accomplishing this at the web server and continue to access LSA as a separate application.
For externally linking out to LSA as a separate app, we have two sources to draw from: the statically served PHP (on either webapp1 or carbon), or from the newer incarnation that was intended to reorganize the CSS assets. The latter is also broken but in a different way than the font problem - it can't find the CSS assets and so it doesn't try to load the offending fonts. So it's hard to tell what the status of it actually is, and whether or not it would have the font problem once the CSS issues are resolved.
The following is a more detailed description of what methods of access work, and what doesn't:
Direct access of static legacy PHP on webapp1:
Direct access of static legacy PHP on carbon:
Direct access of "new" LSA on possum:8271:
LSA proxied via xproc app on carbon, accessing static legacy PHP on webapp1:
LSA proxied via xproc app on carbon, accessing static legacy PHP on carbon:8127:
LSA proxied via xproc on app carbon, accessing "new" LSA on possum:
LSA proxied via xproc on app possum, accessing "new" LSA on possum:
LSA proxied via xproc on possum, accessing static legacy PHP off of webapp1:
I tried the Latent Semantic Analysis tool. I have no idea how it works, but it seems like it did whatever it was supposed to, however, if you hit “HELP Documentation”, a window pops up with nothing in it on Possum or Carbon. Reported by Alex Wingate.