Having issues with multiple .less files importing #font-face custom fonts which are local.
OPTION 1 - Doesn't work
#font-face is generated with .less in a mixin file called font.less one directory above.
#font-face {
font-family: 'custom-font';
src:
url("../fonts/client1/custom-font.woff2") format("woff2"),
url("../fonts/client1/custom-font.woff") format("woff")
}
The font-family is defined in another file or the can be the same mixin file.
#font_family_123: 'custom-font', cursive;
The .woff files are nested outside of scripts in correct path. I can also add google fonts and other hosted .woof files fine with this method. I have used relative and absolute paths, makes no difference..
OPTION 2 - Does work
If I was to include my #font-face and #font-family in a base style like "styles_default.less" everything works as expected and loads fine. Super simple.. Is there some way to separate when working with large amounts of custom fonts or perhaps this is not supported?
BTW using less-rhino 1.7.5
Best-
Related
i trying to add a custom font to Vuetify with a local ttf file, to add it, i tried #font-face but the compiler runs in problems to find the file it work with a #import but the font is not online :c
here is my variable.scss file
#font-face {
font-family: "MyFont";
src: url("assets/font/myfont.ttf");
}
$body-font-family: 'MyFont', sans-serif;
and here is the error
./assets/font/MyFont.ttf in ./node_modules/css-loader/dist/cjs.js??ref--9-oneOf-3-1!./node_modules/postcss-loader/src??ref--9-oneOf-3-2!./node_modules/sass-loader/dist/cjs.js??ref--9-oneOf-3-3!./node_modules/vuetify/src/components/VAlert/VAlert.sass, ./node_modules/css-loader/dist/cjs.js??ref--9-oneOf-3-1!./node_modules/postcss-loader/src??ref--9-oneOf-3-2!./node_modules/sass-loader/dist/cjs.js??ref--9-oneOf-3-3!./node_modules/vuetify/src/components/VApp/VApp.sass and 91 others
it seems to be a problem to find the font but i cannot simply put the ttf file in the node module directory :C
I solved this problem by prepending ~# to my font path according to LinusBorg here and it is now working fine. Yours should be ~#/assets/myfont.ttf.
I know some posts in the nuxt.js github repo cover this a bit, but I would like to know what is the correct way to use font-files in nuxt.js.
So far we had them in the /static/fonts directory, but other people use assets to store the font files.
What are the differences? Is one of the options better and if so, why?
Also there are different ways to include them.
Would a path like this be correct:
#font-face {
font-family: 'FontName';
font-weight: normal;
src: url('~static/fonts/font.file.eot'); /* IE9 Compat Mode */
src: url('~static/fonts/font.file.woff') format('woff'),
url('~static/fonts/font.file.otf') format('otf'),
url('~static/fonts/font.file.eot') format('eot');
}
Thanks for some clarification here :D.
cheers
J
it's very well explained on the official doc: https://nuxtjs.org/guide/assets/
assets\ is reserved for assets to be processed (eg. concat css with webpack)
static\ is useful to expose all static files from the root url (static\img\test.jpg => http://example.fr/img/test.jpg), without any process
I am attempting to use Webpack 2 and Font Awesome in a Cordova application. The Cordova application generates a file structure like this:
app
config.xml
hooks
node_modules
package.json
platforms
plugins
webpack.config.js
www
(This naturally includes my NPM files and webpack configuration, for context. app is where I squirrel away the raw JSX source code).
The structure under www (which is where the compiled out web application should go), looks like this:
css
fonts
img
index.html
js
I created the fonts directory as a target for the webpack configuration. The problem that I am running into is that I can either have the fonts copied to some useful location under the root or I can have the filtered CSS correct, but not both.
For example, if I use an example like the one below:
{
test: /\.(woff(2)?|ttf|eot|svg)(\?v=\d+\.\d+\.\d+)?$/,
loader: "file-loader?name=[name].[ext]&outputPath=www/fonts/&publicPath=/fonts/"
}
The files get placed under www, but the compiled source comes out strange.
#font-face {
font-family: 'FontAwesome';
src: url(/fonts/www/fonts/fontawesome-webfont.eot);
src: url(/fonts/www/fonts/fontawesome-webfont.eot?#iefix&v=4.7.0) format('embedded-opentype'), url(/fonts/www/fonts/fontawesome-webfont.woff2) format('woff2'), url(/fonts/www/fonts/fontawesome-webfont.woff) format('woff'), url(/fonts/www/fonts/fontawesome-webfont.ttf) format('truetype'), url(/fonts/www/fonts/fontawesome-webfont.svg#fontawesomeregular) format('svg');
font-weight: normal;
font-style: normal;
}
I have yet to be able to find a happy medium with the file loader when trying to place fonts under www. The recommendations in How to configure font file output directory from font-awesome-webpack in webpack? and Can't load font-awesome with Webpack really have not gotten me anywhere.
The outputPath option in the file-loader is relative to your output directory and therefore will be included in the path. And publicPath just adds the given path to the beginning of the used paths, it basically means that the output directory will be located somewhere else on the server. This leaves the original path unchanged, since the structure within the directory must be unchanged.
To make it work as you described, you need to change how you handle the output directory. As you've already mentioned your output directory is www, that's where webpack should put everything. Therefore it makes sense to configure output.path to www.
output: {
path: path.resolve(__dirname, 'www'),
// Other output options
}
With this you don't need to specify www in every output name/path. For instance you might have done something along these lines: filename: 'www/bundle.js, this now becomes just filename: 'bundle.js'. Even though the result is the same, the concept behind it is different, because you just tell webpack where to put the output files, but only the filename itself is relevant for any processing, whereas the output directory is irrelevant.
Now you have to change the outputPath in the file-loader to fonts/ and without the publicPath you would get the following URL:
url(fonts/fontawesome-webfont.eot);
That's a relative path, and you probably want to make it a server-relative path. The only thing that is missing is the leading /, therefore you'd set the publicPath to / and your rule becomes (using the nicer webpack 2 syntax instead of inlining the options, which makes it easier to read):
{
test: /\.(woff(2)?|ttf|eot|svg)(\?v=\d+\.\d+\.\d+)?$/,
loader: 'file-loader',
options: {
name: '[name].[ext]',
outputPath: 'fonts/',
publicPath: '/'
}
}
You'll probably want other loaders, that include assets, to also respect the same public path, so instead of defining it per loader, you can set it in output.publicPath.
output: {
path: path.resolve(__dirname, 'www'),
publicPath: '/',
// Other output options
}
I'm trying to create a dojo build file. What do I need to add in the profile.js file to include all the .css files inside the dojo build.js file. I'm getting dijit.js and other .js files, but the dependent .css files are not getting built into the build.js file
I'm using dojo 1.8
It doesn't really make sense to ask to combine JS and CSS into a single file. JavaScript is JavaScript; CSS is CSS.
That said, you should be able to get down to as little as one CSS request by specifying cssOptimize: 'comments' in your build profile, which will strip comments from CSS files within packages the build processes, and flatten imports. As a result, each Dijit theme's main CSS file (e.g. themes/claro/claro.css) will then require only one request, rather than requests for each component.
Initial Post: I moved a project from my server back to my local
environment and now .less files won't compile.
.kit and .js compile well. When I save a .less file codekit says
"Success code kit compiled xy.less" but it didn't generate anything.
Also if I write some rubbish inside a less file there is still a
success message.
All the .less files show up nicely in the code kit window but it seems
to ignore less files altogether
osx Mavericks, codekit 1.9.3
I narrowed the problem down to the #font-face declaration inside a .less import.
I use a webfont from myfonts.com I added the myfonts.com css declarations like this:
#import url('//hello.myfonts.net/count/xy');
#font-face {
font-family: 'Blabla';
src: url('/webfonts/29DFBD_0_0.eot');
src: url('/webfonts/29DFBD_0_0.eot?#iefix') format('embedded-opentype'),
url('/webfonts/29DFBD_0_0.woff') format('woff'),
url('/webfonts/29DFBD_0_0.ttf') format('truetype');
}
The problematic line is the one with format('embedded-opentype') with this line inside my less files, code kit stops compiling, yet hands out a success message.
If I write Hello World on the fourth line:
#import url('//hello.myfonts.net/count/xy');
#font-face {
font-family: 'Blabla';
src: url('/webfonts/29DFBD_0_0.eot'); Hello World
src: url('/webfonts/29DFBD_0_0.eot?#iefix') format('embedded-opentype'),
url('/webfonts/29DFBD_0_0.woff') format('woff'),
url('/webfonts/29DFBD_0_0.ttf') format('truetype');
}
Codekit trows an error at me.
But if I write the same, one line below:
#import url('//hello.myfonts.net/count/xy');
#font-face {
font-family: 'Blabla';
src: url('/webfonts/29DFBD_0_0.eot');
src: url('/webfonts/29DFBD_0_0.eot?#iefix') format('embedded-opentype'), Hello World
url('/webfonts/29DFBD_0_0.woff') format('woff'),
url('/webfonts/29DFBD_0_0.ttf') format('truetype');
}
This throws in a success message and the compiled .css doesn't change.
So it must be this line right?: src: url('/webfonts/29DFBD_0_0.eot?#iefix') format('embedded-opentype'), whats wrong with that?
Contrary to your conclusion, I assume the problem to be the #import declaration that MyFonts uses to track pageviews, i.e.:
/* #import must be at top of file, otherwise CSS will not work */
#import url("//hello.myfonts.net/count/1a2b3c");
Here, the LESS preprocessor within CodeKit has trouble with the URL that lacks a file extension. The fix is to indicate the filetype in brackets right after #import:
#import (css) url("//hello.myfonts.net/count/1a2b3c");
[In fact, the above mentioned CSS segment is not necessary for displaying the webfont, it works just fine without (and does not choke CodeKit either). Omitting it might violate the licence though, because without pinging MyFonts' servers, they don't know if your within the webfont useage quota.]