flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: Here Comes MXMLC!
Date Wed, 28 Mar 2012 09:50:10 GMT
Hello Oleg,

the main difficulty is that its not Open Source. We can not deploy it, 
having no "font tool" out
of the box well ... sucks.

Aside from that. I checked swfmill, its haXe pendant and a few other 
open source projects
but they all just support DefineFont3 (not cff). As far as I can tell 
cff = Microsoft OpenType
content. So: Basically any tool provided would need to transform 
<inputfont> to <opentype>
and add it to the swf.


PS.: You can try to redesign the compiler as much as you want :) I for 
my part wait for Falcon.

On 28/03/2012 18:37, Left Right wrote:
> Hello,
> more out of curiosity: what is the main difficulty behind using FontSwf? Is
> it the generation of the proper SWF tag or is it the generation of the
> outlines or the kinds of fonts it supports, or is it the parsing the source
> font files? I'm asking this because there is another OSS code that manages
> fonts inclusion (beside the font managers used in SDK compiler). Actually
> two that I know, but I don't know on the very technical level how outlines
> / font images are being embedded.
> By "difficulty" I mean: what is the main reason FontSwf is used and what
> part of it one would need to rewrite in order to reproduce the
> functionality it provided today (we could still modify the other font
> managers, right)?
> Finally, I'm not very fond of the compiler design as it is today, which
> says that every thing related to the compilation process must be piled up
> into the same heap. Possibly, in the longer run, if people agree... it
> would be better to split it to modules. I'd see it as a positive thing to
> have decoders and the linker as a separate module. But this is a plan for a
> _very_ distant future, if at all :)
> Best.
> Oleg

View raw message