In the Docs you find two different statements within the same page: 1) From the Docs (above the Example) ...Creates an IFrame HTML Element and extends its window and document with MooTools. 2) From the Docs (below the Example) ... An IFrame's window and document will not be extended with MooTools methods.
This said ... which one should be the valid one? My tests do come to the same result as Izzy's .. the IFrame is created but has no MooTensioned methods available. I fiddled around a bit and even injected a small piece of JS into the iframe to "localy" ask for an elements size .. http://jsfiddle.net/5HBq3/14/ failed, too .. document.id() not a function ... Is there an option to toggle the method extension on/off for newly created elements? On 19 Mai, 21:31, Izzy <[email protected]> wrote: > Unfortunately changing which pdf-ing method we use is not optional. > > the service useshttp://www.html-to-pdf.net/(the ExpertPDF) > > it does all the .NET stuff and we already have the service built, the > higher ups are not so interested in rewriting it, even tho it kind of > sucks (b/c it relies on the local version of IE, and on our production > machines, we cant change that without interrupting service, which > we're highly reluctant to do). > > Can anyone help with the original problem of accessing elements inside > an IFrame and measuring them? > > Thanks, > -Izzy > > On May 19, 2:19 pm, Sanford Whiteman <[email protected]> > wrote: > > > > > > > > > Guess you've already eval'd this, but does the HTML-to-PDF *only* > > parse HTML? I'm thinking of abcPDF, which we use -- we were tempted to > > use the HTML-to-PDF "screen shot" because it seemed easier, but it > > also has robust, true PDF generation from (.NET) code. Tried the HTML > > screen shot until we went crazy. Then we just buckled down, created > > PDF templates, learned the object model, and now fetch from the DB > > into the template. We get truly pixel-perfect PDFs now and everyone is > > happier. > > > -- S.
