MathML in Firefox OS - firefox-os

I am doing a small project where I write mathematical texts in HTML using MathML. When I test it on Firefox, the results are as expected, everything is displayed as expected.
However, in Firefox OS 2.0 (that I would expect to work in the same way), there are problems with characters like the real set (ℝ) or the star (⋆), which are displayed as gray blocks.
Is this a problem with Firefox OS or there are specific tags to be notified on the HTML that allow these symbols to be correctly interpreted? Or is there another way to represent this symbols?

What you are seen is the replacement character, often a black diamond with a white question mark, �, that in Firefox OS is a gray block.
Why you seen the replacement character only in Firefox OS? Because only Firefox OS hasn't the character that you need. As Jason Weathersby already mention, you should check https://bugzilla.mozilla.org/show_bug.cgi?id=775060.
Last year I worked with Firefox OS and MathML for Google Summer of Code, https://r-gaia-cs.github.io/gsoc2014/, and had to build my own image of Firefox OS to have properly fonts available. If you want to try build your own image of Firefox OS with fonts that support MathML, read http://ftb.rgaiacs.com/2015/03/16/math_at_firefox_os.html.
Gays blocks normally means that the font that you are using doesn't has the character.

Related

Why fonts in Qt are appearing blurry or pixelated?

All my fonts are appearing pixelated, so I used AntiAliasing but it isn't helping out. As you can see the pixelated font in the image itself:
This is the code I am currently using:
butt1 = QtWidgets.QLabel("""Scrappr""")
font = QtGui.QFont()
font.setStyleStrategy(QtGui.QFont.PreferAntialias)
font.setPixelSize(22)
font.setFamily('Segoe UI Bold')
butt1.setFont(QtGui.QFont(font))
I tried different solutions on SO, qtforums etc but nothing works for me :(
I tried:
Different combinations of ClearType text but It didn't work out as, by default all the text appears good on windows and chrome but with Qt only, it becomes pixelated.
Changing windows aero theme to classic one...
But none of them helped.
Here are My PC Specs:
windows: 7 ultimate
PySide2 version: 5.14.2.1
Resolution: 1360 X 768
I'm using BrownPro font and the texts were blurry at all resolutions, but much more evident at low resolutions.
I was able to solve the issue by setting the hinting preference for the font to: PreferNoHinting. Applying it at the application level, fixes the issue everywhere.
Here is the documentation: https://doc.qt.io/qt-5/qfont.html#HintingPreference-enum
And here is the code I used:
QFontDatabase::addApplicationFont(":/fonts/BrownPro-Bold.ttf");
QFontDatabase::addApplicationFont(":/fonts/BrownPro-Regular.ttf");
QFontDatabase::addApplicationFont(":/fonts/BrownPro-Light.ttf");
QFont brown_pro_font("BrownPro");
brown_pro_font.setHintingPreference(QFont::HintingPreference::PreferNoHinting); //This line did the trick
QApplication::setFont(brown_pro_font);
Try to see the fonts used by PyQt5:
import PyQt5
from pyQt5 import QtGui
dir(QtGui.QFont)
the result will show all you need for QFond and the fonts can be used:
[..., 'Helvetica',...,'SansSerif',..., 'Serif',..., 'Times', ...
You can try to add your custom fonts but you need to test each font.
For example, the documentation tells us:
In Windows a request for the “Courier” font is automatically changed to “Courier New”, an improved version of Courier that allows for smooth scaling. The older “Courier” bitmap font can be selected by setting the PreferBitmap style strategy (see setStyleStrategy() ).
Once a font is found, the remaining attributes are matched in order of priority:
fixedPitch()
pointSize() (see below)
weight()
style()
I happen to work with Qt last year and i used qml for building the UI part of my application.
Qt itself prefers us to use qml for building UI, since they have written a UI engine that renders everything better compared to the old engines.
In case of PyQt you are using the python only approach which is only not usually recommended, i am not saying that the qml version is pixel perfect. it still works bad at drawing curves (but that is not the stuff we usually require). As far as your problem is concerned qml will work fine for you (it has much better text rendering).
You might struggle a bit finding the learning resource for qml. But at least give it a shot and yes it is easier much easier than Python only approach.

unicode box-drawing does not render correctly in browsers

I recently discovered this historical document, which purports to act as a test of UTF-8 encoding for whatever application displays it.
When I paste it into my terminal (iterm2), it loads the box drawings at the end beautifully (except for a couple at bottom right):
But in both Chrome and Firefox, they are crooked and clearly wrong:
It seems the difference has to do with the width of the rendered character: for example "╲" displays in my terminal as wide as other characters such as "a", but in the browser it displays wider.
Is this a deliberate choice, and if so what inspired it? If not, where is the right place to file a bug?
EDIT
Thanks to Tom Blodget's answer, I am now aware that fonts are an important consideration. I'll clarify:
In my screenshots above, Firefox and Chrome are using Courier as the monospace font, while the terminal is using Monaco. In both contexts, the font seems to apply as much to the box-drawing characters as to the ASCII ones: when I change the font, the appearance of the drawings changes as well as that of the surrounding text.
When I switch the terminal to either Courier or Courier New, it shows the box drawings equally well -- in some ways better!
When I switch either browser to Monaco, it still shows the box drawings wrong, again from characters apparently displaying at a wider-than-monospace width.
So it still seems like the browsers are doing something wrong.
When I go to dev tools, I see the entire test is one pre element. Several fonts are being used on my system. Everything looks okay except the hatch pattern on the right.
If I hack out all of the other text, the only font used is Consolas and it looks okay. I think it's down to which fonts you have, how the browser prioritizes them, especially when it has to use more than one, and (conjecture) two monospaced fonts need not have the same width.
A terminal is likely to be less adept at using multiple fonts, instead, using one fixed one or selecting one "best" match for the required characters.
[Google Chrome 72.0.3626.96 on Windows 10.]
This is likely the same as https://bugs.debian.org/981577
If you have any old fonts installed that don't cover the unicode BOX DRAWING range, it's likely that your browser is stitching them together. While each font itself might be monospace (each glyph is the same width within the font), the combination of fonts might not be monospace (because glyph width differs between fonts), which is why the alignment fails.
I found on my system that uninstalling the legacy Bitstream Vera font resolved the issue. (Bitstream Vera has been superseded by DejaVu Sans)

Chromium and Firefox display colors differently and I don't know which one is doing it right

I've been building a website under Ubuntu 17.10 and use Firefox and Chromium for testing. The two browsers show quite different colors (not only for images but all colors) and I always thought that it is Chromium which for some reason wrongly over-saturates them, so up until now I always chose colors that looked right in Firefox.
But I'm starting to get more and more complaints about the website's background being too purple - which it shouldn't be in my opinion as only the blue component of it's color (#eeeeff) is "elevated", but it has reached a point that more people are seeing it as purple than blue, what makes me confused.
This is the aforementioned color displayed in Firefox (left) and Chromium (right).
And this is how I see a website:
The difference is quite large (notice how even the favicon is different) and I'm asking you to tell me which one is the browser I should trust when choosing the colours of my websites and whether I could do something to avoid it being displayed so differently in different browsers.
(There are some users that see the overly saturated colors in Firefox too. So now which is the right one, really?)
Another option is to open chrome://flags/ and select the option sRGB on the Force color profile item.
By using this setting instead of disabling the Use hardware acceleration when available, you don't lose some nice features like the 3D view on Google Maps.
Solution found here: https://www.reddit.com/r/Fedora/comments/74h5yh/blue_shows_as_purple_in_chrome/
Using GPick as a Color Picker and calling a Website with Color Hexcode like
http://www.color-hex.com/color-palette/54430
I see, that Firefox renders the RGB Colors exactly, meaning GPick identifies the same Hex Code from CSS.
Whereas Chromium renders some kind of differnt color.
You can call
chrome://flags/#force-color-profile
and set the Color Profile in Chromium to sRGB, so the rendered Color from Chromium is identified the same as the HexCode with GPick.
If you disable 'Use hardware acceleration when available' in Chromium Settings and relaunch, Chromium displays colors correctly. When turned on, Chromium colors are off. I consider this as a workaround until Chromium color management issue with hardware acceleration is resolved.
With the other two colours being equal, your colour is right in the middle of "blue territory".
If you convert it to HSL and look on the hue line, you can see it is right in the middle of the "blue" frequency range.
Consequently, any hint of green or red is incorrect.

Batik/Rhino JavaScript support?

Just want to get a sanity check on this before wasting too much time - does Batik actually have usable JavaScript support in its SVG display and rasteriser?
Problem: I've got code which generates SVG files, using a few thousand lines of fairly complex JavaScript. This works on Firefox, Chrome, Opera, Safari, and IE9. I've spent the morning trying to get Batik to display a sample SVG file (in Squiggle) and to rasterise it to png/pdf/etc. I've already fixed one problem (I had to move a text node into the DOM to get splitText to work), and the next problem is only a few lines down (nodeValue.trim() doesn't work on a text node).
Just about to give up and ignore Batik (v1.7, downloaded yesterday), unless someone has some positive experience of it?

How do you change the color of an equation containing images in mathjax?

I noticed that math.SE uses mathjax and has equations in a blue color.
Notice how the infinity sign is colored aswell.
However one would expect this to remain black because - as mentioned here: How to change equations color in MathJax - those symbols are in fact images who's color is not effected. Like so:
So, how do they change the color of those images as well? I thought it was impossible.
MathJax should use image mode only in a few rare cases these days. The main one is when you use Firefox to view local files (via a file:// url) and MathJax is not in the same directory as the HTML file being viewed. In this case, Firefox's same-origin policy considers MathJax to be in a separate domain, and so fails to be able to access the web-based fonts since it considers that to be cross-domain access. So MathJax uses image fonts as a fallback because it can't use web-based fonts. I'm guessing that is what is happening for you.
Math.SE doesn't have that problem since it is not a file:// url and Firefox doesn't have trouble recognizing what domain is what, so you get actual web-based fonts and not images and they can be colored properly (unlike the images). Math.SE doesn't have to do anything special to make that happen, and you are not seeing colored images, but actual fonts. That is the difference from your uncolored examples.
The solution for the Firefox local-file problem is to install the STIX fonts, or MathJax's own OTF fonts, in your system's fonts folder. You can find the MathJax fonts in the MathaJax/fonts/HTML-CSS/TeX/otf directory of the MathJax distribution that you have installed locally. If these are available as actual fonts on your system, MathJax won't have to use web-based versions, and so it can avoid the Firefox issue with the same-origin policy. This will also speed up any page using MathJax anywhere (like Math.SE) since it won't have to download the fonts over the web.

Resources