This page was auto-generated by Emacs' org-mode HTML export. I've got it set up to use MathJax rendering of LaTeX symbols. On the third column of the There Exists line I've used inline LaTeX symbols surrounded by "$"
$\exists x \mid x2>x$
which is proper LaTeX embedding, whereas the line above and below I haven't, i.e., Emacs just picks up LaTeX markup and inserts it without using "$". If you Inspect (I'm using Chrome) this code, you'll see it is throwing in a font-size increase for only this LaTeX markup, seemingly arbitrarily, making the symbols look abnormally large compared to the other symbols.
<span style="display: inline-block; position: relative; width: 5.681em; height: 0px; font-size: 129%;">
How can I stop, block, override this element.style being inserted and blowing up my font size?
element.style {
 display: inline-block;
 position: relative;
 width: 5.713em;
 height: 0px;
 font-size: 129%;
}
Update:
I've narrowed the problem down to something in my custom stylesheet.css:
table {
/* font-family: monospace; */
font-family:'eulermedium_18';
/* font-size: 1.05em; */
margin-left:5%;
margin-right:auto;
margin-top:0.5em;
margin-bottom:0.5em;
line-height: 1.5em;
}
namely, the font-family. Above I've commented out monospace, which gave me a 129% arbitrary size. But then as you see I tried AMS Euler (ttf version converted by Font Squirrel, as is the Computer Modern) and it caused the $...$ parts of the org-mode table in question to reduce the font size to 53%! Craziness. Again, with no font-family in table sizes are normal across LaTeX/MathJax and regular text. Is there any way to have the org-mode HTML export for MathJax stuff use my fonts correctly?
It seems to be related to font-family too. Column 3 of There Exists line seem to be use font as STIXGeneral-Italic, while the default font used at other places seem to be monospace. You can override these styles in your stylesheet.css using !important directive.
.mrow span{
font-family: inherit!important;
font-size: 100%;
}
Related
I have this code:
<p style="line-height: 1;overflow: hidden;">blah_blah</p>
<p>blah_blah</p>
<p style="line-height: 1;overflow: hidden;">qypj;,</p>
<p>qypj;,</p>
which results in (notice no underscore, and cut characters):
That is, it behaves that way in Firefox (66.0.3 on Windows 10). Other browsers seem to render the underscore. The above snippet runner also seems to work (even in Firefox), unless you run it in "Full page".
This Q is similar to Text changes height after adding unicode character except there are no tricks here. "_" is just a simple ASCII character.
My question is which behavior is the correct one.
Is specific character allowed to change line height (I thought it was only supposed to be font dependent)? Shouldn't line-height: 1 imply it can fit exactly any text?
I suppose some characters are special, such as "p", "g", "j" (and possibly "_") that draw below its line. Still which behavior is the correct one. Is it considered overflow or not?
PS: Furthermore I find it funny either overflow-x: hidden;overflow-y: visible; and overflow-x: visible;overflow-y: hidden; still causes this. Which seems more like an actual bug to me.
My question is which behavior is the correct one.
All of them are correct because we don't have the same default font in all browsers and it's also different depending on the OS.
Is specific character allowed to change line height (I thought it was only supposed to be font dependent)?
Character doesn't change line-height. To be more accurate, line-height is a property that can only be changed by setting line-height but you are probably confusing with the line box that is defined by the line-height and a character alone cannot change it.
Shouldn't line-height: 1 imply it can fit exactly any text?
Not necessarely, line-height:1 means that the line box will be equal to the 1xfont-size 1 but is the font designed to include all the character inside this space? Probably most of them will do but we don't know.
Basically, you have two things to consider. The content area that is defined by the font properties and the line box that is defined by the line-height. We have no control over the first one and we can only control the second one.
Here is a basic example to illustrate:
span {
background:red;
color:#fff;
font-size:20px;
font-family:monospace;
}
body {
margin:10px 0;
border-top:1px solid;
border-bottom:1px solid;
animation:change 2s linear infinite alternate;
}
#keyframes change {
from {
line-height:0.2
}
to {
line-height:2
}
}
<span >
blah_blah
</span>
The red is our content area and its height is defined by the font properties and if you inspect the element you will see it has a height equal to 23px (not 20px like the font-size) and the borders define our line box that we control using the line-height.
So if the line-height is equal to 1 we will have a line box equal to 20px which is not enough to contain the 23px of the content area thus it will get truncated and we may probably hide some characters (or a part of them) which is logical:
span {
background: red;
color: #fff;
font-size: 20px;
font-family: monospace;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<span>
blah_blah ÂÄ j p
</span>
a different font-size will remove the underscore in Firefox:
span {
background: red;
color: #fff;
font-size: 26px;
font-family: monospace;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<span>
blah_blah ÂÄ j p
</span>
Another example with a Google Font where the result should be the same cross browser. The underscore is visible but not the ^/¨
span {
background: red;
color: #fff;
font-size: 26px;
font-family: 'Gugi', cursive;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<link href="https://fonts.googleapis.com/css?family=Gugi" rel="stylesheet">
<span>
blah_blah ÂÄ j p
</span>
Another example where the underscore is not visible:
span {
background: red;
color: #fff;
font-size: 27px;
font-family: 'PT Sans', sans-serif;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<link href="https://fonts.googleapis.com/css?family=PT+Sans" rel="stylesheet">
<span>
blah_blah ÂÄ j p
</span>
You can clearly see that we have a different overflow everytime we use a different font which confirms that this is font related. We have no control over it unless we know how the font is designed.
Related questions:
Understanding CSS2.1 specification regarding height on inline-level boxes
Why is there space between line boxes, not due to half leading?
Line height issue with inline-block elements
Here is a good article to get more accurate details and calculation: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
A quote from this article:
It becomes obvious that setting line-height: 1 is a bad practice. I remind you that unitless values are font-size relative, not content-area relative, and dealing with a virtual-area smaller than the content-area is the origin of many of our problems.
1 : I considered a simplified explanation but in reality the calculation of the line box is not only relate to the line-height property.
The default line-height (depending on the font-family) when not otherwise specified is about 1.2 in most browsers. This includes Firefox.
This would explain why the underscore did not show in FireFox when the line-height was set to 1 - the bottom was of the line was cut off. So I don't think it's entirely to do with the font (although this does contribute), but also browser defaults.
Some font-sizes are bigger than other even at seemingly the "same" font size (as I'm sure you've seen when typing documents in e.g. Georgia vs Times new Roman/Baskerville ; so you wouldn't be guaranteed that text would always show on a specified line height of 1 (or 1.2). There are ways of measuring a font in pixels however
Hope this helps
If I use the browser tools in Firefox to inspect my snippet below, there is no height difference between the lines with and without underscore. The only difference is caused by the line-height setting: 16px with line-height: 1, 19.2 px with the browser's default line-height. So the underscore doesn't make a difference here (Firefox 66.0.3 on Mac), and it is visible in both cases.
Note that I set margins to 0 to see the "pure" line-height without distances between the lines. Also, I didn't specify a font-familiy setting, so the default font of the browser for p tags is used.
The only reason for what you describe which I can think of is a font with very particular dimensions/settings, where the descenders (i.e. the parts of letters like p q j which extend below the baseline) are not inside the line-height as defined by the font.
After a bunch of comments back and forth: I suppose it could be caused by the different default (system) fonts on Windows and Mac. Still a bug, I would say (if you are using the default font).
html,
body {
margin: 0;
padding: 0;
}
p {
background: #fb6;
margin: 0px;
}
<p style="line-height: 1;overflow: hidden;">blah_plah</p>
<p style="line-height: 1;overflow: hidden;">blah plah</p>
<p>blah_plah</p>
<p>blah plah</p>
I have two installations of Laravel including Bootstrap.
As far as I can see both include and have Montserrat on the body tag.
One of the installations needs no declaration of that in the app.sass (meaning it gets included with the bootstrap directly).
However, the other needs it, otherwise it defaults to the browser default font.
And yet, even when both installations have the same Montserrat #import-ed, they look different. I suspect the wrong one is really Montserrat, while the right one is some kind of Bootstrap sugar-coating that the other one can't do.
In order to check it out, please follow:
Desired effect: This link and once you log in with maximilian.berbechelov#gmail.com and 123456 click it again. I know it's Cyrillic, but I don't think it matters.
Problematic effect:
This link - no login required.
I have a body font-family declaration in the sass file (the desired one has no such declaration), because without it the font is the browser default.
You can see your font adding !important after the font-family name like this.
body {
margin: 0;
padding: 0 0 50px 0;
min-height: 100vh;
font-family: "Montserrat", sans-serif!important;
background-image: linear-gradient(45deg, #1de099, #1dc8cd);
}
.navbar-brand {
letter-spacing: 3px;
font-family: 'Montserrat', sans-serif;
font-weight: 300;
font-size: 2.1rem;
}
I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).
See this Codepen, for example.
div.a p {
overflow: hidden;
}
p {
background-color: red;
border: 1px solid black;
display: inline-block;
}
.chinese-only {
font-family: "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.english-chinese {
font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.chinese-english {
font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
font-size: 24px;
line-height: 48px;
}
What I am seeing:
Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.
Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.
Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.
On Chrome and Firefox
On Safari
And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.
This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.
Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):
This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)
That’s from last month. So, you know, good luck and Godspeed, basically.
Interestingly, I see a different result in Safari 6.2.2 than you posted:
If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.
When using a <h1> tag for example, is there a reusable formula for getting the outer border of that element to PERFECTLY follow edges of the type? In theory I would expect this to work:
h1{
display: block;
font-family: sans-serif;
font-size: 38px;
line-height: 100%;
height: 38px;
}
So the line height is set to be the same as the absolute text height, which is also the height of the block. However this never works. Here is an example of what does work for sans-serif 38px;
h1{
display: block;
font-family: sans-serif;
font-size: 38px;
line-height: 28px;
height: 35px;
}
Here is another working example.
h1{
display: block;
font-family: sans-serif;
font-size: 25px;
line-height: 19px;
height: 22px;
}
This is all well and good, but it has to be calculated manually in firebug each time. There is no formula I can find to do this.
Additionally, it would be nice if any solution also worked with #font-face fonts, but I understand there is more to take into account there. (like the top alignment that only occurs on Mac).
Does such a formula exist? Is it possible to write one? How about some LESS CSS fancyness?
I agree with #ToddBFisher in the comment, and at this point for me it's more of an usability issue. Consider people can also vary the font sizes in their browsers... in that case using ems would be better. But browsers also render font differently, so something that looks amazing in a mac will look pixelated in a pc. If you want something to look perfect, use images.
Check this other question for more info on line-height: How to achieve proper CSS line-height consistency
Or this one: CSS Line-Height Guide
You can also check the usability stack for discussions about these things: https://ux.stackexchange.com/ There are pretty amazing posts in there.
I have some buttons my page using a custom font face using the CSS and files generated by the Font Squirrel generator.
When the font's colour is black, they display fine...
However, when I change the colour to something else, the text seems to have a smoothing that bleeds the characters into each other and generally makes the characters look too thick...
I've played around with font-smooth property and a few other things, but have been unable to get it to work...
I don't think it's too relevant but the CSS for these buttons are...
color: #FFFFFF;
display: block;
padding: 1em 0.3em;
position: relative;
text-decoration: none;
z-index: 10;
font-family: BebasNeueRegular,Arial,Sans-Serif;
font-size: 22px;
list-style: none outside none;
text-align: center;
text-transform: uppercase;
The background is a separate element.
How can I get the white text to appear like the black text?
(It may be hard to tell the difference between the two, but my boss insists it is there.)
This worked for me:
-webkit-font-smoothing: antialiased;
Part of the problem is that it's not a particularly well-made font. I concur with #thirtydot's suggestion of text-shadow. A 1px black-on-black text-shadow should thin the font out. Any browser that doesn't support text-shadow will be rendering the font horribly anyway.
And remember that some html elements has bold as default, like h1, h2... When I use font squirrel to generate a font and use it with h1, for example, I always put:
font-weight: normal;