swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swftools-common] pdf2swf and AIR


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

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 <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>


--

___________________________________________________________________

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:                       address@hidden                 business:            address@hidden
website:                    www.megazine3.de
Munich HRB 181251    Geschäftsführer:      Hans J. Nücke      USt-Id:   DE266694113
___________________________________________________________________


reply via email to

[Prev in Thread] Current Thread [Next in Thread]