Problemas con el texto dinámico en SVG cuando la fuente no es SVG

Por lo tanto, tengo una cadena de automatización de gráficos que se ha estado ejecutando felizmente en un entorno de Linux sin cabeza utilizando SVG generados/alterados mediante programación y PhantomJS (actualmente 1.9.0) como motor de renderizado final. Tengo algunos requisitos de reemplazo de texto dinámico, y las necesidades de ajuste y escalado de fuentes dinámicas resultantes... He estado usando fuentes SVG incrustadas y algunos javascript incrustados de mala calidad, que funcionan bien, excepto por dos cosas:

1) El cliente tiene algunas solicitudes de fuentes con ligaduras (que el formato de fuente SVG no admite)

2) Estamos considerando una opción de vista previa en vivo y nos encantaría poder mostrar el SVG en la página web sin generar un png/jpeg/lo que sea en nuestro servidor de antemano. mantener la carga baja, hacer que la CPU del cliente haga el trabajo pesado, todo eso.

En interés de estos problemas, he estado jugando con las fuentes WOFF, ya que la compatibilidad con las fuentes SVG nunca fue MUY buena, y ahora que Chrome ya no las admite con el cambio al motor Blink, si quiero el cliente hago mi trabajo necesito algo compatible con tantos navegadores comunes como sea posible...

Así que aquí está el problema: mi escalado automático falla miserablemente cuando uso una fuente WOFF (u OFT o TTF) y la función @font-face.

lo que he estado haciendo es simplemente incrustar la fuente SVG en mi gráfico en las definiciones y hacer referencia con el DOM como cualquier otro elemento SVG. Esto hace las cosas que espero y necesito cuando se combina con un script java como este:

<script id="multiscaler1" type="text/javascript">
    var texta = document.getElementById(&quot;text8093&quot;);
    var textb = document.getElementById(&quot;text8100&quot;);
    var textpatha = document.getElementById(&quot;textPath8097&quot;);
    var textpathb = document.getElementById(&quot;textPath8104&quot;);
    var patha = document.getElementById(&quot;path8091&quot;);
    var pathb = document.getElementById(&quot;path8089&quot;);
    var charcounta = textpatha.getNumberOfChars();
    var charcountb = textpathb.getNumberOfChars();
    var fontsizea = 10;
    var fontsizeb = 10;
    var offseta = -13;
    var offsetb = -13;
    var spacing = 0;
    while ( ((textpatha.getComputedTextLength() + (spacing * charcounta)) &lt; patha.getTotalLength()) &amp;&amp; (fontsizea &lt; 43) )
    {
        fontsizea += .5;
        offseta += 0.2
        textpatha.setAttribute(&quot;font-size&quot;, fontsizea);
        texta.setAttribute(&quot;transform&quot;, &quot;translate(&quot; + offseta + &quot;,0)&quot;);
    }
    while ( ((textpathb.getComputedTextLength() + (spacing * charcountb)) &lt; pathb.getTotalLength()) &amp;&amp; (fontsizeb &lt; 43) )
    {
        fontsizeb += .5;
        offsetb += 0.2
        textpathb.setAttribute(&quot;font-size&quot;, fontsizeb);
        textb.setAttribute(&quot;transform&quot;, &quot;translate(&quot; + offsetb + &quot;,0)&quot;);
    } 
</script>

Bastante basura, lo sé, pero soy gerente de producción y artista gráfico, no programador :P y se ve así:

Que es lo que quiero... (pero, por supuesto, solo funciona en navegadores que admiten fuentes SVG...)

ahora, cuando agrego esta pequeña belleza a mis deffs

<style type="text/css">
@font-face {
  font-family: Narrow-Bold;
  src: url('WOFFFONTS/Narrow-Bold.woff');
}
</style>

y elimino los datos de la fuente SVG, obtengo esto:

Oh querido. Eso no está bien en absoluto. He jugado con mis valores de espaciado (que están ahí para lidiar con otra situación en la que cambio el espaciado de los caracteres para maximizar el tamaño de la fuente en función de la longitud de la cadena...) y puedo hacer que haga esto:

tambien bastante mal :/

¿Qué da aquí? ¿Alguna ayuda? Francamente, sería maravilloso cambiar todo a fuentes WOFF (o fuentes OTF o TTF vinculadas a @font-face, que por cierto, hacen lo mismo) ya que tendría muchos menos SVG de más de 20,000 líneas sin incrustar fuentes por todas partes el maldito lugar...

Probé diferentes herramientas de conversión de fuentes e incluso encontré un truco en algunos resultados de búsqueda de Google en los que construyes el WOFF desde el SVG, no el TTF o el OTF... los mismos resultados.

??

A continuación se muestra un ejemplo simplificado de un SVG autónomo que funciona con una fuente SVG incrustada que utiliza la fuente gratuita Delicious Bold . Obviamente, esto solo funcionará en un navegador que admita fuentes SVG. La fuente incrustada se creó a partir de una nueva descarga de OTF con FontForge para Windows versión 2015-06-12 . También creé una versión WOFF de la misma fuente.de la misma manera (todas las configuraciones predeterminadas, ignorando la advertencia sobre "avance ems no estándar" en la definición TTF) y agregó un enlace @font-face con un nombre diferente que apuntará al WOFF cuando esté en el mismo directorio que el SVG. Al editar font-face="xxxxxx" en el elemento text/textpath del SVG, puede cambiar rápidamente entre la fuente SVG incrustada (que funciona bien), la fuente WOFF vinculada (que escala incorrectamente) y la versión del sistema de la fuente. familia, si está instalada (que quizás sea de notar, se representa de forma ligeramente diferente a la fuente SVG incrustada, pero también se escala correctamente)

Este comportamiento es consistente en todos los navegadores probados (Opera-último para Windows 7 de 64 bits, Mozilla-último Linux Ubuntu 14, Chrome-último Windows 7/8 de 64 bits, Safari 5.1.7 para Windows (admite fuentes SVG) y PhantomJS 1.9.7 Linux CentOS 6.4 final (soporta fuentes SVG) También es consistente en todas las fuentes probadas (muchas...) y motores de conversión de fuentes (squirrel-font, FontForge, Birdfont...)

Como el SVG autónomo es demasiado grande para pegarlo en el cuerpo, aquí hay un enlace pegado en un proyecto JSfiddle .

Sí, me doy cuenta de que podría resolver esto renderizando con Apache batik, pero: 1) Batik es lentooooooooooo. Muuuuy despacioooooooooooooooooooooooow... Dios mío, es lento. 2) Quiero poder descargar la mayor cantidad posible de la carga de la CPU de mi servidor, exactamente lo INVERSO de lo que hará el batik 3) ¡Ese no es el punto, maldita sea!