xworld21
Joined 11 years ago
Joined 11 years ago
The problem is rather how quickly we can change our ways of working to make sure the training and hiring pipeline does not collapse. That's the disastrous scenario, for both the individuals affected and the discipline, that we must avert somehow. I wish we had an easy answer to that. I certainly don't. But I like to think that at least engaging with the public in a constructive way will have a net positive effect.
As with most interesting proofs, the number of core ideas is actually small, I'd say two for the real exponents, and presumably a third idea for lifting up to omnific integers. I have been redoing the real exponents part of the proof going on the ideas only, and with a few smarter choices, I am converging on something very short. And I mean very short, which is amazing. I didn't think the answer would be this close: it 'just' needs looking at the problem from the right angle, and also make a fairly bold guess at the outcome.
Dan's current proof is of course much longer. Between the fossilized ideas that Dan mentions in the post and the formalisation of previous results, there's a lot of cruft that inflates the proof but does not really help understanding what is going on. Luckily the word 'derivation' pops up early, otherwise it would have been very challenging to wade through the lemmas to find the important points.
Yes, screen readers would typically allow you to navigate the formulas in ways that are more sophisticated than text (not to mention the issues with translating to Braille, which I don't claim to understand, at all). In fact alternative text is a poor substitute for structured information about the formula, which is what you get with MathML.
Plus, the MathML + screen reader combo is deterministic and debuggable, as opposed to OCR'ing an image.
> There is katex-rs[0] that outputs html and mathML. I'd assume the two could work together and the mathML would be fed to whatever the screen reader receives instead of the image?
Maybe! You are parsing the input twice, but it could be a pragmatic solution. I don't know myself how native apps are supposed to expose MathML to screen readers (or if it is even possible without an embedded browser!).
Is accessibility anywhere on the roadmap for RaTeX?
> Even the official Adobe's example of reflowing you posted before is quite bad:
> https://helpx.adobe.com/uk/acrobat/using/reading-pdfs-reflow...
> The reflowed PDF is just stacking all text and removing all non-text visual cues. For example, pairs of name/role are separated by whitespace in the PDF, but after reflowing they are undisguishable from each other (who would be the senior VP, Sunny or Daniel?). In HTML, reflowing would preserve semantically relevant whitespace out of the box.
Note how Richard's book adapts to any screen size, can change fonts and color schemes, system settings such as 'high contrast' will affect the rendering of the page, and you could even use browser extensions to restyle the page to e.g. use a more dyslexic friendly font of your choice.
This kind of functionality is not afforded by Adobe Reader. Even the official Adobe's example of reflowing that was posted in another thread is quite bad: https://helpx.adobe.com/uk/acrobat/using/reading-pdfs-reflow... The reflowed PDF is just stacking all text and removing all non-text visual cues. For example, pairs of name/role are separated by whitespace in the PDF, but after reflowing they are undisguishable from each other (who would be the senior VP, Sunny or Daniel?). In HTML, reflowing would preserve semantically relevant whitespace out of the box.
or dvisvgm, which will produce scalable images. However, images are even worse than PDF in terms of accessibility, which is what the article is talking about.
Is there a middle ground? Whenever I check my content with a screen reader, uncommon foreign names are often mispronounced in ways that are sometimes almost irrecognisable. Even my name comes out wrong, although it would be understandable (typically, the stress ends up on the wrong syllable).