Hans, compiling under Linux was easy. One of our team members is trying to compile my "fix" for windows. If successful I will request to my boss that we share it with the community.
On May 18, 2012, at 5:24 PM, "Hans J Nuecke" <[email protected]> wrote: > Hi Chris, > thanks for your feedback; I am a very happy user of swftools and I did not > intend to criticize at all! > The intention was more to backup earlier "requests" ;-) > > I have seen several emails in the past, all reporting difficulties with this > "allowDomain" (or allowInsecureDomain) thing. > > Here my "test environment": > I use pdf2swf to convert PDF files into single SWF pages that then can be > viewed as "interactive (flippable) books". In a dynamic way, i.e. loaded on > request. > With Flashplayer usually everything works fine (besides sometimes problems > with transparency layers). Including links (internal and external ones). > At least until 0.91; with 0.92 we will have to make some adjustments since > something must have been changed regarding handling of links (different topic > ;-). > > For a special project, where an IR camera is used as "touchless device", > connecting via TUIO drivers that convert gestures into mouse events. Using > TCP as communication channel for the AS3 application. > As you know access to local data and parallel network access is not allowed > with Flashplayer (a security thing, sandboxing). > That's why we had to use the AIR framework, which immediately worked with the > actual content (self generated swf animations, jpg images and video files). > > Testing another "book" with swf files converted with pdf2swf resulted not > finishing loads of content and an error with FLASH Builder in Debug mode > (cause "allowDomain" statement). > We made the same experience earlier when we did a quick feasibility study > with AIR on iPad. Besides the allowDomain issue we also had the problem that > Apple does not allow to reload anything with active content. And because even > a stop() is treated as such active content and we need at least that, we put > that project on hold for the time being. > > Based on those experiences and also reading statements of others on this > email list, and seeing comments in different forums, I made the assumption > (I'm not claiming this is 100% verified!) that the option to get rid of that > allowDomain statement could be a help or solution. > > And for a couple of reasons I hesitate to spend time trying to modify sources > and compile the system; I'm personally not experienced in that ;-) > > What kind of examples would you like to see? > I could provide a 4 page PDF, the 4 converted SWF pages, a FLASH projector > file proving those 4 pages work without problems, and an AIR application > that does show the effect of not finishing loading. > I even could send you the complete FLASH Builder project with all sources if > you (or anybody else) want to debug at source level. Just let me know! > > I am pretty sure that building a test version with either allowDomain > deleted, or the option to switch it off or to capture the error with a > try-catch bracket, will be straight forward and "easy" for one of the > developers. If it helps I am prepared to test such versions. Just an idea and > proposal... > > If it is just me and 1 or 2 others showing interest in such a solution, I > understand that this has low priority. > And if anybody can show me/us how to build swf pages that can be dynamically > loaded with AIR - I would love to know that! > JPG images, video and self built swf animations work like a charm with AIR... > > Hopefully this explains my "request" a bit better?!? > > Regards > Hans > > > Am 18.05.2012 11:18, schrieb List_Subs: >> >> On Thu, 17 May 2012 23:30:18 +0200 >> Hans J Nuecke <[email protected]> wrote: >> >>> For future use of pdf2swf for AIR applications it would be necessary >>> to have the option to get rid of the *allowDomain* command. >> [ .. and not forgetting 'allowInsecureDomain' ] >> >>> Otherwise no converted PDF file could be used with an AIR application. >> Isn't that a bit of a wild claim ( possibly hot Air ;o) )? Have all the >> bases been fully checked? >> >>> One option could be a switch, as suggested by Andrew. >>> Another option could be a "try-catch" block, coded directly into the >>> AS3 code generated by swftools. Which would handle both the >>> Flashplayer/network and AIR/local use case automatically (if my >>> assumption is right). >> Ok so it was only a quick skim, however the documentation out there >> seems >> to indicate that such a thing should be unncessary. >> >> How about some concrete examples conclusively proving the case for, >> rather >> than all this 'my application doesn't work, and therefore swftools is to >> blame', rather than the actual method of coding chosen'? ;o) >> >> >>> ImO this should be realized by the developers. They know best how to >>> create such AS3 binary code; and can build the Binaries more easily >>> (assumption based on my problems trying to compile ;-) >> They do? >> >>> Matthias, what do you think about this? >>> Do you have other ideas/suggestions/a work around? >> As stated, how about some examples before going down that particular >> path? >> >> Chris. >> >> [ ..someone coming at this completely cold, in not having Air installed ] >> >> >> >> >> >> >> --------------- >> SWFTools-common is a self-managed list. To subscribe/unsubscribe, or amend >> an existing subscription, please kindly point your favourite web browser >> at:<http://lists.nongnu.org/mailman/listinfo/swftools-common> >> > > -- > ___________________________________________________________________ > > Hans J. Nuecke / Gorch-Fock-Str. 6 • 81827 Muenchen • Germany / VservU GmbH > Home: +49 (89) 45344858 office: > +49 (89) 43906 707 > mobile: +49 (173) 5392957 Skype: > hnuecke > private: [email protected] business: > [email protected] > website: www.megazine3.de > Munich HRB 181251 Geschäftsführer: Hans J. Nücke USt-Id: > DE266694113 > ___________________________________________________________________ > --------------- > SWFTools-common is a self-managed list. To subscribe/unsubscribe, or amend an > existing subscription, please kindly point your favourite web browser > at:<http://lists.nongnu.org/mailman/listinfo/swftools-common>
--------------- SWFTools-common is a self-managed list. To subscribe/unsubscribe, or amend an existing subscription, please kindly point your favourite web browser at:<http://lists.nongnu.org/mailman/listinfo/swftools-common>
