EOT

No — EOT should not be generated for new builds. It exists solely for Internet Explorer 4 through 11, and Microsoft's own successor browser, Edge, dropped EOT support entirely. The W3C standardized WOFF and WOFF2 instead, and virtually every current browser renders WOFF2 natively. A DAM's web-font pipeline should output WOFF2 as the primary format, with WOFF as a fallback, and skip the EOT step, since it only adds build complexity for a rendering target with no remaining production traffic.

Microsoft designed EOT with a 'rooting' mechanism — an encrypted list of authorized domains checked by Internet Explorer's decryption library — to reassure type foundries that embedded fonts couldn't be freely reused off the licensed site.

Only Internet Explorer supported EOT natively, from version 4 in 1997 through Internet Explorer 11. No other browser — not Chrome, Firefox, Safari, Opera, nor Microsoft's own Edge, which replaced IE — ever implemented EOT rendering; each adopted WOFF or WOFF2 instead. For a DAM, this means an EOT file inherited from an old asset library cannot be served directly to today's visitors — it must first be converted to WOFF/WOFF2 or the original TrueType/OpenType source before it will render in any current browser.

No. Microsoft submitted the EOT specification to the W3C twice — first folded into a 2007 CSS3 submission, then as a standalone submission on March 18, 2008, alongside Monotype Imaging's MicroType Express compression spec. The W3C never advanced it past 'submission' status — the category for member-proposed specs it has not endorsed — and instead developed WOFF, later WOFF2, as its Recommendation. For a DAM, this matters: WOFF/WOFF2 are the standardized formats, while EOT remains a proprietary, single-vendor format that never left submission.

Often yes, using tools like FontForge or dedicated EOT-to-TTF converters, though the result should still be checked against the original font's license terms before reuse, since EOT's subsetting may mean it lacks the full original character set.

Deletion is unnecessary and can be counterproductive. EOT files are typically small, so storage cost is negligible, while the file itself documents which domains were originally authorized under the format's encrypted 'rooting' mechanism — useful licensing history if the underlying font's usage rights are ever questioned. The safer approach is to tag each EOT file as deprecated/legacy in the DAM's metadata, exclude it from active build and delivery pipelines so it's never served to a live site, but retain it alongside its original TrueType/OpenType source (if archived) as a record of the asset's licensing and deployment history.

EOT typically compresses fonts using MicroType Express, an LZ-based compression method contributed by Agfa/Monotype, combined with character subsetting that strips out glyphs not used on the source page — together these keep file sizes down while also enabling EOT's encrypted domain-authorization ('rooting') layer, which WOFF and WOFF2 don't have. WOFF wraps the original TrueType/OpenType tables using zlib/deflate compression plus metadata and private-data blocks, while WOFF2 improves on this with Brotli compression and additional table-transform tricks, generally yielding smaller files than either EOT or WOFF for the same source font, with no DRM overhead.

Typically no. EOT files are usually subsetted — trimmed down to include only the characters actually referenced on the specific source page, which is part of how the format kept downloads small on 1990s-era connections. That means an archived EOT file may be missing glyphs for languages, symbols, or punctuation the original page never used. For a DAM, this makes EOT unsuitable as a canonical master: if a font needs to be reused on a different page, in another language, or with expanded character coverage, the pipeline should return to the original full TrueType/OpenType source file rather than the subsetted EOT.