Ots parsing error invalid version tag

Describe the bug

After adding the ASP.NET Identity scaffolding to an ASP.NET Core 2.1 web app, glyph icons don’t display correctly and a number of OTS parsing error: invalid version tag and Failed to decode downloaded font messages are visible in the browser console, referring to these files:

glyphicons-halflings-regular.woff2
glyphicons-halflings-regular.woff
glyphicons-halflings-regular.ttf

Also, an OTS parsing error: invalid version tag and DevTools failed to parse SourceMap messages are visible in relation to bootstrap.css.map.

To Reproduce

• In Visual Studio (on Windows) 2017, create a new ASP.NET Core 2.1 Web Application («File» > «New» > «Project» > Choose «ASP.NET Web Application», click «OK».
• In the pop-up window, choose «.NET Core» and «ASP.NET Core 2.1» in the drop down boxes, choose Web Application (Model-View-Controller), click «OK».
• Click the «IIS Express» button to debug the app (using Chrome 78.0.3904.108) — note that the glyphicon-chevron-left and glyphicon-chevron-right glyphs used as the left/right arrows for the carousel on the home page display correctly.
• Stop debugging the app.
• In Visual Studio, right click on the project name and choose «Add» > «New Scaffolded item…», choose «Identity», click «Add».
• Click «Override all files», select the default «Data context class» and «User class» via the «+» buttons, click «Add».
• Wait for Identity scaffolding code to be generated and added to the project
• Click the «IIS Express» button to debug the app (using Chrome 78.0.3904.108) — note that the glyphicon-chevron-left and glyphicon-chevron-right glyphs used for the carousel on the home page now display incorrectly as white rectangles and the previously mentioned OTS parsing error: invalid version tag messages are now visible in the browser console (in Internet Explorer 11, the glyphicon-chevron-left and glyphicon-chevron-right glyphs do not display at all).

I have searched for the OTS parsing error: invalid version tag error and there appears to be a number of possible causes, from incorrect resource paths to missing MIME types for the font file extensions (.woff, .woff2, etc.). I am not seeing any 404 errors when running the project and looking at the resources being downloaded, nor does MIME type seem to be an issue as far as I can tell.

Further technical details

• ASP.NET Core version (being used): 2.1
• Using Visual Studio 2017 on Windows (15.9.17)

Output of dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.110
 Commit:    4797dabd3c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:Program Filesdotnetsdk2.2.110

Host (useful for support):
  Version: 2.2.8
  Commit:  b9aa1abc51

.NET Core SDKs installed:
  2.1.509 [C:Program Filesdotnetsdk]
  2.2.110 [C:Program Filesdotnetsdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.13 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.13 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.13 [C:Program FilesdotnetsharedMicrosoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:Program FilesdotnetsharedMicrosoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Webpack» OTS parsing error » загрузка шрифтов

мой webpack config указывает, что шрифты должны быть загружены с помощью url-loader , и когда я пытаюсь просмотреть страницу с помощью Chrome, я получаю следующую ошибку:

соответствующие части моей конфигурации выглядят так:

это не происходит в Safari, и я не пробовал Firefox.

в разработке я обслуживаю файлы через webpack-dev-server , в производстве они записываются на диск и копируются в S3; в обоих случаях я получаю одинаковое поведение в Хром.

Это также происходит с большими изображениями (больше, чем ограничение 10 кб в конфигурации загрузчика изображений).

9 ответов:

TL; DR используйте абсолютные пути к вашим активам (включая полное имя хоста), установив output.publicPath например»http://example.com/assets/».

проблема

проблема заключается в том, что URL-адреса разрешаются Chrome, когда они анализируются из динамически загруженного CSS blob.

при загрузке страницы браузер загружает ваш файл JavaScript webpack bundle, который (когда вы используете style-loader ) также содержит кодированную копию Base64 вашего CSS, которая загружается на страницу.

Вот как это выглядит в Chrome DevTools

это нормально для всех изображений или шрифтов, которые закодированы в CSS как URI данных (т. е. содержимое файла встроено в CSS), но для активов, на которые ссылается URL браузер должен найти и принести файл.

теперь по умолчанию file-loader (который url-loader делегаты для больших файлов) будет использовать относительные URL для ссылки на активы-и вот в чем проблема!

это URL-адреса, созданные file-loader по умолчанию — относительные url

при использовании относительных URL-адресов Chrome будет разрешать их относительно содержащего CSS-файла. Обычно это нормально, но в этом случае файл, содержащий в blob://. и любой относительные URL-адреса ссылаются таким же образом. Конечным результатом является то, что Chrome пытается загрузить их из родительского HTML-файла и в конечном итоге пытается проанализировать HTML-файл как содержимое шрифта, что, очевидно, не будет работать.

Решение

силу file-loader использовать абсолютные пути, включая протокол («http»или » https»).

измените конфигурацию webpack, чтобы включить что-то эквивалентное:

теперь URL-адреса, которые он генерирует будет выглядеть так:

Абсолютные URL-Адреса!

эти URL-адреса будут правильно проанализированы Chrome и любым другим браузером.

стоит отметить, что если вы извлекаете свой CSS в отдельный файл, у вас не будет этой проблемы, потому что ваш CSS будет в правильном файле, и URL-адреса будут правильно разрешены.

Как asnwered здесь by @mcortesi если вы удалите исходные карты из запроса загрузчика css, css будет построен без использования blob, а URL-адреса данных будут проанализированы нормально

для меня проблемой было мое регулярное выражение. Ниже сделал трюк, чтобы получить bootstrap работает

Как и в случае с @user3006381 выше, моя проблема заключалась не только в относительных URL-адресах, но и в том, что webpack размещал файлы, как если бы они были файлами javascript. Их содержание было все в основном:

в каталоге шрифтов вместо реальных шрифтов и файлов шрифтов были в выходной папке под хэш-кодами. Чтобы исправить это, мне пришлось изменить тест на моем url-загрузчике (в моем случае мой процессор изображений), чтобы не загружать папку шрифтов. Мне все еще нужно было установить выход.publicPath в webpack.конфиг.js as @will-madden отмечает в своем превосходном ответе.

Я испытал ту же проблему, но по разным причинам.

после того, как решение Уилла Мэддена не помогло, я попробовал все альтернативные исправления, которые я мог найти через Intertubes — также безрезультатно. Исследуя дальше, я просто случайно открыл один из файлов шрифтов, о которых идет речь. Исходное содержимое файла каким-то образом было перезаписано Webpack, чтобы включить какую-то информацию о конфигурации, вероятно, от предыдущего возни с загрузчиком файлов. Я заменил поврежденные файлы на оригиналы и вуаля, ошибки исчезли (как для Chrome, так и для Firefox).

Я знаю, что это не отвечает на точный вопрос OPs, но я пришел сюда с тем же симптомом, но по другой причине:

у меня было .scss файлы Slick Slider включены следующим образом:

при ближайшем рассмотрении оказалось, что он пытался загрузить шрифт из недопустимого места ( /assets/css/fonts/slick.woff ), как это было указано в таблице стилей.

Я закончил тем, что просто скопировал /font/ мой assets/css/ и вопрос был решен для меня.

url-загрузчик работает как файл-загрузчик, но может возвращать DataURL, если файл меньше, чем ограничение в байтах.

таким образом, другим решением этой проблемы было бы сделать предел достаточно высоким, чтобы файлы шрифтов включались как DataURL, например, в 100000 более-менее 100Kb :

всегда с учетом того, что предельное число представляет:

ограничение байта для встроенных файлов в качестве URL-адреса данных

таким образом, вам не нужно указывать полный URL-адрес ресурсов. Что может быть сложно, когда вы хотите, чтобы Webpack не только отвечал с localhost.

только одно последнее соображение, эта конфигурация не рекомендуется для производства. Это просто для развития легкости.

если вы используете угловые вы должны проверить, чтобы убедиться, что ваше

тег приходит перед вашим набором таблиц стилей. Я переключил свой код с этого:

и проблема была решена. Спасибо этот пост за то, что открыл мне глаза.

для Webpack (>4.0) решит эту проблему.

используя extract-text-webpack-plugin в принятом ответе это не рекомендуется для Webpack 4.0+.

Источник

Webpack: Failed to decode downloaded font: OTS parsing error: invalid version tag #923

Description

Since v0.6.1, I’m having an issue with the font I’m using. I was on 0.2.1 before.

Expected behavior

The font should be loaded properly and displayed correctly.

Actual behavior

The font is not displayed and an empty rectangle appear in place of the font/icon

Environment

react-scripts@0.6.1
node v4.5.0
npm 2.15.9

Operating system: OSX 10.11.5 El Capitain
Browser and version: Chrome 53.0.2785.116 64b

Reproducible Demo

The text was updated successfully, but these errors were encountered:

Can you provide a full project reproducing this please?

In the meantime you should be able to use the public folder as an escape hatch to handle fonts without Webpack. There is a section in the user guide on the public folder.

I’ve finded the issue.

The fonts was located in public/fonts/ and css in public/css/ . The font was loaded from the css with url(fonts/myfont.woff) so the font should have been placed in public/css/fonts . Stange about this issue though.

Okay this makes sense. We serve index.html as fallback for unrecognised paths cause it usually makes sense in single page apps. So this is what you were getting instead of the font.

thanks @gaearon loving create-react-app

Hello,
Sorry am late, but in case someone runs into a similar error in future.

I encountered the same issue, and after hours of blind trial and errors, this is how I solved the issue:

Foremost, the browser is unable to use the fonts due to poor formats. In this case, Fonts Squirrel comes in handy. Use the generator to to convert your uploaded standardized web fonts.

After downloading the standardized fonts, move the extracted fonts (*.oet, *.ttf, *.woff, *.woff2) to your public folder in the react app. This ensures that the fonts are available to the react server when the app loads during development and as well after build.

Use the @font-face rule included in the fontsquirrel extract to include the fonts in the .svg file.
You should have something close to this in your .svg file

Источник

OTS parsing error #138

I’m using uicons with jsdelivr. Lately, I’m getting the following errors
dashboard:1 Failed to decode downloaded font: https://cdn.jsdelivr.net/npm/@iconscout/unicons@4.0.0/fonts/line/unicons-6.woff2 dashboard:1 OTS parsing error: invalid sfntVersion: 1936028172 dashboard:1 Failed to decode downloaded font: https://cdn.jsdelivr.net/npm/@iconscout/unicons@4.0.0/fonts/line/unicons-9.woff2 dashboard:1 OTS parsing error: invalid sfntVersion: 4008750 dashboard:1 Failed to decode downloaded font: https://cdn.jsdelivr.net/npm/@iconscout/unicons@4.0.0/fonts/line/unicons-3.woff2 dashboard:1 OTS parsing error: invalid sfntVersion: -369077877 dashboard:1 Failed to decode downloaded font: https://cdn.jsdelivr.net/npm/@iconscout/unicons@4.0.0/fonts/line/unicons-11.woff2 dashboard:1 OTS parsing error: invalid sfntVersion: 1110126000

The text was updated successfully, but these errors were encountered:

hey 7aklhz, any luck with this issue?

nope. still there

thanks. console is just full of warnings. using v3.0.1 for now

Hello. Getting the same in Nuxt and using the URL mentioned on the website:

same problem using integration code recomended by website with vue.

i use
in my index.html

Edit: using v3.0.1 fixed but I dont know what icons I will lose

Same problem — I’m using v4.0.0

same problem v4.0.0

@tarunmangukiya: any news on this please ?

Same problem here.

Any chance of a fix? Sure, it’s not urgent, but because it fills up the console with warnings it makes it easy to miss other warnings.

Still an issue! Please fix

I also have this problem in unicons 4.0.0
I decided to swap version 4 for version 3.
It works well for me:

I’m having the exact same issue with 4.0.1. I’m referencing the CSS and font files locally, but I know the paths and everything are correct because the icons display correctly, yet I get the “OTS parsing error” for all .woff2 fonts.

Same problem. v4.0.0 line
Chrome: » Failed to decode downloaded font: »
Mozilla: «downloadable font: rejected by sanitizer «

Источник

OTS parsing error #40

We are getting this error since yesterday
FortAwesome/Font-Awesome#9352

It works fine on local, but when deployed, the browser fails to parse.

Failed to decode downloaded font: http://xyz.com/fonts/fontawesome-webfont.woff2?v=4.7.0
xyz.com/:1 OTS parsing error: invalid version tag
xyz.com/:1 Failed to decode downloaded font: http://xyz.com/fonts/fontawesome-webfont.woff?v=4.7.0
xyz.com/:1 OTS parsing error: invalid version tag
xyz.com/:1 Failed to decode downloaded font: http://xyz.com/fonts/fontawesome-webfont.ttf?v=4.7.0
xyz.com/:1 OTS parsing error: invalid version tag

The text was updated successfully, but these errors were encountered:

Confirm, does not work on my Travis CI istance.

Our workaround was to use a different gulp task for fontawesome.
The first task always worked, but no longer does. So we added the second task just for fontawesome.

Having the same issue. Will there be a new release with a fix?

Is there a solution for this?

Make sure to have Font Awesome install the CSS and assets to the right place. It’s referencing ../fonts in this case, so make sure your web server deploys them to the right location.

In my case, i have arrange the files as follow:

And I can see that the fonts are loaded in my browser (chrome), but I still get this error:
Failed to decode downloaded font: http://localhost:5000/fonts/fontawesome-webfont.woff2?v=4.7.0
Dashboard#/menu?_k=wtjpz9:1 OTS parsing error: Failed to convert WOFF 2.0 font to SFNT

Am I the only one here? Anyone can point me to the right solution?

I tried to reinstall the fontawesome package from bower.. and now it works just fine.
Please try to reinstall / redownload the font files.

Hope this solve the issue. 😄

I still have the issue with 4.7.0 I completely removed the package and reinstalled it through Bower but the error is still there.

in the bower.json
«main»: [
«css/font-awesome.css»
],
in version 4.7
All fonts file was removed from tag main so that why below code does not work
gulp.task(‘fonts’, function() <
return gulp.src($.mainBowerFiles())
.pipe($.filter(‘**/*.‘))
.pipe($.flatten())
.pipe(gulp.dest(path.join(conf.paths.dist, ‘/fonts/’)));
>);

I had this problem and in my case was Git treating the file as a text file, and messing with its «line endings». This was corrupting the file. you can check this stackoverflow answers for some solutions:

Same thing happened to me that happened to @hermeslm—git corrupted the line endings so I had to create a .gitattributes file and force git to treat .ttf files as binary.

I noticed there was some weird commit with the .ttf files, and after I had created a .gitattributes file, but I guess I didn’t realize I need to revert the odd commit git wanted to make to the .ttf files themselves.

The red herring for me was that I’m using webpack, url-loader/file-loader, Electron, etc.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Font-awesome OTS parsing error: Failed to convert WOFF 2.0 font to SFNT #648

I’m getting the following in the Chrome console recently. I’m using the latest parent and child code.

When I click on the font in the console, its there so the paths seem correct and file is on the server, so I wonder if its being treated as a text file in the gulp copy, rather than a binary? Maybe needing something like options: < process: processFiles, noProcess: [‘ttf,otf,woff,woff2,eot>‘]>?

The text was updated successfully, but these errors were encountered:

Have you tried setting the mime type on server to font/woff2 ?

As far as I understand, pipe literally streams a readable source into a writable destination (may that be a task or file or process) and does not care about whats going in or out. So what ever goes in, comes out.

This demo task is also the preferred method as described in the documentation.

How did you get the files onto the server; is there anything along the path that could have disrupted the encoding or the way the files are read by the server/client?

Thanks guys, really appreciate the help, and sorry if its not actually a bug but a fault with our process.

We use AWS OpsWorks, which basically pulls the latest from the repo, and then runs gulp styles and then gulp dist and copies the dist directory to the web dir, so I’m not sure if it is doing anything else disruptive in the path, its fairly primitive?

Happy to try setting the mime type to font/woff2 , how would I do that?

For apache I think you can add this to .htaccess:

That will set the content-type header.

For nginx I think you can paste this into mime.types file without the surrounding tag and remove AddType from each line.

Obviously this is for all font types, just merge as necessary.

Thanks, I’ve added that to nginx and restarted but still get the errors unfortunately

So I redownloaded the understrap child theme, deleted the fonts and replaced them with the source ones from github, but still get the error.

I’ve also set .gitattributes to force them to binary just in case with:
*.eot binary *.otf binary *.ttf binary *.woff binary *.woff2 binary

At a bit of a loss, as the fonts are there at the url when you click on them in the web page inspector, but just still getting the errors?

Header is set correctly so I guess it’s not that.

How are you uploading the files to server? If you are deploying with git you might need to set filetype as binary in gitattributes so it doesnt modify line endings.

Thanks mate, yes have done that too in .gitattributes

From what I read I´d say that this is most definitely not UnderStrap related. For that reason I´ll close that issue. May the force be with you 😉

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

My setup is a simple Webpack(v1.) with React, jQuery and Bootstrap (all working nicely). I tried to add font-awesome via npm i font-awesome -S. I suppose the best solution would be to load it automatically. I only get a console error in the browser saying the following for each font file:

Failed to decode downloaded font: http://localhost:3000/static/fontawesome-webfont.ttf?v=4.7.0
OTS parsing error: invalid version tag

This is my setup:

webpack.config

...
output: {
  path: path.join(__dirname, 'dist'),
  filename: 'bundle.js',
  publicPath: 'http://localhost:3000/static/'
},
module: {
  loaders: [
    ....
    {
      test: /.woff(2)?(?v=[0-9].[0-9].[0-9])?$/,
      loader: "url-loader?limit=10000&mimetype=application/font-woff"
    },
    {
      test: /.(ttf|eot|svg)(?v=[0-9].[0-9].[0-9])?$/,
      loader: "file-loader"
    }
  ]
},
...

app.scss

$fa-font-path: 'http://localhost:3000/static';
@import '../../node_modules/font-awesome/scss/font-awesome.scss';

… and then I import the scss file in the main App.js file.

As you can see, I am using file-loader and url-loader for the fonts.

It would be nice to see a list of all files that are served in the static-url, is there a way to output that information in the console? Its hard to see even where the problem is. If the fonts aren’t loaded at all or just at the wrong url.

I was wrestling with a very similar problem just recently: using font-awesome (the npm package version) in my Meteor app. It turned out, that the font files weren’t loaded/served at all.

Answering the second part of your question: the font files should be visible in the «Sources» tab (in Chrome developer tools), if they are loaded correctly.

The first part is trickier, and I’ve no solution, just a hint: Since your font files don’t seem to get loaded, I would conclude that webpack doesn’t «see» the font files. Either «node_modules» is excluded somewhere in your configuration, or the font-awesome npm package doesn’t export the font files properly. Or something in between.

My problem was similar: the static content from within the «node_modules» folder isn’t acknowledged whatsoever by Meteor’s internal bundler. So my workaround was to create an npm «postinstall» script in package.js that copies the font files to an appropriate location: «PATH_OF_MY_APP/public/fonts» in my case, so that the bundler could pick them up.

February 27, 2019 at 2:19 pm

#110093

February 27, 2019 at 3:24 pm

#110107

February 28, 2019 at 7:56 am

#110195

February 28, 2019 at 9:55 am

#110209

February 28, 2019 at 2:36 pm

#110263

February 28, 2019 at 3:35 pm

#110274

February 28, 2019 at 3:44 pm

#110277

March 1, 2019 at 7:09 am

#110348

March 1, 2019 at 8:02 am

#110367

March 1, 2019 at 9:35 am

#110403