Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of olegsivokon@gmail.com
 designates 209.85.210.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F72CED6.6020902@leichtgewicht.at>
References: <CB98002A.3E397%aharui@adobe.com>
	<4F72CED6.6020902@leichtgewicht.at>
Date: Wed, 28 Mar 2012 05:37:51 -0400
Message-ID: 
 <CAJQBtgn1_jz19Z9buU3UHCN0ZB-qmO+Fp1ybu97V0G3hpTW5YQ@mail.gmail.com>
Subject: Re: Here Comes MXMLC!
From: Left Right <olegsivokon@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d0447870f6de82f04bc4a5cd9

--f46d0447870f6de82f04bc4a5cd9
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d0447870f6de82f04bc4a5cd9--