I am new to html, css and mathml but can now produce mathematics rendered in Firefox pretty well, if slowly. My problem is how to use the up integral symbols in the STIX fonts.
<mo>∫</mo>
produces a slanted symbol by default. Using fontfamily="STIXIntegralsUp" has no effect on Firefox but produces an up integral symbol in other browsers. I also have STIXMath fonts installed but the up integral symbols do not have a unicode. How do I use these symbols without a unicode?
In short, how do I produce an up integral symbol in Firefox?
In short, how do I produce an up integral symbol in Firefox?
<math display="block" xmlns="http://www.w3.org/1998/Math/MathML"><mo>∫</mo></math>
If you don't want the equation centered,
<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle displaystyle="true"><mo>∫</mo></mstyle></math>
Update
Using fontfamily="STIXIntegralsUp" has no effect on Firefox but produces an up integral symbol in other browsers.
fontfamily are deprecated as you can check in http://www.w3.org/TR/MathML3/chapter3.html. Firefox was update based on the new specification but others browsers weren't.
Related
I converted an SVG font to OTF using FontForge. I know the original font has certain errors, but really don't think any of those errors would cause the following issue:
When using CSS
writing-mode:vertical-lr; text-orientation:upright, I get the following results. The Firefox rendering is perfect, but for some reason the results seem to kern certain letter combinations in Chrome (ver. 96). I've tried doing everything I can think of in FontForge as far as clearing kerning tables, toggling options for "old kerning" and "microsoft kerning", etc. Nothing seems to make any difference to the result.
I know that upright orientation is not well supported by browsers in general, but it's apparent that Arial font renders perfectly under Chrome, so I think there must be something I can do to fix this problem.
The font is generated in FontForge from an SVG font that uses vert-adv-y. The values for that parameter are correct in the SVG (the SVG has other errors, but I don't think they have any bearing here). I'm linking a copy of the exported OTF file. Perhaps someone may discover some sort of kerning or letter-advancing issue there.
Or perhaps Chrome is doing some sort of automatic kerning, in which case, why doesn't it happen to the Arial font? Maybe the Arial font has GPOS settings, whereas my font has old-style kerning? I really have no clue.
LINK TO DOWNLOAD OTF FILE.
Although the letters on the left of the image are lowercase, they are produced using the uppercase keys A, B, C, etc.
Okay, so this seems to have been one of those miraculous-seeming instances when a problem seemed to fix itself. I resaved the file, which then kicks it to a microservice running FontForge, which coverts the SVG to an OTF, and when it reloaded everything appeared good.
I still have no idea why, since I didn't update the microservice, and I haven't changed the SVG-generating code AFAIK. All I did was upgrade Chrome (and the new version had been showing the issue with the old file), but it should still be sending the same data. Still, I'm not complaining!
I’m building a website using Google Fonts. In particular I’m using “Archivo Black”.
The font supports special characters such as accents and others, however in Firefox those accents are rending in a really weird position… and in Chrome they look perfectly fine.
I’ve been looking all around but I don’t think there is a way to control the position of such elements via CSS, so I really don’t understand why this might be happening.
In the images below I'm just highlighting one instance when this is happening but if you look closer you'll see it's a consistent issue.
The problem is likely that you are using the 'COMBINING ACUTE ACCENT' (U+0301) along with the U character instead of the 'LATIN SMALL LETTER U WITH ACUTE' (U+00FA) Ú.
The former character set is not in your font so the browser has to use an other system font, which is why it may not render correctly. You can check this in the font panel of your dev-tools.
However, your font does have the Ú character, so if you fix it in your markup, you should be good in all browsers.
#import url('https://fonts.googleapis.com/css?family=Archivo+Black');
body{
font-family: 'Archivo Black', sans-serif;
}
<div>MÚSICA (U + ́ )</div>
<div>MÚSICA (Ú)</div>
I cannot get Chrome on OSX to print emoji, is there any css trick or other?
Here are 2 emoji: 👍🇦🇹
When I try to print this page, the emoji space is preserved, but it's white. In Safari printing the emoji works just fine.
Here is a screenshot of the print preview of this page on Chrome:
After a lot of dialog in the question's comments, it seems you have a font rendering issue (perhaps a Chrome bug). I do not think this can be solved with any combination of HTML, CSS, or Javascript.
There is, however, the option to work around the issue by not using a font.
You can use a vector image like SVG to have the same kind of scaling capabilities as a font:
SVG for 👍THUMBS UP SIGN Unicode character
SVG for 🇦 REGIONAL INDICATOR SYMBOL LETTER A Unicode character
SVG for 🇹 REGIONAL INDICATOR SYMBOL LETTER T Unicode character
SVG for Thumbs up sign
SVG for Austrian flag
Just link to the SVG as an image and specify its dimensions either in HTML or in CSS as needed.
With a little work, you could automate conversion of user-generated emojis to images by using a dictionary of known images and supplement the misses with the either the SVG or the emoji PNG at FileFormat.Info. They have a list of emojis you could scrape (assuming it's not a violation of their terms of service) for PNGs as well as an SVG for every character (emoji or otherwise) which can be obtained from from just the character code. For example, here's U+1f44d (👍):
http://www.fileformat.info/info/unicode/char/1f44d
It'll be the only SVG link on the page, so you could do this in JS:
var svg_src = fileformat_info.querySelector('a[href$=".svg"]').href;
That said, it'd be vastly preferable to have this ready-made rather than creating from scratch. #pandawan's answer suggesting twemoji looks promising.
Perhaps there is a CSS-only workaround: I've also read elsewhere that you can properly print these characters by avoiding bold (and perhaps all font and text manipulation? perhaps just make the font size bigger?). This may depend on the fonts installed on the client system.
This is due to a rendering difference between Chrome and Safari, I would not named it a bug since I do not believe that the expect behavior is defined anywhere (Firefox has issues rendering your emojis too by the way).
If you want a full and simple emoji support across all platforms you can use twemoji, a small library developed by Twitter for this specific need.
I have a formula in LaTex or MathML and I want to render it on a browser, I try MathJax but is so slow, there is another javascript for render some formula faster the mathjax?
For tex-like input you could give jqmath a try, it is much smaller and faster than mathjax (but doesn't try to do such a complete job) http://mathscribe.com/author/jqmath.html
For MathML input webkit and firefox now support that by default but getting math fonts installed by default on the platforms is still an issue, and it may take a while for the mathml support to reach all relevant browsers. For example MathML is in Chrome 24 released last week, but neither the mobile version of chrome (nor the android stock browser) use a new enough webkit base at present. Obviously the built in MathML support will be a lot faster than a javascript implementation.
You can probably use this: WP Latex
I am editing font with fontforge font editor everything is good but in
ligature when i want to make multi word ligature (space between it) don't work on firefox and opera ,it will work with word pad and notepad.
is this bug or limit?
what should i do to solve problem?
note:i am using #font-face css syntax to import font and font is ttf.
Ligature making is an optional feature in an OpenType font. Examples of ligatures are the glued together sets of letters like, fi, ff, fl, ffi, ffl. A common font that has ligatures is Calibri that came as the default font in Microsoft Office 2007.
The font has a lookup table that goes like this:
f i -> fi
f l -> fl
f f -> ff
ff i -> ffi
ff l -> ffl
As you type the letters on the left hand side of the equation, the ligatures shown on right go and replace the currently displayed character (whether a single letter or an already formed ligature). Type 'difficult' inside Notepad using Calibri in some large size to see this happen. Notice that a ligature has multiple cursor positions inside it. You can stop automatic ligature formation by intervening the hidden character ZWNJ (Zero Width non-Joiner, u200C, HTML-‌) between letters.
Firefox 4 forms ligatures without the aid of CSS / SVG. MS Word can do ligatures starting from version 2010 but it needs to be enabled under Advanced tab, AbiWord (freeware) does also support it.
Check out this web site (use Firefox or Safari) that uses ligature feature to show a complex script on top of a transliterated text.
This smartfont has 400 odd ligatures that Firefox and Safari display without effort even after downloading the font.
A concrete example would be helpful, as this question is very unclear.
I assume that the issue is that you are attempting to access ligature features that are not part of the default for the font (i.e. it must be turned on as an opentype feature). CSS does not provide a way to specify opentype features to activate. Sorry.
If it is a logo, or similar, you could simply create the text as an image, either in something like png, or as an SVG.
For a short paragraph, SVG again might be suitable.
If not, then maybe there is a font that supports the appropriate ligature by default.
There's no way to make a "multi-word ligature" work in Firefox; it does not support ligatures (or other types of OpenType rule, such as contextual alternates) across inter-word spaces.
This is a fairly common limitation, actually; the same is true of XeTeX, for example. Inter-word spaces are not treated in the same way as normal printable characters by many text-layout systems, and so the OpenType lookups will not match in the way you expect.