This is less of asking for code solution, but more of requesting an explanation of the unexpected code behavior.
When I use kable_styling on console, the table is displayed as expected: white background, black font.
However, when I run it within Rmd, the resulting table is white background and white font, that can only be seen if you highlight it.
I fixed this by simply adding table.attr = "style = \"color: black;\"", but can someone chime in why this strange behavior occur?
Thank you.
Seems to be that the RStudio theme you chose (under tools, global options, appearances) applies the theme (dark w/ white letters) to everything in the viewer pane, including your rendered table. If you switch the theme to something with darker letters, the output in the viewer pane will follow.
It's also addressed here: https://community.rstudio.com/t/using-dark-theme-with-preview/1891
Related
(Discaimer: I only learned to code alone and upload some contents.)
I retrieved a symbol for a running person and used the code to build an html file to upload. The problem is that the image appears in different ways in different browsers.
A temporary mwe example.
direct view in my site ramoneando.com
code snippet:
<h1><span style="font-family:'Segoe UI Symbol';color:black;font-size:40px;">🏃</span>runner</h1>
(Desired) Image on local browser.
Why does this happen and how can it be avoided?
I actually am OK with the variants. The worse thing is that some look to the right and others to left. I would prefer to remain with the first image, in dark filling and looking to the right.
The problem is that not every computer has the font Segoe UI Symbol installed, so the ones that don't just display the character with code 🏃 in the default font.
For example, this is what the snippet looks like on my computer
(It used the font Unicode Upper, if you're interested.)
So what you can do is any of the following:
Accept that the "Man running" symbol looks differently in different fonts and keep it the way it is
Use Segoe UI Symbol as a webfont (this may be overkill for displaying just one icon)
Or make a screenshot of the icon and turn it into a png file.
I've got a Typekit font running on my website, but it get's cut-off. Doing nothing unorthodox — just imported it.
Might be best to just show it, so check out the link below.
Check the the last "t" in this photo.
I have trouble figuring out an issue I've been having with svg->font conversion.
Using Inkscape, I created a new svg (dimensions - 1000x1000) that has a shape star using the draw tool in the rectangular path create mode.
The path I used to create is this:
bottom left -> top center -> bottom right -> left top -> right top -> left top
Here's the created file: star.svg. There's no issue with this file so far.
Now, I've used fontcustom to compile this svg into a font, and you can look at the generated preview here.
This preview looks differently in Safari vs Chrome (or Firefox or Opera). But there's a filled area in all of them. You can check the preview link yourself, or here's the screenshots of how it looks:
Chrome:
Safari:
Why's this fill area coming in the first place? Why is it different in browsers?
A bit of context:
The actual issue is much bigger. I've a set of svgs created by someone in Adobe Illustrator, some of which are glitchy in similar fashion (unwanted fill) in chrome and other browsers. Safari and webkit2png somehow render the svg fonts correctly. So I tried to recreate the process in above mentioned steps.
More context:
I've also used icomoon app which many suggested, and it just gives blank glyphs for some reason.
In almost all cases, font glyphs are composed of filled shapes. They don't use the stroke (line). So when your SVGs are being converted to a font, the font SVGs are getting a fill applied, even if they didn't have one before.
The differences between browsers is probably explained by the fact that each browser may be loading a different generated font type. Eg. woff vs TTF etc.
The fix is to design your SVGs so that they only use filled shapes and don't rely on strokes (ie. line colour, width etc). If you follow the following rules, your glyphs should always work when converted:
Keep your line colour as "none" or "transparent",
Never use any fill colour except black (ie. don't use "white" to make holes)
Never let shapes cross over themselves or other shapes.
So, for example, in the case of your star, it should be designed as a filled star shaped object with a star shaped hole in it.
I have a few links that are slightly smaller (at their bottom part) than the rest of the text and I don't understand why is that and what I did wrong that could have caused this.
The problem exists here on following links: github, link, email, comment and lab.
If i move the list outside of #top_container, then the size becomes normal and the weird spacing at the bottom of these links disappears.
Does anyone have an idea of what I did wrong? Thanks.
What you see is, actually, an optical illusion generated by the contrast between white and red fonts. Also, you use bold fonts for links which only add to the impression that these fonts are smaller. Try changing their colors and weight.
I've uploaded a screenshot of a fragment of your page. That line can be used as a base to compare a little more accurately these fonts. Hope it helps.
EDIT. I use Firefox. Maybe in other browsers bold fonts are rendered a little different and the discrepancy is real (not an optical illusion as I've supposed the first time).
Never seen before that url bar would change its font, but if you go to the following link in Chrome, you would see that "New Features" is written in different font:
Copying url into text file reveals some magic symbols:
http://g-wiki.net/wiki/Battlefield_3%EF%BC%9ANew_Features
Can anyone explain why it changes font and what else can I do with this technique (can I make red bold letters)?
That's a full-width colon character. The only difference should be that it takes more horizontal space; it's not supposed to affect the font and it doesn't do so for me. However, because it's missing from many fonts, some operating systems might switch to a different font or rendering mode in order to display that character, and may continue to apply this change to subsequent text.
I've noticed this before in instant messaging. I'll copy some Chinese characters into my message, and the rest of it will be displayed differently. It's the same effect and I'd consider this to be a bug in the the operating system/font routines. It's probably not been deliberately programmed.