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
___________________________________________________________________