On Fri, Dec 5, 2008 at 8:24 AM, Marc-Antoine Ruel <[EMAIL PROTECTED]> wrote: > > As an argument, you could say that isn't it funny activex controls can > override the specified viewport size and even resize itself whenever > it wants while a NPAPI has no control on its viewport?
You can actually do that with NPAPI (I just verified). Call NPN_GetValue for NPNVPluginElementNPObject, then NPN_GetProperty on the result for "style". You can then NPN_SetProperty on that result for "width" and "900px" for example (let me know if you want some sample code). Paul, can this help in making MathML be implementable using NPAPI? The other blockers you mentioned were getting the font/size of surrounding text and accessibility. The latter can be done on your own if you use a windowed plugin, since Windows will just send you the relevant WM messages for accessibility. For getting the font/size, you can walk the DOM in NPAPI just like how you do it in ActiveX. i.e. using NPN_GetValue for NPNVWindowNPObject. > > M-A > > On Fri, Dec 5, 2008 at 10:52 AM, PaulTopping <[EMAIL PROTECTED]> wrote: >> >> I did propose that to the WebKit developer list a few years back but I >> suppose it is time again. Unless things have changed, they seem dead >> set against anything that is not open source. >> >> Paul >> >> On Dec 4, 11:06 pm, Darin Fisher <[EMAIL PROTECTED]> wrote: >>> An extension like that would have to involve hooks into WebKit's rendering >>> pipeline (obviously). That means, that WebKit would first need to support >>> those hooks before we could surface support for loading a binary to >>> implement those hooks. In other words, we have no intention or desire to >>> fork WebKit (beyond using V8 instead of JSC). In fact, we are aggressively >>> working toward being able to use WebKit tip-of-tree source directly from >>> svn.webkit.org without any modifications. This means that you should >>> probably go back and propose / seek changes to WebKit if you wish to see >>> these kinds of extension APIs available to Chrome extensions in the future. >>> I suggested NPAPI because it may be easier / more acceptable by the WebKit >>> developers to add to NPAPI to accomplish what you'd need. >>> -Darin >>> >>> >>> >>> On Tue, Dec 2, 2008 at 12:08 PM, PaulTopping <[EMAIL PROTECTED]> wrote: >>> >>> > Those are interesting ideas. I was assuming you meant using NPAPI in >>> > the traditional way. Your suggestions bear some thought. >>> >>> > To answer your questions about MathPlayer in IE, it is a binary >>> > rendering behavior written in C++. It is not an ActiveX control in the >>> > sense of a control that might be used in a form or in Visual Basic. It >>> > does use and implement COM interfaces as does pretty much everything >>> > that works with IE. >>> >>> > Rendering proceeds as follows. IE asks MathPlayer how much space it >>> > needs on the page. To answer that question, MP has to traverse the >>> > MathML DOM nodes and ask IE about the ambient font, font size, and >>> > column width. Later, IE asks MP to render itself in a device context >>> > passed to it. There is also code to handle mouse clicks and display a >>> > context menu but this is all standard stuff. >>> >>> > On Dec 2, 11:46 am, Aaron Boodman <[EMAIL PROTECTED]> wrote: >>> > > Resending, as I sent the first time from the wrong address. >>> >>> > > > On Tue, Dec 2, 2008 at 8:06 AM, PaulTopping <[EMAIL PROTECTED]> wrote: >>> > > >> This is all very old territory. As far as I know, NPAPI requires that >>> > > >> the amount of space the equation takes up on a page be known in >>> > > >> advance, rather than be calculated at run-time to be dependent on the >>> > > >> MathML content. There is no support for baseline alignment of the >>> > > >> equation with the surrounding text. The rendering can't adapt to the >>> > > >> font and point size of the surrounding text, an absoluter requirement >>> > > >> for math. There is no connection to accessibility. Authors are not >>> > > >> interested in writing separate MathML files. With a typical technical >>> > > >> paper containing hundreds of equations, it very quickly becomes a >>> > > >> nightmare. >>> >>> > > > That isn't how I meant to suggest using NPAPI. And just so you know, >>> > > > I'd be happy to have people building these kind of extensions on top >>> > > > of Chromium's extension system; I'm not trying to shoo you away. I'm >>> > > > just curious to know where NPAPI falls short because it seems like a >>> > > > good way to implement something like this. >>> >>> > > > How I envisioned you might use NPAPI is to have a single script, >>> > > > similar to gears_init.js [1] that you ask authors to embed on their >>> > > > pages. In browsers that natively support MathML, the script does >>> > > > nothing. Otherwise, if it detects your plugin is installed, it creates >>> > > > and embeds it. The script then interacts with the plugin, eventually >>> > > > modifying the DOM of the page. The NPAPI plugin could generate base-64 >>> > > > encoded images which could be embedded by the script using IMG >>> > > > elements with data: URLs. The script could even detect page resizes >>> > > > and font size changes and regenerate the images. >>> >>> > > > In IE, how do you actually render the math content? Is the visible >>> > > > area an Active-X control? Or are you implementing an IE binary >>> > > > behavior to do custom handling of tags? >>> >>> > > > - a >>> >>> > > > [1]http://code.google.com/apis/gears/tools.html-Hide quoted text - >>> >>> > > - Show quoted text -- Hide quoted text - >>> >>> - Show quoted text - >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
