What’s the difference between EOT lite and EOT compressed?
It says that EOT files have a domain binding built in, but for example I can convert my fonts to EOTs with the FontSquirrel converter where I cannot enter any URL where the files should be bound to.
Would be great if somebody could enlighten me! :)
The domain binding isn't necessary and can be dropped. EOT Lite is effectively just a TTF with a different file ending while EOT compressed is just adding MTX compression to the mix. You can actually check that yourself by comparing a FontSquirrel generated TTF and EOT lite against each other in a hex editor. Except for a few additional flags the files are practically identical.
Source
Related
I wanted to write a little website which provides quite long audio playbacks.
Because I have a very limited webspace I wanted to compress the .wav files I have with the tool wavpack. The compression works pretty good and the vlc media player is able to play the file but used within a website via the audio tag it does not work. I noticed that windows is not able to display the bitrate nor the length of the audio file in its detail page maybe this is an indicator that the file is not properly converted/compressed?
Does someone know if the current browser support wavpack, what the correct MIME type would be or if there is another lossless compression for .wav files.
Thank you all in advance.
Unfortunately, there is no MIME type for WavPack (see here and there).
But that's probably not a problem! Actually, in the default mode, WavPack only compacts your WAV files. As mentioned on their website (emphasis mine):
In the default lossless mode WavPack acts just like a WinZip compressor for audio files. However, unlike MP3 or WMA encoding which can affect the sound quality, not a single bit of the original information is lost…
So, if you use the default mode:
you gain a bit of disk space/bandwidth compared to the original audio
you don't lose any quality
For the purpose of a website, you would be better off encoding your files to a lossy format (AAC, Ogg Vorbis, MP3, etc.) which will give you a real compression gain.
In the end, you have two solutions:
You don't care about bandwidth / You care about quality: Use pure WAV files
You care about bandwidth / You care less about quality: Use AAC or Ogg Vorbis
First, I apologize as I'm essentially new to working with audio.
The web application I currently work on, designed using asp.net/vb.net, allows users to record and play back audio using the Nanogong applet (http://nanogong.ust.hk/doc_faq.html). We are shifting over to HTML5 audio as support for the NPAPI plugin has been removed from most browsers (except Firefox until the end of this year).
Nanogong uses 4-bit IMA ADPCM to encode wav files. I'm able to convert the Nanogong wav file into 16-bit PCM using sox, and then using that wav file create an ogg version using oggenc2 and an mp3 version using lame. We need the ogg files for Firefox and Chrome, and the mp3 for Safari.
What I would like to learn is why browsers do not seem to be able to play the 4-bit IMA ADPCM format? Can they only play PCM format in 8-bit or 16-bit? In Firefox, firebug indicates the IMA ADPCM wav file cannot be decoded; Chrome and Opera don't mention anything in the developer console, but I'm guessing it's the same as Firefox since the file won't play in those browsers.
I've tried searching the web but there doesn't seem to be a whole lot about HTML5 audio, or most of it seems to be older information. I also see more articles about converting from PCM to ADPCM.
Any guidance or resources would be greatly appreciated. Thanks!!
Browser vendors are not required to support any particular audio format. There are issues such as licensing, although perhaps not so relevant in this case, which make vendors only support the most basic (such as uncompressed PCM) and common formats (MP3, OGG etc.), and in some cases would rely on the underlying system to decode audio (or video). Size of code base relative to gain could be another factor.
4-bit IMA ADPCM would fall into the category "not so common" as of today which is likely why there is no support to find in the browsers.
It's possible to get around this though by supporting the format manually using Audio API (which eliminates IE) and binary parsing/decoding. I am doing this is my audio-reader-js library but currently I have no support for IMA encoded data. It can be used as a basis though to implement support for this as well.
<img src="./img/pic.png">
<img src="./img/pic.svg">
Locally the two lines above work and display two pictures but once deployed remotely (for example, on a ftp) only the png displays (permissions are set to the most permissive for both files).
Any idea?
By the way, it seems any sort on svg cannot be display, I can access to pic using its path but loading in html does not work.
I'm sure this is real stupid.
Seems weird as SVG support is pretty good on a lot of browsers
http://caniuse.com/#search=svg
This could be down to your server, If it's an Apache server you could try adding
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
to the .htaccess.
I am building an offline Html5 App and I have to prepare my manifest file for caching all files I am using.In previous releases of JQM I just included:
jquery.mobile-x.x.x.min.js, jquery.mobile-x.x.s.min.css, the 2 icon files and the spinner.gif....And my App worked just fine...
Now it turns out that JQM 1.4.1 includes a bunch of files that I don't know if I have to cache them all?
What should I do with all these files?
Do I have to include them all in my manifest file?
This is not a thorough answer but no, you don't need both the regular and "minified" version of all those files. The .min.* files should theoretically load a bit faster and are worth bundling into the cache manifest. Also if you are targeting multiple device formats, you might want both the PNG and SVG images. However if you are targeting a single device profile (as we are) you can probably isolate only the image format that you want. The default is now SVG with PNGs as backup for browsers that don't support vector images fully.
I recently started using svg images in my sites. Some of them are complex and quite big, so I've started compressing them. They compress really well.
Why would one ever not use SVGZs (instead of the uncompressed version)? Are there well-known pitfalls that I should be aware of?
As long as your webserver sets the proper Content-Encoding HTTP header it should work in all browsers that support SVG.
The one pitfall I know of is if you want to be able to open the svgz files from disk locally (that is: without using a webserver). That doesn't work in all browsers.
Also if your svg files are big, then you should consider preprocessing them with SVG Scour or similar. It's rather common to see vector graphics editors such as Illustrator and Inkscape output display-redundant data in the files (binary blobs or custom xml markup).
Is it for desktop browsers, mobile? I know Opera supports SVGZ natively since 8.0 at least (maybe even earlier).
What server? Apache, IIS? You might have to configure it and/or mess with .htaccess. Here's a howto for Apache: http://kaioa.com/node/45
Keep in mind that the server might be already serving your content compressed, if your client supports it, as SVGZ is just a normal SVG with gzip compression applied.