It seems to me that sIFRed text when selected allways have black background. My site design is dark (mostly black). So when use select sIFRed text it looks like nothing happens, it is selected but no one can see that cause both site and selected text background are black. Normal text have white or some kind of dark-green color depending on font color.
How to change color of selected text background?
http://yourpalmark.com/2007/08/13/changing-selection-color-on-dynamic-textfields/
use this and compile your font .swf again. but i would use cufon, sifr is too laggy!
After all those years things has changed. Best way to do it now is to omit sIFR, cufon and others and use just CSS #font-face. Best with fallbacks e.g.:
#font-face {
font-family: 'font-name';
src: url('fonts/font-name.eot');
src: url('fonts/font-name.eot?#iefix') format('embedded-opentype'),
url('fonts/font-name.woff2') format('woff2'),
url('fonts/font-name.woff') format('woff'),
url('fonts/font-name.ttf') format('truetype'),
url('fonts/font-name.svg#fontname') format('svg');
font-weight: normal;
font-style: normal;
}
Always fresh things about that can be (and probably will be in a future) found at http://www.fontsquirrel.com/
Related
That's it, I'm on Mac Mojave with weasyprint-44, python 3.6, and Cairo etc. versions match. The PDF renders nicely otherwise - symbols and letters are fine - just no numbers?
So weird.
Can anyone point me in the right direction?
I was able to fix this problem by eliminating the font "Segoe UI Emoji" from a font-family CSS declaration. Numbers started appearing again once this font was removed from CSS.
The bug seems to have started with some change on macOS 10.14.4.
I am on Mac (Mojave 10.14.5) and have the same problem. I managed to fix it by defining a different font family for print. In my case, I use:
font-family: "Open Sans", Calibri, Candara, Arial, sans-serif;
everything prints out nicely.
The same issue occurs on Sierra (10.12) and High Sierra (10.13), as well as Mojave (10.14), especially when using Bootstrap 4.
The default body definition looks as follows:
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
Where both Apple Color Emoji as well as Segoe UI Emojii can cause the final PDF to not display numbers properly.
Removing all mentions of the Emojii fonts brings the numbers back.
Note: The numbers are still there, you can copy and paste them, however, they are not actually visible.
I have a problem rendering the "font-smoothing" CSS property with html2canvas on all browsers I have (FF/Chrome/Safari/0pera)
But trying desperately to solve that, I eventually wondered why I had to smooth the text in the first place and i noticed that only the fonts displayed on a dark background were causing problems.
So, I made a JSFiddle to make some tests (see the link below)
If you are on Mac (I don't know about PC's browsers), you can see with jsFiddle that:
the black font on a white background is totally ok.
the white version of the same font on a black background is now bolder and messier for whatever reason.
And this would be resolved only if I apply a css "font-smoothing" property to it.
Nothing changed in the css and the font is absolutely standard.
All that changed is the constrast: dark background with a bright font or the contrary.
So, clearly, it's not a problem related to the font or to a technically blocking issue. It just depends on the background and the font color.
I originally thought it was because of my fancy font but even the standard webfonts will generate the problem.
So, at the end of the day, it only seems to be a matter of contrast.
Black on white is ok while white on black is not.
Is there any (css) workaround to get the same results, whatever the background luminosity/contrast or font color, whitout using "font-smoothing" as a non standardized fix then?
The contrast thing is probably a known issue and I can't believe it has no standard fix or, at least, a workaround that would work without browser-specific css properties.
Applying a css property according to the background color seems very awkward.
Here is the html:
<div class="white_no_smoothing">Test of text 0123</div>
<div class="black_no_smoothing">Test of text 0123</div>
<div class="black_smoothing" >Test of text 0123</div>
Here is the CSS:
.white_no_smoothing{
background:#fff;
color:#000;
width:250px;
height:50px;
display:block;
font-size:36px;
}
.black_no_smoothing{
background:#000;
color:#fff;
width:250px;
height:50px;
display:block;
font-size:36px;
}
.black_smoothing{
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
background:#000;
color:#fff;
width:250px;
height:50px;
display:block;
font-size:36px;
}
JSFiddle:
https://jsfiddle.net/Lzy4s4tw/3/
Thanks.
I'm trying to design something similar to GitHubs sliding file browser
It's mostly working but im trying to style it and I get this with my borders:
.claim-header, .support-header{
text-align: center;
background-color: $argument-review-banners;
padding: 0.3em;
font-family: "Jockey One",Arial,Georgia,sans-serif;
font-style: normal;
font-weight: 400;
font-size: 20px; // <--- this line breaks it
text-transform: uppercase;
border-color: black;
border-style: solid;
}
it appears as if the font-size within the div (each one of these rows is a div as it's not really a table, as I'm not doing file browsing per se) is what breaks it, it seems to make the calculation of the width different because of font-size. I thought that susy caculates widths based on the base-font, not the font of the element. It's off by 2 pixels and I wonder if this is some sort of rounding error.
I could fix it with yet another wrapper div. But I'm wondering what the proper solution would be.
This issue is not related to Susy - you would have the same problem with any em-based width. Susy has no way of knowing that you changed the font size, or want to use a different em value - that all gets calculated at the browser level.
The container mixin will output the same em width each place you use it (given the same settings), but em's are relative to local font-size. That's calculated by the browser, and Susy has no knowledge of it, or control over it. There are several options.
You can build your grids in rem (root em) values instead, on modern browsers.
You can use the $container-width setting to override the calculated width - use px, %, or set the width .
You can set a single outer container (maybe the <body>?) around all these elements.
You can change the font size in a nested element, rather than on the container.
Hey folks, I'm attempting to style a client's article h1's with a simple background color and padding. I need the text to be centered vertically and horizontally within the padding, but I'm finding there's a baseline difference between OS X and Windows. At least that's my best guess. Here's the specific code for the offending elements:
.entry-title {
color: #fff;
background: #A3BCC3;
font-size: 24px;
text-transform: uppercase;
text-align: center;
}
.normal .entry-title {
float: left;
width: 100%;
padding: 10px;
margin-bottom: 30px;
}
Here are the screenshots:
OS X: http://i54.tinypic.com/2a0bx1v.png
Windows: http://i56.tinypic.com/2gv4vie.png
You'll notice it's rendering just fine on Windows, but it's a few px too high on OS X. They render the same throughout browsers, the only difference is between the operating systems. The font is Quicksand Book, and is being implemented via #font-face. If you need to see a working version of the site, it's available at http: // angryg.nom.es/rosebud. If you do manage to check it out, you'll notice I'm having the same problem on the static content footer at the bottom of the home page.
Anyway, any help would be greatly appreciated.
You need to specify a line-height for the specific browser (painfull) use this type of properties: 1.1, etc over specifying pixels, from my experience it works better.
Also, still in the Mac, between Safari and Firefox you'll notice a difference between line-heights! So this isn't just OSX vs Windows.
Your font-files may be incorrect.
I had the same issue with a local installed webfont too.
Thankfully Google provided the same font as a webfont, solved the problem for me.
Default font of operating systems is different so add a font-family: Arial to your elements css. It should work in OSX and Windows because Arial is supported by both of them.
At this site, in IE 6 & 7 the footer's background should be grey; outside of the white box. It looks correct in firefox, chrome & IE8, but not IE6 & 7 the footer's background is white and inside the box. I have tried many things with no luck. I wonder if anyone can offer suggestions?
The problem is the way you're floating the footer components left and right, which lifts them out of the footer's content flow. Essentially what this does is it leaves your footer with no content so it occupies no space. If you put a width property onto your #foot then you'll regain the control to do what you're trying to.
#foot {
background-color: #dfe0e0;
font-family: Arial, Helvetica, sans-serif;
font-size: 11px;
color: #6D6F72;
font-weight: bold;
width: 980px;
}
The reason it 'appears' to work in firefox etc is that they're handling the overflow: visible style on your #main correctly, whereas IE6 & 7 really don't have a clue.