You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/03/27 21:04:34 UTC
Here Comes MXMLC!
Today we finally got the last blocking legal issue resolved and are now hunting down executives to sign the appropriate documents to submit the source code for MXMLC to Apache. The final signature has to come from a VP who is on vacation this week, but we are going to try to get him to sign from where ever he is. Yes, there is still some chance of a glitch in the approvals, but it is low probability.
Then, of course, we have to get Apache Infra to do an SVN load of the code with history. But Carol will probably check in code w/o history into her whiteboard.
There are some things related to this donation that you should be aware of:
1) We were unable to get clearance for any compiler tests. They were too infested with stuff with incompatible licenses. So, those interested might want to plan out how to verify compiler changes going forward.
2) CFF Font Embedding is not being donated. The source code is not under control of the Flex team at Adobe. This means that you won’t be able to compile
@font-face(“somefile.ttf”); embedAsCFF:true
For now, you can use the JAR files from a full Adobe Flex release. You can also use the fontswf utility or Adobe CS products to make a SWF with a CFF font in it and embed from there. We will try to figure out a better solution later. We decided not to delay the compiler donation for this issue.
3) We are also watching a discussion on the general@i.a.o list about binary dependencies that will affect the MXMLC –services option. We will eventually have the code for that when BlazeDS gets donated, but for now, we were going to check in the jar file. We may need to write the equivalent code for this capability as well until BlazeDS gets in.
Once the code is loaded into SVN, Carol will try to execute the steps of making an Apache release. I expect it will take several attempts. And we would like someone else to also try to be a “release manager” as Carol will be unavailable during the week leading up to 360Flex. But once we think we have it figured out, I think we can open all of the donated source for changes, especially for the compiler if there are folks writing tests for it. Meanwhile I will be working on getting Mustella donated. I am trying to find a clever way to get a minimum amount of it donated by 360Flex. No promises though.
So, please try to reserve some time to participate in the release process, and if interested, in creating a compiler test suite.
Thanks for your patience.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Here Comes MXMLC!
Posted by Alex Harui <ah...@adobe.com>.
On 3/27/12 12:56 PM, "Om" <bi...@gmail.com> wrote:
> 2) CFF Font Embedding is not being donated. The source code is not under
>> control of the Flex team at Adobe. This means that you won¹t be able to
>> compile
>> @font-face(³somefile.ttf²); embedAsCFF:true
>> For now, you can use the JAR files from a full Adobe Flex release. You
>> can also use the fontswf utility or Adobe CS products to make a SWF with a
>> CFF font in it and embed from there. We will try to figure out a better
>> solution later. We decided not to delay the compiler donation for this
>> issue.
>>
>
> Can you please elaborate on this? Does this mean that it wont be possible
> to compile a font with mxmlc going forward?
No, just CFF fonts from source font files. You can get the Adobe fontswf
utility and make SWFs to embed CFF fonts.
> And this
> also means that we wont be able to use TLF as well?
If you have a SWF with CFF fonts, you can embed those fonts and use them
with TLF.
>
> If I understand it correct, your workaround is as follows:
>
> 1.) Use the FontSwf utility (available here:
> http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f
> 5f.html#WS02f7d8d4857b16776fadeef71269f135e73-8000)
> to convert a single font (.ttf or .otf) file into a font.swf file
> 2. Embed the font.swf file into the targeted Flex application.
> 3. Use the Font as usual in the Flex application
Yup
>
> More questions:
>
> 1. Do we get the source code for FontSwf? (I am guessing not...)
No. And we are not donating the binaries either at this time.
>
> 2. Will it be okay to distribute FontSwf (binary) along with Apache Flex?
No. Not at this time.
>
> 3. I see that FontSwf is only for users of the MPL version of the Flex
> SDK. This clause needs to changed to make it work with Apache Flex, right?
No, not at this time. We are still working out what are options are for CFF
embedding.
>
> 4. In the long run, do you think it is possible to wire MXMLC with the
> FontSwf utility internally, so that end users dont have to jump through
> these hoops to embed fonts?
It is possible, but not my favorite solution.
>
> 5. You said:
>
>> For now, you can use the JAR files from a full Adobe Flex release.
>>
>
> What does 'for now' mean?
Until we decide on and implement a permanent solution for CFF embedding.
> I am guessing we dont have the license for the
> JAR file.
That is correct.
This topic is complicated enough that we opted not to delay the compiler
donation because of it. Yes, it means that you may have to modify your Flex
4 apps to embed CFF fonts until we find the right solution.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Here Comes MXMLC!
Posted by Om <bi...@gmail.com>.
Great news, Alex! This is a big step forward for sure :-)
I have some questions on the CFF Font embedding issue.
2) CFF Font Embedding is not being donated. The source code is not under
> control of the Flex team at Adobe. This means that you won’t be able to
> compile
> @font-face(“somefile.ttf”); embedAsCFF:true
> For now, you can use the JAR files from a full Adobe Flex release. You
> can also use the fontswf utility or Adobe CS products to make a SWF with a
> CFF font in it and embed from there. We will try to figure out a better
> solution later. We decided not to delay the compiler donation for this
> issue.
>
Can you please elaborate on this? Does this mean that it wont be possible
to compile a font with mxmlc going forward? That is a big deal. And this
also means that we wont be able to use TLF as well?
If I understand it correct, your workaround is as follows:
1.) Use the FontSwf utility (available here:
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f5f.html#WS02f7d8d4857b16776fadeef71269f135e73-8000)
to convert a single font (.ttf or .otf) file into a font.swf file
2. Embed the font.swf file into the targeted Flex application.
3. Use the Font as usual in the Flex application
Please confirm.
More questions:
1. Do we get the source code for FontSwf? (I am guessing not...)
2. Will it be okay to distribute FontSwf (binary) along with Apache Flex?
3. I see that FontSwf is only for users of the MPL version of the Flex
SDK. This clause needs to changed to make it work with Apache Flex, right?
4. In the long run, do you think it is possible to wire MXMLC with the
FontSwf utility internally, so that end users dont have to jump through
these hoops to embed fonts?
5. You said:
> For now, you can use the JAR files from a full Adobe Flex release.
>
What does 'for now' mean? I am guessing we dont have the license for the
JAR file.
Thanks,
Om
On Tue, Mar 27, 2012 at 12:15 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
>
> >Today we finally got the last blocking legal issue resolved and are now
> hunting down executives to sign the appropriate documents to submit the
> source code for MXMLC to Apache. The final signature has to come >from a
> VP who is on vacation this week, but we are going to try to get him to sign
> from where ever he is. Yes, there is still some chance of a glitch in the
> approvals, but it is low probability.
>
> Alex,
>
> Interesting news. I am obviously interested in getting my hands on this. I
> am concerned about the tests but we will just have to figure it out.
>
> Mike
>
>
RE: Here Comes MXMLC!
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Today we finally got the last blocking legal issue resolved and are now hunting down executives to sign the appropriate documents to submit the source code for MXMLC to Apache. The final signature has to come >from a VP who is on vacation this week, but we are going to try to get him to sign from where ever he is. Yes, there is still some chance of a glitch in the approvals, but it is low probability.
Alex,
Interesting news. I am obviously interested in getting my hands on this. I am concerned about the tests but we will just have to figure it out.
Mike
Re: Here Comes MXMLC!
Posted by Petr Svoboda <wo...@gmail.com>.
woohoo :) great & thanks for ur work!
On Tue, Mar 27, 2012 at 9:04 PM, Alex Harui <ah...@adobe.com> wrote:
> Today we finally got the last blocking legal issue resolved and are now
> hunting down executives to sign the appropriate documents to submit the
> source code for MXMLC to Apache. The final signature has to come from a VP
> who is on vacation this week, but we are going to try to get him to sign
> from where ever he is. Yes, there is still some chance of a glitch in the
> approvals, but it is low probability.
>
> Then, of course, we have to get Apache Infra to do an SVN load of the code
> with history. But Carol will probably check in code w/o history into her
> whiteboard.
>
> There are some things related to this donation that you should be aware of:
>
> 1) We were unable to get clearance for any compiler tests. They were too
> infested with stuff with incompatible licenses. So, those interested might
> want to plan out how to verify compiler changes going forward.
>
> 2) CFF Font Embedding is not being donated. The source code is not under
> control of the Flex team at Adobe. This means that you won’t be able to
> compile
> @font-face(“somefile.ttf”); embedAsCFF:true
> For now, you can use the JAR files from a full Adobe Flex release. You
> can also use the fontswf utility or Adobe CS products to make a SWF with a
> CFF font in it and embed from there. We will try to figure out a better
> solution later. We decided not to delay the compiler donation for this
> issue.
>
> 3) We are also watching a discussion on the general@i.a.o list about
> binary dependencies that will affect the MXMLC –services option. We will
> eventually have the code for that when BlazeDS gets donated, but for now,
> we were going to check in the jar file. We may need to write the
> equivalent code for this capability as well until BlazeDS gets in.
>
> Once the code is loaded into SVN, Carol will try to execute the steps of
> making an Apache release. I expect it will take several attempts. And we
> would like someone else to also try to be a “release manager” as Carol will
> be unavailable during the week leading up to 360Flex. But once we think we
> have it figured out, I think we can open all of the donated source for
> changes, especially for the compiler if there are folks writing tests for
> it. Meanwhile I will be working on getting Mustella donated. I am trying
> to find a clever way to get a minimum amount of it donated by 360Flex. No
> promises though.
>
> So, please try to reserve some time to participate in the release process,
> and if interested, in creating a compiler test suite.
>
> Thanks for your patience.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: Flash Player premium features
Posted by Igor Costa <ig...@gmail.com>.
Adobe still doesn't know how to make money with Flash Player and still
struggles to fail attempts, like this one.
Maybe this sound gross for some sensitive people. But this is true. And
this isn't something really new, they wrote that in road map
http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
Fails like Flash Catalyst, LCDS, Cocomo, Flash Player Mobile, etc. Made
many serious people who I know abandon Flash Player in some critical
projects.
Regards
Igor
On Wed, Mar 28, 2012 at 5:57 AM, Giorgio Natili <g....@gnstudio.com>wrote:
> Hi All,
>
> I know that Flex is not related to the gaming but I would love to know
> which is the feeling of the mailing list about this news
> http://www.adobe.com/devnet/flashplayer/articles/premium-features.html.
>
> In my opinion it will be used again against the Flash platform, what do
> you think?
>
> Giorgio Natili
> Twitter + skype: giorgionatili
>
>
>
>
>
Re: Flash Player premium features
Posted by Tomislav Pokrajcic <to...@svemir.net>.
ASP.NET frameworks are not transferred to the community, they just
opened the source and applied the Apache license. Microsoft still has to
approve every patch.
Adobe did that with Flex way back in 2008.
AFAIK the problem with Adobe was that it didn't have well established
model (and resources) for accepting community requests and code. Maybe
MS will be able to handle that with more success...
Cheers,
Tomislav
On 30.3.2012. 17:28, Thomas Sammons wrote:
> I just saw the MS release about putting ASP.NET MVC, Web API, Razor (asp.net web pages) out as open source to CodePlex under the Apache license, and the response was completely opposite of Adobe's handling of Flex. Pretty much sums up how badly Adobe botched it.
>
>
RE: Flash Player premium features
Posted by Thomas Sammons <ts...@sei.cmu.edu>.
I just saw the MS release about putting ASP.NET MVC, Web API, Razor (asp.net web pages) out as open source to CodePlex under the Apache license, and the response was completely opposite of Adobe's handling of Flex. Pretty much sums up how badly Adobe botched it.
Re: Flash Player premium features
Posted by JP Bader <jp...@zavteq.com>.
Hey Mark,
One (actually two) slight correction(s):
'(the only source of revenue from flex for Adobe)'
1) Adobe made money off of consulting
2) Some of us made money off of how bad Adobe consulting was when we
had to go in and fix it.
Regardless, Adobe has made it clear what they are focusing in on for
the Flash player, and it is a very specific industry niche (video
streaming/gaming). It is growing and should not be ignored, but it
is, IMO, limited in scope. Flex is, IMHO, more utilitarian, with a
vision to the future that isn't (I hope) limited to games, but
available for any industry, any platform, and possibly (eventually)
any output format.
Adobe is saying they have a huge install base (much, much larger than
any console or browser video game base), and are trying to take
advantage of that. I'm happy to hear they think they have a plan for
taking advantage of premium plans for making money on advanced
features that we, as Flex developers, may or may not use. However the
inventor may not always see the greatest potential of their invention.
Their marketing still is a fiasco, and I am glad I am not in that
department.
That said, glad Adobe made an announcement, but that shouldn't affect
us as Apache.
Cheers,
On Wed, Mar 28, 2012 at 9:00 AM, Mark Fuqua <ma...@availdata.com> wrote:
> I currently (and probably for the next few weeks), do all my Flex
> development for free...because I am still learning. It is not something I
> plan or can do for long...but that's ok, because I can imagine a time in the
> very near future when I will be making money from Flex. As much as I enjoy
> Flex, I need to make money. Adobe might be exponentially larger than my
> tiny little company, but they are no different.
>
> Anything they can do to make money off the Flash platform is fine by me.
>
> Hell, if all us Flex developers had just bought a copy or two of Flash
> Builder Premium (the only source of revenue from flex for Adobe), they would
> probably still be actively investing in Flex and this mailing list would not
> exist.
>
> Adobe quit Flex and Flash for mobile for one reason and one reason
> only...they couldn't make enough money to justify the huge expense and they
> couldn't imagine a different scenario looking forward.
>
> They did it in a stupid, shoot yourself in the foot (and our feet too) way,
> but they really had little choice. They were hemorrhaging money.
>
> Mark
>
> -----Original Message-----
> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> Sent: Wednesday, March 28, 2012 9:23 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flash Player premium features
>
> Hi Giorgio,
>
> I honestly don't really care about it. As a web developer I am not getting
> Flash projects anyways due to last years marketing and because agencies like
> buzz words. As a app developer I do not care of this particular feature as I
> will not be affected (rarely a app really needs the fast memory and stage
> 3d. As a game developer I am/will not be successful enough that this will
> affect me, and even if it would: Its software I use. If I earn more than 50k
> for a app (after taxes) I guess I wouldn't be greedy, after all I can accept
> that some of the success is based on the Flash platform and I have no
> problem to reward them for that (if I use Unity then I haven't paid a cent
> for other Adobe products).
>
> Anyways: the way how it went down is ugly. Specially that they deprecated
> the old avm calls.
> Its one thing if you deprecate something that makes problems but something
> that is actually
> used and useful is uhm: why?? It just annoys people. Makes me wonder
> if they really value bad
> marketing that much...
>
> So: yeah marketing suicide continues... but who really cares: People that
> have no way around .swf will use it like before (my policy is for 6years
> already: use flash only if there is no html option).
>
> yours
> Martin.
>
>
> On 28/03/2012 17:57, Giorgio Natili wrote:
>> Hi All,
>>
>> I know that Flex is not related to the gaming but I would love to know
>> which is the feeling of the mailing list about this news
>> http://www.adobe.com/devnet/flashplayer/articles/premium-features.html.
>>
>> In my opinion it will be used again against the Flash platform, what
>> do you think?
>>
>> Giorgio Natili
>> Twitter + skype: giorgionatili
>>
>>
>>
>>
>>
>>
>
>
>
--
JP Bader
Principal
Zavteq, Inc.
@lordB8r | jp@zavteq.com
608.692.2468
RE: Flash Player premium features
Posted by Mark Fuqua <ma...@availdata.com>.
Sorry, you're correct...Flex specifically and the Flash Platform as a whole, were hemorrhaging money...with no end in sight.
-----Original Message-----
From: Peter Elst [mailto:peter.elst@gmail.com]
Sent: Wednesday, March 28, 2012 10:10 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flash Player premium features
> They did it in a stupid, shoot yourself in the foot (and our feet too)
> way, but they really had little choice. They were hemorrhaging money.
I can't help comment on that - the same November press release that announced restructuring and 750 people laid off celebrated their "record revenue quarter". Adobe as a company is not hemorrhaging money, but particularly the Flex side of the Flash Platform did not fit into their new strategy.
Re: Flash Player premium features
Posted by Peter Elst <pe...@gmail.com>.
> They did it in a stupid, shoot yourself in the foot (and our feet too) way,
> but they really had little choice. They were hemorrhaging money.
I can't help comment on that - the same November press release that
announced restructuring and 750 people laid off celebrated their "record
revenue quarter". Adobe as a company is not hemorrhaging money, but
particularly the Flex side of the Flash Platform did not fit into their new
strategy.
RE: Flash Player premium features
Posted by Mark Fuqua <ma...@availdata.com>.
I currently (and probably for the next few weeks), do all my Flex
development for free...because I am still learning. It is not something I
plan or can do for long...but that's ok, because I can imagine a time in the
very near future when I will be making money from Flex. As much as I enjoy
Flex, I need to make money. Adobe might be exponentially larger than my
tiny little company, but they are no different.
Anything they can do to make money off the Flash platform is fine by me.
Hell, if all us Flex developers had just bought a copy or two of Flash
Builder Premium (the only source of revenue from flex for Adobe), they would
probably still be actively investing in Flex and this mailing list would not
exist.
Adobe quit Flex and Flash for mobile for one reason and one reason
only...they couldn't make enough money to justify the huge expense and they
couldn't imagine a different scenario looking forward.
They did it in a stupid, shoot yourself in the foot (and our feet too) way,
but they really had little choice. They were hemorrhaging money.
Mark
-----Original Message-----
From: Martin Heidegger [mailto:mh@leichtgewicht.at]
Sent: Wednesday, March 28, 2012 9:23 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flash Player premium features
Hi Giorgio,
I honestly don't really care about it. As a web developer I am not getting
Flash projects anyways due to last years marketing and because agencies like
buzz words. As a app developer I do not care of this particular feature as I
will not be affected (rarely a app really needs the fast memory and stage
3d. As a game developer I am/will not be successful enough that this will
affect me, and even if it would: Its software I use. If I earn more than 50k
for a app (after taxes) I guess I wouldn't be greedy, after all I can accept
that some of the success is based on the Flash platform and I have no
problem to reward them for that (if I use Unity then I haven't paid a cent
for other Adobe products).
Anyways: the way how it went down is ugly. Specially that they deprecated
the old avm calls.
Its one thing if you deprecate something that makes problems but something
that is actually
used and useful is uhm: why?? It just annoys people. Makes me wonder
if they really value bad
marketing that much...
So: yeah marketing suicide continues... but who really cares: People that
have no way around .swf will use it like before (my policy is for 6years
already: use flash only if there is no html option).
yours
Martin.
On 28/03/2012 17:57, Giorgio Natili wrote:
> Hi All,
>
> I know that Flex is not related to the gaming but I would love to know
> which is the feeling of the mailing list about this news
> http://www.adobe.com/devnet/flashplayer/articles/premium-features.html.
>
> In my opinion it will be used again against the Flash platform, what
> do you think?
>
> Giorgio Natili
> Twitter + skype: giorgionatili
>
>
>
>
>
>
Re: Flash Player premium features
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hi Giorgio,
I honestly don't really care about it. As a web developer I am not
getting Flash projects
anyways due to last years marketing and because agencies like buzz
words. As a app developer
I do not care of this particular feature as I will not be affected
(rarely a app really needs the
fast memory and stage 3d. As a game developer I am/will not be
successful enough that this
will affect me, and even if it would: Its software I use. If I earn more
than 50k for a app (after taxes)
I guess I wouldn't be greedy, after all I can accept that some of the
success is based on the Flash platform and I have no problem to reward
them for that (if I use
Unity then I haven't paid a cent for other Adobe products).
Anyways: the way how it went down is ugly. Specially that they
deprecated the old avm calls.
Its one thing if you deprecate something that makes problems but
something that is actually
used and useful is uhm: why?? It just annoys people. Makes me wonder
if they really value bad
marketing that much...
So: yeah marketing suicide continues... but who really cares: People
that have no way around .swf
will use it like before (my policy is for 6years already: use flash only
if there is no html option).
yours
Martin.
On 28/03/2012 17:57, Giorgio Natili wrote:
> Hi All,
>
> I know that Flex is not related to the gaming but I would love to know
> which is the feeling of the mailing list about this news
> http://www.adobe.com/devnet/flashplayer/articles/premium-features.html.
>
> In my opinion it will be used again against the Flash platform, what do
> you think?
>
> Giorgio Natili
> Twitter + skype: giorgionatili
>
>
>
>
>
>
Flash Player premium features
Posted by Giorgio Natili <g....@gnstudio.com>.
Hi All,
I know that Flex is not related to the gaming but I would love to know
which is the feeling of the mailing list about this news
http://www.adobe.com/devnet/flashplayer/articles/premium-features.html.
In my opinion it will be used again against the Flash platform, what do
you think?
Giorgio Natili
Twitter + skype: giorgionatili
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Alex Harui <ah...@adobe.com>.
On 3/28/12 11:00 AM, "Om" <bi...@gmail.com> wrote:
>> I hope the solution we come up with will work for Falcon as well.
>>
>>
> We == Adobe?
>
We == Apache Flex
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Om <bi...@gmail.com>.
> I hope the solution we come up with will work for Falcon as well.
>
>
We == Adobe?
I am wondering if there is anything at all that Apache Flex can do in terms
of solving this problem.
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Alex Harui <ah...@adobe.com>.
On 3/28/12 10:41 AM, "Om" <bi...@gmail.com> wrote:
> Does Falcon come with support for CFF Fonts?
> When it is open-sourced, will
> it be gimped in the same way when it comes to fonts?
I hope the solution we come up with will work for Falcon as well.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Om <bi...@gmail.com>.
On Wed, Mar 28, 2012 at 10:20 AM, Alex Harui <ah...@adobe.com> wrote:
>
> On 3/28/12 5:31 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>
> > Yes Martin, I understood the legal problem. I was just wondering what is
> > particular about the code that it cannot be replaced by other (modified)
> > font managers. As you probably know, there are 4 managers currently in
> SDK
> > which can encode fonts using somewhat different techniques, but only one
> > can encode them in a way they fit for the use with the FTE classes. This
> > is, I assume, the one Alex is talking about. So my question was rather:
> >
> > what if we take on of the existing managers and modify it so it will
> > generate DefineFont4 tags - how much of an effort will it require? Or
> maybe
> > the technology itself is patented (I doubt this very much... but you
> never
> > know)?
> >
> I'm still trying to make sure I understand both the technical and legal
> issues. I see specs for CFF and DefineFont4, but there are rumors that the
> conversion is currently done via proprietary algorithms. If we (Apache
> Flex) just write our own, there may be a quality issue.
>
>
Does Falcon come with support for CFF Fonts? When it is open-sourced, will
it be gimped in the same way when it comes to fonts?
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Alex Harui <ah...@adobe.com>.
On 4/4/12 9:30 AM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> As I search about implementing fonts in haXe i stumbled upon this [1]. I
> have to say hxswfml is easier to read than the fontforge source.
An update: Adobe is still investigating what it would take to make a set of
JARs available to Apache.
The fontswf utility is only available in the full Adobe Flex SDK. Someone
would have to have an Adobe license then could create SWFs with fonts in
them that can be embedded into Apache Flex SWFs.
I've been told that DefineFont4 is really just a blog of CFF data, so any
utility that can convert other fonts to CFF has a chance of working.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
As I search about implementing fonts in haXe i stumbled upon this [1]. I
have to say hxswfml is easier to read than the fontforge source.
yours
Martin.
[1] http://code.google.com/p/hxswfml/source/detail?spec=svn118&r=117
<http://code.google.com/p/hxswfml/source/detail?spec=svn118&r=117>
On 30/03/2012 09:37, Dave Fisher wrote:
> On Mar 28, 2012, at 6:05 PM, Left Right wrote:
>
>> Aha... so, as far as I could understand, CFF is different from TTF in that
>> it uses cubic curves for outlines instead of quadratic. Is there anything
>> else that is different?
>> Would this also mean that fonts, originally in OTF (CFF) format can be
>> compiled right away w/o needing to do some [more] complex math to translate
>> outlines fairly? If so, that could be a start, well, at least for people
>> who use CFF for the features built on top of it rather then for it's own
>> qualities (*sigh* which is another interesting paradox of how originally
>> good idea turned into disaster...) could continue using it to some extent.
>> It's also strange that the format exists for almost 10 years, and
>> is standardized under ISO and no opensource libraries exist for using /
>> converting it? Sounds fishy, I'd say...
> FontForge might be a possibility. [1]
>
> It is only offered in source now. I've got to hold onto my old MacOS/X11 version. It uses a revised BSD license which could be checked if the project is interested.
>
> It claims to support CFF. [2]
>
> Regards,
> Dave
>
> [1] http://fontforge.sourceforge.net/
> [2] http://fontforge.sourceforge.net/TrueOpenTables.html
>
>
>
>> Best.
>>
>> Oleg
>
>
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Dave Fisher <da...@comcast.net>.
On Mar 28, 2012, at 6:05 PM, Left Right wrote:
> Aha... so, as far as I could understand, CFF is different from TTF in that
> it uses cubic curves for outlines instead of quadratic. Is there anything
> else that is different?
> Would this also mean that fonts, originally in OTF (CFF) format can be
> compiled right away w/o needing to do some [more] complex math to translate
> outlines fairly? If so, that could be a start, well, at least for people
> who use CFF for the features built on top of it rather then for it's own
> qualities (*sigh* which is another interesting paradox of how originally
> good idea turned into disaster...) could continue using it to some extent.
> It's also strange that the format exists for almost 10 years, and
> is standardized under ISO and no opensource libraries exist for using /
> converting it? Sounds fishy, I'd say...
FontForge might be a possibility. [1]
It is only offered in source now. I've got to hold onto my old MacOS/X11 version. It uses a revised BSD license which could be checked if the project is interested.
It claims to support CFF. [2]
Regards,
Dave
[1] http://fontforge.sourceforge.net/
[2] http://fontforge.sourceforge.net/TrueOpenTables.html
>
> Best.
>
> Oleg
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Left Right <ol...@gmail.com>.
Aha... so, as far as I could understand, CFF is different from TTF in that
it uses cubic curves for outlines instead of quadratic. Is there anything
else that is different?
Would this also mean that fonts, originally in OTF (CFF) format can be
compiled right away w/o needing to do some [more] complex math to translate
outlines fairly? If so, that could be a start, well, at least for people
who use CFF for the features built on top of it rather then for it's own
qualities (*sigh* which is another interesting paradox of how originally
good idea turned into disaster...) could continue using it to some extent.
It's also strange that the format exists for almost 10 years, and
is standardized under ISO and no opensource libraries exist for using /
converting it? Sounds fishy, I'd say...
Best.
Oleg
Re: CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 29/03/2012 02:20, Alex Harui wrote:
> I'm still trying to make sure I understand both the technical and legal
> issues. I see specs for CFF and DefineFont4, but there are rumors that the
> conversion is currently done via proprietary algorithms. If we (Apache
> Flex) just write our own, there may be a quality issue.
Converting <any-font-format> to <otf> is not properly defined, as far as
I know. Also: the various
font formats have different capabilities and not all cases are 100%
clear. That means that any
algorithm will work slightly different. Additionally: If Adobe
"improved" the algorithms to a
a non-straight conversion but flash focused conversion then that's
hidden knowledge (nowhere
documented etc.). I do not see the effort to try to reverse engineer the
algorithm as appropriate.
May the new version be Apache Flexy.
yours
Martin.
CFF Font Embedding (was Re: Here Comes MXMLC!)
Posted by Alex Harui <ah...@adobe.com>.
On 3/28/12 5:31 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> Yes Martin, I understood the legal problem. I was just wondering what is
> particular about the code that it cannot be replaced by other (modified)
> font managers. As you probably know, there are 4 managers currently in SDK
> which can encode fonts using somewhat different techniques, but only one
> can encode them in a way they fit for the use with the FTE classes. This
> is, I assume, the one Alex is talking about. So my question was rather:
>
> what if we take on of the existing managers and modify it so it will
> generate DefineFont4 tags - how much of an effort will it require? Or maybe
> the technology itself is patented (I doubt this very much... but you never
> know)?
>
I'm still trying to make sure I understand both the technical and legal
issues. I see specs for CFF and DefineFont4, but there are rumors that the
conversion is currently done via proprietary algorithms. If we (Apache
Flex) just write our own, there may be a quality issue.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Here Comes MXMLC!
Posted by Left Right <ol...@gmail.com>.
Yes Martin, I understood the legal problem. I was just wondering what is
particular about the code that it cannot be replaced by other (modified)
font managers. As you probably know, there are 4 managers currently in SDK
which can encode fonts using somewhat different techniques, but only one
can encode them in a way they fit for the use with the FTE classes. This
is, I assume, the one Alex is talking about. So my question was rather:
what if we take on of the existing managers and modify it so it will
generate DefineFont4 tags - how much of an effort will it require? Or maybe
the technology itself is patented (I doubt this very much... but you never
know)?
Best.
Oleg
Re: Here Comes MXMLC!
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
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.
yours
Martin.
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
>
Re: Here Comes MXMLC!
Posted by Left Right <ol...@gmail.com>.
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
RE: Testing MXMLC (was Re: Here Comes MXMLC!)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I'm not well-versed on exactly how the compiler folks were doing there testing, but in a tests folder we could not donate, it appeared that there were several small source files, but it appeared that they all came >from Tamarin, so we cannot take them at Apache.
Ah, I bet I know what they were doing.
Take a look here:
https://developer.mozilla.org/En/Tamarin/Tamarin_Acceptance_Testing
and in particular here:
https://developer.mozilla.org/En/Tamarin/Tamarin_Acceptance_Testing/Running_Tamarin_acceptance_tests
They are building with their compiler and running the tamarin acceptance tests. If they pass, it means they generated viable abc for the ActionScript input.
Clever,
Mike
Testing MXMLC (was Re: Here Comes MXMLC!)
Posted by Alex Harui <ah...@adobe.com>.
On 3/28/12 1:41 AM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> On 28/03/2012 15:39, Alex Harui wrote:
>> I'm not quite sure what you meant by test data, but I don't think we
>> have anything to offer at this time.
> Its a compiler
>
> <take source files> mangle them <output binaries>
>
> I'd assume that a test case, for the I/O exists but judging from your
> answer I guess they were made at
> a different level.
I'm not well-versed on exactly how the compiler folks were doing there
testing, but in a tests folder we could not donate, it appeared that there
were several small source files, but it appeared that they all came from
Tamarin, so we cannot take them at Apache.
BTW, is it sufficient to test the compiler simply by
source->compile->verify-output? Should junit be involved somehow?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Here Comes MXMLC!
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 28/03/2012 15:39, Alex Harui wrote:
> I'm not quite sure what you meant by test data, but I don't think we
> have anything to offer at this time.
Its a compiler
<take source files> mangle them <output binaries>
I'd assume that a test case, for the I/O exists but judging from your
answer I guess they were made at
a different level.
yours
Martin.
Re: Here Comes MXMLC!
Posted by Alex Harui <ah...@adobe.com>.
On 3/27/12 11:18 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> Would it be possible to sort out test data at least? Like: sourcefolder
> + expected swf without a test system behind that? Having to start from 0
> is really a tremendous amount of work...
I'm not quite sure what you meant by test data, but I don't think we have
anything to offer at this time.
> That is a problem, possibly a release-breaker. Luckily the ByteCode for
> DefineFont4 seems rather simple - just requires a <font> to OpenType
> converter. FontForge[1] seems to offer conversion mechanisms, its BSD
> licensed and cross platform, worth looking into?!
Yup, worth looking into.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Here Comes MXMLC!
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 28/03/2012 04:04, Alex Harui wrote:
> Today we finally got the last blocking legal issue resolved and are now hunting down executives to sign the appropriate documents to submit the source code for MXMLC to Apache. The final signature has to come from a VP who is on vacation this week, but we are going to try to get him to sign from where ever he is. Yes, there is still some chance of a glitch in the approvals, but it is low probability.
>
> Then, of course, we have to get Apache Infra to do an SVN load of the code with history. But Carol will probably check in code w/o history into her whiteboard
Sounds like a plan!
> There are some things related to this donation that you should be aware of:
>
> 1) We were unable to get clearance for any compiler tests. They were too infested with stuff with incompatible licenses. So, those interested might want to plan out how to verify compiler changes going forward.
Would it be possible to sort out test data at least? Like: sourcefolder
+ expected swf without a test system behind that? Having to start from 0
is really a tremendous amount of work...
> 2) CFF Font Embedding is not being donated. The source code is not under control of the Flex team at Adobe. This means that you won’t be able to compile
> @font-face(“somefile.ttf”); embedAsCFF:true
> For now, you can use the JAR files from a full Adobe Flex release. You can also use the fontswf utility or Adobe CS products to make a SWF with a CFF font in it and embed from there. We will try to figure out a better solution later. We decided not to delay the compiler donation for this issue.
That is a problem, possibly a release-breaker. Luckily the ByteCode for
DefineFont4 seems rather simple - just requires a <font> to OpenType
converter. FontForge[1] seems to offer conversion mechanisms, its BSD
licensed and cross platform, worth looking into?!
yours
Martin.
[1] http://fontforge.sourceforge.net/generate.html