Falha ao decodificar a fonte baixada

Esse é um erro que estou recebendo no Chrome e, infelizmente, procurá-lo não me deu muitos resultados. A fonte em si está aparecendo corretamente. No entanto, ainda recebo esse erro / aviso. Mais especificamente, este é o aviso completo:

"Falha ao decodificar a fonte baixada: http: // localhost: 8000 / app / fonts / Lato / "

Meus CSS são estes:

@font-face {
    font-family:"Lato";
    src: url("../fonts/Lato/");
}

html, body {
    font-family:'Lato';
}

Apenas não entendo. A fonte é aplicada corretamente, mas o aviso está sempre lá. Tentar usar Sans-Seriffaz com que a fonte volte para a fonte normal do navegador, de modo que possa ser, mas não tenho certeza e, mesmo depois de pesquisar, não encontrei nada. Obrigado!

EDITAR

Existem vários arquivos de fonte, todos da mesma família. Estou tentando carregar todos eles. Os arquivos de fonte são .ttf. Eu estou carregá-los a partir de uma pasta local, e há várias fontes-arquivos, como Lato-Black.ttf, Lato-Bold.ttf, Lato-Italic.ttfetc.

Na regra css, você deve adicionar a extensão do arquivo. Este exemplo com o suporte mais profundo possível:

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

EDITAR:

"Falha ao decodificar a fonte baixada" significa que a fonte está corrompida ou incompleta (métricas ausentes, tabelas necessárias, registros de nomenclatura, um milhão de coisas possíveis).

Às vezes, esse problema é causado pela própria fonte. A fonte do Google fornece a fonte correta de que você precisa, mas, se necessário, eu uso o Transfonter para gerar todo o formato da fonte.

Às vezes, é o cliente FTP que corrompe o arquivo (não neste caso, porque está no PC local). Certifique-se de transferir o arquivo em binário e não em ASCII.

Ocorreu um problema semelhante no Visual Studio, causado por um url()caminho incorreto para a fonte em questão.

Parei de receber esse erro após alterar (por exemplo):

