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]
<mailto:[email protected]> business: [email protected]
<mailto:[email protected]>
website: www.megazine3.de <http://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>
