|From:||Hans J Nuecke|
|Subject:||Re: [Swftools-common] pdf2swf and AIR|
|Date:||Sat, 19 May 2012 00:23:58 +0200|
|User-agent:||Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1|
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?!?
Am 18.05.2012 11:18, schrieb List_Subs:
On Thu, 17 May 2012 23:30:18 +0200 Hans J Nuecke <address@hidden> 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>
|[Prev in Thread]||Current Thread||[Next in Thread]|