Re: [OT] Re: Extending Safari
Re: [OT] Re: Extending Safari
- Subject: Re: [OT] Re: Extending Safari
- From: Greg Langmead <email@hidden>
- Date: Wed, 12 Feb 2003 11:43:35 -0800
Thanks for all the detailed responses, Leonard! More follow-ups:
So are you saying that Safari handles an XHTML page where the SVG nodes
are in a special namespace by firing up the Adobe plugin (if it's
installed) to render each such node? That's good news -- maybe I'm way
behind, but I thought you had to have an explicit tag that invoked a
plugin with a mime type, URL of the data, width and height. Or is this
still true and I misunderstood you?
As to SVG being scalable while having a default size, let's examine the
case where the default size of the graphic is smaller than the frame
allocated for the plugin. It would still be true that the plugin frame
parameter sets aside exactly that much real estate in the web page.
The SVG may not necessarily fill that space, but the rest will then
remain empty. I'm interested in having my plugin render inline XML
nodes that are indistinguishable from the surrounding text (mathematics
is my motivating example, but not the only one). This requires that
the plugin actually tell the layout engine how much real estate to set
aside, not the other way around.
I'm not surprised IBehavior is nasty in the way you describe. I don't
have experience with it directly, but I know it lets you ask the layout
engine questions about the ambient font that allow behaviors to adapt
their contents to match.
On Wednesday, February 12, 2003, at 11:23 AM, Leonard Rosenthol wrote:
At 11:00 AM -0800 2/12/03, Greg Langmead wrote:
I have a follow-up about the Adobe SVG viewer Leonard mentioned. The
Adobe plugin is a plugin in the sense that its rectangular area is
specified inside the HTML, and the plugin cannot negotiate a
different size.
Correct.
Is this always good enough for SVG, or should SVG really dictate the
size itself?
It is always good enough for SVG, since the content scales to fit the
"frame". It is no different than if the data filled an entire window
and user resized the window.
I am in fact slightly confused on this point. My mental analogy is
with PICTs, which can be arbitrarily scaled but yet have a notion of
a default size.
SVG is similar - it has a defined size and can be arbitrarily scaled.
Apps that import PICTs usually ask for this size and use it, in
essence letting the PICT decide its rectangle whenever possible.
BUT they still fit that PICT inside of a "frame" - usually an entire
window or other editing environment, or even an actual frame of an
editing environment (Quark, PageMaker, AppleWorks, etc.)
A second point is that SVG should ideally be sprinkled throughout an
XHTML document, not stored in separate files.
Integrated, more so then sprinkled. You could have some number of
SVG "blocks" inside of your XHTML file - but each is somewhat
self-contained.
Does the Adobe plugin only handle the case where a separate URL
pointing to a file with just SVG markup is indicated?
Handling of different namespaces inside of an XHTML stream is up to
the browser (Safari in this case) and not the plugin.
Again, my understanding was that a better implementation would
require tighter integration, where individual nodes of XML could be
passed off to a component.
Define better...
There are advantages and disadvantages to the model you suggest.
There are also ways to accomplish the end goal of better
plugin/browser/data integration w/o the complexity that you suggest.
[snip]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.