@@font-face{
    font-family: "Example Font";
    src: url("/Fonts/ExampleFont.eot?#iefix");

para isso:

@@font-face{
    font-family: "Example Font";
    src: url("../fonts/ExampleFont.eot?#iefix");

Mudar de formato ('woff') para formato ('font-woff') me ajuda a resolver esse problema agora.

Basta mudar uma pequena mudança aqui da resposta de Germano Plebani

 @font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('font-woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

Verifique se as fontes do seu navegador podem abri-lo e qual é o tipo

Verifique se o servidor está enviando os arquivos de fonte com o tipo / mímica correto .

Recentemente, tenho o mesmo problema ao usar o nginx porque alguns tipos de mímica de fonte estão ausentes do /etc/nginx/mime.typesarquivo vanilla .

Corrigi o problema adicionando os tipos MIME ausentes no local em que eu precisava deles assim:

location /app/fonts/ {

  #Fonts dir
  alias /var/www/app/fonts/;

  #Include vanilla types
  include mime.types;

  #Missing mime types
  types  {font/truetype ttf;}
  types  {application/font-woff woff;}
  types  {application/font-woff2 woff2;}
}

Você também pode verificar isso estendendo o mime.types no nginx: estendendo o arquivo padrão nginx mime.types

Eu tive que adicionar type="text/css"à minha tag de link. Eu mudei de:

<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700" rel="stylesheet">

para:

<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700" rel="stylesheet" type="text/css">

Depois que eu mudei, o erro desapareceu.

Acabei de ter o mesmo problema e o resolvi alterando

src: url("Roboto-Medium-webfont.eot?#iefix")

para

src: url("Roboto-Medium-webfont.eot?#iefix") format('embedded-opentype')

Para mim, esse erro ocorreu quando referenciei uma fonte do google usando https. Quando mudei para http, o erro desapareceu. (e sim, tentei várias vezes para confirmar que era a causa)

Então eu mudei:

@import url(https://fonts.googleapis.com/css?family=Roboto:300,400,100,500,900);

Para:

@import url(http://fonts.googleapis.com/css?family=Roboto:300,400,100,500,900);

Às vezes, esse problema ocorre quando você carrega / baixa as fontes usando o método FTP errado. As fontes devem ser editadas por FTP usando o método binário, não o ASCII. (Dependendo do seu humor, pode parecer contra-intuitivo, risos). Se você ftp os arquivos de fonte usando o método ASCII, você pode receber esta mensagem de erro. Se você enviar seus arquivos por ftp com o método 'auto' e receber essa mensagem de erro, tente forçar o método binário por ftp.

Eu estava tendo o mesmo problema com a fonte awesome v4.4 e a corrigi removendo o formato woff2. Eu estava recebendo um aviso apenas no Chrome.

@font-face {
  font-family: 'FontAwesome';
  src: url('../fonts/fontawesome-webfont.eot?v=4.4.0');
  src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.4.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff?v=4.4.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.4.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.4.0#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

No meu caso, foi causado por um arquivo de caminho incorreto, em .htaccess. verifique a correção do caminho do arquivo.

Para mim, o erro foi esquecer de colocar o FTP no modo binário antes de carregar os arquivos de fonte.

Editar

Você pode testar isso carregando outros tipos de dados binários, como imagens. Se eles também não forem exibidos, esse pode ser o seu problema.

Eu também tive o mesmo problema, mas resolvi adicionando 'Content-Type': 'application / x-font-ttf' no cabeçalho de resposta de todos os arquivos .ttf

No meu caso, isso foi causado pela criação de um arquivo de patch SVN que incluía a adição dos arquivos de fonte. Igual a:

1. Adicione arquivos de fonte do sistema de arquivos local ao tronco subversionado
2. O tronco funciona conforme o esperado
3. Crie patch SVN de alterações de tronco, para incluir a adição de arquivos de fonte
4. Aplicar patch a outro ramo
5. Os arquivos de fonte são adicionados à ramificação subversionada (e podem ser confirmados), mas estão corrompidos, gerando erro no OP.

A solução foi fazer o upload dos arquivos de fonte diretamente para a filial do meu sistema de arquivos local. Suponho que isso aconteceu porque os arquivos de patch SVN devem converter tudo para o formato ASCII e não necessariamente retêm o binário dos arquivos de fonte. Mas isso é apenas um palpite.

No meu caso - usando o React with Gatsby - o problema foi resolvido com a verificação dupla de todos os meus caminhos. Eu estava usando o React / Gatsby com Sass e os arquivos de origem do Gatsby procuravam as fontes em um local diferente dos arquivos compilados. Depois que eu dupliquei os arquivos em cada caminho, esse problema desapareceu.

No meu caso, ao baixar um modelo, os arquivos de fonte eram apenas arquivos vazios. Provavelmente um problema com o download. O Chrome deu esse erro genérico sobre isso. A princípio, pensei na solução de mudar woffpara font-woffresolvê-lo, mas isso apenas fez o Chrome ignorar as fontes. Minha solução foi encontrar as fontes uma por uma e fazer o download / substituí-las.

Se você estiver usando o express, precisará permitir a veiculação de conteúdo estático adicionando algo como: var server = express (); server.use (express.static ('./ public')); // onde public é a pasta raiz do aplicativo, com as fontes contidas nela, em qualquer nível, por exemplo, public / fonts ou public / dist / fonts ... // Se você estiver usando o connect, pesquise no Google uma configuração semelhante.

Eu uso o .Net Framework 4.5 / IIS 7

Para corrigi-lo, coloquei o arquivo Web.config na pasta com o arquivo de fonte.

Conteúdo do Web.config:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

para mim, foi um problema com arquivos lfs que não foram baixados

git lfs fetch --all

corrigiu o problema.

consulte https://github.com/git-lfs/git-lfs/issues/325

Se estiver no servidor (não no host local), tente fazer o upload das fontes manualmente, porque às vezes o cliente FTP (por exemplo, o FileZilla) corrompe os arquivos e pode causar o problema. Para mim, enviei manualmente usando a interface Cpanel.

Meu caso parecia semelhante, mas a fonte estava corrompida (e é impossível decodificar). Foi causado pela configuração no maven. Adicionar nonFilteredFileExtension para extensões de fonte dentro maven-resources-pluginme ajudou:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <nonFilteredFileExtensions>
            <nonFilteredFileExtension>ttf</nonFilteredFileExtension>
            <nonFilteredFileExtension>otf</nonFilteredFileExtension>
            <nonFilteredFileExtension>woff</nonFilteredFileExtension>
            <nonFilteredFileExtension>woff2</nonFilteredFileExtension>
            <nonFilteredFileExtension>eot</nonFilteredFileExtension>
        </nonFilteredFileExtensions>
    </configuration>
</plugin>