feature request: use of @font-face
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dvisvgm |
New
|
Medium
|
Martin Gieseking |
Bug Description
Hi, this is not a bug, but a feature request. However, I did not find a special forum for posting feature requests, so I put this here...
I would like to request that future versions of dvisvgm support the @font-face feature of CSS (http://
The idea would be that
\documentclass{
\usepackage{
\begin{document}
Hallo Welt.
\end{document}
produces something like this:
<?xml version='1.0' encoding=
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://
<!-- This file was generated by dvisvgm 1.2.2 (x86_64-
<!-- Fri Aug 23 12:45:33 2013 -->
<svg height='630.635pt' version='1.1' viewBox='-46.3263 27.9508 405.479 630.635' width='405.479pt' xmlns='http://
<defs>
<font horiz-adv-x='0' id='rm-lmr10'>
<font-face ascent='1127' descent='-290' font-family=
<missing-glyph d=''/>
<glyph d='M192 53...' glyph-name='period' horiz-adv-x='278' unicode='.'/>
<glyph d='M419 0...' glyph-name='one' horiz-adv-x='500' unicode='1'/>
...
</font>
</defs>
<style type='text/
@font-face {
font-
src: url("lmroman10-
}
text.f0 {font-family:
]]>
</style>
<g id='page1' transform=
<text class='f0' x='77' y='63'>Hallo<tspan x='103.
<tspan x='112.
<tspan x='232' y='633'>1</tspan>
</text>
</g>
</svg>
Note the added @font-face. At least on Safari, this causes the fonts to be rendered using the real OpenType font, if the font is available at the specified URL and, if not, the embedded font is used as a fallback.
I know this is kind of tough to implement since it is hard to "tell" where the actual fonts are and it is not clear what the URLs should look like (absolute? relative? should the fonts be copied?). However, if one wishes to use SVG as a replacement for PDF during a presentation or for longer text to be read online, high-quality fonts would be a real plus.
Thanks for your suggestion. I have to think about it a bit more before I assess whether it works in a generic way.
Especially, one problem might be the fact that there's not always a simple relation between the DVI character code and the corresponding UTF-8 code point. All recent versions of dvisvgm create SVG files that use the DVI char codes to mark and reference the characters. Thus, if some of them differ from the unicode points, you get wrong results when directly accessing the font files.
However, I'm currently switching the code to correct UTF-8 encoding which requires a lot of font table magic. I'll see if an acceptable support of @font-face descriptions is possible.